Dumb python questions

[Tim Peters]

[Andrew Dalke]
> Now my chance to ask a dumb question.  When do you need to know
> how many bits are used for a number?  I admit to never needing
> that functionality, but then again, I've almost never used long
> integers in real code.

It's a common enough need in bigint code, but since you almost never use the
latter, it's expected that you wouldn't see a need for the former <wink>.

Determining the number of bits "should be" a constant-time operation, but
there's no way to get at it from Python now faster than O(log2(N)), i.e.
time proportional to the number of bits (BTW, the quickest way is to use
marshal to create a string and then reverse-engineer the marshal storage
format -- using hex() is simpler, but a bit slower last time there was a
speed battle comparing the two).

When a builtin operation doesn't have the right order behavior, that
propagates up into every algorithm using it; e.g., what "should be" a
linear-time algorithm can turn into an N*log N algorithm, and so on.  Many
examples of this unpleasant phenomenon were posted in years past, although I
don't recall any recently.

About twice every three years, somebody gets excited about this, and says
they're going to "do something" about it; and Guido approved of the idea of
adding some methods to longs years ago.  In reality, nothing happens,
apparently because the kind of person who gets excited about this can't
restrain themself from getting excited about all sorts of other enhancements
too, and that's fatal for all the usual reasons.

I hope that the next time this happens, we're at least left with a PEP to
remember it by <wink>.