> 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