> > Im not sure if this is a genuine understanding, or trollish > > obtuseness. > > If you are referring to what I write, it is based on genuine > understanding of Python.
This is getting 'interesting'. In a way. I meant to write 'misunderstanding', as I think the context made quite clear. So again this adds another layer of doubt as to whether you are being obtuse for its own sake, or if there is yet another layer of misunderstanding stacked on top of the others. Either way, lets continue with the benefit of the doubt. > One use case of *target is to ignore the stuff collected in the target > because one only wants a few end values from the iterable. Another is to > pull stuff out because one wants to iterate through the rest. For both > uses, a list is as good as anything. So what is the point of having different sequence types, if a list can do anything? I would argue that the different performance characteristics and differences in semantics give each sequence type ample reason for existence. > Convert. For the very few cases one wants to do this, it is quite adequate. Or so you opine. As you may recall, the original idea was motivated by args/kwargs syntactic clarity and flexibility; I merely shifted focus to this use case of collection unpacking since it is somewhat simpler and easier to discuss. Keep that in mind, should you seek to build a case for that assertion in the future. > > but the question is whether this language design can be improved upon. > > Not easily. Again, so you opine. Care to give a refutation of my proposed double colon syntax? Ignoring for a moment whether or not it is useful; does it clash with anything? I havnt been able to think of anything in the past few hours, but im not taking that to mean much; there are probably some subtleties I am overlooking. I think it dos not clash with slicing syntax for instance, but im not sure. > For a linked list, no *target and no copying is needed: > > head, tail = llist I have no idea what this means. > >>>> head, deque(tail) = somedeque > > > Is better in every way I can think of (readability, consistence, > > performance) than: > >>>> head, *tail = somedeque > >>>> tail = deque(tail) > > But your suggestion is much worse in each way than > > head = somedeque.popleft() No its not. First of all, its not semantically equivalent; popleft mutates a collection type, and collection unpacking does not; it creates a set of disjoint views of the collection's data. Whether its worse in terms of readability is debatable, but in terms of the other two stated metrics, your claim of it being any kind of worse is objectively false. Furthermore, this brings us back again to the point I raised several times before. Yes, obviously you can already DO these things, but NOT within the same uniform collection unpacking syntactic construct. Again, you have failed to point out what is wrong with supplying a type constrain to python and let it do the right thing based on that; to reiterate: head, tail::deque = deque No need to mutate anything; python can create the view of the linkedlist internally. A single unambigious syntax, and single unambigious semantics, for all sequence types. Whats not to like? If you dont like the extra characters you have to type; there is of course such a thing as defaults. You can choose: head, tail:: = deque; if the type constraint is omitted, we could make tail a list by default, or my preferred solution, infer it from the right hand side type. In case of the former, all you had to do was type :: instead of *, and your python universe would otherwise be completely unchanged. If thats 'not easily', I dont know what is. > To repeat, there is no reason to copy even once. If one does not want to > mutate the deque, then one mutates an iterator view of the deque. And arrive at yet another construction to do the same thing. -- http://mail.python.org/mailman/listinfo/python-list
