> > To my mind, the *ideal* is that there's a single type, probably > > called "int" or "integer" which can take on an arbitrary size and > > precision BUT which, if it happens to be small enough to fit in > > a C int will take up less memory and run faster. The fact that > > it's stored differently should be an implementation detail not > > visible to the user. > > Hmmmm... How important is the "less memory" angle versus the "faster" > angle? Why not just add a few bytes to the long type to store an int? > If you're using the int, the pointer is NULL, and you're saving that > memory, at least. The only harm is some extra memory in the type > object. I'd say that the "less memory" angle is pretty important. The int implementation has been using every trick in the book to save memory from very early days on: it has the most sophisticated special-purpose allocator, *and* it uses a cache for popular values, *and* you really can't squeeze any more bits out of the structure. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4