Issue470429
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-10-11 23:31 by phr, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Messages (2) | |||
---|---|---|---|
msg6903 - (view) | Author: paul rubin (phr) | Date: 2001-10-11 23:31 | |
I'm not sure how to submit this--"feature request" isn't really right. A documentation bug may also be involved. The specification for integers is in section 2.1.4 "Numeric Types" of the Python 2.1.1 library docs, which makes it unclear whether integers are supposed to be part of the language spec, or part of the library--so alternative implementations can implement integers differently and still conform to the language spec. Anyway, the Numeric Types section says "Plain integers (also just called integers) are implemented using long in C, which gives them at least 32 bits of precision". I don't think a sentence like that should be in a specification, since it describes how something is implemented (using long in C) rather than how it should behave. For example, Jython uses java ints or longs rather than C longs, so the description that ints are implemented as C longs is simply incorrect. So if this section is supposed to be a specification, the reference to C longs should be removed, or clearly labelled as a description of how one particular implementation works. More substantively, I think the requirement that ints have 32 bits of precision should be relaxed to 30 bits. That just means changing the specification-- implementations are free to continue supporting 32 bit ints. But it makes it easier to implement Python using 32-bit words with tag bits, a traditional implementation method for dynamically typed languages. Numerous processors even offer hardware support for tagged integers--not just special processors like Lisp machines, but also general purpose RISC cpu's like the Sparc. Since Python offers arbitrary sized longs and already doesn't promise a fixed size for ints, I don't think it would suffer by offering implementers a little more flexibility. In a more philosophical vein, Python is a really cool language and the designers should begin to think of "success" in terms of more implementations being developed, native-code compilers being written, a possible ANSI standard some day, etc. So care should be taken to keep the formal specification as precise as possible, and free of requirements of things that are really just implementation hacks. |
|||
msg6904 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-10-12 13:46 | |
Logged In: YES user_id=6380 The documentation reference to C long ints is not intended to require any particular implementation; rather, it is intended to require that the range requirements for Python ints are the same as those for C longs -- basically, at least 32 bits precision. We could change the docs to clarify that, but I'm not sure what purpose it serves. Implementations should behave *as if* it were implemented using C longs on some hypothetical architecture, and that's what Jython does. Regarding the suggestion to reduce the limit to 30 bits: the trend is going the other way. Read PEP 237. Eventually there won't be any difference between plain and long ints, so I don't see a point in reducing the number of bits for plain ints. If you do an alternative implementation that limits plain ints to 30 bits and gracefully overflows to long ints, that may technically not be conforming, but in a few years it will be, so who cares. I personally define success in terms of number of users. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:31 | admin | set | github: 35313 |
2001-10-11 23:31:36 | phr | create |