Hi Mark,
Thank you for your message. I might be able to answer some of the
questions and also address some issues with the underlying assumptions
in your email---after all, we would most certainly want to avoid
discussing and reasoning about straw men, as you yourself have
repeatedly pointed out.
Why the use of "shape" in "scare quotes"?
Because the `shape' of an object is not something that is a
well-defined term, but rather addresses the intuitive understanding to
explain what we are talking about. It is usually the intention of the
abstract to give a rough overview, before delving into the details and
more formal descriptions.
Using a contrived example like this seems like a straw man. It
feels like it is constructed to favour the PEP, whilst being unlike
any real code.
It is a trait of many (good) tutorials to present a new structure with
an example that highlights its feature in an approachable way rather
than coming up with `real code'---particularly given that real code is
always surrounded by a larger context, which rather clouds any
understanding. And it would only be a straw man had we constructed a
contrived example of unrealistic code that we then showed to be
simplified by pattern matching. That's not the case: it really is
just a simple educational example to present the idea.
BTW: as a matter of course, it is constructed in favour of the PEP!
There seem to be three things you want to enhance here:
Unpacking; to avoid calls to `len`
Type checking; to avoid calls to `isinstance`.
To avoiding nesting by using complex lvalues.
Actually, no. Pattern matching is not about _avoiding_ anything, it
is about a more concise syntax. The suggestion that we wanted to
avoid calls to `len` or `isinstance` is similar to the idea of using a
lambda to avoid a function. The objective of pattern matching is to
introduce a more succinct and readable way to express structure. It's
all still there but we want to focus on the structure rather than
`isinstance` calls.
Pattern matching already exists in some limited way in Python. Even
today you can write:
`a, b = value`
instead of:
`a = value[0]
b = value[1]`
The idea of this is, of course, not so much about avoiding item
access, but about having a more concise syntax for it. Moreover,
saying this only saves a single line and is therefore rather useless
is quite beside the point. It is about a better representation of
what the code is supposed to do and not about saving lines.
Saves two lines of code, but introduces two bugs!
(Assuming that the original behavior should be preserved)
Thank you for pointing out the bug in our example. This highlights,
however, rather the difficulty of refactoring (did I already mention
the issue of the 'context' that real code is embedded in?), than any
shortcoming of pattern matching as a tool. And by the way:
constructive critisism would perhaps include explicitly naming the two
bugs.
For example, by adding a simple "matches" method to Node and Leaf,
`is_tuple` can be rewritten as something like:
This assumes that you have full control over the entire code. But if
you are using some third-party library, you cannot "simply add a
`matches` method" (without some substantial trickery). Moreover,
there is quite some work needed to define such a `matches` function as
you propose it (including support for the ellipsis as wildcard). In
effect, you would have to implement large parts of the pattern
matching for just this simple example. Whereas we believe that it has
merit enough to have the compiler do it for a wide range of possible
use cases.
I really don't see you how you can claim that
`case 406:`
is more readable than
`elif response == HTTP_UPGRADE_REQUIRED:`
?
Preventing the use of symbolic constants or other complex rvalues is
a impairment to usability.
First, let me quote what the PEP has to say on that exact example:
Although this will work, it's not necessarily what the proposal is
focused on.
Moreover, it is usually a good idea to put constants into a separate
namespace that further describes their meaning and intended use. And
that is fully supported by the syntax as proposed in the PEP.
```
match response.status:
case HTTP_RESPONSE.UPGRADE_REQUIRED:
...
```
For a PEP to succeed it needs to show two things.
1. Exactly what problem is being solved, or need is to be fulfilled,
and that is a sufficiently large problem, or need, to merit the
proposed change.
2. That the proposed change is the best known solution for the
problem being addressed.
IMO, PEP 622 fails on both counts.
This seems fair enough as far as the two issues are concerned. It
might seem indeed as if pattern matching does not add anything that
could not be done already in Python. Part of the problem is that
pattern matching starts to really shine when the objects and data get
more complex---which requires a lot of built-up and context just to
get to the point. This is similar to OOP: as long as you stick with
the easy introductory examples, OOP does not really provide anything
that you could not solve using procedural programming. For instance,
I often see critisism of Java based on some simple hello-world
examples, which completely misses the point of OOP in the first place,
of course.
As far as referring to the best solution: may I humbly point out that
pattern matching has been around for some 40 years now and has been
adopted by an increasing number of languages lately. We put a lot of
effort into designing a version of it that fits well with Python and
covered a huge design space, while also taking all the lessons of
those who came before us to heart. This is not just a new feature we
propose on a whim.
In the end, pattern matching is an increasingly popular feature that
favours higher-level declarative expressiveness over spelling out all
the details of how to check the structure of data and extract
information from it. Think of it perhaps this way: pattern matching
is like introducing grammars and parser generators instead of writing
a new parser each time. It answers the question of: could we have
something like regular expressions for graph-like objects instead of
only text...?
Kind regards,
Tobias
_______________________________________________
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/AFQTT2MI4R3CSQNTROMXFHYUVP4KWVZC/
Code of Conduct: http://python.org/psf/codeofconduct/
