Mailing List Archive

1 2 3  View All
Re: New assignmens ... [ In reply to ]
On Tue, Oct 26, 2021 at 7:18 AM Antoon Pardon <antoon.pardon@vub.be> wrote:
>
> Op 25/10/2021 om 20:39 schreef Chris Angelico:
> > On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon <antoon.pardon@vub.be> wrote:
> >> By putting limits on the walrus code, you are not reducing complexity, you are increasing it.
> >> You are increasing complexity because you can't just reuse the code that handles an ordinary
> >> assignment. You now need specific code to limit it's use.
> >>
> > What does this code do?
> >
> > while x, y := foo():
> > ...
> >
> > Is it more complicated or less complicated when arbitrary assignment
> > targets are permitted?
>
> Well I would guess it would do something similar to
>
> while [x, y := foo()]:
> ...
>

And does it unpack what foo returns?

Should it?

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ... [ In reply to ]
We have had discussions debating if Python is a good language for teaching.
The short answer is NO unless you only teach a small subset and the students
know there is more they can learn as needed. The language is too rich and
has too many ways to do seemingly anything and that is before you add more
functionality. But that can make it a great language for developers.

Assignments in middle of expressions are often syntactic sugar that may be
re-arranged internally to similar code than what could be done other ways
without it. It can lead to ambiguities. And it can make it harder for anyone
other than the programmer that wrote it (or them a day later) to understand.

So, while we are at it, why not add the ++ and --- operators that were
deliberately NOT included in Python? Why not throw back pointers?

The short answer is that there are plenty of programming languages to choose
from and some of those do have the features you want and some do not want
them. Sure, you might push in what you want but have you considered all the
places it might be tried? Can you do it in a comprehension where an
assignment is implicitly being done?

[ var := 5 in range(10) ]

The old adage is that some people will be given a finger and take a hand. I
had NOTHING to do with the process but others here know more. Chris suggests
that there was a compromise of sorts here and a choice to implement a
limited subset of fuller functionality for NOW without ruling out doing some
more later. So those wanting more, feel free to petition for it as an
ADDITION but I suggest a more polite tone than trying to say the people who
did it were idiots who did it badly.

Personally, I don't care what is done and suspect I will rarely feel much
need to use the current walrus operator, let alone an enhanced Odobenus
rosmarus operator like ::== ...

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Christman, Roger Graydon
Sent: Monday, October 25, 2021 12:48 PM
To: python-list@python.org
Subject: Re: New assignmens ...

Message: 8
Date: Mon, 25 Oct 2021 11:20:52 +0200
From: Antoon Pardon <antoon.pardon@vub.be>
To: python-list@python.org
Subject: Re: New assignmens ...
Message-ID: <5761dd65-4e87-8b8c-1400-edb8212048db@vub.be>
Content-Type: text/plain; charset=utf-8; format=flowed On 25/10/2021 11:20,
Anton Pardon wrote:
> Suppose I would like to write a loop as follows:

> while ((a, b) := next_couple(a, b))[1]:
> do needed calculations


> What I can do is write it as follows:

> while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
> do needed calculations

> I really don't see what is gained by "forcing" me to right the second code
over the first.

No, nobody is forcing you to right it the second way over the first.
Nobody is forcing you to use the walrus operator at all!

Instead, I would recommend something more like:

while b:
do needed calculations
(a,b) = next_couple(a,b)

This requires even less typing than what you had before!

But it also raises a whole lot of problems with this particular example:
-- neither a nor b is defined in your sample while loop. It seems you
would
need to initialize a and b before your while loop (and mine)
-- is b truly a boolean value, or are you short-cutting some other value?
-- are a and b truly necessary parameters to next_couple, or are they just
there to remind the function of its previous return values?
If the latter, poerhaps you want a stream or list or something with
yield

This example (and some of the others I have seen) just highlight how
programmers will take advantage of any new tool to help them write
worse code than if they did not have the tool. In my mind, the walrus
operator was designed to serve a particular niche case like this one:

while (x := input()) > 0:

where not having the operator required duplicating the input() operation
both before the loop and at the end of the loop -- or more complicated
cases where some additional operations had to be performed to get that test
value for the while condition (such as getting the b out of (a,b)).

But the walrus only adds a benefit if it is there to avoid the duplication
of the code that is used to obtain that test condition. This next_couple
example does not qualify, since apparently (a,b) are initialized by some
other means (and not be a call to next_couple with undefined values)

