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. To feel it natural, it would
need to be written as "case [_ as x, _ as y]:", but that's exactly what
PEP634 already allows, and nothing needs to be done! And I'd like to
remind that one of the original alternatives raised for the syntax was
something like:
case [>x, >y]:
Which is both concise and intuitive (for as long as you accept that
">" here represent an arrow, which should be one-time-in-life learning
event).
The argument for "lone as" can be "just let that syntax keep you
hostages for some time (say, one week of regular usage) and you'll
acquire Stockholm Syndrome for it." That may very well be true. But
1-or-2-character punctuation prefix sigil is still more concise and more
intuitive.
[]
> For the other point, consider the following examples (using "match
> SUBJECT as case PTRN" as a strawman one-shot pattern matching syntax):
>
> # One shot PEP 634 pattern
> match addr as case object(host=host, port=port)
>
> # One shot PEP 642 pattern
> match addr as case object{.host as host, .port as port}
>
> # Attribute tuple (PEP 642 based deferred idea)
> host, port = addr{.host, .port}
>
> One shot pattern matching turns out to have an inherent verbosity
> problem,
My bet that it has "inherent verbosity problem" only because there was
no such proposal. And any such proposal would start with basics:
What's syntax for sequence destructuring aka pattern matching against
catch-all variables? Assignment to a tuple/list:
(a, b) = tuply
Ok, what happens if you assign to a dict syntax now:
{a: b} = dicty
Syntax error? Ok, that's new one-time dict matching.
What happens if you assign to a function call syntax now (also object
constructor syntax):
Addr(ip, port) = addr_obj
Syntax error? That's new one-time object matching.
Not verbose at all:
(a, b) = tuply
{a: b} = dicty
Addr(ip, port) = addr_obj
Now, those throw ValueError, what if you want to get a boolean? Just
wrap it in the "if" context:
if (a, b) = tuply:
if {a: b} = dicty:
if Addr(ip, port) = addr_obj:
>From there, bikeshedding can start. E.g., there will be strong cry that
"= and == are easy to mix up", so it'll become:
if match (a, b) = tuply:
if match {a: b} = dicty:
if match Addr(ip, port) = addr_obj:
That's a whole 1 token more verbose, but 6 chars more, so someone will
come up with following alternatives:
if_m (a, b) = tuply:
if (a, b) m= tuply:
Etc, the usual bikeshedding whirlwind.
[]
--
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/OAKCB4JI7K7CN4A64EDYL6GDM6KX2M7U/
Code of Conduct: http://python.org/psf/codeofconduct/
