On 7/12/20 3:20 PM, Guido van Rossum wrote:
On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings <la...@hastings.org
<mailto:la...@hastings.org>> wrote:
Having thought about it some, I propose it'd be acceptable to do
dead store optimization if-and-only-if optimizations are
explicitly enabled, e.g. with "-O". Allowing explicitly-enabled
optimizations to observably affect runtime behavior does have some
precedent, e.g. "-OO" which breaks doctest, docopt, etc. It'd be
a shame if the existence of locals() et al meant Python could
never ever perform dead store optimization.
Assuming you're still talking about how to implement wildcards, it
really sounds like you're willing to add a lot of complexity just to
have a "consistent" treatment of `_`. But why would you care so much
about that consistency?
I'm a fan of the Zen guidance here: "special cases aren't special enough
to break the rules".
More on this topic in a moment--rather than reorder paragraphs, let me
return to this below.
Using the same character in patterns makes intuitive sense to anyone
who is familiar with this convention in Python. Furthermore it also
makes sense to anyone who is familiar with patterns in other
languages: *all* languages with structural pattern matching that we
found at uses `_` -- C#, Elixir, Erlang, Scala, Rust, F#, Haskell,
Mathematica, OCaml, Ruby, and Swift. (That's a much stronger precedent
than the use of `?` in shell and regular expressions IMO. :-)
Python hasn't been afraid to go its own way syntactically in the past.
Consider the conditional (ternary) operator. Most languages I've
encountered with a conditional operator just copy C's syntax, with '?'
and ':' (PHP, C#, Java). Some languages don't need a conditional
operator, as their existing flow control already works just fine (FORTH,
Rust). Python's syntax for the conditional operator was neither, and
was AFAIK unique--but this syntax was judged the most Pythonic, so it won.
Similarly, AFAIK Python's "None" is unique. Most other languages I've
seen use the word "null", albeit with varying capitalization.
So I'm unconcerned about Python using a different token for the wildcard
pattern. Python already doesn't look like other languages, Python's
proposed syntax for pattern matching isn't exactly like the pattern
matching syntax of other languages. I don't understand why it's so
important that it look like other languages in this one specific respect.
As for leveraging the convention of using '_' for values you don't care
about in Python--that's actually why I /don't/ like it as the wildcard
pattern. To date, everyone who uses '_' understands it's just an
identifier, no different from any other identifier. I imagine I18N
programmers avoid this convention for exactly that reason--there's
nothing special about '_', so they need to take care to not overwrite or
occlude it with a don't-care value.
However, if I understand PEP 622 correctly, the places you use '_' as
the wildcard pattern are also places where you could put an identifier.
But in this one context, '_' doesn't behave like the other identifiers,
even though in every other context in Python it still does. This is the
"special case" that "breaks the rules" I alluded to above.
Consistency with the longstanding semantics of '_', and consistency with
other identifiers, is much more important to me than consistency with
other languages for the pattern matching wildcard token.
Using `?` as the wildcard has mostly disadvantages: it requires
changes to the tokenizer, it could conflict with other future uses of
`?` (it's been proposed for type annotations as a shorter version of
Optional, and there's PEP 505, which I think isn't quite dead yet),
and Python users have no pre-existing intuition for its meaning.
One reason I prefer '?' for the wildcard pattern is precisely /because/
users have no pre-existing intuition as to its meaning. Unlike '_', the
user would have no preconceived notion about its semantics to unlearn.
Also, it doesn't behave like an identifier, and accordingly it doesn't
look like an identifier. This strikes me as harmonious.
Is changing the tokenizer to support '?' as a token a big deal? You
mention two other existing proposals to use it as a token--surely this
is a bridge we'll have to cross sooner or later.
My goal in starting this discussion was to see if we could find a
compromise everyone could live with. People who want to use '_' for
wildcard pattern could do so, people who didn't like '_' having a
special meaning in this one context would be appeased. The message I'm
getting is "this compromise won't work". Okay, fair enough. I don't
plan to pursue it any further.
Cheers,
//arry/
_______________________________________________
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/KJPWIDR2E5OELH62K5RCOPZ7JDDXJ5G3/
Code of Conduct: http://python.org/psf/codeofconduct/
