list.pop(0) vs. collections.dequeue

Terry Reedy tjreedy at udel.edu
Sat Jan 23 03:13:49 EST 2010


On 1/23/2010 12:58 AM, Steve Howell wrote:

> I really want to use list *normally* with all its perfectly good
> semantics and reasonable implementation, except for its blind spot
> with respect to popping the first element off the list.

It was not designed for that. .pop() was added to lists about 10 years 
ago because I asked for it (with no parameter, pop off end only) and 
wrote what would now be a PEP -- and because Tim Peters later supported 
the idea. Adding the optional parameter was something of an afterthought 
(never publicly discussed as far as I know) for occasional use for 
'short' lists where O(n) is tolerable. You have half persuaded me that 
that the parameter addition was a mistake. Perhaps is is too attractice 
a nuisance for some people ;=).

>  The whole
> reason I use CPython vs. C in the first place is that CPython
> programmers can generally program basic data structures better than I
> can.

They have given us three options other that .pop(0).

1. listiterator
2. queue.Queue
3. collections.deque\

Why are you so stubborn about not using a data structure intended for 
your use case instead of one that was not?

There is also
4. a two-list design for queues: iterator through one (or pop() from a 
reversed version thereof) while appending to another; switch when the 
first is empty. I plan to write it up with tests some day this year.

> I know Python's number one concern will never be speed, but if Python
> makes an O(1) operation into an unnecessarily O(N) operation for no
> good reasons other than "it's too complicated, " or it "adds another
> pointer to the structure," or "it adds another conditional check to
> list_ass_slice for operations that aren't popping off the top," I
> think it's reasonable to challenge the design philosophy.

Challenge yes, mock no.

Part of writing good basic data structures is not adding needless 
complication from featuritis and not penalizing 99.99% of access to 
satify a .01% need better satisfied another way.

Terry Jan Reedy





More information about the Python-list mailing list