New assignmens ...

[Antoon Pardon]

Op 27/10/2021 om 10:05 schreef Chris Angelico:
> On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon <antoon.pardon at vub.be> wrote:
>>
>>
>> Op 26/10/2021 om 00:24 schreef Chris Angelico:
>>> TBH, I don't think there's a lot of value in multiple-assignment,
>>> since it has a number of annoying conflicts of syntax and few viable
>>> use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
>>> then by all means, post on python-ideas to propose widening the scope.
>> I think you should seperate the costs from the benefits. It is not because
>> the costs can be high there is little value.
>>
>> And how do you count use cases? What about the following pattern:
>>
>> while (a, b) := next_couple(a,b)[-1]:
>>       ...
>>
>> Is that one use case or is that a use case for each kind of couple?
>>
>> And even if the benefits are little per case, they can add up with every
>> occasion such a case pops up.
>>
> I'm not sure that it's much of a use-case; isn't it an infinite loop as written?
>
> And that's the problem. With multiple-assignment, the overall value is
> going to be the tuple, so you then have to add extra parentheses and
> subscripting to get what you want to check. That makes it far less
> clean, far less tempting, far less valuable. You have to parenthesize
> the assignment target (otherwise it'll build a tuple out of one value
> and the assigned target), then parenthesize again, and subscript at
> the end.

That is only a problem if you want to consider it one. This wouldn't be the
only place in python where you have to be careful with parentheses. IMO it
should be the responsibility of each programmer to decide which way to
program will be most clean. Maybe you are completly right and at the
same time it could still be more clean than the other possibilitie python
allows.

> So if you want this added, show a use-case that makes it look way
> better than the alternatives (including a generator, a mid-loop break,
> etc).

Way better according to which criteria? IMO to realy make something like
this you would need a one and a half loop. But although at some time there
was a strong indication it would get included, the idea was eventually discarted.

So I'll argue for incremental better if I see a possibility. A few incremental
betters can eventually result in something that is way better than the original.