Or the other abuse I saw recently about using the walrus operator:

while (self.ctr := self.ctr-1) > 0:

-- there was no compelling reason for a loop counter to be a class variable
(anyone who peeks at this counter when the loop is down would only see a
zero)
-- this requires self.ctr to be initialized to a value one higher than the
first meaningful value (start at 11 if you want to count down from 10) So my
recommended alternative, which furthermore also takes less typing:

while ctr > 0:
...
ctr = ctr-1

TL;DR: The Walrus operator serves the purpose as described in its PEP
just as it is, and I see no compelling reason to expand its use.
It is there to reduce code size by eliminating a duplication of code, If the
code you write using the walrus operator is longer or more complicated than
the code would be without it, you are misusing it.

Roger Christman
Pennsylvania State University
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list
<python-list@python.org> wrote:
> Personally, I don't care what is done and suspect I will rarely feel much
> need to use the current walrus operator, let alone an enhanced Odobenus
> rosmarus operator like ::== ...
>

..... wait what?

Ah. Had to look that one up. :)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On 26/10/2021 10.45, Chris Angelico wrote:
> On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list
> <python-list@python.org> wrote:
>> Personally, I don't care what is done and suspect I will rarely feel much
>> need to use the current walrus operator, let alone an enhanced Odobenus
>> rosmarus operator like ::== ...
>>
>
> ..... wait what?
>
> Ah. Had to look that one up. :)


Each year I assist friends who own one of local orchards, at harvest
time. I usually run the sealing machine, to preserve fruit which will be
transported refrigerated. It is such a novelty to be asked to fill-out
a time-sheet. Under "name" it asks for "position", so I entered
"Erignathus barbatus" (bearded seal), which caused similar
consternation, and for some days, until someone thought to look it up...


Back on-topic, I am slightly curious:-

aside from 'starting small' with an option to widen/'open-up' later, is
there a particular reason why 'the walrus' has not been made available
(could not be ...?) for use with object-attributes?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On Tue, Oct 26, 2021 at 9:19 AM dn via Python-list
<python-list@python.org> wrote:
> Back on-topic, I am slightly curious:-
>
> aside from 'starting small' with an option to widen/'open-up' later, is
> there a particular reason why 'the walrus' has not been made available
> (could not be ...?) for use with object-attributes?

I can't think of any other reasons. But the one you cite is quite an
important one. In order to get real-world usage examples, the feature
was rolled out in the restricted form, because threads like this are
*exactly* how the value can be judged. So I do not in any way regret
that assignment expressions were accepted in their current form, but
also, don't be afraid to propose an opening up of the syntax. Be
specific, and cite usage examples that would benefit.

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.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ... [ In reply to ]
Stefan,

Yes, I often pass even fairly trivial functions like "add" or "+" or
whatever the language makes me say, to other functions in various forms of
functional programing. My point is that my example may seem trivial and not
necessary as an EXAMPLE of the greater point that may be easier to
understand than something complex. A sum() is often a generalization of
adding two things by allowing a second addition to the sub-sum and so on.
But in a straightforward program where I am asking to add exactly two
things, few would use sum(a,b) versus just a+b. On the other hand, in
agreement with you, if I have two vectors or matrices or some other such
data holder and I want to add each position to a corresponding position,
then some kind of call to a function where I pass the two objects and the
name of a function that adds two things, is a decent way to go. But it need
not be a souped-up generalized_sum() function when a simple one will do and
be faster when invoked so many times.

And note often what is used is a temporary lambda anonymous function that
may look like \(x,y) x+y ... or whatever syntax your language uses.


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Stefan Ram
Sent: Monday, October 25, 2021 12:57 PM
To: python-list@python.org
Subject: Re: New assignmens ...

"Avi Gross" <avigross@verizon.net> writes:
>Now, yes, nobody needs a function to just add two numbers.

If one uses a framework like "functools.reduce", the only
way to reduce an iterable to its sum, is to do just that:
Write a function to add two numbers.

Of course, one can circumvent "functools.reduce" (or use
"operator.add"), but in other cases there are frameworks
that need to be used and where one sometimes does need to
write functions (callbacks) as simple as "lambda: None".


