On Mon, Dec 29, 2008 at 11:46 AM, Feat wrote:
> At 11:30 -0500 29/12/08, David Hostetler wrote:
>>The 'weird' results you were seeing when using 'is' were really just the
>>python interpretor lifting up its skirts a bit and (inadvertantly perhaps)
>>revealing when it had shared the memory storag
At 11:30 -0500 29/12/08, David Hostetler wrote:
>The 'weird' results you were seeing when using 'is' were really just the
>python interpretor lifting up its skirts a bit and (inadvertantly perhaps)
>revealing when it had shared the memory storage for a string literal and when
>it hadn't.
Yes: t
To describe it another way: 'is' does exactly what it say it does --
tests for object instance equivalence. That's _NOT_ the same as type
value equivalence. Perhaps think of 'is' as doing memory address, or
pointer, comparison, if you've done any C/C++ programming. If you
need to do that kind o
see: http://docs.python.org/reference/expressions.html#id24
"Due to automatic garbage-collection, free lists, and the dynamic
nature of descriptors, you may notice seemingly unusual behaviour in
certain uses of the is operator, like those involving comparisons
between instance methods, or constan
At 16:59 +0100 29/12/08, Ronald Oussoren wrote:
>Because strings aren't stored as unique objects. That is, there is no
>guarantee whatsoever that 'string1 == string2' implies 'string1 is string2'.
Optimization, uh? Okay, that settles it: thanks!
--
Jym Feat ~ Paris FR 75018
___
Do not rely on the id of instances of builtin types of Python. The "is"
operator is used to determine if two expressions refer to the same object, use
the "==" operator to determine if two expressions have the same value.
For some builtin value types the interpreter always uses the same Python o
On Monday, December 29, 2008, at 04:01PM, "Feat" wrote:
>I thought a string was stored as a unique object, so why isn't this evidenced
>by the code below ?
Because strings aren't stored as unique objects. That is, there is no guarantee
whatsoever that 'string1 == string2' implies 'string1 is
The only way to ensure it will *always* work is when sharing values:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
>>> c1 = 'red' ; c2 = 'green' ; colors = (c1, c2)
>>> [x is c2 for x in colors]
[Fa
Maybe at first sight, but look:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
>>> C = 'red', 'green'
>>> [light is 'green' for light in C]
[False, False]
NB: I have to quit Python each time and reload to make sure the workspace
hasn't b
Interesting... It behaves correctly for strings if you use a list inside the
comprehension instead of a tuple.
~Sean
On Mon, Dec 29, 2008 at 7:01 AM, Feat wrote:
> I thought a string was stored as a unique object, so why isn't this
> evidenced by the code below ?
>
>Python 2.5.2 (r252:60
I thought a string was stored as a unique object, so why isn't this evidenced
by the code below ?
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
>>> [light is 'green' for light in 'green', 'red']
[True, Fal
11 matches
Mail list logo
