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
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
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
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
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
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
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
___
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
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
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
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
11 matches
Mail list logo