--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 25/10/2021 om 23:03 schreef Chris Angelico:
> On Tue, Oct 26, 2021 at 7:18 AM Antoon Pardon <antoon.pardon@vub.be> wrote:
>> Op 25/10/2021 om 20:39 schreef Chris Angelico:
>>> On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon <antoon.pardon@vub.be> wrote:
>>>> By putting limits on the walrus code, you are not reducing complexity, you are increasing it.
>>>> You are increasing complexity because you can't just reuse the code that handles an ordinary
>>>> assignment. You now need specific code to limit it's use.
>>>>
>>> What does this code do?
>>>
>>> while x, y := foo():
>>> ...
>>>
>>> Is it more complicated or less complicated when arbitrary assignment
>>> targets are permitted?
>> Well I would guess it would do something similar to
>>
>> while [x, y := foo()]:
>> ...
>>
> And does it unpack what foo returns?
>
> Should it?

1) No it doesn't.

2) I don't care. This is IMO not a question of what should or should not, but just a
question of deciding how you want to treat this. I guess that since it doesn't unpack
already, this behaviour is more or less fixed for futere releases. Should the python
developers in the future decide that de walrus operator can unpack things. The above
code will not unpack in order to not break already existing code and if you want
to unpack one will have to write something like:

while [(x, y) := foo()]:
...

But the answer to that second question has very little relevance to how complicated the
parser will be. It is just deciding which of , or := has a higher precedence. Since that
decision has already been more or less made, there is not much to decide here either.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list
RE: New assignmens ... [ In reply to ]
Why force unpacking? Why not assign a tuple? That would look like a simple assignment: x := (alpha, beta, gamma)
And you could access x[0], x[1] and x[2].

I think asking := to support x, y := alpha, beta is a request to address an unnecessary, easily worked around, issue. And as previously pointed out you can still just use = .

--- Joseph S.


Teledyne Confidential; Commercially Sensitive Business Data

-----Original Message-----
From: Chris Angelico <rosuav@gmail.com>
Sent: Monday, October 25, 2021 6:25 PM
To: Python <python-list@python.org>
Subject: Re: New assignmens ...

On Tue, Oct 26, 2021 at 9:19 AM dn via Python-list <python-list@python.org> wrote:
> Back on-topic, I am slightly curious:-
>
> aside from 'starting small' with an option to widen/'open-up' later,
> is there a particular reason why 'the walrus' has not been made
> available (could not be ...?) for use with object-attributes?

I can't think of any other reasons. But the one you cite is quite an important one. In order to get real-world usage examples, the feature was rolled out in the restricted form, because threads like this are
*exactly* how the value can be judged. So I do not in any way regret that assignment expressions were accepted in their current form, but also, don't be afraid to propose an opening up of the syntax. Be specific, and cite usage examples that would benefit.

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.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 25/10/2021 om 18:47 schreef Christman, Roger Graydon:
> Message: 8
> Date: Mon, 25 Oct 2021 11:20:52 +0200
> From: Antoon Pardon <antoon.pardon@vub.be>
> To: python-list@python.org
> Subject: Re: New assignmens ...
> Message-ID: <5761dd65-4e87-8b8c-1400-edb8212048db@vub.be>
> Content-Type: text/plain; charset=utf-8; format=flowed
> On 25/10/2021 11:20, Anton Pardon wrote:
>> Suppose I would like to write a loop as follows:
> > while ((a, b) := next_couple(a, b))[1]:
> > do needed calculations
>
>
>> What I can do is write it as follows:
>> while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
> > do needed calculations
>
>> I really don't see what is gained by "forcing" me to right the second code over the first.
> No, nobody is forcing you to right it the second way over the first.
> Nobody is forcing you to use the walrus operator at all!
>
> Instead, I would recommend something more like:
>
> while b:
> do needed calculations
> (a,b) = next_couple(a,b)

But AIU the walrus operator was introduced so we no longer needed, to write such code,
with the calculation of the next candidate at the bottom and the test at the top.
You just confirmed the walrus operator is not very useful once the next candidate is
no longer just a name.

--
Antoon.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 26/10/2021 om 19:46 schreef Schachner, Joseph:
> Why force unpacking? Why not assign a tuple? That would look like a simple assignment: x := (alpha, beta, gamma)
> And you could access x[0], x[1] and x[2].
>
> I think asking := to support x, y := alpha, beta is a request to address an unnecessary, easily worked around, issue. And as previously pointed out you can still just use = .

Because the names usually have meaning, while the tuple has not.

