Mailing List Archive: Python: Python

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

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

dmitrey15 at gmail

Apr 20, 2012, 12:10 PM

Post #1 of 142 (1279 views)
Permalink

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

I have spent some time searching for a bug in my code, it was due to
different work of "is" with () and []:
>>> () is ()
True
>>> [] is []
False

(Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] )

Is this what it should be or maybe yielding unified result is better?
D.
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 20, 2012, 12:21 PM

Post #2 of 142 (1222 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sat, Apr 21, 2012 at 5:10 AM, dmitrey <dmitrey15 [at] gmail> wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True
>>>> [] is []
> False

Okay, let's take a step back. What do you expect "is" to be doing? It
doesn't check for equality.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

robert.kern at gmail

Apr 20, 2012, 12:26 PM

Post #3 of 142 (1228 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 4/20/12 8:10 PM, dmitrey wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True

The empty tuple is unique, immutable, and common so the Python runtime optimizes
this by reusing the same object, much like small integers are interned. This is
not something your code should rely on, though.

>>>> [] is []
> False

Empty lists are mutable and may be modified differently, so they cannot be the
same object. Every time you use an empty list literal, it must create a new object.

> (Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?

If your code is relying on the difference, or a lack of one, it's buggy.

--
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

sg552 at hotmail

Apr 20, 2012, 12:34 PM

Post #4 of 142 (1223 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 20/04/2012 20:10, dmitrey wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True
>>>> [] is []
> False
>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?
> D.

The reason that "[] is []" evaluates to false is because lists are
mutable and each expression "[]" evaluates to a different object.
Therefore you can change one without changing the other:

>>> a, b = [], []
>>> a.append(None)
>>> a
[None]
>>> b
[]

On the other hand tuples are immutable, so there's no danger in having
each literal () evaluate to the same object - since you can't change a
tuple but only replace a reference to a tuple with a reference to
another tuple, there's no need to have the two "()"s in something like

>>> a, b = (), ()

evaluate to different objects, since there is no danger that one can
affect the value of b by doing stuff to a.

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, though I can't find the
quotation right now. If my recollection is correct then you probably
shouldn't rely on something like "() is ()" giving the same answer
across platforms.

--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix
--
http://mail.python.org/mailman/listinfo/python-list

alain at dpt-info

Apr 20, 2012, 12:37 PM

Post #5 of 142 (1223 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

dmitrey <dmitrey15 [at] gmail> writes:

> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True
>>>> [] is []
> False
>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?

Tuples are immutable, while lists are not. Because tuples are immutable,
there is no point in having several empty tuples: one value is enough,
and "is" recognizes this. Lists are different, they can change "value"
(contents), and several names can be bound to the same list (in other
words, you can have side-effects on a list). With:

a = []
b = a
a.append(42)
print b

you get [42]. If instead you do:

a = []
b = []
a.append(42)
print b

you get the expected []. I.e., you need several distinct empty lists,
to make sure they can change value independently.

(In case you wonder: lists in Python are not linked lists of cons-cells,
they are more monolithic structures, and two lists cannot share a common
tail.)

-- Alain.
--
http://mail.python.org/mailman/listinfo/python-list

roy at panix

Apr 20, 2012, 5:01 PM

Post #6 of 142 (1218 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

In article <877gxajit0.fsf [at] dpt-info>,
Alain Ketterlin <alain [at] dpt-info> wrote:

> Tuples are immutable, while lists are not.

If you really want to have fun, consider this classic paradox:

>>> [] is []
False
>>> id([]) == id([])
True
--
http://mail.python.org/mailman/listinfo/python-list

sg552 at hotmail

Apr 20, 2012, 8:25 PM

Post #7 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 21/04/2012 01:01, Roy Smith wrote:
> In article<877gxajit0.fsf [at] dpt-info>,
> Alain Ketterlin<alain [at] dpt-info> wrote:
>
>> Tuples are immutable, while lists are not.
>
> If you really want to have fun, consider this classic paradox:
>
>>>> [] is []
> False
>>>> id([]) == id([])
> True

Huh. This is not what I would have expected. What gives?

--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix
--
http://mail.python.org/mailman/listinfo/python-list

research at johnohagan

Apr 20, 2012, 9:04 PM

Post #8 of 142 (1218 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sat, 21 Apr 2012 04:25:36 +0100
Rotwang <sg552 [at] hotmail> wrote:

> On 21/04/2012 01:01, Roy Smith wrote:
> > In article<877gxajit0.fsf [at] dpt-info>,
> > Alain Ketterlin<alain [at] dpt-info> wrote:
> >
> >> Tuples are immutable, while lists are not.
> >
> > If you really want to have fun, consider this classic paradox:
> >
> >>>> [] is []
> > False
> >>>> id([]) == id([])
> > True
>
> Huh. This is not what I would have expected. What gives?
>

I'm just guessing here, but as id is "is guaranteed to be unique among
simultaneously existing objects", the list literals on each side of the
comparison do not simultaneously exist; presumably the first one is created,
id'ed, then garbage collected (as it is not named), then the other one is
created and gets the same id just freed up by the first one.

OTOH, "is" hangs on to both objects in order to compare them.

c.f.:

>>> l, m = [], []
>>> id(l) == id(m)
False

Is that right?

--
John
--
http://mail.python.org/mailman/listinfo/python-list

d at davea

Apr 20, 2012, 9:32 PM

Post #9 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 04/20/2012 11:25 PM, Rotwang wrote:
> On 21/04/2012 01:01, Roy Smith wrote:
>> In article<877gxajit0.fsf [at] dpt-info>,
>> Alain Ketterlin<alain [at] dpt-info> wrote:
>>
>>> Tuples are immutable, while lists are not.
>>
>> If you really want to have fun, consider this classic paradox:
>>
>>>>> [] is []
>> False
>>>>> id([]) == id([])
>> True
>
> Huh. This is not what I would have expected. What gives?
>

It'd be easier to respond if you would say what's confusing to you about
that result. The first is exactly what I'd expect, and the second is
implementation dependent.

[] is [] produces two independent lists, then compares their ID, then
discards them. So of course they must be different.

id([]) prepares a list object and figures out its id. Then discards the
object. You do it a second time, and you *might* get a new object with
the same id. After all, the first one is gone now, so there's no harm
in re-using the id. In particular, the CPython implementation currently
uses the address of the object as the ID, so if the memory is available,
the next allocation just might get the same memory.

Remember that the only guarantee on id() is that it won't assign the
same number to two objects that exist at the same time. Once an object
is gone, its ID may be reused right away, or after a while, or never.

--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

john.tantalo at gmail

Apr 20, 2012, 9:34 PM

Post #10 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

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

I was curious where that might be on my system, and found the disagreement with the ((),) case and up.

(Python 2.7.1, Darwin 11.3.0, GCC 4.2.1)
--
http://mail.python.org/mailman/listinfo/python-list

news at blinne

Apr 21, 2012, 1:46 AM

Post #11 of 142 (1218 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

Am 21.04.2012 05:25, schrieb Rotwang:
> On 21/04/2012 01:01, Roy Smith wrote:
>> In article<877gxajit0.fsf [at] dpt-info>,
>> Alain Ketterlin<alain [at] dpt-info> wrote:
>>
>>> Tuples are immutable, while lists are not.
>>
>> If you really want to have fun, consider this classic paradox:
>>
>>>>> [] is []
>> False
>>>>> id([]) == id([])
>> True
>
> Huh. This is not what I would have expected. What gives?

This happens only because the first [] gets destroyed after evaluation
of id([]). The second [] then by accident gets the same id as the first
one had.

>>> a = []
>>> b = []
>>> id(a) == id(b)
False

Greetings
--
http://mail.python.org/mailman/listinfo/python-list

storchaka at gmail

Apr 21, 2012, 2:13 AM

Post #12 of 142 (1218 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

>>>> [] is []
> False
>>>> id([]) == id([])
> True

>>> id([1]) == id([2])
True

;)

