is None or == None ?
in [Python]
|
Prev: 2to3 on Mac - unknown encoding: mbcs
Next: safely returning objects from a Process to the parent through aQueue()
From: Rami Chowdhury on 6 Nov 2009 12:04 On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps(a)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'? -- 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)
From: Raymond Hettinger on 6 Nov 2009 12:21 On Nov 6, 5:20 am, mk <mrk...(a)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
From: Alf P. Steinbach on 6 Nov 2009 12:28 * Rami Chowdhury: > On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps(a)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. 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
From: Hrvoje Niksic on 6 Nov 2009 12:22 "Alf P. Steinbach" <alfps(a)start.no> 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
From: Alf P. Steinbach on 6 Nov 2009 13:45
* Hrvoje Niksic: > "Alf P. Steinbach" <alfps(a)start.no> 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 |