On Dec 13, 7:15 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote: > 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.
Fair enough. Still, I dont readily see myself using the construct, and I do feel myself longing for something like that to be included as a builtin collection type. Im not sure why python is so stingy with the collections it provides. > > 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. True > > 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. Yes, I think consistent semantics over all sequence types is very important. Although, returning a view for immutable collections like tuples and 'functional lists' (for lack of a better term), and always returning a copy for mutable container types (lists and doubly-linked- lists / deques) is not so bad either, imo. Just one extra simple rule that is clear and obvious enough. > > 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. How are we contributing to it? If we dont know the type of the RHS, we dont know the type of the LHS either, but its not like we lost any information. If we do know the type of the RHS, then we do know the type of the LHS as well; its conserved. > 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. Thanks for the constructive feedback; something to think about. -- http://mail.python.org/mailman/listinfo/python-list