--
http://mail.python.org/mailman/listinfo/python-list

sg552 at hotmail

Apr 21, 2012, 5:14 AM

Post #13 of 142 (1216 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 21/04/2012 09:46, Alexander Blinne wrote:
> Am 21.04.2012 05:25, schrieb Rotwang:
>> On 21/04/2012 01:01, Roy Smith wrote:
>>> In article<877gxajit0.fsf [at] dpt-info>,
>>> Alain Ketterlin<alain [at] dpt-info> wrote:
>>>
>>>> Tuples are immutable, while lists are not.
>>>
>>> If you really want to have fun, consider this classic paradox:
>>>
>>>>>> [] is []
>>> False
>>>>>> id([]) == id([])
>>> True
>>
>> Huh. This is not what I would have expected. What gives?
>
> This happens only because the first [] gets destroyed after evaluation
> of id([]). The second [] then by accident gets the same id as the first
> one had.

Thanks.

--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix
--
http://mail.python.org/mailman/listinfo/python-list

g.starck at gmail

Apr 21, 2012, 5:51 AM

Post #14 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

Le samedi 21 avril 2012 10:46:39 UTC+2, Alexander Blinne a �crit�:
> Am 21.04.2012 05:25, schrieb Rotwang:
>
> This happens only because the first [] gets destroyed after evaluation
> of id([]). The second [] then by accident gets the same id as the first
> one had.
>
> >>> a = []
> >>> b = []
> >>> id(a) == id(b)
> False
>
> Greetings

