Michael Foord wrote: > On 26/01/2010 00:28, Christian Heimes wrote: >> I favor this approach over an integer offset because doesn't change the >> semantic of ob_item. >> > Well, on the face of it this doesn't sound like a huge increase in > complexity. Not that I'm qualified to judge.
Christian's approach is a good one for minimising the semantic changes, and compared to an offset based approach actually has a decent chance of working without breaking too much C code (you'd have to change the way sys.getsizeof() worked for lists, but I can't think of anything else off the top of my head that would definitely break). The potential of resizing and hence relocation of the storage buffer means it was already unsafe to cache ob_item when changing the size of the list, so code should generally be unaware that ob_item can now change even when the buffer isn't reallocated. However, as Cameron pointed out, the O() value for an operation is an important characteristic of containers, and having people get used to an O(1) list.pop(0) in CPython could create problems not only for other current Python implementations but also for future versions of CPython itself. This idea changes list from a simple concept (ob_item points to the beginning of an allocated array which may change length) to a more complicated deque-like one (ob_item points somewhere near the beginning of an allocated array which may change length). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
