Hi,
Le 12/11/2020 à 18:55, Guido van Rossum a écrit :
> The position of PEP 622/634/535/636 authors is clear:
well, let me first emphasize that I did *not* mean to reopen the
discussion on those PEPs, which explain and discuss their design choices
thoroughly (even better since the rewrite, thanks for that). And I
definitely did not mean to spawn another "mark capture or value"
subthread… I thought "PEP 642 v2" in the thread title was explicit
enough, should have been more cautious :-)
PEP 642 states as a design principle that parallelism between patterns
and assignments should be kept as much as possible (let's not discuss
this principle here). Thus, introducing different semantics for dotted
names deserves a discussion in that PEP (by contrast, literal
constraints need little discussion, because they have no semantics in
assignments).
> we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality is
> being migrated from literals (e.g. case 404) to named constants (e.g.
> case HTTPStatus.NOT_FOUND). Bothering users with the technicality of
> needing to use '==' here is a big usability hit.
Indeed, enums and other dotted constants are the heart of the matter.
And I get your point about not making useful refactoring more difficult.
Still it could make sense (in the philosophy of PEP 642, again) to defer
the choice and see how strong the need is. What PEP 642 ends up
proposing will be Nick Coghlan's call.
Cheers,
Baptiste
P.S.: a few examples for "taste":
# your example
match status:
case == HTTPStatus.NOT_FOUND:
...
vs. case HTTPStatus.NOT_FOUND:
# worst-case where constants are buried in the pattern
match sock:
case socket(family=(==socket.AF_INET), type=(==socket.SOCK_STREAM)):
...
vs. case socket(family=socket.AF_INET, type=socket.SOCK_STREAM):
# same with plain constants, PEP 642 only
match sock:
case socket(family=(==AF_INET), type=(==SOCK_STREAM)):
...
_______________________________________________
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/CZWZRN5J6QIJZM2C4IUOBGCWNJ7EM6QX/
Code of Conduct: http://python.org/psf/codeofconduct/
