(...) Nor am I keen on "expressions" being interpreted
differently after 'case' than elsewhere in Python.
Python already has "expressions" (intentional quotes) that are interpreted differently depending on the context. `x` may mean "the value bound to x" in code like `print(x)`, or "the name x inside some scope" when doing `x = 3`. `x[0]` may mean "calling `__getitem__(x, 0)` in the type of x" , or it may mean a call to `__setitem__(x, 0, something)` instead if you do `for x[0] in some_iter`. `[a, *b]` may mean "build a list with a, and all the elements that come from iterating b" in some contexts, in other it might mean "extract one element from an iterator and bind it to a. Then build a list with the other elements of the same iterator, put them into a new list , and bind that to b" if you are doing `[a, *b] = myiter`.
Many people in this thread have argued that the double meaning in the PEP might be confusing, but Python already has a double meaning in other places. It's so NOT confusing, that people even forget that exists :) It works because the two meanings are not completely unrelated, and that's what PEP622 is trying to achieve.
It may be surprising the first time you read the PEP in the air. The question to answer is if it will be confusing after we've seen this statement half a dozen of times in our codebases.
Best,
D.
But I don't know
what syntax (where necessary) to suggest.
I'm not keen on special treatment of the '_' variable, and would
prefer to be able to use 'else:' after 'match'.
Best wishes
Rob Cliffe
On 03/07/2020 15:56, Chris Angelico wrote:
>
> The PEP is still a draft and has not been accepted. Don't worry, the
> normal process is still happening :)
>
> Having a reference implementation is a HUGE help, because people can
> play around with it. There's a fork running an interactive playground
> so you can go right now and get a feel for the way the syntax works.
>
> The implementation has *not* been merged into the CPython trunk. It's
> not a fait accompli - it's a tool to help people evaluate the proposal
> (and all of the different variants of the proposal as it evolves).
>
> Speaking with my PEP Editor hat on, I would be *thrilled* if more
> proposals came with ready-to-try code. Only a very few have that
> luxury, and a lot of the debating happens with nothing but theory -
> people consider what they *think* they'd do, without actually being
> able to try it out and see if it really does what they expect. Having
> a reference implementation isn't necessary, of course, but it's
> definitely a benefit and not a downside. Also, there HAVE been
> proposals with full reference implementations that have ended up
> getting rejected; it's not a guarantee that it'll end up getting
> merged.
>
> Hope that lessens your fears a bit :)
>
> ChrisA
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/NWNG5KII3ZJAUZ2J7X7SFV2MIBORIDJR/
Code of Conduct: http://python.org/psf/codeofconduct/