[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Guido van Rossum]

(For people who fail to find any mention of protocols in PEP 634, Protocols
(PEP 544) can be used (with the @runtime decorator) to override
isinstance(), and class patterns are defined to use isinstance() for the
class check.)

On Wed, Nov 18, 2020 at 11:50 AM Brett Cannon  wrote:

>
>
> On Wed, Nov 18, 2020 at 1:25 AM Robin Becker  wrote:
>
>> Is there a bestiary of examples for the current pattern matching
>> proposal(s)?
>>
>> It seems I don't have a good handle on how one matches simple tests like
>> callability,
>
>
> Doable using protocols.
>
>
>> function signatures,
>
>
> I don't think that's directly doable, but there might be some way to bend
> it to protocols.
>
>
>> possession of
>> specific attribute(s).etc.
>>
>
> Protocols.
>
>
>>
>> Also will matching ever extend into the Typing universe?
>>
>
> In what way do you have in mind? With protocol support baked into PEP 634
> that already ties into type hints.
>
> -Brett
>
>
>>   --
>> Robin Becker
>> ___
>> 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/OKBOTKDQ6WBEDPCBTDRYRI5HRDHRDVER/
>> 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/YMLP5QDXRCO2QJG2GXJFIG3F4F56VLPL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/42GPITT4Z7TOBYSYJ6DOMUVVBYN27MUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Guido van Rossum]

On Wed, Nov 18, 2020 at 11:39 AM Brett Cannon  wrote:

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

I suspect that historically there is a connection here; we used "_" in
Python for a number of special purposes because it's defined to be an
identifier by the lexer but not likely to be used as a "regular"
identifier, being kind of an edge case. Like Python, many other languages
inherited this from C, with its definition of identifiers as "letter
(letter|digit)*" where "_" is considered a letter.

Also, in Scala its usage in patterns is similarly different from the rest
of the language; there, too, it is a normal variable name except in
patterns.

PS. Why do you think that this is "late in Python's history?" In 100 years
people will chuckle about that. :-)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/5VBDCGYHWFZM3C4AB5364M7XY4H3ZSUE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Brett Cannon]

On Wed, Nov 18, 2020 at 1:25 AM Robin Becker  wrote:

> Is there a bestiary of examples for the current pattern matching
> proposal(s)?
>
> It seems I don't have a good handle on how one matches simple tests like
> callability,


Doable using protocols.


> function signatures,


I don't think that's directly doable, but there might be some way to bend
it to protocols.


> possession of
> specific attribute(s).etc.
>

Protocols.


>
> Also will matching ever extend into the Typing universe?
>

In what way do you have in mind? With protocol support baked into PEP 634
that already ties into type hints.

-Brett


>   --
> Robin Becker
> ___
> 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/OKBOTKDQ6WBEDPCBTDRYRI5HRDHRDVER/
> 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/YMLP5QDXRCO2QJG2GXJFIG3F4F56VLPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

[Brett Cannon]

On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing 
wrote:

> On 18/11/20 4:36 pm, Larry Hastings wrote:
> >
> > But,
> > the thinking went, you'd never want to examine the last value from a
> > list generator, so it was more convenient if it behaved as if it had its
> > own scope.
>
> List comprehensions used to leak, but apparently that was considered
> surprising by enough people that it was changed.
>
> Generator expressions are a bit different -- the only sane way to
> implement them was to make the body implicitly a separate function,
> and non-leaking behaviour naturally fell out of that. Making them
> leak would have taken extra work just to get something that nobody
> really had a good use case for.
>
> The desire to make list comprehensions and generator expressions
> behave consistently may have contributed to the decision to change
> list comprehensions to be non-leaking.
>

It did if I remember correctly.

For me, generator expressions are small functions like you say (see, people
did get the equivalent of multi-line lambdas, just in a very specific
format 😉), and all the comprehensions are just passing a generator
expression to the appropriate constructor, e.g. list(), set(), and dict().
In that regard the scoping is consistent to me.

-Brett


>
> So yes, it's all a bit messy, for reasons that are partly historical
> and partly pragmatic, but things seem to work out okay in practice
> most of the time.
>
> If there's anything I would change, it would be to have the for
> statement create a new binding on each iteration, so that capturing
> it with a def or lambda inside the loop works as expected. I even
> came up with a way to do that while still allowing the last-bound
> value to be seen afterwards, but the idea didn't gain any traction.
>
> --
> Greg
> ___
> 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/FC7WYLN7C54ZK2FRQSLH5GFA4P2OHBBC/
> 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/OI2DAQYQT3PWL2K3WSG2TA2U3TN2FYGB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Brett Cannon]

