Hi Brett,
Thanks for your replies.
_> But you can write `123 .bit_length()`. 😊 That's a parser limitation
more than human understanding._
Touché. I took this ambiguity of the dot so much for granted that I
would not have thought of trying that.
_> Yep, but PEP 634 not only changes the convention, it special-cases
"_" to be different in how it can be used anywhere else in Python.
[...]_
I feel this is a bit of a misunderstanding, though: the underscore is
really only special as a pattern. Nothing in the PEP is changing
anything outside of pattern matching. I think it is quite important
that such a complex feature is kind of separate from the rest of the
language.
_> Welcome to worrying about every little detail in language design. 😉_
Cheers ^_^. To be fair, I learned a lot in this regard during the
past months and I feel extremely lucky to have benefitted so much from
working with these very smart and highly experienced team mates. At
the same token, we researched and approached the topic from so many
different angles that I feel quite comfortable with the result and
think this turned out to be a solid proposal.
_> [...]Â Now obviously "practicality beats purity" as well, but the
argument "other languages do it this way" doesn't hold well for a
language that doesn't use curly braces for scoping delineation. 😉_
I completely get that I fully agree with the intent of it. We
obviously have to concentrate much more on OCaml, Pascal, and Basic,
which do not use curly braces for scoping delineation, either ;-)
;-P. Honestly, though, I guess there is a certain grey area here. I
am thinking, for instance, of things like a for-loop, which indicates
iteration in about every language known(*), although there is research
indicating that the keyword ``for`` itself is a rather bad choice. At
some point, it just becomes so much a standard that it transcendents
into some kind of "meta-language". I would argue that in this case,
the burden of proof kind of reverses: you then need a very good
argument why /_not_/ to stick to a universal standard. And somehow,
"Python only sticks superficially and by convention to the standard
but we want to be able to break the rules even in this case whenever
we fancy" strikes me as particularly convincing... :)
_> My question about adding pattern matching later was more to comment
on the fact that the languages that use "_" for a wildcard pattern did
it from early on, not later on; it had nothing to do with the proposal
proposing pattern matching late in Python's history._
Hmm, yes I understand. Still, it is probably hard to make a solid
argument either way, because only few languages really added pattern
matching later, with most of them being statically typed, functional,
and so on. So, there is not really much to go for I guess. It is
probably Python's burden now to embark on adventures to seek out new
worlds, new possibilities and boldly go where no snake has gone
before... :)
Kind regards,
Tobias
(*)Â And yes, I am fully aware of assembly, purely functional
languages, brainf*, etc.
Quoting Brett Cannon <br...@python.org>:
Â
On Tue, Nov 17, 2020 at 1:16 PM Tobias Kohn
<ko...@tobiaskohn.ch> wrote:
_Hi Brett,
Without having really looked at the history of all the languages we
mention in the PEPs, I have a hunch that most of them had pattern
matching from quite the beginning or an early stage on, indeed.Â
That being said, I think the question itself does not really make
much sense, though. Programming languages are rarely if ever just
invented out of the blue these days, but evolve from other
languages that have gone before them. So, sure C++ and Objective-C
both had objects and classes from the very beginning on, but if we
take into consideration that they strongly build on C, we could
argue just as well that OOP was a later addition to C. It really
depends on your point of view.
But since we are talking about different languages here, there is
one example I could bring up. In C#, the underscore is a perfectly
legal variable name. And yet, it is also used as a 'discard' [1]
in newer versions. Moreover, F#, which certainly uses the
underscore as a wildcard, runs on the same platform as C# and thus
has to deal with this, too. Somehow, Microsoft and its developers
seem able to cope with it.
If I may widen the topic here a bit and seize the opportunity to go
beyond just answering your email: I must admit that I find this
entire discussion about the wildcard pattern rather mind-boggling.Â
We seem all to accept the reality that ``match`` and ``case`` are
context-sensitive keywords (i.e. they are both keywords and legal
names)_
Â
_Yes, because that's new syntax that's unambiguously new even if
you have been programming in Python for decades._
_Â _
_and that you cannot write ``123.bit_length()`` because the dot has
several different meanings._
Â
_But you can write `123 .bit_length()`. 😊 That's a parser
limitation more than human understanding._
_Â _
_Â But when it comes to the underscore and the idea that *as a
pattern* it might simply not store a value, it is considered an
insurmountable obstacle to learning and understanding pattern
matching?_
Â
_I don't think "insurmountable" is a fair assessment of the
general sentiment. But consistency is in the Zen of Python for a
reason: "Special cases aren't special enough to break the rules".
Now obviously "practicality beats purity" as well, but the argument
"other languages do it this way" doesn't hold well for a language
that doesn't use curly braces for scoping delineation. 😉_
Â
_Â _
_Â Particularly because, after all, the underscore is in Python
only a wildcard *by convention*?_
_Yep, but PEP 634 not only changes the convention, it
special-cases "_" to be different in how it can be used anywhere
else in Python. And that convention is wide enough that tools like
linters rely on it, so it's gone far enough to almost be a standard.
It's like trying to redefine some slang term that hasn't made it
into the dictionary yet, but based purely on how it's used in a
sentence; it doesn't break the "rules", but it doesn't necessarily
help using it that way mentally either (especially for those of us
who have been using the "slang" for a decade or more)._
Â
_And to be clear, I'm not arguing for or against redefining the
meaning of "_" for pattern matching, just trying to help explain why
people are speaking up about it._
_Â _
_I think pattern matching has a lot in common with 'recursion': if
you see it for the first time, it can be very hard to wrap you head
around it and understand what is going on or why anyone would want
to do such a thing. But once you understood it, it can be an
extremely elegant solution to many problems. So, I really can
fully understand a lot of the reservations brought forward about
this feature and various aspects of it. And there were enough good
and valid points brought up by the community, which we then
integrated into and respected in our overhauled design---but that
the wildcard pattern causes so much grief really is entirely beyond
me..._
Â
_Welcome to worrying about every little detail in language design. 😉_
Â
_-Brett_
_Â _
_So, yes, most languages had pattern matching quite from the outset
on (or not at all). But then, again, Python is about the only
language I know to have introduced 'type' annotations so late in
life rather than from its very beginning. It came at the cost of
using the colon for something different than compound statements or
dictionaries. If we consider how much annotations have been
expanded in more recent versions of Python and how many tools make
good use of it, I would call that a pretty successful move,
though---even though all other languages might have had type
annotations from their very birth._
Â
_My question about adding pattern matching later was more to
comment on the fact that the languages that use "_" for a wildcard
pattern did it from early on, not later on; it had nothing to do
with the proposal proposing pattern matching late in Python's
history._
_Â _
_Kind regards,
Tobias
P.S. Sorry, I guess this turned out to be not so much a reply to
your comment alone, as much more a reply to many a message and
discussion that has been posted here over time.
[1]Â https://docs.microsoft.com/en-us/dotnet/csharp/discards
Quoting Brett Cannon <br...@python.org>:_
_Â _
_On Mon, Nov 16, 2020 at 9:03 AM Tobias Kohn
<ko...@tobiaskohn.ch> wrote:_
__Hi Mark,
Thank you for your interest and the questions.
1. This really comes down to how you look at it, or how you
define pattern matching. The issue here is that the concept of
pattern matching has grown into a large and somewhat diverse
flock of interpretations and implementations (as a side note:
interestingly enough, some of the only universally agreed-upon
standards are to use `_` as a wildcard and not to mark names that
capture/bind values---which are quite exactly the points most
fiercely debatted here).__
__How many of those languages added pattern matching
/later/ and not at the earliest stages of the language (if not
from the beginning)? And for those that added it later, how many
of those didn't already have a convention surrounding "_"? My
suspicion is "not many" and "not many". 😉__
__Â __
__-Brett__
Â
________________________________________________
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/KP2TVEAPDT553VXL4QEUOTYBHHMDUXSK/
Code of Conduct: http://python.org/psf/codeofconduct/_
_______________________________________________
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/AAJUGDI37TQATNRDMBZMZ2JCGMJMUSGH/
Code of Conduct: http://python.org/psf/codeofconduct/
