Hello,

On Sat, 6 Feb 2021 06:17:08 +1100
Chris Angelico <ros...@gmail.com> wrote:

> On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky <pmis...@gmail.com>
> wrote:
> > And looking back now, that seems like intentionally added accidental
> > gap in the language (https://en.wikipedia.org/wiki/Accidental_gap).
> > Similar to artificially limiting decorator syntax, which was already
> > un-limited. But seems, there're no "lessons learned", and there's
> > now need to wait a decade again before fixing that?  
> 
> Lesson learned: Early limitations ARE easily lifted, so it's still a
> good idea to limit them until we've seen how they get used in
> practice. :)

Well, I wish there was also a bit of "try to make things consistent
from the beginning", because "easily lifted" is a bit optimistic
characterization.

That said, that's meta-level thought, down to earth case is that I
indeed would like to start talks on actually extending walrus syntax to
accept tuple/list on LHS.

I've now triaged
https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=walrus&submit=search&status=-1%2C1%2C2%2C3
and see that the only case it was mention is
https://bugs.python.org/issue42295 , which was a case of walrus
precedence confusion.

I thus submitted https://bugs.python.org/issue43143 for future
reference.

> > > The principal a.e. use in conditional expressions is testing for
> > > non-nullness.  Your
> > >  
> > >  > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > >  >    a2 = a1 + 1
> > >  >    b2 = b1 + 1  
> > >
> > > is an unusual and very specific use.  
> >
> > Well, many people were thinking (and I bet still think) that ":="
> > itself is very unusual case. But if it's in, why not make it
> > consistent with the assignment statement and unleash the full power
> > of it?  
> 
> TBH I don't think I'm understanding the use-case here,

I hope we understand that we go into rabbit hole of discussing a
specific case, whereas I reported a general limitation, and tried to
back it with more or less general example (i.e. not a once-off case,
with the "SSA conversion" usecase, each and every while would be
affected).

With that in mind, I guess it's fine for python-ideas to discuss that
particular usecase in detail.

> because it
> looks like it'd work just fine with fewer variables and a cleaner
> rendition:
> 
> while a1 < 5:
>     a1, b1 = phi([a0, a1], [b0, b1])
>     a1 += 1
>     b1 += 1

Let's first note that you omitted the initialization of a0 and b0 which
was in my example. And with that in mind, you'll immediately see what's
wrong with your code: it tries to access uninitialized a1. That's on
first loop iteration. On next, it will test *old* value of a1, whereas
it should test already updated value.

That's why it really has to assign new values in the loop's condition
expression:

while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:

(of course, if you're careful, you'll notice that a2, b2 are
initialized on 1st iter, so assume there're initialized as:

a2 = b2 = __undef__

Where __undef__ causes exception on any operation with it.
)

> > Right, but I started my original email with "I finally found a
> > usecase where *not* using assignment expression is *much* worse
> > than using it."  
> 
> "Much worse" doesn't fit with what I would write that code as, so I
> must have misunderstood your code somewhere.

*My* motivation is "SSA is already pretty complex conversion, so it
would be nice to avoid *additional* Python source transformations not
related to SSA per se, especially if Python generic syntax now allows
that".

But, again, it's just an example case. I use it to illustrate an
apparent gap in ":=" functionality comparing to "=", and propose to
lift that restriction.

> 
> ChrisA

[]

-- 
Best regards,
 Paul                          mailto:pmis...@gmail.com
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DQWTDLBMJH2MPY3A57XXMWJUL7IWKVKE/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to