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/