Raymond Hettinger added the comment:
+1 for "approximately equivalent". The "conceptually equivalent" wording
raises more questions in my mind than it answers.
What we're really trying to say here is that for typically symmetric operations
such as __eq__(), an implementation is free to use either a==b or b==a. The
choice usually doesn't matter, but can be revealed by a clever user.
Pretty all of the pure python equivalents in the docs are only approximate
equivalents. 1) Tracebacks are different. 2) Timing of exceptions can be
different (C functions tend to check arguments before the body of the function
and pure python code tends to check when the argument is used). 3)
Thread-safety may be different (C datatypes have to work hard to prevent
segfaulting when a container mutates in the middle of a call, but in pure
python code that tends to be too expensive and the consequences don't result in
a segfault). 4) The internal algorithms may be different.
With respect to 4, we really do want to preserve implementation freedom.
Otherwise, it would have been impossible to switch to the timsort algorithm or
for set intersection to decide to iterate over the smaller input set. Another
reason that implementation freedom is important is that what is fast, clear,
and convenient in one implementation is may by slow, obscure, and difficult in
another.
Lastly, the primary purpose of the pure python approximate equivalents in the
docs is to help people get a high level understanding of what is going on. If
we were to modify the pure python code to be an exact equivalent, it would 1)
tend to over-specify the implementation resulting in unnecessary rigidity and
2) it would tend to be more obscure, defeating our goal of making the docs more
clear.
Perhaps, there should be a general FAQ entry to this effect. The approximate
pure python equivalents should be read loosely with the goal of understanding
overall functionality and not be interpreted as exact drop in replacements (the
PyPy folks can attest that exact drop-in replacements tend to be much more
difficult than you might guess).
The FAQ should also mention that in order to make even simple examples of pure
python code possible, there needs to be generous reading of the code the
precludes the uncommon, exotic, or diabolical contortions that the language is
capable of doing. For example, after "b = a", there a values that cause all of
these assertions to fail "assert a==b; assert b==a; assert a==b;". For another
example, after "s = {a, a}", there are values than can cause these to fail
"assert a in s; assert len(s) == 1".
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27605>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
