On Sun, 22 Nov 2020 at 00:31, Greg Ewing
On 22/11/20 6:47 am, David Mertz wrote:
I'm convinced by Guido, Brandt, and others that the binding use will be far more common, so adding extra characters for the 90% case does not feel desirable
Minimising the number of characters is not the only consideration. Readability counts too, and I think the proposed DWIM rules suffer in the readability area.
There are about five different contexts in which a bare name can appear as part of a match case:
* As a constructor name * As a bare name in an argument position * As part of a dotted expression * On the left of an = * On the right of an =
Only in some of those contexts is it treated as a name to be assigned. That's a fairly complex bit of mental parsing to do when reading a case.
Hi Greg, Look at the following (non-pattern-matching) snippet: event = datetime.date(x, month=y, day=z) you have bare names appearing as: * a constructor name (date) * bare name in an argument position (x) * part of a dotted expression (datetime, date) * left of = (event, month, day) * right of = (y, z) some of them are lookups in the namespace (datetime, x, y, z). Others are targets to write (event). "date" is actually a literal to be used as attribute lookup, for reading (a key in the module dictionary). "month" and "day" are literals to lookup in the list of formal parameters of a function, for writing into the new function stack frame. I never found Python students struggle too much with the line above, and I don't expect it to be much different for names in patterns. Names in Python can appear with a lot of different "roles" in a lot of different contexts, but the context is usually easy to recognise (is it left or right of a chain of dots? does it have an = on the left or right? is it in an argument list? a parameter list?). Of course I can never deny if you tell me "I find this syntax hard to read" (only a person can decide what's easy or hard to read for them), but I don't think this "bare names appear in many contexts" is a solid explanation. A hypothesis I have is that many readers of the PEP have been scared of these semantics because they have been laid bare when explaining them in detail, but would never notice in day to day life, in the same way that most Python users would never stop twice to look at the meaning of "a.b.c = 0", even if a semantic description requires us to describe that each of the three names has a different role ("a" is a lookup in the current scopes, "b" is a constant name for the purpose of reading attributes, and "c" is a constant name for the purpose of writing attributes). But looking at the details description of what's going on under the hood is scarier than the intuitive look, and when people read the PEP they are looking under the hood rather than looking at this as users. This is guesswork and could be absolutely wrong, but I hope it helps read this with a different set of eyes.
-- Greg _______________________________________________ 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/LMALNSPB... Code of Conduct: http://python.org/psf/codeofconduct/