On Fri, 2009-01-23 at 19:31 -0500, Benjamin Kaplan wrote:
On Fri, Jan 23, 2009 at 7:28 PM, Gary Herron
gher...@islandtraining.com wrote:
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I
Terry Reedy wrote:
Roger wrote:
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create copies ...
Does the interpreter
Steve Holden wrote:
Terry Reedy wrote:
In 2.x, the *names* 'True' and 'False' can be rebound because bool is
new and people write
try:
False,True
except NameError:
False,True = 0,1
to make code back compatible.
I would claim that the ability to rebind True and False is a simple bug,
Terry Reedy wrote:
Steve Holden wrote:
Terry Reedy wrote:
In 2.x, the *names* 'True' and 'False' can be rebound because bool is
new and people write
try:
False,True
except NameError:
False,True = 0,1
to make code back compatible.
I would claim that the ability to rebind True and
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create copies ...
Does the interpreter guarantee the same for False and True
Why do you think it matters?
Intellectual curiosity hence why I asked the question. It doesn't
matter if I know why the sky is blue but it's interesting to know
regardless.
--
http://mail.python.org/mailman/listinfo/python-list
Roger wrote:
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create copies ...
Does the interpreter guarantee the same for
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 20:33:45 -0500, Steve Holden wrote:
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.) My own
testing indicates that the former beats the latter by about 30% on
average. Not a log for a single instruction but it can add up in
large projects.
I'm looking
On Fri, Jan 23, 2009 at 11:58 AM, Gerald Britton
gerald.brit...@gmail.com wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.) My own
testing indicates that the former beats the latter by about 30% on
average.
Chris Rebert wrote:
On Fri, Jan 23, 2009 at 11:58 AM, Gerald Britton
gerald.brit...@gmail.com wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.) My own
testing indicates that the former beats the latter by
On Jan 23, 12:48 pm, Roger rdcol...@gmail.com wrote:
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create copies ...
On Jan 24, 7:48 am, Roger rdcol...@gmail.com wrote:
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create copies ...
Does
Jason Scheirer schrieb:
Yes. I know that there are the PyObject* structs defined for you
Py_True, Py_False and Py_None in the C level. Confusingly enough, the
integers -5 through 257 are also singletons where the is test will
work, but any int out of that range will not.
Small ints are
John Machin schrieb:
On Jan 24, 7:48 am, Roger rdcol...@gmail.com wrote:
And, just for completeness, the is test is canonical precisely because
the interpreter guarantees there is only ever one object of type None,
so an identity test is always appropriate. Even the copy module doesn't
create
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
That entirely depends on whether you wish to test for something which
*is* None or something with *equals*
On Fri, Jan 23, 2009 at 6:49 PM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
That
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
That entirely depends on whether you wish to test for something which
On Fri, Jan 23, 2009 at 7:28 PM, Gary Herron gher...@islandtraining.comwrote:
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
Steven D'Aprano wrote:
var is None is a micro-optimization, but that's not why we do it. We do
it because usually the correct test is whether var *is* None and not
merely equal to None. Any random object might happen to equal None
(admittedly most objects don't), but only None is None.
On Fri, 23 Jan 2009 16:28:15 -0800, Gary Herron wrote:
If something
*equals* None, it also *is* None. This is a consequence of the fact
that there is only ever one value of None anywhere in the system.
...
The only way something can *equal* None is if it *is* None.
class Empty:
...
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
That entirely depends on whether you wish to test for something which
*is* None
On Fri, 23 Jan 2009 20:33:45 -0500, Steve Holden wrote:
Steven D'Aprano wrote:
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
Hi -- Some time ago I ran across a comment recommending using var is
None instead of var == None (also var is not None, etc.)
That entirely depends on
23 matches
Mail list logo