And you just confirmed my point that the walrus operator isn't very useful here
by suggesting that I should abandon it and use an assignment.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
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.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon <antoon.pardon@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.

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).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 27/10/2021 om 10:05 schreef Chris Angelico:
> On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon <antoon.pardon@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.
>
> 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).
>
> ChrisA

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On 24/10/2021 22.23, O365 Dict wrote:
> Well I have the following use case:
>
> while (temp_result := calculate_next_couple(a, b))[1]:
> a, b = temp_result
> more calculations
>
> Which IMO would be clearer if I could just write:
>
> while ((a, b) := calculate_next_couple(a,b))[1]:
> more calculations
>
> Of course it would even more clear if I could write something like:
>
> while (a, b) := calculate_next_couple(a, b); b:
> more calculations
>
> or
>
> do:
> a, b = calculate_next_couple(a, b)
> while b:
> more calculations


Found (all of) the above less-than-obvious to read. Putting it in front
of trainees this morning caused only confusion - even the
currently-legal variation.


Accordingly: is this a job for the walrus operator at all? Let's "talk
of many [other] things"*.


Is this an algorithmic complexity, or a complicated way to look at (and
manipulate) data?

Well, judging from the code (above), use of the walrus certainly
presumes the former. Instead let's review any possibility of the latter
(if only for academic interest)...


What do we want out of the first line? (in no particular order)

1 use calculate_next_couple() to compute (new) a from an (old) a and b
2 use calculate_next_couple() to compute (new) b from an (old) a and b
3 use (new) b to decide if the loop should execute or terminate

The 'problem' then, has been phrased as these three objectives ask too
much of the (current implementation of the) walrus-operator.


NB after one (or more) cycles, when the loop 'returns to the top', what
I've termed 'new' a and b (above), will become (my reference) the 'old'
pair/tuple.


That all looks simple. What is dn complaining about?


Could we use a data structure to continue to keep things straight-forward?

class my_class():
def __init__( self, a, b )->None;
self.a = a
self.b = b

instance = my_class( a, b )


Sorry, you're probably becoming impatient with me. Surely I'm typing
more code than necessary? Maybe, but there are other measures of
code-quality/good-practice/etc, and there's likely more to 'it' than
just these few lines...


First consideration: the algorithm needs us to 'feed' the
while-condition. So let's flesh-out:

def is_more( self )->bool:
# you know what goes here - I don't, but that's not the issue
# the return value is all that matters
return is_there_any_more_data_to_calculate?

In which case, the loop becomes:

while instance.is_more():
more calculations

and 'readability' improves immeasurably!

NB for extra credit, turn the boolean function into a "property", and be
able to omit the (unsightly?) parentheses from the 'call'!


But, not so fast - what about the calculation itself, currently embedded
in calculate_next_couple()?

Well, those details are out of my sight, and I'm assuming include
reasonable complexity - otherwise you wouldn't propose this as a
good-example. Allow me to muddle-through with:

def calculate_next_couple( self )->None:
self.a = calculation of 'new' a
self.b = calculation of 'new' b

To avoid an 'extra' call against the instance from the while-loop,
execute the 'calculate' method from either __init__() or is_more(), as
appropriate (given that it likely needs to precede the return from the
latter - particularly if the computation is 'expensive'). The choice may
be subject-dependent ...


Now within "more calculations", one assumes, references to "a" and "b"
will need to be amended to become 'instance.a' and 'instance.b'. More
typing! What about preserving our fingers?


Readability will further improve when "a" and "b" (etc) are replaced by
'real names'.

The processing steps within "more calculations" could be reviewed. Some
may be candidates for inclusion as my_class methods - which would even
enable further simplifications and/or encapsulation of code-suites
relevant to the application, and/or "a" and "b" and the processes around
them.

If the "calculation" of 'next_couple' currently involves looking-up
another data-structure, eg a list of data-points, then combining such
with/into my_class may well yield further simplifications,
encapsulations, and benefits - but all in-theory and complete ignorance
of your application...


Hope the above gives you some ideas/pause for thought!


* this gratuitous and somewhat awkward expression is me claiming to be
clever by quoting Lewis Carroll - if he isn't sick of me
baiting-the-hook, it might earn extra brownie-points (or another groan)
from @Chris...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 27/10/2021 om 10:05 schreef Chris Angelico:
> On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon <antoon.pardon@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.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon <antoon.pardon@vub.be> wrote:
> > 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.

According to any criteria you like. Remember, the onus is not on the
status quo to justify itself; the onus is on someone who wants to make
a change.

