On 4/22/2012 3:17 PM, John Roth wrote:
On Sunday, April 22, 2012 1:43:36 PM UTC-6, John Nagle wrote:
On 4/20/2012 9:34 PM, john.tant...@gmail.com wrote:
On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
I believe it says somewhere in the Python docs that it's
undefined and implementation-dependent whether two identical
expressions have the same identity when the result of each is
immutable
Bad design. Where "is" is ill-defined, it should raise
ValueError.
A worse example, one which is very implementation-dependent:
http://stackoverflow.com/questions/306313/python-is-operator-behaves-unexpectedly-with-integers
a = 256
b = 256 a is b
True # this is an expected result
a = 257 b = 257 a is b
False
Operator "is" should be be an error between immutables unless one
is a built-in constant. ("True" and "False" should be made hard
constants, like "None". You can't assign to None, but you can
assign to True, usually with unwanted results. It's not clear why
True and False weren't locked down when None was.)
John Nagle
Three points. First, since there's no obvious way of telling whether
an arbitrary user-created object is immutable, trying to make "is"
fail in that case would be a major change to the language.
If a program fails because such a comparison becomes invalid, it
was broken anyway.
The idea was borrowed from LISP, which has both "eq" (pointer
equality) and and "equals" (compared equality). It made somewhat
more sense in the early days of LISP, when the underlying
representation of everything was well defined.
Second: the definition of "is" states that it determines whether two
objects are the same object; this has nothing to do with mutability
or immutability.
The id([]) == id([]) thing is a place where cPython's implementation
is showing through. It won't work that way in any implementation that
uses garbage collection and object compaction. I think Jython does it
that way, I'm not sure about either IronPython or PyPy.
That represents a flaw in the language design - the unexpected
exposure of an implementation dependency.
Third: True and False are reserved names and cannot be assigned to in
the 3.x series. They weren't locked down in the 2.x series when they
were introduced because of backward compatibility.
That's one of the standard language designer fuckups. Somebody
starts out thinking that 0 and 1 don't have to be distinguished from
False and True. When they discover that they do, the backwards
compatibility sucks. C still suffers from this.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
