On 4/22/2012 3:43 PM, 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.
There is no ambiguity about the meaning of 'is' in Python. It is always
well-defined. So the suggestion is a nullity. The equivalent function
form in Python is
def is(a, b):
return id(a) == id(b)
It is important here that the expressions corresponding to both a and b
are evaluated and the resulting objects bound to names a and b first and
that they are not unbound and possibly destroyed until after the return
is computed.
The inline form of the function call is
__tem1__ = a
__tem2__ = b
result = id(a) == id(b)
del __tem1__, __tem2__
Leaving out the temporaries is a (common) mistake, but it changes the
meaning.
The id(object) function is also well-defined: it is the immutable
internal integer id assigned to the object upon creation by the
interpreter. The interpreter may use that internal number to associate
names with object and to find objects given a name, but how it does do
is up to the interpreter. In any case, the return value is always the
same for a given object. That is the meaning of 'well-defined'.
Python is an object-based language. Its objects have identity, class,
and value. Most functions in Python are *value* functions. The result is
independent of object id. However, id is an *object* function. It is, in
fact, the basic object function. Class and value can change for some
objects, but identity never does. Identity is independent of class and
value and not predictable from them.
I believe you are confusing 'unpredictable from other, uncorrelated
object attributes' with 'ill-defined'.
If you want 'ill-defined', consider the other comparison operators,
which can be redefined in user subclasses. For such comparisons, a op b
may not be the same as b op a. The use of 'is' in production code is to
be a predictable comparison operator. That way, we can write 'if a is
None:' rather than having to write 'if None is a:' to ensure getting the
expected and desired result.
>>> a = 256
>>> b = 256
>>> a is b
True # this is an expected result
'Expected' is in the mind of the designer or beholder.
>>> a = 257
>>> b = 257
>>> a is b
False
The other use of 'is' and 'id' is to reveal and test implementation details.
Operator "is" should be be an error between immutables
unless one is a built-in constant.
The CPython-specific part of the Python test suite has test like the
above to test such implementation details. Do you really want to disable
that and make it impossible ;-?
"True" and "False" should be made hard constants, like "None".
The developers agree, and did exactly this about 3 years ago.
You can't assign to None, but you can assign to True, usually with
unwanted results.
Not any more, except in 2.x, for back compatibility.
It's not clear
It is completely clear and has been discussed here many times.
why True and False weren't locked down when None was.
Are you really unaware that before False and True were added officially,
many people routinely wrote in their code:
False, True = 0, 1
and that locking the names, when it was done in 3.0, broke such code?
And that is was not done earlier to avoid breaking code earlier, in
accordance with the general policy to mostly avoid such breakage?
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
