Hello,
On Fri, 13 Nov 2020 18:45:55 -0000
"Brandt Bucher" <brandtbuc...@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/FYGTU4RMZGKTQUANDSTRUSTC5GTZ5WUY/).
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/F66J72JUEAUKBM5VDSMG4HRHUEQBWI5M/
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/Q2ARJULLJG6HRCDXR4SSA7K6NLTOPUL7/
,
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:pmis...@gmail.com
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DPAGHD5DNLP2AJQEQA7QQL66YVTWEDSA/
Code of Conduct: http://python.org/psf/codeofconduct/
