Perché la documentazione in alcune lingue dice "equivalente a" piuttosto che "è"?

itertools.chain(*iterables)

...

Equivalente a:

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

O questo riferimento C ++ su find_if:

Il comportamento di questo modello di funzione è equivalente a:

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;
}

Se questo non è il vero codice, non possono pubblicarlo? E se è il codice attuale, perché devono dire che è "equivalente" piuttosto che semplicemente "è"?

— Jon McClung
fonte

Nota che ciò che vedi nonfind_if è "la" documentazione per C ++. Se lo fosse, il cast (che vedi nella risposta sotto) sarebbe sbagliato. bool

— Mehrdad,

Nel caso di Python se cerchi il codice sorgente troverai che chainè implementato direttamente in C, quindi è "equivalente" a quel codice Python perché produce lo stesso risultato, ma evita un po 'di sovraccarico nell'interpretare che bytecode.

— Bakuriu,

@Mehrdad Sono consapevole che non è la documentazione ufficiale, è solo la risorsa che ho trovato più utile per scoprire i dettagli del C ++

— Jon McClung,

Sarebbero costretti a usare qualsiasi approccio stabilito nello standard, anche se fosse disponibile uno significativamente migliore.

— Kevin,

Perché gli scrittori standard non vogliono davvero affermare un'implementazione. Vogliono definire cosa fa , ma non necessariamente come lo fa. Quindi, ad esempio, se guardi la versione GNU C ++ difind_if , vedrai che l'implementazione è leggermente diversa da quella che dai, che si basa sullo standard 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;
}

Questo è funzionalmente equivalente a quello che ha lo standard, ma non è esattamente lo stesso. Ciò offre flessibilità agli scrittori del compilatore. Potrebbe esserci un modo migliore per farlo per una particolare piattaforma. L'implementatore potrebbe voler utilizzare un diverso stile di codifica.

Ciò è particolarmente vero per i linguaggi di scripting come Python in quanto l'implementatore può decidere di implementare in un linguaggio completamente diverso per motivi di prestazioni. Qualcuno che implementa Python può, ad esempio, scrivere itertools.chain(*iterables)in C ++. Questo va perfettamente bene se lo standard dice "equivalente a" fintanto che il codice fa lo stesso del pitone fornito. Se invece lo standard dicesse "è", gli implementatori sarebbero tenuti a implementare in quella lingua o non soddisfare lo standard.

In sintesi:

Perché non vogliono impedire a un'implementazione di scrivere codice migliore rispetto allo standard fornito
Perché non vogliono impedire a un'implementazione di utilizzare un linguaggio completamente diverso, per migliorare le prestazioni

— Gort il robot
fonte

Grazie per la risposta illuminante! Sospettavo che la risposta fosse qualcosa del genere.

— Jon McClung,

@lerenard, potresti trovare ancora più illuminante leggere la piena implementazione di find_if dal link di Steven. (Quello che ha lì è davvero solo un estratto.)

— Winston Ewert,

@WinstonEwert, purtroppo non sono del tutto a livello di comprensione del codice come quello, ma l'uso liberale di caratteri di sottolineatura è sicuramente un punto di interesse!

— Jon McClung,

@lerenard: Questi caratteri di sottolineatura principali aggiuntivi sono presenti in modo tale che gli interni della libreria standard non interferiscano con il codice che potresti scrivere (i nomi con caratteri di sottolineatura principali doppi sono riservati all'uso da parte del compilatore / scrittori di librerie standard).

— Bart van Ingen Schenau,

Bene, in C e C ++, c'è sempre la regola as-if, quindi anche se lo standard detto è invece che equivalente, l'implementazione effettiva potrebbe differire.

— Deduplicatore,