is None or == None ?

[Alf P. Steinbach]

* Carl Banks:
> On Nov 6, 9:28 am, "Alf P. Steinbach" <al... at start.no> wrote:
>> * Rami Chowdhury:
>>
>>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <al... at 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