is None or == None ?
Alf P. Steinbach
alfps at start.no
Fri Nov 6 20:41:41 CET 2009
* 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>
>>>> 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
> 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.
More information about the Python-list