On Fri, 2009-01-23 at 19:31 -0500, Benjamin Kaplan wrote:
>
>
> On Fri, Jan 23, 2009 at 7:28 PM, Gary Herron
> 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 co
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
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,
tho
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
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 Fal
> 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
> 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
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 is
None instead of == None (also is not None, et
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 is
>>> None instead of == None (also is not None, etc.)
>>
>> That entirely depend
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 is
>> None instead of == None (also is not None, etc.)
>
> That entirely depends on whether you wish to test for something which
> *is* None o
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:
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.
Addit
On Fri, Jan 23, 2009 at 7:28 PM, Gary Herron 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 is
> >> None instead of == None (also is not None, etc.)
> >>
> >
> > That entire
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 is
>> None instead of == None (also is not None, etc.)
>>
>
> That entirely depends on whether you wish to test for something which
>
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 is
> > None instead of == None (also is not None, etc.)
>
> That entire
On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
> Hi -- Some time ago I ran across a comment recommending using is
> None instead of == None (also is not None, etc.)
That entirely depends on whether you wish to test for something which
*is* None or something with *equals* None. Tho
John Machin schrieb:
> On Jan 24, 7:48 am, 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 cop
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 cac
On Jan 24, 7:48 am, 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 in
On Jan 23, 12:48 pm, 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 i
Chris Rebert wrote:
> On Fri, Jan 23, 2009 at 11:58 AM, Gerald Britton
> wrote:
>> Hi -- Some time ago I ran across a comment recommending using is
>> None instead of == None (also is not None, etc.) My own
>> testing indicates that the former beats the latter by about 30% on
>> average. Not
On Fri, Jan 23, 2009 at 11:58 AM, Gerald Britton
wrote:
> Hi -- Some time ago I ran across a comment recommending using is
> None instead of == None (also 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 instructi
Hi -- Some time ago I ran across a comment recommending using is
None instead of == None (also 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 for a (semi)
23 matches
Mail list logo