Hi all,
I started reading it. You're saying the same things that everyone else
has said, so I stopped reading.
Do you have anything new to add to the discussion, or is this 2000
lines of rehash?
I'm new to the subject, and I find the rehash of everything that has
been said on the subject useful. Apart from the OP's gist I could find
only one publication on subject
<https://thautwarm.github.io/Site-32/Design/PEP622-1.html> which
actually spends more space discussing an alternative approach. If OP's
gist is one-sided, I'd prefer to read more summaries from people who
defend the PEP. The proposed changes are substantial, and the arguments
collected by OP against it are quite compelling (the example with
changing HTTP_OK value is downright horrifying).
To make my comment slightly less meta, I'd like to ask if the following
aspect was already discussed. In some cases the problem that PEP 622 is
intended to solve is solved by the "dict of lambdas" pattern (here
<https://medium.com/@julian.harley/custom-formatter-in-python-3-7e056b21d2d7>
is an example in the wild). Particularly, the HTTP example is handled
easily this way (note that I handled more cases in the same number of
lines):
RESPONSE_STATUS_REACTIONS = { HTTP_OK: lambda:
do_something(response.data), HTTP_MOVED_PERMANENTLY: lambda:
retry(response.location), # no way to merge with the one above in
current syntax HTTP_FOUND: lambda: retry(response.location),
HTTP_UNAUTHORIZED: lambda: retry(auth=get_credentials()),
HTTP_UPGRADE: lambda: retry(delay=DELAY), # `retry` is pretty magical
here # `lambda: raise` does not work in current syntax
HTTP_INTERNAL_SERVER_ERROR: lambda: raise_(RequestError("we couldn't get
the data")), # same problems with merging here HTTP_BAD_GATEWAY:
lambda: raise_(RequestError("we couldn't get the data")),
HTTP_SERVICE_UNAVAILABLE: lambda: raise_(RequestError("we couldn't get
the data")),}RESPONSE_STATUS_REACTIONS.get(response.status, lambda:
raise_(RequestError(f"Unexpected response status {response.status}")))()
But of course dict only matches keys exactly, so the following won't
work for subclasses of bool or int:
key = { bool: lambda key: ('false', 'true')[key], int: _intstr, #
no idea what _intstr does, just rewording the gist example
}[type(key)](key)
I wonder if some better mapping class can be added to the standard
library that would accept more flexible patterns and match them in
correct order without assigning anything? Assignment or whatever side
effects would then be performed explicitly and kept separate from matching.
With Best Regards,
Marat Khalili
_______________________________________________
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/BFXBYKXBSMWE5K6BXVVUMBNDZBV25DMX/
Code of Conduct: http://python.org/psf/codeofconduct/