Hi,

I played (python3.2) a bit on that and :

case 1) Ok to me (right hand side is a tuple, whose elements are evaluated one per one and have same effect as your explanation (first [] is destroyed right before the second one is created) :

>>> x, y = id([]), id([])
>>> x == y
True
>>>

case 2) also ok to me:

>>> x = id([]) ; y = id([])
>>> x == y
True
>>>

case 3) NOT ok to me :

>>> x = id([])
>>> y = id([])
>>> x == y
False
>>>

case 4) ok to me :

>>> def f():
x = id([])
y = id([])
return x == y

>>> f()
True
>>>

I'd have thought that cases 2&3 are totally, while 3&4 nearly, syntactically equal and that case 3 is the incorrect result..

how would you explain case 3 vs cases 2 and 4 ??

regards,

gs.

--
http://mail.python.org/mailman/listinfo/python-list

Bernd.Nawothnig at t-online

Apr 21, 2012, 6:02 AM

Post #15 of 142 (1216 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 2012-04-20, dmitrey wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True

You should better not rely on that result. I would consider it to be
an implementation detail. I may be wrong, but would an implementation
that results in

() is () ==> False

be correct or is the result True really demanded by the language
specification?

>>>> [] is []
> False

Same for that.

>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?

See above.

Bernd

--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
--
http://mail.python.org/mailman/listinfo/python-list

d at davea

Apr 21, 2012, 6:21 AM

Post #16 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 04/21/2012 09:02 AM, Bernd Nawothnig wrote:
> On 2012-04-20, dmitrey wrote:
>> I have spent some time searching for a bug in my code, it was due to
>> different work of "is" with () and []:
>>>>> () is ()
>> True
> You should better not rely on that result. I would consider it to be
> an implementation detail. I may be wrong, but would an implementation
> that results in
>
> () is () ==> False
>
> be correct or is the result True really demanded by the language
> specification?

You're correct, the behavior is undefined. An implementation may happen
to produce either True or False.

>>>>> [] is []
>> False
> Same for that.

Here I have to disagree. If an implementation reused the list object
for two simultaneously-existing instances, it would violate first
principles.

The distinction is simply that () is immutable, so the implementation
*may* choose to reuse the same one.

--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 21, 2012, 8:03 AM

Post #17 of 142 (1216 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sat, Apr 21, 2012 at 10:51 PM, gst <g.starck [at] gmail> wrote:
> case 2) also ok to me:
>
>>>> x = id([]) ; y = id([])
>>>> x == y
> True
>>>>
>
>
> case 3) NOT ok to me :
>
>>>> x = id([])
>>>> y = id([])
>>>> x == y
> False
>>>>

