[Python-Dev] Int FutureWarnings and other 2.4 TODOs (original) (raw)
Aahz aahz at pythoncraft.com
Fri Dec 5 12:30:00 EST 2003
- Previous message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Re: Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Dec 05, 2003, Guido van Rossum wrote:
Aahz:
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.
Right, that's what's historically true. Question is, by the time 3.0 comes out, should it still be true? As pointed out downthread, we've already got a problem with the int free list; earlier discussions on python-dev have talked about ways of dealing with that (the simplest of which will be to make range() an iterator, since that's the most common problem source). Why not use some of that memory savings to make the int object easier to handle? "Simple is better than complex"; I suspect that we might have a win-win situation.
Perhaps we could push some of the memory-saving techniques into the long object?
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
- Previous message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Re: Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]