Hello,
On Sat, 9 Jan 2021 12:27:45 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde,
> <contreba...@gmail.com> wrote:
>
> > Paul Sokolovsky wrote:
> > > Hello,
> > > On Tue, 5 Jan 2021 20:37:27 +1000
> > > Nick Coghlan ncogh...@gmail.com wrote:
> > > > object(host=as host, port=as port}:", but that
> > > > couldn't ever be
> > > > I'd like to point out the weirdness of the "as" syntax when
> > > > applied
> > > to
> > > positional arguments, e.g.:
> > > case [as x, as y]:
> > > case Cls(as x, as y):
> > > That feels unnatural, and the fact behind that intuitive feeling
> > > is that "as" never used like that in Python so far. Where it's
> > > used now, there's explicit "what" is available before "as":
> > > import org_name as alias_name
> > > with expr as var:
> > > So again, standalone "as" feels weird.
> >
> > It's a matter of taste, I like the compacity of the standalone as.
> > It describe clearly the variable name, and the order matches the
> > positional arguments so I don't find it surprising. If it's not the
> > positional value, what else can it be ? What would be clearer by
> > using an underscore, which itself corresponds to nothing ?
> > The fact that it was never used like this it not an argument per se,
> > because that's the point of new syntax...
>
>
> It's also a pure syntactic shortcut, so anyone that really dislikes it
> could favour the "__ as name" form. The extra leading "__" doesn't
> convey any information that the leading "as" doesn't convey on its
> own, but YMMV.
>
> The key difference relative to PEP 634 is that even when the code
> author uses the shorthand form, *readers* will still get at least the
> "as" keyword as a prompt,
Ok, so let's summarize the alternatives:
1. PEP634, which says that "case Cls(a, b):", etc. is not worse than
other languages.
2. PEP642, which says that taking existing "as" and using it (and it's
also an English word with a specific meaning) with rather different
meaning in pattern matching is ok.
3. Alternative proposal sounded on the list, which says that taking
existing punctuational operator like ">" or "->" (and they're also
graphemes depicturing arrows) and using them (still with rather
different meaning) in pattern matching is ok.
PEP642 never mentions 3rd alternative. And it actually starts its
presentation with things like:
> case {"host" as host, "port" as port}:
There're 2 obvious problems with it:
a) In Python, {} with things inside it, but no ":" inside it, is a set,
set.
b) Everywhere else in Python, thing on the left of "as" gets into
thing on the right of "as", behold:
import foo as bar # original module "foo" gets into "bar".
with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c"
Then based on the existing Python syntax, the meaning of '{"host" as
host, "port" as port}' is: a set, whose contained, constant in this
case, values "host" and "port" get captured as variables host and port.
In pattern matching context (with 'case' in front), it means: match
using a set, check for presence on constant "host" and "port" elements,
and capture those constants to variables host and port (that
capturing doesn't make much sense, yeah. And yet syntax tells just
that. You propose to assign to it completely different meaning.).
So, the "dict pattern shortcut syntax" proposed by PEP642 is rather
ambiguous and confusing, and represent climax of PEP642's "fixing too
many things at once", where it goes over the summit and onto the dark
side.
And even looking at:
case {"host": as host, "port": as port}
I'm personally tripped by the meaning of "as" in English, and think
that it does something about thing on the left of it, i.e. the
dictionary *key*, not the *value*, as it really does. To get around that
effect, I'd need to write it as:
case {"host": (as host), "port": (as port)}
That finally looks pretty unambiguous to me. Again, an alternative is:
case {"host": ->host), "port": ->port}
Which is pretty self-expressive and unambiguous right away IMHO. (Of
course, there's a fine distinction between "arrow points from A to B"
vs "arrow points into B", I bet on the last meaning).
Also, the distinction between "as" vs "->" in patterns is of the same
nature as distinction between "or" vs "|" in them (there're reasons
why "|" is used for alternatives, and not "or", right?)
> rather than having to just know that "name"
> appearing in a pattern means "__ as name",
But PEP634 doesn't have no "__ as name"! It has "_ as name". And
that's another case of PEP642's "too much at once". While that change
is pretty clearly presented in the PEP642, I find that discussion here
rather downplays it. Specifically, you use "__" even in the context
talking about PEP634, as if you take it for granted. Instead, each time
you mention "__", you'd rather say "which is another alternative syntax
PEP642 propose".
Because you see, I'm almost sure that readers of just this thread don't
even pay enough attention that you use double-underscore instead of the
original underscore. That leads us to the obvious concern:
1. The difference between "__" and "_" isn't visible enough.
People should start saying "OMG" and "horror!" now, not when PEP642 gets
implemented and they finally notice that they need to type _ twice.
Which leads us to:
2. Both PEP642 and discussion here should elaborate explicitly what
happens when people still use "_" in patterns.
Beyond that:
3. The PEP642 attributes the idea to "a Stackoverflow answer", but
discloses that the author of the PEP is also the author of the
Stackoverflow answer. There's nothing wrong with that. But, given that
the answer is from 2011, how much adoption that idea got in the
meantime? If not enough, what would be the reasons for that? How
those reasons might affect the usage in PEP642? The Stackoverflow answer
specifically mentions:
> (many folks prefer a double-underscore, __, as their throwaway
> variable for exactly this reason).
Never saw that, sorry. (Maybe I saw, but didn't pay enough attention
that it's double-underscore instead of single, exactly the problem we
discuss).
> Linters often recognize this use case. [...] The fix, if day is truly
> not needed, is to write year, month, _ = date().
So, you see, it says "many people prefer __", and then immediately says
"linters recognize _ as a special case". So, 10 years later, how many
linters recognize double-underscore as a special case too?
Other general comments on PEP642v3 text:
> * allow an initial form of pattern matching to be developed and
> released without needing to decide up front on the best default
> options for handling bare names, attribute lookups, and literal values
Can this be made more explicit with appending: " (that's why it
proposes to prefix both capture patterns and value constraints, even
though prefixing just one would be enough to avoid ambiguity)".
> MatchValue(matchop op, expr value)
> matchop = EqCheck | IdCheck
Why bloat ASDL with duplicates? Why not "matchop = Eq | Is" ?
> whereas that path is blocked for "_" by i18n related use cases.
> ...
> This deprecation path couldn't be followed for _, as there's no way
> for the interpreter to distinguish between attempts to read back _
> when nominally used as a "don't care" marker, and legitimate reads of
> _ as either an i18n text translation function or as the last
> statement result at the interactive prompt.
A way to deprecate lagacy use of "_" would be something like "from
__future__ import _". Sources which use legacy i18n naming can't use
pattern matching, might be considered a fair tradeoff. Interactive
prompt is also a separate usecase.
> this PEP restricts sequence patterns specifically to the square
> bracket form.
That's relatively minor, but sad choice, because [...] signifies a
mutable list, whereas a language should promote use of immutable values,
like tuple (...).
> This means that only types that actually define __match_args__ will
> be usable in class defined patterns. Types that don't define
> __match_args__ will still be usable in instance attribute patterns.
All this is neat, smart construction, but not intuitive, sufficiently
irregular, complicated, and confusing.
I grokked the idea after reading the PEP642, it's smart, again. But I
don't think it's ok to subject innocent to study these complex
conceptual hierarchies of "objects designed to be used with Cls(as foo,
as bar) matching syntax, and those which weren't, and must use unheard
of, and NIH syntax of Cls{.attr1 as foo, .attr2 as bar} instead".
People should just learn pattern matching as it's presented in other
languages indeed. To help them with "may bind to the right" matter, a
very simple, focused change was proposed - to add explicit arrow
pointing straight at the bind/capture target. Instead of that simple
measure, PEP642 builds whole parallel hierarchy of concepts, which is
very artificial and complex response ("seeing complication,
rehash everything, and add significantly more overall complexity to deal
with originally simple case").
Again, I pray for PEP642 rejection, based on its "attempting to do too
much, and overdoing it to "remedy is worse than the problem" situation,
and trying to build complex hierarchies to artificially separate
concepts in pattern matching, instead of treating pattern matching as
"cartesian product" of simple concepts (and see how to make these
simple concepts more explicit to humans, rather than adding more
constraints for humans to be aware of).
Deep and unobvious constraints, how on earth I know if some class
defines __match_args__ or not, so I can select appropriate syntax? I
simply will use the syntax which is usable for all cases (and that's the
ugly one), and the other syntax will be used only for builtin types,
and whoever will see it used for a non-builtin class will be shocked and
confused.
[]
--
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/IV3NWCEOWBODWITZOFU45AOCYELFTGYU/
Code of Conduct: http://python.org/psf/codeofconduct/