The fact that ids get reused at all is an implementation detail ONLY.
In CPython, id() returns the object's memory address, but in other
Python implementations, it returns something else (one (Jython??)
returns a sequential number, never reused).

Here's my take on the difference here. You did all of these in a
single session, so by the time you got to case 3, x already contained
a value (the previous integer). The allocation and deallocation of
integer objects created your different behavior. I tried these from
command-line Python (3.2 on Windows, fwiw), restarting the interpreter
between, and got consistent results.

The main thing to know, though, is that the id MAY be reused once the
object is destroyed, but any reuse should be considered utterly
coincidental. A Python could be completely compliant with an id
implementation in which object type gets encoded into it somehow, but
programs written to make use of that information would be just as
vulnerable as those making use of reuse.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Apr 21, 2012, 9:17 AM

Post #18 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 4/21/2012 9:02 AM, Bernd Nawothnig wrote:

> You should better not rely on that result. I would consider it to be
> an implementation detail. I may be wrong, but would an implementation
> that results in
>
> () is () ==> False
>
> be correct or is the result True really demanded by the language
> specification?

To make sure that the result is not due to ref counting garbage
collection in the middle of the expression, one must test like so:
>>> a=()
>>> b=()
>>> a is b
True

This is explicitly an implementation detail, something that *may* be
done. I am not sure if the above has always been the case for CPython.
CPython's set of pre-built ints has been expended. I think string
interning has also changed.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

d at davea

Apr 21, 2012, 12:43 PM

Post #19 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 04/21/2012 09:48 AM, Bernd Nawothnig wrote:
> On Sat, Apr 21, 2012 at 09:21:50AM -0400, Dave Angel wrote:
>>>>>>> [] is []
>>>> False
>>> Same for that.
>>
>> Here I have to disagree. If an implementation reused the list object
>> for two simultaneously-existing instances, it would violate first
>> principles.
>
> Hm.
>
> Even if there is no chance to reach any of these two lists after the
> comparison because *no* references to them exist and both *must* be
> identical because they are both noted as the same literals?
>
> If any references exist, no question, that is pretty clear and
> understandable. But in that special case?
>

You forgot to CC the list on your two messages to me.

Clearly, False has to be a valid return result. So I assume your
question is why shouldn't an implementation be permitted to return True,
in other words why couldn't it be ambiguous, like the immutable case.

Why would you (a hypothetical compiler writer) write an optimizer to
look for such a special case like this, when the code would probably
never appear in a real program, and certainly not in a performance
critical portion of one.

And if you did write one, why would you have it produce a different
result than the non-optimized version? Why not have it return 42 if
that's the goal?

--

DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Bernd.Nawothnig at t-online

Apr 21, 2012, 2:15 PM

Post #20 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sat, Apr 21, 2012 at 03:43:03PM -0400, Dave Angel wrote:
> On 04/21/2012 09:48 AM, Bernd Nawothnig wrote:
> > On Sat, Apr 21, 2012 at 09:21:50AM -0400, Dave Angel wrote:
> >>>>>>> [] is []
> >>>> False
> >>> Same for that.
> >>
> >> Here I have to disagree. If an implementation reused the list object
> >> for two simultaneously-existing instances, it would violate first
> >> principles.
> >
> > Hm.
> >
> > Even if there is no chance to reach any of these two lists after the
> > comparison because *no* references to them exist and both *must* be
> > identical because they are both noted as the same literals?
> >
> > If any references exist, no question, that is pretty clear and
> > understandable. But in that special case?
> >
>
> You forgot to CC the list on your two messages to me.

Sorry, I'm reading the list via usenet gateway. Hopefully it works now.

> Clearly, False has to be a valid return result. So I assume your
> question is why shouldn't an implementation be permitted to return True,
> in other words why couldn't it be ambiguous, like the immutable case.

Yes.

> Why would you (a hypothetical compiler writer) write an optimizer to
> look for such a special case like this, when the code would probably
> never appear in a real program, and certainly not in a performance
> critical portion of one.
> And if you did write one, why would you have it produce a different
> result than the non-optimized version? Why not have it return 42 if
> that's the goal?