Demonstrate that a change is needed by showing the benefits.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On Wed, Oct 27, 2021 at 7:39 PM dn via Python-list
<python-list@python.org> wrote:
> Accordingly: is this a job for the walrus operator at all? Let's "talk
> of many [other] things"*.

+1

> Could we use a data structure to continue to keep things straight-forward?
>
> class my_class():
> def __init__( self, a, b )->None;
> self.a = a
> self.b = b
>
> instance = my_class( a, b )
>
>
> Sorry, you're probably becoming impatient with me. Surely I'm typing
> more code than necessary? Maybe, but there are other measures of
> code-quality/good-practice/etc, and there's likely more to 'it' than
> just these few lines...
>
>
> First consideration: the algorithm needs us to 'feed' the
> while-condition. So let's flesh-out:
>
> def is_more( self )->bool:
> # you know what goes here - I don't, but that's not the issue
> # the return value is all that matters
> return is_there_any_more_data_to_calculate?
>
> In which case, the loop becomes:
>
> while instance.is_more():
> more calculations
>
> and 'readability' improves immeasurably!

I'd be inclined to write all of this as a generator function, yielding
a series of tuples, but YMMV.

> * this gratuitous and somewhat awkward expression is me claiming to be
> clever by quoting Lewis Carroll - if he isn't sick of me
> baiting-the-hook, it might earn extra brownie-points (or another groan)
> from @Chris...

Given that you were talking about a walrus, I think it was quite apt :)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 27/10/2021 om 10:38 schreef dn via Python-list:
> On 24/10/2021 22.23, O365 Dict wrote:
>> Well I have the following use case:
>>
>> while (temp_result := calculate_next_couple(a, b))[1]:
>> a, b = temp_result
>> more calculations
>>
>> Which IMO would be clearer if I could just write:
>>
>> while ((a, b) := calculate_next_couple(a,b))[1]:
>> more calculations
>>
>> Of course it would even more clear if I could write something like:
>>
>> while (a, b) := calculate_next_couple(a, b); b:
>> more calculations
>>
>> or
>>
>> do:
>> a, b = calculate_next_couple(a, b)
>> while b:
>> more calculations
>
> Found (all of) the above less-than-obvious to read. Putting it in front
> of trainees this morning caused only confusion - even the
> currently-legal variation.

A lot of python idioms are less than obvious for trainees when they first
encounter them. I don't think "Is obvious for trainess" is a good measure
to evaluate possible future programming constructs.

> Accordingly: is this a job for the walrus operator at all? Let's "talk
> of many [other] things"*.
>
> ...
>
>
> That all looks simple. What is dn complaining about?
>
>
> Could we use a data structure to continue to keep things straight-forward?

Yes off course we could. Before the walrus operator was introduced, we could
also introduce extra code so that we wouldn't need the walrus operator at all.


> ...
> Hope the above gives you some ideas/pause for thought!

No they don't. You have taken an example to illustrate an idea and
treated it as if it was some production code you had to review.

What you are suggesting boils downto that if one has a loop in which
one has two work variables, with a condition on those variable to
control a loop. In order to make use of the walrus operator we should
combine those two work variables into some kind of instance no matter
how contrived.

--
Antoon Pardon.


--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 27/10/2021 om 10:49 schreef Chris Angelico:
> On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon <antoon.pardon@vub.be> wrote:
>>> 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.
> According to any criteria you like. Remember, the onus is not on the
> status quo to justify itself; the onus is on someone who wants to make
> a change.

Then don't answer that I can justify it according to any criteria I like.
It will have to be done according to criteria that are important to the
people who like the status quo. That it will be justified according to
criteria I like, will be totally unimportant.

> Demonstrate that a change is needed by showing the benefits.

Nothing is needed. But the walrus operator wasn't needed either. Asking to
show something is needed is putting a burden on who wants to advocate for
this, that isn't put on others.

--
Antoon Pardon.

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On 2021-10-27 19:05:52 +1100, Chris Angelico wrote:
> On Wed, Oct 27, 2021 at 6:00 PM Antoon Pardon <antoon.pardon@vub.be> wrote:
> > while (a, b) := next_couple(a,b)[-1]:
> > ...
[...]

> 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.

Right. I think for that you would want something like what Go does in
if:

if [assignment-statement ;] condition {
statements
}

Then you could write

while a, b = next_couple(a,b); b:
...