On Tue, Nov 17, 2020 at 1:16 PM Tobias Kohn  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,
> Tobia

[Python-Dev] Re: The semantics of pattern matching for Python

[Daniel Moisset]

[sorry for the duplicate, meant to reply-all]

Thank you for this approach, I find it really helpful to put the
conversation in these terms (semantics and guiding principles).

This is not an answer to the proposal (which I've read and helps me
contextualize) but to your points below and how they apply to PEP-634. I'm
also answering personally, with a reasonable guess about what the other
authors of 634-636 would agree, but they may correct me if I'm wrong.

On Mon, 16 Nov 2020 at 14:44, Mark Shannon  wrote:

> (...)
> I believe that a pattern matching implementation must have the following
> properties:
>
> * The semantics must be precisely defined.
> * It must be implemented efficiently.
> * Failed matches must not pollute the enclosing namespace.
> * Objects should be able determine which patterns they match.
> * It should be able to handle erroneous patterns, beyond just syntax
> errors.
>
> PEP 634 and PEP 642 don't have *any* of these properties.
>

Let me answer this one by one:

1. "The semantics must be precisely defined":
If this happens in PEP634 I don't think it was intentional, and I'm pretty
sure the authors would be happy to complete any incompleteness that it has.
I would happily have a more accurate description (I drafted a non-official
one for a much earlier version of PEP-622,
https://github.com/dmoisset/notebook/blob/master/python/pep622/semantic-specs.md
).
Can you clarify where you see these imprecisions?

2. "It must be implemented efficiently":
I don't think "efficient implementation" was a priority in PEP634,
although I saw your proposal defines this as "same performance as the
equivalent if statement", and I'm quite sure that level of performance can
be achieved (if it isn't already by Brandt's implementation). Finding the
best way to optimise wasn't a priority, but I think if there was anything
in our implementation that would make optimisations harder we would
consider them as a change. Do you think anything like that has been
presented?

3. "Failed matches must not pollute the enclosing namespace":
This for me is one of the less-desirable parts of the proposal, and was
agreed more as a matter of practicality and an engineering tradeoff. If you
have a reasonable way of solving this (like putting matched variables in
the stack and popping it later) reasonably I'd be much happier putting that
in.

4. "Objects should be able determine which patterns they match."
This is something that you and I, and most of the authors of 622 agree on.
What we found out when discussing this is that we didn't have clear what
and how to open that customization. Some customization options added a lot
of complexity at the cost of performance, some others were very simple but
it wasn't clear that they would be actually useful, or extensible in the
future. This has a lot to do with this being a somewhat new paradigm in
Python, and our lack of knowledge on what the user community may do with it
beyond what we imagined. So the decision was "pattern matching as it is
presented without extensibility is useful, let's get this in, and once we
see how it is used in the wild we'll understand better what kind of
extensibility is valuable". For a crude analogy, imagine trying to get the
descriptor protocol right when the basic python object model was being
implemented. These things happened as different times as the use of the
language evolved, and my opinion is that customization of the match
protocol must follow a similar path.

5. "It should be able to handle erroneous patterns, beyond just syntax
errors."
I'll be answering this based on the example in your document, matching
RemoteCount(success=True,
count=count) where RemoteCount is a namedtuple. The code is likely an
error, and I'm in general all for reporting errors early, but the kind of
error detection proposed here is the kind of errors that python normally
ignore. I find that example really similar to the kind of error you could
make writing "if remcount.count == 3: ..." or going beyond this example
"maxelems = configfile.read(); if len(elems) == maxelems: ...". There are
many type errors that python ignores (especially related to equality), and
Python has already made the decision of allowing mixed type equality
comparisons everywhere, so why do you think pattern matching should be
different with respect to this? In my opinion trying to "fix" this (or even
agreeing if this is a bug or not) is a much more general issue unrelated to
pattern matching. Given the current status-quo I normally trust python type
checkers to help me with these errors, and I'd expect them to do the same
with the "erroneous" match statement.
If there are other examples you had in mind when you wrote this I'd also be
happy to discuss those.

I'll try to get some time to review your specific counterproposal later,
thanks for it.

Best,
Daniel

>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to py

[Python-Dev] PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Robin Becker]

Is there a bestiary of examples for the current pattern matching proposal(s)?

It seems I don't have a good handle on how one matches simple tests like callability, function signatures, possession of 
specific attribute(s).etc.


Also will matching ever extend into the Typing universe?
 --
Robin Becker
___
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/OKBOTKDQ6WBEDPCBTDRYRI5HRDHRDVER/
Code of Conduct: http://python.org/psf/codeofconduct/