Hello, On Fri, 13 Nov 2020 18:45:55 -0000 "Brandt Bucher" <brandtbucher@gmail.com> wrote:
Paul Sokolovsky wrote:
Use punctuation ("sigils") to mark as-binding terms. This choice still seems to be under-considered. (As in: it doesn't seem like many people, including the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean, try really hard. I trust the "gang of 4" spent maybe whole few hours on that and delivered "no" to all us. It's still not the same as dozens of people trying it over a few months).
To anyone actually wondering how much time and mental energy we’ve spent on a particular issue: please take a look at our tracker before guessing “maybe whole few hours”:
Thanks for the very useful response. (Which follows another useful from another PEP author, Tobias Kohn, https://mail.python.org/archives/list/python-dev@python.org/thread/FYGTU4RMZ...). Thanks gentlemen for still keeping up the discussion even if you went thru all those matter many times.
- Issue #1(!), April, 29 comments: https://github.com/gvanrossum/patma/issues/1 - Issue #90, June, 84 comments: https://github.com/gvanrossum/patma/issues/90 - Issue #92, June, 33 comments: https://github.com/gvanrossum/patma/issues/92 - Issue #105, June, 17 comments: https://github.com/gvanrossum/patma/issues/105 - Issue #143, August, 7 comments: https://github.com/gvanrossum/patma/issues/143
(I won't judge anyone for skimming a bit; it's a *lot* of discussion.
I have to admit that I didn't read thru it. And fairly speaking, my aim is not to argue with the PEP authors, but "raise awareness" of the implications of choices made by PEP634 (and that the choice made there is not the "absolute winner", but more and more look like a leap of faith among other viable choices.) Anyway, given that you even included the # of messages above, let me still do some homework and add to stats number of participants in the ticket thread above (as an indirect way to assess community outreach): 5 + 12 + 8 + 6 + 5 I'm not sure what to do with these numbers (doing max() perhaps?). It's clear that the discussions there are more active than on the mailing list.
Do note, though, that for months I was one of the proponents of store sigils like `?` until I was eventually convinced otherwise.)
That's another great answer! Given that PEP622 had 6 authors, it's pretty mathematically clear that there should have been proponents of all 3 load/store options, and I wondered who's who. []
I'll also add, for anyone considering choosing yet another ASCII symbol off their keyboard and proposing it as a “novel”, “intuitive” marker: one problem with most of the hastily suggested adornments are
I don't think the problem is "hastily suggested <foo>". The problem is more that: despite all your great and multiple considerations, finding a compromise among you 6, compressing it to a small paragraph of PEP635, with culminating sentence in it starting with "However, this is based on the misconception", which sets the tone very well - despite all this great work, there're still people who think that you didn't do fairness to the idea of marking the stores. A possible solution would have been to extend discussion of this option in PEP635, and start with considering what would be lost by *not* adopting that approach, instead of coloring it all in a dismissive tone from the start. I know that might have been hard. As we know, an "alternative" PEP 642 was spawned exactly out of rejection of additional information regarding "sigils for loads" idea: https://github.com/python/peps/pull/1564
that they do not nest very well, for even simple cases.
I propose to add a unary prefix operator (choices among ">", ">>", "->", "@", etc.) Those do nest well. Some are completely unambiguous.
Further, the fact that constructions like `p = Point(x, y)` look exactly the same as deconstructions like `case Point(x, y):` is absolutely intentional (which touches back on Guido’s “rhyme” comment last night).
I don't think that "exactly the same" is the right words, or expectations to have. For example, PEP622 used phrase "It would break the syntactic parallels of the current grammar". And that's the whole point: `case Point(>x, >y)` is exactly parallel to `p = Point(x, y)`! The only difference is that the bind-to terms (here, the variables) are explicitly marked. Consider if the language had a color as syntactic means. Then in `p = Point(x, y)`, x and y would be colored in one way, but in `case Point(x, y)` - in different way. But they would be exactly parallel, and maybe even "the same". Thankfully, we don't use colors as syntactic means. The closest device we have is punctuation, and that's where idea to use sigils come from.
Very briefly, compare the current syntax:
``` case first, *middle, last: rebuilt = first, *middle, last case {"key": value, **rest}: rebuilt = {"key": value, **rest} case Point(x=a, y=b): rebuilt = Point(x=a, y=b) ```
with (using your own syntactic flavor):
``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) ```
(I had to stop and think *hard* where exactly the `>` should go in `*middle` and `**rest`. I'm not confident I made the correct guess, either.)
In my idea, ">" (or the like) would be a kind of low-precedence unary operator with only comma "," being of lower precedence. It would be written correspondingly, at the outermost level of the term, e.g.: case >first, >*middle, >last: rebuilt = first, *middle, last case {"key": >value, >**rest}: rebuilt = {"key": value, **rest} case Point(x = >a, y = >b): # Space is mandatory here, why I think ">" # alone would not be adopted. So, you say compare it with PEP634? But that's how I arrived here! Months after first reading initial PEP622 and being sleep-walked thru that option by it ("No other language use that option, so we don't want either" - "No, of course not, sir!") - I decide to think "what if", and write down something like the above. And I have to say you, it doesn't look that bad! It resolves a hard gripe I have with PEP622/634, that it can't do: MY_LOVELY_CONSTANT = 1 case MY_LOVELY_CONSTANT: But beyond that, it also makes clear to even kids what's being captured, and what's not. And just as we speak, real fun only starts. The echo just starts to reach the wider community which starts to think what stuff in PEP634 *really* means. https://mail.python.org/archives/list/python-dev@python.org/message/F66J72JU... is only a first in a wave of "d'oh" emails. Can't say I expect there would a zunami, but one can easily expect a long, persistent, not subsiding trickle of those. But not only novices (novices in Python, but also novices in pattern matching) are confused. In https://mail.python.org/archives/list/python-dev@python.org/message/Q2ARJULL... , a core Python developer publicly admits "it wasn't something that had previously occurred to me as a possible problem". I.e. he read PEPs all this time, got some issues with them (caused him to submit an "elaboration" PEP), but he didn't see *all* issues with them. Dear Brandt, please hang on with us, the wider Python community, as it starts to dawn on us. The real fun just begins. -- Best regards, Paul mailto:pmiscml@gmail.com