That doesn't even need the walrus operator.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Re: New assignmens ... [ In reply to ]
On 2021-10-24 11:23:48 +0200, O365 Dict wrote:
> do:
> a, b = calculate_next_couple(a, b)
> while b:
> more calculations

I actually like that syntax.

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Re: New assignmens ... [ In reply to ]
On Wed, Oct 27, 2021 at 8:20 PM Antoon Pardon <antoon.pardon@vub.be> wrote:
>
>
>
> Op 27/10/2021 om 10:49 schreef Chris Angelico:
> > On Wed, Oct 27, 2021 at 7:46 PM Antoon Pardon <antoon.pardon@vub.be> wrote:
> >>> 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.
> > According to any criteria you like. Remember, the onus is not on the
> > status quo to justify itself; the onus is on someone who wants to make
> > a change.
>
> Then don't answer that I can justify it according to any criteria I like.
> It will have to be done according to criteria that are important to the
> people who like the status quo. That it will be justified according to
> criteria I like, will be totally unimportant.
>
> > Demonstrate that a change is needed by showing the benefits.
>
> Nothing is needed. But the walrus operator wasn't needed either. Asking to
> show something is needed is putting a burden on who wants to advocate for
> this, that isn't put on others.
>

You can argue the word "need" all you like, but the fact remains that
YOU want a change, so YOU have to convince people of the benefits.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
Op 27/10/2021 om 11:59 schreef Chris Angelico:
> You can argue the word "need" all you like, but the fact remains that
> YOU want a change, so YOU have to convince people of the benefits.

That is true. But there is nothing wrong in asking what might convince
people.

But I'll give you my thought below and you can decide in how far this
is convincing to you.

I regularly come with a problem for which a one and a half loop is very
suited to solve it. Unfortunately python doesn't have a one and a half
loop. However with the introduction of the walrus operator there is a
way to simulate a significant number of one and a half loops.

Consider the following:

do
a = expr1
b = expr2
while 2 * a > b:
more calculations

We could write that now as

while [.
a := expr1,
b := expr2,
2 * a > b][-1]:
more calculations

Now there is some ugly side on the above and it may not be obvious at first
what is going on, but once you understand it is a rather easy idiom. I certainly
prefer it over writing something like

while True:
a = expr1
b = expr2
if not (2 * a > b):
break
more calculations.

So for me any limitation on the walrus operator that is removed is a plus because
it will allow me to write more one and a half loops in more natural way.

Off course should the python developers decide to intoduce a real one and a half
loop all the above is probably a whole let useful.

--
Antoon Pardon

--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On 27/10/2021 8:28, Anton Pardon wrote:
>>> Suppose I would like to write a loop as follows:
>>. > while ((a, b) := next_couple(a, b))[1]:
>> > do needed calculations
>>
>>
>>> What I can do is write it as follows:
>>> while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
>> > do needed calculations
>>
>>> I really don't see what is gained by "forcing" me to right the second code over the first.
>> No, nobody is forcing you to write it the second way over the first.
>> Nobody is forcing you to use the walrus operator at all!
>>
>> Instead, I would recommend something more like:
>>
>> while b:
>> do needed calculations
>> (a,b) = next_couple(a,b)

> But AIU the walrus operator was introduced so we no longer needed, to write such code,
> with the calculation of the next candidate at the bottom and the test at the top.
> You just confirmed the walrus operator is not very useful once the next candidate is
> no longer just a name.

I must disagree with the first sentence here regarding why the walrus operator was introduced.
I read through the PEP, and saw nothing about that in the Rationale. I do see the loop-and-a-half
example, but that actually had its next candidate value near the top (just before a break).

I'm going to provide two loop-and-a-half segments to illustrate my interpretation
of this PEP and the purpose of the walrus operator:

Without the walrus:

total = 0
value = input()
while value >= 0:
total += value
value = input()
print(total)

With the walrus:

total = 0
while (value := input()) > 0:
total += value
print(total)

In terms of the PEP -- I want to compare each input value to 0 for the loop test,
but I also want to preserve that value, to add to the total. There is a subexpression
(input()) within a larger expression (compared to 0) that I wish to name for reuse.

Now contrast with this example:

Without the walrus:

replay = True
while replay:
play_game()
replay = input("Play again? ") in ['y','Y','yes','Yes']

(I think it silly to ask about playing again at first).

With the walrus:

