On 4/27/12 12:07 AM, Paul Rubin wrote:
Nobody<nob...@nowhere.com> writes:
All practical languages have some implementation-defined behaviour, often
far more problematic than Python's.
The usual reason for accepting implementation-defined behavior is to
enable low-level efficiency hacks written for specific machines. C and
C++ are used for that sort of purpose, so they leave many things
implementation-defined. Python doesn't have the same goals and should
leave less up to the implementation. Java, Ada, Standard ML, etc. all
try to eliminate implementation-defined behavior in the language much
more than Python does. I don't have any idea why you consider that to
be "throwing the baby out with the bath water".
I think there are two implementation-defined behaviors that are being discussed
in this thread. One is that some immutable objects like the empty tuple may be
interned such that all instances of them are the same object and have the same
identity. This is allowed for efficiency reasons. CPython has used this freedom
to good effect. The optimization is not theoretical.
The other is that identities may be reused by different objects that do no
coexist at the same time. This is to permit implementations where the ID is the
address of the object in memory, like CPython. But other implementations with
different memory models (including ones where "address in memory" doesn't make
any sense) may forbid reuse of IDs. This allows alternative implementations like
Jython and IronPython.
There are specific, deliberate, practical consequences of those two
implementation-defined behaviors. These are the babies that you would be
throwing out.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
