Adam DePrince wrote:
> It just happens that the
> logical operation
>
> (a is b ) -> (a == b )
>
> is always True.
That is incorrect:
>>> inf = 1e300*1e300
>>> nan = inf-inf
>>> nan is nan, nan==nan
(True, False)
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>, Roy Smith wrote:
> This may even be useful. What if you were trying to emulate SQL's
> NULL? NULL compares false to anything, even itself.
Strictly speaking, comparing NULL to anything gives NULL, not False.
--
http://mail.python.org/mailman/listinfo/python-list
On 3 Apr 2006 10:37:11 -0400 in comp.lang.python, [EMAIL PROTECTED] (Roy
Smith) wrote:
>Adam DePrince <[EMAIL PROTECTED]> wrote:
>> It just happens that the
>>logical operation
>>
>> (a is b ) -> (a == b )
>>
>>is always True.
>
>Only for small values of "always". You can always do pathologic
Adam DePrince <[EMAIL PROTECTED]> wrote:
> It just happens that the
>logical operation
>
> (a is b ) -> (a == b )
>
>is always True.
Only for small values of "always". You can always do pathological
things with operators:
class Foo:
def __eq__ (self, other):
return False
f = Foo
On Mon, 2006-03-27 at 17:17 -0500, Terry Reedy wrote:
> "Clemens Hepper" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > It's strange: python seem to cache constants from 0 to 99:
>
> The Python specification allows but does not require such behind-the-scenes
> implementatio
Joel Hedlund wrote:
>> [*] I discovered a neat feature I didn't know my editor had: grepping
>> for "<[c:python-keyword>is"
>
> Neat indeed. Which editor is that?
Epsilon from www.lugaru.com. The drawback is that it costs real money
although you can try the beta for the next version until it i
> [*] I discovered a neat feature I didn't know my editor had: grepping for
> "<[c:python-keyword>is"
Neat indeed. Which editor is that?
Thanks for a quick and comprehensive answer, btw.
Cheers!
/Joel
--
http://mail.python.org/mailman/listinfo/python-list
Joel Hedlund wrote:
> It basically boils down to "don't ever use 'is' unless pushed into a
> corner, and nevermind what PEP8 says about it".
A quick grep[*] of the Python library shows the following common use-cases
for 'is'. The library isn't usually a good indicator of current style
though: a
>> For me, this means several things, and I'd really like to hear people's
>> thoughts about them.
> you need to spend more time relaxing, and less time making up arbitrary
> rules for others to follow.
I'm very relaxed, thank you. I do not make up rules for others to follow. I ask
for other peo
Joel Hedlund wrote:
>> There's no requirement that the socket module or
>> anything else return values using the same object that the
>> socket.AF_UNIX constant uses.
>
>
> Ouch. That's certainly an eyeopener.
>
> For me, this means several things, and I'd really like to hear people's
> thought
sorry
> You compare a module.CONSTANT to the result of an expression
s/an expression/a binary operation/
/joel
Joel Hedlund wrote:
>>If it weren't for the current CPython optimization (caching small
>>integers)
>
>
> This has already been covered elsewhere in this thread. Read up on it.
>
Joel Hedlund wrote:
> For me, this means several things, and I'd really like to hear people's
> thoughts about them.
>
> It basically boils down to "don't ever use 'is' unless pushed into a corner,
> and nevermind what PEP8 says about it".
nonsense.
> Identity checks can only be done safely to c
> There's no requirement that the socket module or
> anything else return values using the same object that the
> socket.AF_UNIX constant uses.
Ouch. That's certainly an eyeopener.
For me, this means several things, and I'd really like to hear people's
thoughts about them.
It basically boils do
> If it weren't for the current CPython optimization (caching small
> integers)
This has already been covered elsewhere in this thread. Read up on it.
> this code which it appears you would support writing
>
>if (flags & os.R_OK) is os.R_OK:
I do not.
You compare a module.CONSTANT to the
Em Ter, 2006-03-28 às 15:18 -0800, Ross Ridge escreveu:
[snip]
> Consider this example using the socket.IPPROTO_RAW constant:
>
> >>> socket.getaddrinfo("localhost", None, socket.AF_INET, socket.SOCK_RAW,
> >>> socket.IPPROTO_RAW)[0][2] is socket.IPPROTO_RAW
> False
>
> >>> socket.getaddrinfo("l
Felipe Almeida Lessa wrote:
> That said, you can do thinks like:
> >>> import socket
> >>> a = socket.AF_UNIX
> >>> a is socket.AF_UNIX
> True
>
> That kind of constants can be used with "is". But if don't want to be
> prone to errors as I do, use "is" only when you really know for sure
> that you'
On Tue, 28 Mar 2006 12:12:52 +0200, Joel Hedlund wrote:
> I try to stay away from speed microoptimisations as much as possible since it
> generally results in less readable code, which in turn often results in an
> overall speed loss because code maintenance will be harder.
+1 QOTW
--
Steven
Joel Hedlund wrote:
>>This does *not* also mean constants and such:
>
>
>
>>>>> a = 123456789
>>>>> a == 123456789
>>True
>>>>> a is 123456789
>>False
>
> I didn't mean that kind of constant. I meant named constants with defined
> meaning, as in the example that I cooked up
> a is None
>
> is quicker than
>
> a == None
I think it's not such a good idea to focus on speed gains here, since they
really are marginal (max 2 seconds total after 1000 comparisons):
>>> import timeit
>>> print timeit.Timer("a == None", "a = 1").timeit(int(1e7))
4.19580316544
>>> pr
>>Not those kind of constants, but this one:
>
>
>>Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
>>[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2
>>Type "help", "copyright", "credits" or "license" for more information.
>>
>CONST = 123456789
>a = CONST
>a == CONST
>>
>>True
>>
>>You should _never_ use 'is' to check for equivalence of value. Yes, due
>>to the implementation of CPython the behaviour you quote above does
>>occur, but it doesn't mean quite what you seem to think it does.
>
>
> /me not checking for value. I'm checking for identity. Suppose "a" is a
> consta
> This does *not* also mean constants and such:
> >>> a = 123456789
> >>> a == 123456789
> True
> >>> a is 123456789
> False
> >>>
I didn't mean that kind of constant. I meant named constants with defined
meaning, as in the example that I cooked up in my post. More examp
Em Seg, 2006-03-27 às 23:02 -0800, alex23 escreveu:
> Felipe Almeida Lessa wrote:
> > I said [constants defined in your code] can (maybe "should"?) be used with
> > "is", and
> > AFAICT I'm right as well:
> > >>> b = a
> > >>> b is a
> > True
>
> You should _never_ use 'is' to check for equivalen
Op 2006-03-27, Donn Cave schreef <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> ...
>> So - your conclusion is basically right: use is on (complex) objects, not on
>> numbers and strings and other built-ins. The exception from the rule is
>
Felipe Almeida Lessa wrote:
> I said [constants defined in your code] can (maybe "should"?) be used with
> "is", and
> AFAICT I'm right as well:
> >>> b = a
> >>> b is a
> True
You should _never_ use 'is' to check for equivalence of value. Yes, due
to the implementation of CPython the behaviour y
Em Seg, 2006-03-27 às 21:05 -0500, Dan Sommers escreveu:
> Right off the top of my head, I can't think of a way to make "a = b; a
> is b" return False.
Sorry for being so --quiet. I will try to be more --verbose.
I can think of two types of constants:
1) Those defined in the language, like True,
On Mon, 27 Mar 2006 11:08:36 -0300,
Felipe Almeida Lessa <[EMAIL PROTECTED]> wrote:
> Em Seg, 2006-03-27 às 08:23 -0500, Dan Sommers escreveu:
>> On Mon, 27 Mar 2006 14:52:46 +0200,
>> Joel Hedlund <[EMAIL PROTECTED]> wrote:
>>
>> > ... According to PEP8 (python programming style guidelines) you
Terry Reedy:
>The Python specification allows but does not require such behind-the-scenes
>implementation optimization hacks. As released, CPython 2.4 caches -5 to
>99, I believe. In 2.5, the upper limit was increased to 256. The limits
>are in a pair of #define statements in the int object s
Terry Reedy wrote:
> The Python specification allows but does not require such behind-the-scenes
> implementation optimization hacks. As released, CPython 2.4 caches -5 to
> 99, I believe. In 2.5, the upper limit was increased to 256. The limits
> are in a pair of #define statements in the i
"Clemens Hepper" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It's strange: python seem to cache constants from 0 to 99:
The Python specification allows but does not require such behind-the-scenes
implementation optimization hacks. As released, CPython 2.4 caches -5 to
99, I
In article <[EMAIL PROTECTED]>,
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
...
> So - your conclusion is basically right: use is on (complex) objects, not on
> numbers and strings and other built-ins. The exception from the rule is
> None - that should only exist once, so
>
> foo is not None
>
Clemens Hepper wrote:
> It's strange: python seem to cache constants from 0 to 99:
That's true. The Python api doc says that Python keeps an array of
integer objects for all integers between -1 and 100. See
http://docs.python.org/api/intObjects.html.
This also seems to be true for integers from -5
mwql wrote:
> It's really strange,
>
> if
> a = 1
> b = 1
> a is b ==> True
>
> the same thing applies for strings, but not for dict, lists or tuples
> I think the 'is' operator is useful for objects only, not for primitive
> types,
> I think I solved the mystery behind my bugged code =)
The r
Em Seg, 2006-03-27 às 08:23 -0500, Dan Sommers escreveu:
> On Mon, 27 Mar 2006 14:52:46 +0200,
> Joel Hedlund <[EMAIL PROTECTED]> wrote:
>
> > ... According to PEP8 (python programming style guidelines) you should
> > use 'is' when comparing to singletons like None. I take this to also
> > include
Dan Sommers wrote:
> This does *not* also mean constants and such:
>
> Python 2.4.2 (#1, Feb 22 2006, 08:02:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a = 123456789
> >>> a == 123
mwql wrote:
> It's really strange,
>
> if
> a = 1
> b = 1
> a is b ==> True
>
> the same thing applies for strings
Not quite:
>>> 'abc' is 'abc'
True
>>> 'abc' is 'ab' + 'c'
False
--
Benji York
--
http://mail.python.org/mailman/listinfo/python-list
It's really strange,
if
a = 1
b = 1
a is b ==> True
the same thing applies for strings, but not for dict, lists or tuples
I think the 'is' operator is useful for objects only, not for primitive
types,
I think I solved the mystery behind my bugged code =)
--
http://mail.python.org/mailman/listi
On Mon, 27 Mar 2006 14:52:46 +0200,
Joel Hedlund <[EMAIL PROTECTED]> wrote:
> ... According to PEP8 (python programming style guidelines) you should
> use 'is' when comparing to singletons like None. I take this to also
> include constants and such ...
This does *not* also mean constants and such
Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> Joel Hedlund <[EMAIL PROTECTED]> wrote:
>
>> Which means that "is" comparisons in general will be faster than ==
>> comparisons.
>
> I thought that == automatically compared identify before trying to compare
> the values. Or am I thinking o
Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> Joel Hedlund <[EMAIL PROTECTED]> wrote:
>>Which means that "is" comparisons in general will be faster than ==
>>comparisons.
>
> I thought that == automatically compared identify before trying to compare
> the values. Or am I thinking of som
In article <[EMAIL PROTECTED]>,
Joel Hedlund <[EMAIL PROTECTED]> wrote:
> Which means that "is" comparisons in general will be faster than ==
> comparisons.
I thought that == automatically compared identify before trying to compare
the values. Or am I thinking of some special case, like strin
> "is" is like id(obj1) == id(obj2)
> (Think of id as memory adresses.)
Which means that "is" comparisons in general will be faster than ==
comparisons. According to PEP8 (python programming style guidelines) you should
use 'is' when comparing to singletons like None. I take this to also includ
mwql wrote:
> Hey guys, this maybe a stupid question, but I can't seem to find the
> result anywhere online. When is the right time to use 'is' and when
> should we use '=='?
>
> Thanks alot~
'==' is the equality operator. It is used to test if two objects are
'equal'.
'is' is the identity opera
mwql wrote:
> Hey guys, this maybe a stupid question, but I can't seem to find the
> result anywhere online. When is the right time to use 'is' and when
> should we use '=='?
"is" is like id(obj1) == id(obj2)
>>> 100+1 == 101
True
>>> 100+1 is 101
False
They don't have the same id. (Think o
mwql:
>Hey guys, this maybe a stupid question, but I can't seem to find the
>result anywhere online. When is the right time to use 'is' and when
>should we use '=='?
http://docs.python.org/ref/comparisons.html
--
René Pijlman
--
http://mail.python.org/mailman/listinfo/python-list
Hey guys, this maybe a stupid question, but I can't seem to find the
result anywhere online. When is the right time to use 'is' and when
should we use '=='?
Thanks alot~
--
http://mail.python.org/mailman/listinfo/python-list
46 matches
Mail list logo
