On 2/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > Now consider how nice it would be, on occasion, to be able to operate > on an integer that's guaranteed to be 8, 16, 32, or 64 bits, to > ensured the desired shifting/masking behavior for certain kinds of > low-level programming; and also on one that's unsigned, in each of > these sizes. Python could have a module offering signed8, unsigned16, > and so forth (all combinations of size and signedness supported by the > underlying C compiler), all subclassing the abstract int, and > guarantee much happiness to people who are, for example, writing a > Python prototype of code that's going to become C or assembly...
I dearly hope such types do NOT subclass abstract int. The reason is that although they can represent an integral value they do not behave like one. Approximately half of all possible float values are integral, but would you want it to subclass abstract int when possible? Of course not, the behavior is vastly different, and any function doing more than just comparing to it would have to convert it to the true int type before use it. I see little point for more than one integer type. long behaves properly like an integer in all cases I can think of, with the long exception of performance. And given that python tends to be orders of magnitudes slower than C code there is little desire to trade off functionality for performance. That we have two integer types is more of a historical artifact than a consious decision. We may not be willing to trade off functionality for performance, but once we've already made the tradeoff we're reluctant to go back. So it seems the challenge is this: can anybody patch long to have performance sufficiently close to int for small numbers? -- Adam Olsen, aka Rhamphoryncus _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
