2017-11-29 22:33 GMT+03:00 Steve Barnes
Just a thought but what about a syntax something along the lines of:
a, b, *remainder = iterable
Where remainder becomes the iterable with the first two values consumed by assigning to a & b. If the iterator has less than 2 values, (in the above case), remaining it should error, if it has exactly 2 then remainder would become an exhausted iterable. Of course the user could also use:
a, b, *iterable = iterable
Others may differ but this syntax has a lot of similarity to the f(a, b, *args) syntax, possibly enough that most users could understand it.
Before I started this thread, not so long ago, I have already asked a question about this semantics [1 https://mail.python.org/pipermail/python-ideas/2017-November/048027.html]. But it appears to be very ambiguous in practice for the various rhs: ... x, *y, z = some_iter *x , y, z = some_iter x, y, *z = some_iter And only for the last case it will mean something special. In addition, it is a huge backward compatibility break. Probably, some time ago it was necessary to split this thread into two questions: 1. Philosophical question regarding sequences and iterators. In particular, should they behave differently depending on the context, or, in other words, whether to emphasize their different nature as fixed-size containers and those that are lazily produce values on demand. 2. Additional syntax in the assignment statement for partial extraction of values from the iterable. 2017-11-30 22:19 GMT+03:00 Paul Moore
Mostly corner cases, and I don't believe there have been any non-artificial examples posted in this thread.
Certainly no-one has offered a real-life code example that is made
significantly worse by the current semantics, and/or which couldn't be easily worked around without needing a language change.
Yes, in fact, this is a good question, is whether that is sufficiently
useful to justify extending the syntax. But it is not about corner cases,
it is rather usual situation.
Nevertheless, this is the most difficult moment for Rationale. By now, this
feature does not give you new opportunities for solving problems. It's more
about expressiveness and convenience. You can write:
x, y, ... = iterable
or,
it = iter(iterable)
x, y = next(it), next(it)
or,
from itertools import isclice
x, y = islice(iterable, 2)
or,
x, y = iterable[:2]
and others, also in some cases when you have infinite generator or
iterator, you should use 2nd or 3rd. In fact, this has already been said
and probably I will not explain it better:
2017-11-28 1:40 GMT+03:00 Greg Ewing
Guido van Rossum wrote:
Is this problem really important enough that it requires dedicated syntax? Isn't the itertools-based solution good enough?
Well, it works, but it feels very clumsy. It's annoying to have to specify the number of items in two places.
Also, it seems perverse to have to tell Python to do *more* stuff to mitigate the effects of stuff it does that you didn't want it to do in the first place.
Like I said, I'm actually surprised that this doesn't already work. To me it feels more like filling in a piece of functionality that was overlooked, rather than adding a new feature. Filling in a pothole in the road rather than bulding a new piece of road.
(Pushing the road analogy maybe a bit too far, the current itertools solution is like digging *more* potholes to make the road bumpy enough that you don't notice the first pothole.)
(Or failing that, couldn't we add something to itertools to make it more
readable rather than going straight to new syntax?)
I'm not sure how we would do that. Even if we could, it would still feel clumsy having to use anything from itertools at all.
With kind regards, -gdg