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

> 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>;


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
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

> > 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
Message archived at 
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to