...

To show this on simple example:

...

...

...

from itertools import count, islice it = count() x, y = it it count(3)

For everyone else who was confused by this, as I was, that's not actually a copy and paste from the REPL. There should be a ValueError raised after the x, y assignment. As given, it is confusing because it looks like the assignment succeeded, when in fact it didn't.

...

Here the count was advanced two times but assignment did not happen.

Correct, because there was an exception raised.

Sorry for that, I did not want to embarrass anyone, so I wrote below that the assignment did not happen. But probably the code should speak for itself, especially if it looks like a copy from REPL

if isinstance(it, collections.abc.Iterator): # special case for iterators x, y = it else: # sequences keep the old behaviour x, y = it[:2]

No, it can be simply x, y = iter(it)

...

Cons: 1. A special case of how assignment works 2. As with any implicit behavior, hard-to-find bugs

Right. Hard-to-find bugs beats any amount of convenience in the interactive interpreter. To use an analogy:

"Sure, sometimes my car suddenly shifts into reverse while I'm driving at 60 kph, sometimes the engine falls out when I go around the corner, and occasionally the brakes catch fire, but gosh the cup holder makes it really convenient to drink coffee while I'm stopped at traffic lights!"

:-) Perhaps a better idea might be special syntax to tell the interpreter

you don't want to run the right-hand side to completion. "Explicit is better than implicit" -- maybe something special like:

x, y, * = iterable

I wrote somewhere above, that "may be I like this form". But for me * '"starred" target implies -> collect something from iterable. So now I'm towards: x, y, ... = iterable But I have not summed up yet what pitfalls can be on this path. Thank you your remarks were very extensive! With kind regards, -gdg