Carl Banks wrote:
> On Mar 8, 5:32 am, Lie Ryan wrote:
>> Mel wrote:
>>> wrote:
Steven D'Aprano writes:
> It is never
> correct to avoid using "is" when you need to compare for identity.
When is it ever necessary to compare for identity?
>>> Ho-hum. MUDD game.
>>> def broadcas
Paul Rubin wrote:
> Steven D'Aprano writes:
>> It is never
>> correct to avoid using "is" when you need to compare for identity.
>
> When is it ever necessary to compare for identity?
For example when providing a unique "sentinel" value as a function
argument. The parameter must be tested for i
Gary Herron wrote:
> Robert Kern wrote:
>> On 2009-03-06 14:23, Gary Herron wrote:
>>> Robert Kern wrote:
On 2009-03-06 13:46, Gary Herron wrote:
> Emanuele D'Arrigo wrote:
>> Hi everybody,
>>
>> while testing a module today I stumbled on something that I can work
>> around
On 2009-03-08 12:39, Mark Dickinson wrote:
On Mar 7, 2:14 pm, Christian Heimes wrote:
Steven D'Aprano wrote:
Yes. Floating point NANs are required to compare unequal to all floats,
including themselves. It's part of the IEEE standard.
As far as I remember that's not correct. It's just the way
On Mar 8, 5:32 am, Lie Ryan wrote:
> Mel wrote:
> > wrote:
>
> >> Steven D'Aprano writes:
> >>> It is never
> >>> correct to avoid using "is" when you need to compare for identity.
> >> When is it ever necessary to compare for identity?
>
> > Ho-hum. MUDD game.
>
> > def broadcast (sender, mess
"Emanuele D'Arrigo" writes:
> I just find it peculiar more than a nuisance, but I'll go to the
> blackboard and write 100 times "never compare the identities of two
> immutables". Thank you all!
That's the wrong lesson to learn from this.
The right lesson to learn is, “Equality comparison is no
On Mar 7, 2:14 pm, Christian Heimes wrote:
> Steven D'Aprano wrote:
> > Yes. Floating point NANs are required to compare unequal to all floats,
> > including themselves. It's part of the IEEE standard.
>
> As far as I remember that's not correct. It's just the way C has
> interpreted the standard
Robert Kern wrote:
On 2009-03-07 08:14, Christian Heimes wrote:
Steven D'Aprano wrote:
Yes. Floating point NANs are required to compare unequal to all floats,
including themselves. It's part of the IEEE standard.
As far as I remember that's not correct. It's just the way C has
interpreted the
Mel wrote:
wrote:
Steven D'Aprano writes:
It is never
correct to avoid using "is" when you need to compare for identity.
When is it ever necessary to compare for identity?
Ho-hum. MUDD game.
def broadcast (sender, message):
for p in all_players:
if p is not sender:
On 2009-03-07 08:14, Christian Heimes wrote:
Steven D'Aprano wrote:
Yes. Floating point NANs are required to compare unequal to all floats,
including themselves. It's part of the IEEE standard.
As far as I remember that's not correct. It's just the way C has
interpreted the standard and Python
On 2009-03-07 02:11, Albert Hopkins wrote:
On Sat, 2009-03-07 at 03:07 -0500, Albert Hopkins wrote:
On Fri, 2009-03-06 at 23:57 -0800, Paul Rubin wrote:
alex23 writes:
But _you_ only _just_ stated "It does have some (generally small)
performance ramifications as
well" and provided timing exam
On Mar 6, 10:46 pm, "Martin v. Löwis" wrote:
> For b), the rationale is that such string literals
> in source code are often used to denote names, e.g.
> for getattr() calls and the like. As all names are interned,
> name-like strings get interned also.
Thank you Martin, and all others who have r
Steven D'Aprano wrote:
> Yes. Floating point NANs are required to compare unequal to all floats,
> including themselves. It's part of the IEEE standard.
As far as I remember that's not correct. It's just the way C has
interpreted the standard and Python inherited the behavior. But you may
proof me
wrote:
> Steven D'Aprano writes:
>> It is never
>> correct to avoid using "is" when you need to compare for identity.
>
> When is it ever necessary to compare for identity?
Ho-hum. MUDD game.
def broadcast (sender, message):
for p in all_players:
if p is not sender:
p
Emanuele D'Arrigo wrote:
> Gary, thanks for your reply: your explanation does pretty much answer
> my question. One thing I can add however is that it really seems that
> non-alphanumeric characters such as the forward slash make the
> difference, not just the number of characters. I.e.
(Actually,
standard.
btw, have anybody noticed that the subject line "/a" is not "/a" is
actually False.
>>> "/a" is not "/a"
False
>>> a = "/a"
>>> b = "/a"
>>> a is not b
True
--
http://mail.python.org/mailman/listinfo/python-list
Marc 'BlackJack' Rintsch writes:
> What should this example show? And where's the singleton here? BTW:
I misunderstood at first what you meant by "singleton". Sorry.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 06 Mar 2009 16:26:46 -0800, Paul Rubin wrote:
> Gary Herron writes:
>> Experts: Singleton immutable types *may* be compared with "is",
>
> That is absolutely wrong:
>
> >>> a = 2^100
> >>> b = 2^100
> >>> a == b
> True
> >>> a is b
> False
What should this exa
Albert Hopkins wrote:
> I would think (not having looked) that the implementation of == would
> first check for identity (for performance reasons)...
For some types, it may. I believe that string equality testing first tests
whether the two strings are the same string, then tests if they have the
On Sat, 2009-03-07 at 03:07 -0500, Albert Hopkins wrote:
> On Fri, 2009-03-06 at 23:57 -0800, Paul Rubin wrote:
> > alex23 writes:
> > > But _you_ only _just_ stated "It does have some (generally small)
> > > performance ramifications as
> > > well" and provided timing examples to show it. Without
On Fri, 2009-03-06 at 23:57 -0800, Paul Rubin wrote:
> alex23 writes:
> > But _you_ only _just_ stated "It does have some (generally small)
> > performance ramifications as
> > well" and provided timing examples to show it. Without qualification.
>
> The performance difference can be large if the
alex23 writes:
> But _you_ only _just_ stated "It does have some (generally small)
> performance ramifications as
> well" and provided timing examples to show it. Without qualification.
The performance difference can be large if the objects are (for
example) long lists.
--
http://mail.python.org/
Paul Rubin wrote:
> Steven D'Aprano writes:
>> It is never
>> correct to avoid using "is" when you need to compare for identity.
>
> When is it ever necessary to compare for identity?
Is that a trick question? The obvious answer is, any time you need to.
The standard library has dozens of test
On Mar 7, 10:57 am, s...@pobox.com wrote:
> Right. Again though, when newcomers conflate the concepts they can deceive
> themselves into thinking "is" is just a faster "==".
But _you_ only _just_ stated "It does have some (generally small)
performance ramifications as
well" and provided timing ex
s...@pobox.com wrote:
> Steven> Mutable versus immutable is irrelevant. The complexity of the
> Steven> object is irrelevant. The phase of the moon is irrelevant. The
> Steven> *only* relevant factor is the programmer's intention:
>
> Which for a new user not familiar with the differi
Gary Herron wrote:
>>> Newbies: Never use "is" to compare anything.
>>
>> Worse and worse! Now you're actively teaching newbies to write buggy
>> code!
>
> Nonsense. Show me "newbie" level code that's buggy with "==" but
> correct with "is".
What's "newbie" level code? What does that even *mean
Steven> Mutable versus immutable is irrelevant. The complexity of the
Steven> object is irrelevant. The phase of the moon is irrelevant. The
Steven> *only* relevant factor is the programmer's intention:
Which for a new user not familiar with the differing concepts of "is" and
"==" can
On 2009-03-06 18:29, Paul Rubin wrote:
Steven D'Aprano writes:
It is never
correct to avoid using "is" when you need to compare for identity.
When is it ever necessary to compare for identity?
Caches of arbitrary objects.
When checking if an object (which may be have an arbitrarily pervers
s...@pobox.com wrote:
> Of course, the more complex the objects you are comparing the
> stronger the recommendation agaist using 'is' to compare two objects.
Why is there so much voodoo advice about "is"? Is object identity really
such a scary concept that people are frightened of it?
Mutable ve
Steven D'Aprano writes:
> It is never
> correct to avoid using "is" when you need to compare for identity.
When is it ever necessary to compare for identity?
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 6, 12:23 pm, Gary Herron wrote:
> Robert Kern wrote:
> > On 2009-03-06 13:46, Gary Herron wrote:
> >> Emanuele D'Arrigo wrote:
> >>> Hi everybody,
>
> >>> while testing a module today I stumbled on something that I can work
> >>> around but I don't quite understand.
>
> >> *Do NOT use "is"
En Fri, 06 Mar 2009 19:31:02 -0200, Emanuele D'Arrigo
escribió:
a = "a"
b = "a"
a is b
True
a = "/a" <- same as above, except the forward slashes!
b = "/a" <- same as above, except the forward slashes!
a is b
False
So, it appears that in the first case a and b are names to the same
str
Gary> *Do NOT use "is" to compare immutable types.* **Ever! **
The obvious followup question is then, "when is it ok to use 'is'?"
Robert> Well, "foo is None" is actually recommended practice
Indeed. It does have some (generally small) performance ramifications as
well. Two trivia
Emanuele D'Arrigo wrote:
On 6 Mar, 19:46, Gary Herron wrote:
It is an implementation choice (usually driven by efficiency considerations) to
choose when two strings with the same value are stored in memory once or twice.
In order for Python to recognize when a newly created string has the
> So, it appears that in the first case a and b are names to the same
> string object, while in the second case they are to two separate
> objects. Why?
This question is ambiguous:
a) Why does the Python interpreter behave this way?
(i.e. what specific algorithm produces this result?)
or
b) Why
Steven D'Aprano wrote:
Gary Herron wrote:
Robert Kern wrote:
...
Use "is" when you really need to compare by object identity and not
value.
But that definition is the *source* of the trouble. It is *completely*
meaningless to newbies. Until one has experience in programm
Emanuele D'Arrigo wrote:
> So, it appears that in the first case a and b are names to the same
> string object, while in the second case they are to two separate
> objects. Why? What's so special about the forward slash that cause the
> two "/a" strings to create two separate objects? Is this an
>
On 6 Mar, 19:46, Gary Herron wrote:
> It is an implementation choice (usually driven by efficiency considerations)
> to choose when two strings with the same value are stored in memory once or
> twice. In order for Python to recognize when a newly created string has the
> same value as an alre
Thank you everybody for the contributions and sorry if I reawoke the
recurring "is vs ==" issue. I -think- I understand how Python's
object model works, but clearly I'm still missing something. Let me
reiterate my original example without the distracting aspect of the
"==" comparisons and the four
Gary Herron wrote:
>> Huh? How am I supposed to compare immutable types for identity then? Your
>> bizarre instruction would prohibit:
>>
>> if something is None
>>
>
> Just use:
>
> if something == None
>
> It does *exactly* the same thing.
Wrong.
"something is None" is a pointer compar
Gary Herron wrote:
> Robert Kern wrote:
...
>> Use "is" when you really need to compare by object identity and not
>> value.
>
> But that definition is the *source* of the trouble. It is *completely*
> meaningless to newbies. Until one has experience in programming in
> general and experience
Steven D'Aprano wrote:
Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.***Ever! **
Huh? How am I suppos
Robert Kern wrote:
On 2009-03-06 14:23, Gary Herron wrote:
Robert Kern wrote:
On 2009-03-06 13:46, Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare
Emanuele D'Arrigo wrote:
> Hi everybody,
>
> while testing a module today I stumbled on something that I can work
> around but I don't quite understand.
Why do you have to work around it?
What are you trying to do that requires that two strings should occupy the
same memory location rather than
Gary Herron wrote:
> Emanuele D'Arrigo wrote:
>> Hi everybody,
>>
>> while testing a module today I stumbled on something that I can work
>> around but I don't quite understand.
>>
>
> *Do NOT use "is" to compare immutable types.***Ever! **
Huh? How am I supposed to compare immutable type
On 2009-03-06 14:23, Gary Herron wrote:
Robert Kern wrote:
On 2009-03-06 13:46, Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.* *
Robert Kern wrote:
On 2009-03-06 13:46, Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.* **Ever! **
Well, "foo is None" is actual
Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.***Ever! **
Then it should be a detected error to do so.
On 2009-03-06 13:46, Gary Herron wrote:
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.* **Ever! **
Well, "foo is None" is actually recommended pract
Emanuele D'Arrigo wrote:
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
*Do NOT use "is" to compare immutable types.***Ever! **
It is an implementation choice (usually driven by efficiency considerations) to
cho
Emanuele D'Arrigo wrote:
c = "/a"
d = "/a"
c == d
> True # all good so far
c is d
> False # ek!
>
> Why c and d point to two different objects with an identical string
> content rather than the same object?
Because you instantiated two difference
Hi everybody,
while testing a module today I stumbled on something that I can work
around but I don't quite understand.
>>> a = "a"
>>> b = "a"
>>> a == b
True
>>> a is b
True
>>> c = "/a"
>>> d = "/a"
>>> c == d
True # all good so far
>>> c is d
False # ek!
Why c
52 matches
Mail list logo
