Hello,
On Mon, 16 Nov 2020 12:21:35 +1300 Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: [] > > please explain why you chose to proceed anyway (and apply > > workarounds), instead of first introducing the concept of constants > > to the language. (Given that amount of work to implement pattern > > matching is certainly an order of magnitude larger than to > > introduce constants)." > > That's not certain at all, and moreover it's not just a matter of > work, it's a language design issue that would require its own > extensive investigation and debate. Everything would need discussion, maybe even debate. So, currently we debate various conceptual holes in the pattern matching proposal (like inability to match against a plain simple constant). We could discuss/debate things which would allow to resolve that and other issues in more proper way, that's the whole point. And we don't speak about some obscure "innovative" idea. Const'ness aka immutability is well-known and widely used feature in programming languages. So, we at least can be sure we're on the right path. Whereas now we're standing on one lag and wonder why our walking that way is awkward. > Members of the intended audience > (people very familiar with Python and its technicalities) can be > expected to understand this, so the PEP doesn't need to spell it out. So, the passage you quoted (and the whole original mail) was mostly related to the DLS'20 paper (https://gvanrossum.github.io//docs/PyPatternMatching.pdf), not PEP. I won't argue what PEP should do (under one interpretation, given that PEPs are accepted by SC, it might be even empty if SC is ready to accept it like that). But for a scientific paper which already considers various choices, omitting more detailed discussion of a pretty obvious choice caught some attention. > > How to support multiple variable scopes in one stack frame is not a > > rocket science at all. One just need to remember how C did that > > We can't just do it "like C does" because C requires variables to > be declared and Python doesn't. Again, my original mail criticized such simplistic write-offs in the DLS'20 paper, and in a reply to it, we again get the same story. So, let's go over it again. You probably say that C uses following syntax to define a variable in a particular scope: <type> <var>; e.g.: int var; Right, Python doesn't have that syntax. But it has other syntaxes to designate that a variable is defined in a particular scope: # e is defined in the scope of the following block except Exception as e: # x is defined in the scope of a comprehension [x for x in seq] Then for pattern matching, case a, b: *Could* define a, b in the scope of following block (and not beyond). That would have pros and cons, an obvious pro is that failing-to-match patterns would not litter in surrounding namespace, and con that "pattern matching as expression" usage would be more harder. If anything, use of block scoping could be considered to alleviate the littering problem, because the above should be equivalent to: case _1, _2: a, b = _1, _2 Where _1 and _2 *are* block-scoped *variables* (even if a and b aren't). Since then, "The semantics of pattern matching for Python" topic presented very similar ideas, except that it again tried to preserve the tabu on block-level scoping and argued for stack-machine workarounds. Instead of mentioning the shining-thru idea that it's perfect usecase for generic block-level scoping. Finally (and that's why this thread is brought up again), in a parallel thread on python-ideas (https://mail.python.org/archives/list/python-id...@python.org/thread/3ZKYV6WQPPWR7SBPKRWW743OPSI22RDA/), we see that block scoping would fit the bill to alleviate some issues with the scoping of "for" loop variables. > > The only reasons for not implementing the same solution in Python > > would be intertia of thought and "but it's not done anywhere else in > > Python". > > No, other reasons include that it would require making unrelated > language changes that open various other wormcans. Let's strive for solutions which follow the best practices in the programming language design (const'ness, block-level scoping are 2 good examples), and that should increase benefits/effort ratio of the solutions. > > nobody del'eted local variables behind users' backs > > either, before somebody started to do that for exception clause > > variables. > > There was a good reason for that having to do with reference cycles. > Nobody liked it much, but we didn't really have a choice. There is > no such pressing need for special scope rules in match statements. "Undefined behavior" regarding how failed matches may affect surrounding namespace is unlikely something to be proud of. Whether it's "pressing" or not, I won't debate. The point I want to show is that we have some history of workarounds for scoping-related matters. We're about to make workarounds (or just close eyes and say "there's no problem") in regard to pattern matching and/or "for" scoping improvement. Whereas all these cases seem to fit the bill of the generic block-level scoping pretty well, and discussing that approach might have bigger long-term benefits than keeping to apply adhoc workarounds. > > -- > Greg -- 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/RYVCBEDPBQPSDO7OILRVZIHFSC4DPDX3/ Code of Conduct: http://python.org/psf/codeofconduct/
