On 07/14/2020 11:05 AM, Mark Shannon wrote:
On 14/07/2020 5:25 pm, Tobias Kohn wrote:
On 07/14/2020, Mark Shannon wrote:
In future, could you avoid editing emails when replying to them?
A lot of context can get lost.
I appreciate posters who take the time to trim the parts of an email that they
are not replying to.
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.
You ignore my point about explaining PEP 622 directly. Sure, the abstract must
give a high level overview, but it should be able to do that without so much
hand waving.
I find the PEP abstract concrete enough. Perhaps you could write a replacement
that you think does a better job?
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.
I should have been clearer. Avoiding *explicit* calls to `len` and
`isinstance`. Yes, the pattern matching syntax is more concise in some
circumstances, but there still needs to be justification why a combination of
simpler language changes is insufficient.
My apologies if I missed it, but do you have some ideas of these simpler
language changes that would do the job?
Pattern matching already exists in some limited way in Python. Even today you
can write:
`a, b = value`
I think most of us are aware of unpacking in Python ;)
Yes, but not everyone recognizes that unpacking is a form of pattern matching.
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.
How do you quantify "better representation" then?
You mean, without large study groups and lots of money and/or time? Not easily.
I can tell you that
a, b = value
is much more informative, and easier to read and process, than the alternative
of using item assignment.
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.
I'm not sure it would be more constructive, this is not a bug report or code
review after all.
It should be. If the PEP is to be decided on it should be as correct as
possible.
The point I am making is this:
It is far too easy to make mistakes using the constructs proposed in PEP 622.
You're point is false. They weren't crafting new code, they were refactoring.
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.
You wouldn't have to implement large parts of the pattern matching,
because this would be specific to one class. There are only two or three cases
to deal with.
If you don't have access to the original source, then it can be made a
function, not a method.
So, a few lines for that example, another few for a different example, some
more for that example over there -- how many times do we have to write similar
code before we let Python do the grunt work for us?
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.
So why does the PEP include it as one of just three examples?
To show that it is possible?
The PEP needs to convince us that it is a useful tool.
Or we can look in our own code and see where it would be useful. I was able to
find a location within only moments of searching, and I even managed to get the
refactoring correct.
Providing compelling real world examples is necessary.
I found the examples provided very compelling.
Pattern matching is well suited to statically typed functional languages.
Python is, at its heart, a dynamically typed procedural language.
And this PEP will finally give us pattern matching for our dynamic language.
Higher-level more declarative programming is great, but there are many ways to
do it. List comprehensions, dataclasses, and f-strings are examples.
Each of those adds a clear benefit without being overly complex.
It was also clear what code patterns they streamlined.
PEP 622 fails to make clear which code patterns it streamlines.
I found it very clear:
- lots of conditions to see if you have the object you think you have? Use
Pattern Matching.
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...?
Objects are about encapsulation. They may be graphs internally but that should
be hidden.
Objects should be able to provide an interface without exposing their
internals, which means you can't efficiently pattern match on them.
Pattern matching is for Algebraic Data Types, not Objects.
Pattern matching is not enabling us to check for anything we weren't already
checking for, it's just making it easier to see what is being checked for. And
since everything in Python is an object, and a working implementation of
pattern matching for Python now exists, I would say pattern matching is
definitely for objects.
--
~Ethan~
_______________________________________________
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/ZSBYKQ5WRJC5QWGTQITJZM5EMC5R5LYS/
Code of Conduct: http://python.org/psf/codeofconduct/
