Dlaczego dokumentacja niektórych języków mówi „odpowiednik”, a nie „jest”?

Dlaczego w dokumentacji niektórych języków jest napisane „odpowiednik” zamiast „jest”?

Na przykład, mówią Python Docs

itertools.chain(*iterables)

...

Odpowiednik :

def chain(*iterables):
    # chain('ABC', 'DEF') --> A B C D E F
    for it in iterables:
        for element in it:
            yield element

Lub to odwołanie do C ++ nafind_if :

Zachowanie tego szablonu funkcji jest równoważne z:

template<class InputIterator, class UnaryPredicate>
  InputIterator find_if (InputIterator first, InputIterator last, UnaryPredicate pred)
{
  while (first!=last) {
    if (pred(*first)) return first;
    ++first;
  }
  return last;
}

Jeśli to nie jest prawdziwy kod, czy nie mogą go opublikować? A jeśli jest to rzeczywisty kod, dlaczego muszą powiedzieć, że to „ekwiwalent”, a nie po prostu „jest”?

Ponieważ zwykli pisarze nie chcą faktycznie potwierdzać implementacji. Chcą zdefiniować, co robi , ale niekoniecznie jak to robi. Na przykład, jeśli spojrzysz na wersję GNU C ++find_if , zobaczysz, że implementacja różni się nieco od tego, co dajesz, który jest oparty na standardzie C ++:

template<typename _InputIterator, typename _Predicate>
inline _InputIterator
__find_if(_InputIterator __first, _InputIterator __last,
    _Predicate __pred, input_iterator_tag)
{
    while (__first != __last && !bool(__pred(*__first)))
     ++__first;
       return __first;
}

Jest to funkcjonalnie równoważne z tym, co ma standard, ale nie dokładnie takie samo. Daje to autorom kompilatorów elastyczność. Może być lepszy sposób na zrobienie tego dla konkretnej platformy. Implementator może chcieć użyć innego stylu kodowania.

Jest to szczególnie prawdziwe w przypadku języków skryptowych takich jak Python, ponieważ implementator może zdecydować się na implementację w zupełnie innym języku ze względu na wydajność. Ktoś implementujący python może na przykład pisaćitertools.chain(*iterables) w C ++. Jest to całkowicie w porządku, jeśli standard mówi „ekwiwalent”, o ile kod robi to samo co podany python. Jeśli zamiast tego standard mówi „jest”, wówczas implementatorzy będą musieli albo wdrożyć w tym języku, albo nie spełnić standardu.

W podsumowaniu:

1. Ponieważ nie chcą uniemożliwić implementacji pisania lepszego kodu niż podany standard
2. Ponieważ nie chcą uniemożliwić implementacji użycia zupełnie innego języka, aby poprawić wydajność