[Python-Dev] deque alternative (was: Linked lists)
Phillip J. Eby
pje at telecommunity.com
Mon Dec 26 04:08:36 CET 2005
At 09:10 PM 12/25/2005 -0500, Martin Blais wrote:
>I still haven't had time to cook a proper reply to Guido, but one
>thing I see is that many ppl on the list seem to think that because
>there aren't many use cases (that they can see), therefore there isn't
>much use for a list collection type. I would instead argue that
>because the list type has never been available, people have gotten
>used not to use them, and therefore settle with arrays and do not see
>a need for them.
Since I routinely use 2-item tuples (twoples?) as cons cells when I
actually need a linked list, I think I'm in a good position to say that
this isn't true. Certainly it's not true for me.
Since Python effectively has single-character operations for both consing
and car/cdr (a ',' on the right or left sides of an assignment statement
respectively), as well as trivial truth testing for () as a "nil", suggests
to me that anybody who wants a lispy list can easily have one. For any
application where such a structure excels (like shared sublists/trees and
recursive traversals), it's so darn easy to use them in Python that I don't
think anything special is needed.
Honestly, ISTM that the One Obvious Way to do lispy lists in Python is to
just use two-tuples, with no special library functions. Sequence packing
and unpacking is extremely fast in Python, too, probably faster than any
method calls to a more heavyweight builtin type could be.
Thus, I'm -1 on creating another cons type. Why do this:
foo = cons(bar, None)
car_foo = foo.car
cdr_foo = foo.cdr
when you can just do this:
foo = bar, ()
car_foo, cdr_foo = foo
How much simpler can you get?
More information about the Python-Dev
mailing list