why () is () and [] is [] work in other way?

[Robert Kern]

On 4/27/12 12:07 AM, Paul Rubin wrote:
> Nobody<nobody at 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