My original statement was: don't rely on such behaviour, it is an
implementation detail.

Your argument above was: it would violate first principles. And I still don't
see that point. The comparison [] is [] maybe totally useless, of course, but
which first principle would be violated by a compiler that lets that
expression evaluate to True?

Where can I read that the result *must* be False?

Otherwise it is simply an ambigious and not clearly defined expression like

() is ()

Bernd
--
http://mail.python.org/mailman/listinfo/python-list

robert.kern at gmail

Apr 21, 2012, 2:54 PM

Post #21 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 4/21/12 10:15 PM, Bernd Nawothnig wrote:

> Your argument above was: it would violate first principles. And I still don't
> see that point. The comparison [] is [] maybe totally useless, of course, but
> which first principle would be violated by a compiler that lets that
> expression evaluate to True?
>
> Where can I read that the result *must* be False?

http://docs.python.org/reference/expressions.html#list-displays

"A list display yields a new list object."

--
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

steve+comp.lang.python at pearwood

Apr 21, 2012, 8:14 PM

Post #22 of 142 (1216 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sat, 21 Apr 2012 15:02:00 +0200, Bernd Nawothnig wrote:

> On 2012-04-20, dmitrey wrote:
>> I have spent some time searching for a bug in my code, it was due to
>> different work of "is" with () and []:
>>>>> () is ()
>> True
>
> You should better not rely on that result. I would consider it to be an
> implementation detail. I may be wrong, but would an implementation that
> results in
>
> () is () ==> False
>
> be correct or is the result True really demanded by the language
> specification?

It would be correct, and the result True absolutely is NOT demanded by
the language. For example, Jython does not make that same optimization:

steve [at] rune:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> () is ()
False

so code which relies on it is already broken.

Python the language makes no promises that literals will always evaluate
to the same object. The ONLY such promises that it makes are that a small
handful of special constants are singletons:

None
NotImplemented
True
False

and perhaps one or two others. Everything else is an accident of the
implementation.

The CPython interpreter is especially aggressive in optimizing multiple
literals in the same line. Compare this:

>>> x = 3.1; y = 3.1; x is y
True

with this:

>>> x = 3.1
>>> y = 3.1
>>> x is y
False

Again, this is an accident of implementation, and cannot be relied on.

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 21, 2012, 8:54 PM

Post #23 of 142 (1217 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Sun, Apr 22, 2012 at 1:14 PM, Steven D'Aprano
<steve+comp.lang.python [at] pearwood> wrote:
> The CPython interpreter is especially aggressive in optimizing multiple
> literals in the same line. Compare this:
>
>>>> x = 3.1; y = 3.1; x is y
> True
>
> with this:
>
>>>> x = 3.1
>>>> y = 3.1
>>>> x is y
> False
>
>
> Again, this is an accident of implementation, and cannot be relied on.

That's the interactive interpreter, which works on a basis of lines.
With .py files, both 2.6 and 3.2 on Windows appear to do the same
optimization at module level. But either way, that's optimization of
constants.

>>> x=3.1+1.0; y=3.1+1.0; x is y
False
>>> x=3.1; y=3.1; x+y is x+y
False

Which can have micro-optimization implications:
>>> x=1048576; y=1048576; x is y
True
>>> x=1<<20; y=1<<20; x is y
False

But if you're concerning yourself with this kind of optimization,
you're probably wasting your time. :)

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

nagle at animats

Apr 22, 2012, 12:43 PM

Post #24 of 142 (1216 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On 4/20/2012 9:34 PM, john.tantalo [at] gmail 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

--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 22, 2012, 1:06 PM

Post #25 of 142 (1215 views)
Permalink

Re: why () is () and [] is [] work in other way? [In reply to]

On Mon, Apr 23, 2012 at 5:43 AM, John Nagle <nagle [at] animats> wrote:
> 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.)

Only in Python 2. In Python 3:

>>> True=3
SyntaxError: assignment to keyword

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads