Mailing List Archive: Python: Python

is None or == None ?

1 2

View All

Index | Next | Previous | View Threaded

mrkafk at gmail

Nov 6, 2009, 5:20 AM

Post #1 of 48 (886 views)
Permalink

is None or == None ?

Hello,

Some claim that one should test for None using:

if x is None:

..but the standard equality which is theoretically safer works as well:

if x == None:

So, which one is recommended?

Can there be two None objects in interpreter's memory? Is testing for
identity of some variable with None safe? Does language guarantee that?
Or is it just property of implementation?

Regards,
mk

--
http://mail.python.org/mailman/listinfo/python-list

stefan_ml at behnel

Nov 6, 2009, 5:33 AM

Post #2 of 48 (866 views)
Permalink

Re: is None or == None ? [In reply to]

mk, 06.11.2009 14:20:
> Some claim that one should test for None using:
>
> if x is None:

Which is the correct and safe way of doing it.

> ..but the standard equality which is theoretically safer works as well:
>
> if x == None:

Absolutely not safe, think of

class Test(object):
def __eq__(self, other):
return other == None

print Test() == None, Test() is None

Stefan
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 5:35 AM

Post #3 of 48 (867 views)
Permalink

Re: is None or == None ? [In reply to]

* mk:
> Hello,
>
> Some claim that one should test for None using:
>
> if x is None:
>
> ..but the standard equality which is theoretically safer works as well:
>
> if x == None:
>
> So, which one is recommended?
>
> Can there be two None objects in interpreter's memory? Is testing for
> identity of some variable with None safe? Does language guarantee that?
> Or is it just property of implementation?

As I understand it, 'is' will always work and will always be efficient (it just
checks the variable's type), while '==' can depend on the implementation of
equality checking for the other operand's class.

Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

sjmachin at lexicon

Nov 6, 2009, 6:09 AM

Post #4 of 48 (867 views)
Permalink

Re: is None or == None ? [In reply to]

On Nov 7, 12:35 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * mk:
>
> > Hello,
>
> > Some claim that one should test for None using:
>
> > if x is None:
>
> > ..but the standard equality which is theoretically safer works as well:
>
> > if x == None:
>
> > So, which one is recommended?
>
>
> As I understand it, 'is' will always work and will always be efficient (it just
> checks the variable's type),

It doesn't check the type. It doesn't need to. (x is y) is true if x
and y are the same object. If that is so, then of course (type(x) is
type(y)) is true, and if not so, their types are irrelevant. "is"
testing is very efficient in the CPython implementation: addressof(x)
== addressof(y)
--
http://mail.python.org/mailman/listinfo/python-list

marco at sferacarta

Nov 6, 2009, 6:13 AM

Post #5 of 48 (867 views)
Permalink

Re: is None or == None ? [In reply to]

Alf P. Steinbach wrote:

> As I understand it, 'is' will always work and will always be efficient
> (it just checks the variable's type), while '==' can depend on the
> implementation of equality checking for the other operand's class.

"== None" makes sense, for instance, in the context of the SQLAlchemy
sql construction layer, where the underlying machinery defines __eq__()
/ __ne__() and generates the appropriate 'IS NULL' SQL code when
appropriate.

--
http://mail.python.org/mailman/listinfo/python-list

mrkafk at gmail

Nov 6, 2009, 6:32 AM

Post #6 of 48 (860 views)
Permalink

Re: is None or == None ? [In reply to]

Stefan Behnel wrote:
> mk, 06.11.2009 14:20:
>> Some claim that one should test for None using:
>>
>> if x is None:
>
> Which is the correct and safe way of doing it.

ok

>> ..but the standard equality which is theoretically safer works as well:
>>
>> if x == None:
>
> Absolutely not safe, think of
>
> class Test(object):
> def __eq__(self, other):
> return other == None
>
> print Test() == None, Test() is None

Err, I don't want to sound daft, but what is wrong in this example? It
should work as expected:

>>> class Test(object):
... def __eq__(self, other):
... return other == None
...
>>> Test() is None
False
>>> Test() == None
True

My interpretation of 1st call is that it is correct: instance Test() is
not None (in terms of identity), but it happens to have value equal to
None (2nd call).

Or perhaps your example was supposed to show that I should test for
identity with None, not for value with None?

That, however, opens a can of worms, sort of: whether one should compare
Test() for identity with None or for value with None depends on what
programmer meant at the moment.

Regards,
mk

--
http://mail.python.org/mailman/listinfo/python-list

fetchinson at googlemail

Nov 6, 2009, 6:51 AM

Post #7 of 48 (861 views)
Permalink

Re: is None or == None ? [In reply to]

> Some claim that one should test for None using:
>
> if x is None:
>
> ..but the standard equality which is theoretically safer works as well:
>
> if x == None:
>
> So, which one is recommended?

It depends on what you want to do. There is no single answer to your
question, until you tell us what your context is.

The None object in python is a singleton. If you want to check whether
a given object is this singleton None object (note that this is
unambiguous, it either occupies the same address in memory as the
singleton None or it doesn't) then you should use 'x is None'.

If, however you want to test for equality, you should use 'x == None'.
An object 'x' may implement equality checks in a funny way and it may
be that 'x == None' is True although 'x is None' is False. But it may
be that this is exactly what you want, because the author of the
object 'x' intentionally has written the equality check code to make
this so. In this case you need 'x == None'.

So unless you tell us in what context you are asking this question,
there is no single answer to it.

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 7:16 AM

Post #8 of 48 (860 views)
Permalink

Re: is None or == None ? [In reply to]

* John Machin:
> On Nov 7, 12:35 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * mk:
>>
>>> Hello,
>>> Some claim that one should test for None using:
>>> if x is None:
>>> ..but the standard equality which is theoretically safer works as well:
>>> if x == None:
>>> So, which one is recommended?
>>
>> As I understand it, 'is' will always work and will always be efficient (it just
>> checks the variable's type),
>
> It doesn't check the type.
> It doesn't need to. (x is y) is true if x
> and y are the same object. If that is so, then of course (type(x) is
> type(y)) is true, and if not so, their types are irrelevant. "is"
> testing is very efficient in the CPython implementation: addressof(x)
> == addressof(y)

Maybe.

I imagined it wouldn't waste additional space for e.g. (Python 2.x) int values,
but just use the same space as used for pointer in the case of e.g. string, in
which case it would have to check the type -- an integer can very easily have
the same bitpattern as a pointer residing there.

If you imagine that instead, for an integer variable x it stores the integer
value in the variable in some other place than ordinarily used for pointer, and
let the pointer point to that place in the same variable, then without checking
type the 'is' operator should report false for 'x = 3; y = 3; x is y', but it
doesn't with my Python installation, so if it doesn't check the type then even
this half-measure (just somewhat wasteful of space) optimization isn't there.

In short, you're saying that there is an extreme inefficiency with every integer
dynamically allocated /plus/, upon production of an integer by e.g. + or *,
inefficiently finding the previously allocated integer of that value and
pointing there, sort of piling inefficiency on top of inefficiency, which is
absurd but I have seen absurd things before so it's not completely unbelievable.

I hope someone else can comment on these implications of your statement.

Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

marco at sferacarta

Nov 6, 2009, 7:51 AM

Post #9 of 48 (860 views)
Permalink

Re: is None or == None ? [In reply to]

Alf P. Steinbach wrote:

> If you imagine that instead, for an integer variable x it stores the
> integer value in the variable in some other place than ordinarily used
> for pointer, and let the pointer point to that place in the same
> variable, then without checking type the 'is' operator should report
> false for 'x = 3; y = 3; x is y', but it doesn't with my Python

Yes, CPython caches a handful of small, "commonly used" integers, and
creates objects for them upon startup. Using "x is y" with integers
makes no sense and has no guaranteed behaviour AFAIK

> In short, you're saying that there is an extreme inefficiency with every
> integer dynamically allocated /plus/, upon production of an integer by
> e.g. + or *, inefficiently finding the previously allocated integer of
> that value and pointing there,

no, it doesn't "point there":

>>>> a=1E6
>>>> a is 1E6
> False
>>>> a=100
>>>> a is 100
> True
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 8:54 AM

Post #10 of 48 (859 views)
Permalink

Re: is None or == None ? [In reply to]

* Marco Mariani:
> Alf P. Steinbach wrote:
>
>> If you imagine that instead, for an integer variable x it stores the
>> integer value in the variable in some other place than ordinarily used
>> for pointer, and let the pointer point to that place in the same
>> variable, then without checking type the 'is' operator should report
>> false for 'x = 3; y = 3; x is y', but it doesn't with my Python
>
> Yes, CPython caches a handful of small, "commonly used" integers, and
> creates objects for them upon startup. Using "x is y" with integers
> makes no sense and has no guaranteed behaviour AFAIK
>
>> In short, you're saying that there is an extreme inefficiency with
>> every integer dynamically allocated /plus/, upon production of an
>> integer by e.g. + or *, inefficiently finding the previously allocated
>> integer of that value and pointing there,
>
> no, it doesn't "point there":
>
>>>>> a=1E6
>>>>> a is 1E6
>> False
>>>>> a=100
>>>>> a is 100
>> True

I stand corrected on that issue, I didn't think of cache for small values.

On my CPython 3.1.1 the cache seems to support integer values -5 to +256,
inclusive, apparently using 16 bytes of storage per value (this last assuming
id() just returns the address).

But wow. That's pretty hare-brained: dynamic allocation for every stored value
outside the cache range, needless extra indirection for every operation.

Even Microsoft COM managed to get this right.

On the positive side, except that it would probably break every C module (I
don't know), in consultant speak that's definitely a potential for improvement. :-p

Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

rami.chowdhury at gmail

Nov 6, 2009, 9:04 AM

Post #11 of 48 (859 views)
Permalink

Re: is None or == None ? [In reply to]

On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps [at] start>
wrote:

> But wow. That's pretty hare-brained: dynamic allocation for every stored
> value outside the cache range, needless extra indirection for every
> operation.
>

Perhaps I'm not understanding this thread at all but how is dynamic
allocation hare-brained, and what's the 'needless extra indirection'?

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
--
http://mail.python.org/mailman/listinfo/python-list

python at rcn

Nov 6, 2009, 9:21 AM

Post #12 of 48 (858 views)
Permalink

Re: is None or == None ? [In reply to]

On Nov 6, 5:20 am, mk <mrk...@gmail.com> wrote:
> Some claim that one should test for None using:
>
> if x is None:
>
> ..but the standard equality which is theoretically safer works as well:
>
> if x == None:
>
> So, which one is recommended?

In the standard library, we use "x is None".

The official recommendation in PEP 8 reads:
'''
Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.

Also, beware of writing "if x" when you really mean "if x is not
None"
-- e.g. when testing whether a variable or argument that
defaults to
None was set to some other value. The other value might have a
type
(such as a container) that could be false in a boolean context!
'''

Raymond
--
http://mail.python.org/mailman/listinfo/python-list

hniksic at xemacs

Nov 6, 2009, 9:22 AM

Post #13 of 48 (853 views)
Permalink

Re: is None or == None ? [In reply to]

"Alf P. Steinbach" <alfps [at] start> writes:

> But wow. That's pretty hare-brained: dynamic allocation for every
> stored value outside the cache range, needless extra indirection for
> every operation.
>
> Even Microsoft COM managed to get this right.
>
> On the positive side, except that it would probably break every C
> module (I don't know), in consultant speak that's definitely a
> potential for improvement. :-p

Tagged integers have been tried, shown not really worth it, and
ultimately rejected by the BDFL:

http://mail.python.org/pipermail/python-dev/2004-July/thread.html#46139
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 9:28 AM

Post #14 of 48 (858 views)
Permalink

Re: is None or == None ? [In reply to]

* Rami Chowdhury:
> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps [at] start>
> wrote:
>
>> But wow. That's pretty hare-brained: dynamic allocation for every
>> stored value outside the cache range, needless extra indirection for
>> every operation.
>>
>
> Perhaps I'm not understanding this thread at all but how is dynamic
> allocation hare-brained, and what's the 'needless extra indirection'?

Dynamic allocation isn't hare-brained, but doing it for every stored integer
value outside a very small range is, because dynamic allocation is (relatively
speaking, in the context of integer operations) very costly even with a
(relatively speaking, in the context of general dynamic allocation) very
efficient small-objects allocator - here talking order(s) of magnitude.

A typical scheme for representing dynamically typed objects goes like, in C++,

enum TypeId { int_type_id, dyn_object_type_id };

struct Object
{
int type_id;
union
{
void* p;
int i;
// Perhaps other special cased type's values in this union.
};
};

This would then be the memory layout of what's regarded as a variable at the
script language level.

Then getting the integer value reduces to

int intValueOf( Object const& o )
{
if( o.type_id != int_type_id ) { throw TypeError(); }
return o.i;
}

If on the other hand int (and perhaps floating point type, whatever) isn't
special-cased, then it goes like

int intValueOf( Object const& o )
{
if( o.type_id != int_type_id ) { throw TypeError(); }
return static_cast<IntType*>( o.p )->value; // Extra indirection
}

and depending on where the basic type id is stored it may be more extra
indirection, and worse, creating that value then involves a dynamic allocation.

Cheers & hth.

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 10:45 AM

Post #15 of 48 (853 views)
Permalink

Re: is None or == None ? [In reply to]

* Hrvoje Niksic:
> "Alf P. Steinbach" <alfps [at] start> writes:
>
>> But wow. That's pretty hare-brained: dynamic allocation for every
>> stored value outside the cache range, needless extra indirection for
>> every operation.
>>
>> Even Microsoft COM managed to get this right.
>>
>> On the positive side, except that it would probably break every C
>> module (I don't know), in consultant speak that's definitely a
>> potential for improvement. :-p
>
> Tagged integers have been tried, shown not really worth it, and
> ultimately rejected by the BDFL:
>
> http://mail.python.org/pipermail/python-dev/2004-July/thread.html#46139

Yah, as I suspected. I looked at the first few postings in that thread and it
seems an inefficient baroque implementation was created and tested, not
realizing more than 50% speedup in a test not particularly much exercising its
savings, and against that counts as mentioned in the thread and as I mentioned
in quoted material above, breaking lots of existing C code.

Speedup would likely be more realistic with normal implementation (not fiddling
with bit-fields and stuff) not to mention when removing other inefficiencies
that likely dwarf and hide the low-level performance increase, but still I agree
wholeheartedly with those who argue compatibility, not breaking code.

As long as it Works, don't fix it... ;-)

Cheers, (still amazed, though)

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

pavlovevidence at gmail

Nov 6, 2009, 11:20 AM

Post #16 of 48 (853 views)
Permalink

Re: is None or == None ? [In reply to]

On Nov 6, 9:28 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Rami Chowdhury:
>
> > On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <al...@start.no>
> > wrote:
>
> >> But wow. That's pretty hare-brained: dynamic allocation for every
> >> stored value outside the cache range, needless extra indirection for
> >> every operation.
>
> > Perhaps I'm not understanding this thread at all but how is dynamic
> > allocation hare-brained, and what's the 'needless extra indirection'?
>
> Dynamic allocation isn't hare-brained, but doing it for every stored integer
> value outside a very small range is, because dynamic allocation is (relatively
> speaking, in the context of integer operations) very costly even with a
> (relatively speaking, in the context of general dynamic allocation) very
> efficient small-objects allocator - here talking order(s) of magnitude.

Python made a design trade-off, it chose a simpler implementation and
uniform object semantic behavior, at a cost of speed. C# made a
different trade-off, choosing a more complex implementation, a
language with two starkly different object semantic behaviors, so as
to allow better performance.

You don't have to like the decision Python made, but I don't think
it's fair to call a deliberate design trade-off hare-brained.

Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list

rami.chowdhury at gmail

Nov 6, 2009, 11:28 AM

Post #17 of 48 (852 views)
Permalink

Re: is None or == None ? [In reply to]

On Fri, 06 Nov 2009 09:28:08 -0800, Alf P. Steinbach <alfps [at] start>
wrote:

> * Rami Chowdhury:
>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps [at] start>
>> wrote:
>>
>>> But wow. That's pretty hare-brained: dynamic allocation for every
>>> stored value outside the cache range, needless extra indirection for
>>> every operation.
>>>
>> Perhaps I'm not understanding this thread at all but how is dynamic
>> allocation hare-brained, and what's the 'needless extra indirection'?
>
> Dynamic allocation isn't hare-brained, but doing it for every stored
> integer value outside a very small range is, because dynamic allocation
> is (relatively speaking, in the context of integer operations) very
> costly even with a (relatively speaking, in the context of general
> dynamic allocation) very efficient small-objects allocator - here
> talking order(s) of magnitude.

Well, sure, it may seem that way. But how large a cache would you want to
preallocate? I can't see the average Python program needing to use the
integers from -10000 to 10000, for instance. In my (admittedly limited)
experience Python programs typically deal with rather more complex objects
than plain integers.

> int intValueOf( Object const& o )
> {
> if( o.type_id != int_type_id ) { throw TypeError(); }
> return static_cast<IntType*>( o.p )->value; // Extra
> indirection
> }

If a large cache were created and maintained, would it not be equally
indirect to check for the presence of a value in the cache, and return
that value if it's present?

> creating that value then involves a dynamic allocation.

Creating which value, sorry -- the type object?

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 11:41 AM

Post #18 of 48 (853 views)
Permalink

Re: is None or == None ? [In reply to]

* Carl Banks:
> On Nov 6, 9:28 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * Rami Chowdhury:
>>
>>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <al...@start.no>
>>> wrote:
>>>> But wow. That's pretty hare-brained: dynamic allocation for every
>>>> stored value outside the cache range, needless extra indirection for
>>>> every operation.
>>> Perhaps I'm not understanding this thread at all but how is dynamic
>>> allocation hare-brained, and what's the 'needless extra indirection'?
>> Dynamic allocation isn't hare-brained, but doing it for every stored integer
>> value outside a very small range is, because dynamic allocation is (relatively
>> speaking, in the context of integer operations) very costly even with a
>> (relatively speaking, in the context of general dynamic allocation) very
>> efficient small-objects allocator - here talking order(s) of magnitude.
>
>
> Python made a design trade-off, it chose a simpler implementation

Note that the object implementation's complexity doesn't have to affect to any
other code since it's trivial to provide abstract accessors (even macros), i.e.,
this isn't part of a trade-off except if the original developer(s) had limited
resources -- and if so then it wasn't a trade-off at the language design level
but a trade-off of getting things done then and there.

> and uniform object semantic behavior,

Also note that the script language level semantics of objects is /unaffected/ by
the implementation, except for speed, i.e., this isn't part of a trade-off
either. ;-)

> at a cost of speed.

In summary, the trade-off, if any, couldn't as I see it be what you describe,
but there could have been a different kind of getting-it-done trade-off.

It is usually better with Something Usable than waiting forever (or too long)
for the Perfect... ;-)

Or, it could be that things just evolved, constrained by frozen earlier
decisions. That's the main reason for the many quirks in C++. Not unlikely that
it's also that way for Python.

> C# made a
> different trade-off, choosing a more complex implementation, a
> language with two starkly different object semantic behaviors, so as
> to allow better performance.

Don't know about the implementation of C#, but whatever it is, if it's bad in
some respect then that has nothing to do with Python.

> You don't have to like the decision Python made, but I don't think
> it's fair to call a deliberate design trade-off hare-brained.

OK. :-)

Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 11:50 AM

Post #19 of 48 (853 views)
Permalink

Re: is None or == None ? [In reply to]

* Rami Chowdhury:
> On Fri, 06 Nov 2009 09:28:08 -0800, Alf P. Steinbach <alfps [at] start>
> wrote:
>
>> * Rami Chowdhury:
>>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps [at] start>
>>> wrote:
>>>
>>>> But wow. That's pretty hare-brained: dynamic allocation for every
>>>> stored value outside the cache range, needless extra indirection for
>>>> every operation.
>>>>
>>> Perhaps I'm not understanding this thread at all but how is dynamic
>>> allocation hare-brained, and what's the 'needless extra indirection'?
>>
>> Dynamic allocation isn't hare-brained, but doing it for every stored
>> integer value outside a very small range is, because dynamic
>> allocation is (relatively speaking, in the context of integer
>> operations) very costly even with a (relatively speaking, in the
>> context of general dynamic allocation) very efficient small-objects
>> allocator - here talking order(s) of magnitude.
>
> Well, sure, it may seem that way. But how large a cache would you want
> to preallocate? I can't see the average Python program needing to use
> the integers from -10000 to 10000, for instance. In my (admittedly
> limited) experience Python programs typically deal with rather more
> complex objects than plain integers.

Uhm, you've misunderstood or failed to understand something basic, but what? The
CPython implementation uses a cache to alleviate problems with performance. A
tagged scheme (the usual elsewhere, e.g. Windows' Variant) doesn't need any
cache and can't benefit from such a cache, since then an integer's value is
directly available in any variable that logically holds an int. In short, a
cache for integer values is maningless for the tagged scheme.

>> int intValueOf( Object const& o )
>> {
>> if( o.type_id != int_type_id ) { throw TypeError(); }
>> return static_cast<IntType*>( o.p )->value; // Extra
>> indirection
>> }
>
> If a large cache were created and maintained, would it not be equally
> indirect to check for the presence of a value in the cache, and return
> that value if it's present?

Again, that's meaningless. See above.

>> creating that value then involves a dynamic allocation.
>
> Creating which value, sorry -- the type object?

Well it's an out-of-context quote, but t'was about creating the value object
that a variable contains a pointer to with the current CPython implementation.

I'm sure that more information about tagged variant schemes are available on the
net.

E.g. Wikipedia.

Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

mwilson at the-wire

Nov 6, 2009, 12:12 PM

Post #20 of 48 (852 views)
Permalink

Re: is None or == None ? [In reply to]

Alf P. Steinbach wrote:
> Note that the object implementation's complexity doesn't have to affect to
> any other code since it's trivial to provide abstract accessors (even
> macros), i.e., this isn't part of a trade-off except if the original
> developer(s) had limited
> resources -- and if so then it wasn't a trade-off at the language design
> level but a trade-off of getting things done then and there.

But remember what got us in here: your belief (which followed from your
assumptions) that computing `is` required testing the object types. You
might optimize out the "extra indirection" to get an object's value, but
you'd need the "extra indirection" anyway to find out what type it was
before you could use it.

Mel.

--
http://mail.python.org/mailman/listinfo/python-list

rami.chowdhury at gmail

Nov 6, 2009, 12:19 PM

Post #21 of 48 (848 views)
Permalink

Re: is None or == None ? [In reply to]

On Fri, 06 Nov 2009 11:50:33 -0800, Alf P. Steinbach <alfps [at] start>
wrote:

> * Rami Chowdhury:
>> On Fri, 06 Nov 2009 09:28:08 -0800, Alf P. Steinbach <alfps [at] start>
>> wrote:
>>
>>> * Rami Chowdhury:
>>>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps [at] start>
>>>> wrote:
>>>>
>>>>> But wow. That's pretty hare-brained: dynamic allocation for every
>>>>> stored value outside the cache range, needless extra indirection for
>>>>> every operation.
>>>>>
>>>> Perhaps I'm not understanding this thread at all but how is dynamic
>>>> allocation hare-brained, and what's the 'needless extra indirection'?
>>>
>>> Dynamic allocation isn't hare-brained, but doing it for every stored
>>> integer value outside a very small range is, because dynamic
>>> allocation is (relatively speaking, in the context of integer
>>> operations) very costly even with a (relatively speaking, in the
>>> context of general dynamic allocation) very efficient small-objects
>>> allocator - here talking order(s) of magnitude.
>> Well, sure, it may seem that way. But how large a cache would you want
>> to preallocate? I can't see the average Python program needing to use
>> the integers from -10000 to 10000, for instance. In my (admittedly
>> limited) experience Python programs typically deal with rather more
>> complex objects than plain integers.
>
> Uhm, you've misunderstood or failed to understand something basic, but
> what?

Oh, I see, you were referring to a tagging scheme as an alternative. Sorry
for the misunderstanding.

>
> Well it's an out-of-context quote, but t'was about creating the value
> object that a variable contains a pointer to with the current CPython
> implementation.
>

Again, perhaps I'm just misunderstanding what you're saying, but as I
understand it, in CPython if you're looking for the value of a
PyIntObject, that's stored right there in the structure, so no value
object needs to be created...

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
--
http://mail.python.org/mailman/listinfo/python-list

alfps at start

Nov 6, 2009, 12:49 PM

Post #22 of 48 (847 views)
Permalink

Re: is None or == None ? [In reply to]

* Mel:
> Alf P. Steinbach wrote:
>> Note that the object implementation's complexity doesn't have to affect to
>> any other code since it's trivial to provide abstract accessors (even
>> macros), i.e., this isn't part of a trade-off except if the original
>> developer(s) had limited
>> resources -- and if so then it wasn't a trade-off at the language design
>> level but a trade-off of getting things done then and there.
>
> But remember what got us in here: your belief (which followed from your
> assumptions) that computing `is` required testing the object types.

Yes, I couldn't believe what I've now been hearing. Uh, reading. :-)

> You
> might optimize out the "extra indirection" to get an object's value, but
> you'd need the "extra indirection" anyway to find out what type it was
> before you could use it.

No, that type checking is limited (it just checks whether the type is special
cased), doesn't involve indirection, and is there anyway except for 'is'. It can
be moved around but it's there, or something more costly is there. 'is' is about
the only operation you /can/ do without checking the type, but I don't see the
point in optimizing 'is' at cost of all other operations on basic types.

Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

pavlovevidence at gmail

Nov 6, 2009, 12:53 PM

Post #23 of 48 (846 views)
Permalink

Re: is None or == None ? [In reply to]

On Nov 6, 11:41 am, "Alf P. Steinbach" <al...@start.no> wrote:
> Note that the object implementation's complexity doesn't have to affect to any
> other code since it's trivial to provide abstract accessors (even macros), i.e.,
> this isn't part of a trade-off except if the original developer(s) had limited
> resources -- and if so then it wasn't a trade-off at the language design level
> but a trade-off of getting things done then and there.

I totally disagree with this; it would be like squaring the
implementation complexity. It is far from "trivial" as you claim.
Even if it were just a matter of accessor macros (and it isn't) they
don't write themselves, especially when you focused on speed, so
that's a non-trivial complexity increase already. But you besides
writing code you now have reading code (which is now cluttered with
all kinds of ugly accessor macros, as if the Python API wasn't ugly
enough), debugging code, maintaining code, understanding semantics and
nuances, handling all the extra corner cases. To say it's trivial is
absurd.

> > C# made a
> > different trade-off, choosing a more complex implementation, a
> > language with two starkly different object semantic behaviors, so as
> > to allow better performance.
>
> Don't know about the implementation of C#, but whatever it is, if it's bad in
> some respect then that has nothing to do with Python.

C# is a prototypical example of a language that does what you were
suggesting (also it draws upon frameworks like COM, which you
mentioned) so it is a basis of comparison of the benefits versus
drawbacks of the two approaches.

Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list

stefan_ml at behnel

Nov 6, 2009, 11:20 PM

Post #24 of 48 (823 views)
Permalink

Re: is None or == None ? [In reply to]

mk, 06.11.2009 15:32:
> Stefan Behnel wrote:
>> class Test(object):
>> def __eq__(self, other):
>> return other == None
>>
>> print Test() == None, Test() is None
>
> Err, I don't want to sound daft, but what is wrong in this example? It
> should work as expected:
>
> >>> class Test(object):
> ... def __eq__(self, other):
> ... return other == None
> ...
> >>> Test() is None
> False
> >>> Test() == None
> True

Yes, and it shows you that things can compare equal to None without being None.

> Or perhaps your example was supposed to show that I should test for
> identity with None, not for value with None?

Instead of "value" you mean "equality" here, I suppose. While there are
certain rare use cases where evaluating non-None objects as equal to None
makes sense, in normal use, you almost always want to know if a value is
exactly None, not just something that happens to return True when
calculating its equality to None, be it because of a programmer's concious
consideration or buggy implementation.

Stefan
--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Nov 7, 2009, 7:05 AM

Post #25 of 48 (813 views)
Permalink

Re: is None or == None ? [In reply to]

On Fri, 06 Nov 2009 16:51:18 +0100, Marco Mariani wrote:

> Using "x is y" with integers
> makes no sense and has no guaranteed behaviour AFAIK

Of course it makes sense. `x is y` means *exactly the same thing* for
ints as it does with any other object: it tests for object identity.
That's all it does, and it does it perfectly.

Python makes no promise whether x = 3; y = 3 will use the same object for
both x and y or not. That's an implementation detail. That's not a
problem with `is`, it is a problem with developers who make unjustified
assumptions.

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads