On Tue, Dec 13, 2011 at 1:44 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote: > 'for i in llist' is not quite going to fly is it? Thats probably the > reason noone ever uses that construct; its not a proper sequence type.
Not really a problem, because fortunately Python makes it super-easy to create custom iterators. def listiter(llist): while llist: head, llist = llist yield head And you're done. If you like, you could also wrap this up in a class with all the sequence-related magic methods you want, although you lose the simplicity of the literal syntax by doing so. If this is rarely used, it is more likely because custom containers are going to be less efficient than built-ins, but if you want to do functional programming and are not overly concerned with the speed of iteration, this is not a bad way to do it. > Good point. Copy-on-write semantics could be used, but really one > should have several linked list types reflecting the underlying > implementations. I would like to have an immutable singly linked list > builtin of the standard functional type, which you can only unpack > from one end and renders these issues moot, plus a builtin doubly > linked list with copy-on-write or copy-on-unpacking semantics. Copy-on-write could be implemented with any type. You don't need a doubly linked list for that. > We are not talking black magic here; we are talking about an EXPLICIT > type constraint provided on the very same line. An explicit type constraint with very different semantics depending on what particular type you specify and what particular type you're unpacking from, as I had understood it before. Now you seem to be saying that it would always be a copy, but sharing state with copy-on-write possible, which is a different situation. > Well perhaps, but not always knowing the type of your objects at write- > time is inherent to weakly typed languages; this happens all the time. > Not knowing the type of the sequence to be unpacked is in a sense an > asset; I can use this construct in a function, and unpack any sequence > type in a manner appropriate for it. About the result of the unpacking > I will know just as much as about the input to it; that they are the > same type. Just because the issue is inherent doesn't mean we should contribute to it. Knowing that an object is an arbitrary sequence is fine if all you want to do is iterate and index it. If you want to do anything else, then it's important to know the type. The copy-on-write suggestion does make the type-matching approach a bit more attractive. On the other hand, it's also more fragile (what if the type being unpacked can't be constructed from an iterable? For example, a database cursor), so that approach potentially needs additional error-handling. Anyway, the more I think about it, that concern is really more of an issue for straight copying. One of my pet peeves is that I prefer list(x) for copying sequences rather than the more common x[::]. The latter is fine if all I need is an immutable sequence of uncertain type to iterate and index over -- but then why did I need to make a copy? Unpacking implies different use cases, though, and maybe a good argument can be made for it to match type. -- http://mail.python.org/mailman/listinfo/python-list