replay = None
while replay==None or (replay := input("Play again? ") in ['y','Y','yes','Yes']:
play_game()

To use the walrus operator here, I have to fabricate a value that would
allow me to bypass the input operation, that cannot be otherwise produced.
I do not find this second version any clearer or more intuitive than the first
(and the PEP did emphasize the value of clarity).

Now reading this in terms of the PEP, where I subexpression (the input)
in a larger expression (seeing if it is the list), I do not really seem to have
a compelling reason to name the value of that subexpression, since I am
not using it for any other purpose, so I could keep the input in the while
condition without using the walrus operator:

first_play = True
while first_play or input("Play again? ") in ['y','Y','yes','Yes']:
play_game()
first_play = False

I do not find this particularly clearer or better than my first version
with the test at the bottom, again since it requires me to do some extra
machinery to avoid the undesired input before the first repetition.
But I might also still argue that this is a little bit clearer than the
walrus alternative above.

My claim from these two examples is that the walrus is helpful to
reduce duplicating or recomputing subexpressions, not simply just
to facilitate code movement. It is not at all useful for a while loop
condition if the subexpression you wish to evaluate depends on
whether or not this is the first iteration of the loop.

Which then gets me back to your own illustrated use-case for
which I had raised a few questions/objections to before:

while ((a, b) := next_couple(a, b))[1]:
do needed calculations

What is the name of the value you wish to test? b
What is this actually testing? element [1] of a tuple

So already the code is unclear (and was made worse
when you said the existing walrus operator forced you
to make a list of three elements, two assigned with the
walrus, and then using a subscript of [-1] to get what you wanted.
My proposed solution explicitly tested b, since that
seemed to be what was of interest:

while b:
do needed calculations
(a,b) = next_couple(a,b)

To which you had replied:
> But AIU the walrus operator was introduced so we no longer needed, to write such code,
> with the calculation of the next candidate at the bottom and the test at the top.
> You just confirmed the walrus operator is not very useful once the next candidate is
> no longer just a name.

Okay, I would be happy to confirm my belief that the walrus is not very useful
when the thing you wish to test is not the same as the thing you with to assign.

But to relate this use case to my earlier loop-and-a-half examples:

(a,b) := next_couple(a,b)

presumes that there is are values for a and b to begin with for that first call to next_couple.
How do you initialize them correctly?

If you initialize them to the "first" couple (whatever that is), then your loop will
start off finding the second couple and you would be missing your first iteration.

Do you put special code in next_couple() to recognize that the provided arguments
are actually the first couple so it can return those unmodified, but then require its
own mental note not to give you an infinite loop forever returning that first couple?

Do you have to define a special case such as (a,b) = (0,0) or (None,None) to tell
next_couple that you really want the first one? That seems a little counter-intuitive
to have something named "next" need a special input to mean "first",

Not to mention whatever you use to initialize is probably not going to be very meaningful or
clear on its own terms. In my earlier note, I objected to "(ctr := ctr-1) > 0" on the grounds
that it required initializing the counter to 11 when you really wanted to count down from 10.

I favor using the walrus operator when it actually makes the code simpler and clearer;
I don't favor using it willy-nilly just because you wish to do an assignment operation
inside of a test condition, if its usage makes the code less clear. I interpret the PEP
has using the walrus to define a name for a particular value that would be both tested
and reused, and not that it would be used to assign to a value that was not being
tested (such as the a part of (a,b)).

Or in short, I do not find your choice of use-case really lines up with the rationale
given for walrus operator. You are free to disagree with me, but fortunately, we have
one of those PEP authors participating in this list regularly if you want his opinion.

Roger Christman
Pennsylvania State University


--
https://mail.python.org/mailman/listinfo/python-list
Re: New assignmens ... [ In reply to ]
On 27/10/2021 at 12:45 Antoon Pardon wrote:
> However with the introduction of the walrus operator there is a
> way to simulate a significant number of one and a half loops.

> Consider the following:

> do
> a = expr1
> b = expr2
> while 2 * a > b:
> more calculations

> We could write that now as

> while [.
> a := expr1,
> b := expr2,
> 2 * a > b][-1]:
> more calculations

Why don't you try this?

while 2 * (a := expr1) > (b := expr2):
more calculations

It seems you are just compelled to create tuple and lists
in all of your use-cases, even when they serve no purpose.

Roger Christman
--
https://mail.python.org/mailman/listinfo/python-list

1 2 3  View All