[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Brandt Bucher]

Guido van Rossum wrote:
> Well, now I have egg on my face, because the current implementation does 
> reject multiple occurrences of the same identifier in __match_args__. We 
> generate an error like "TypeError: C() got multiple sub-patterns for 
> attribute 'a'". However, I cannot find this uniqueness requirement in PEP 
> 634, so I think it was a mistake to implement it.
> 
> Researching this led me to find another issue where PEP 634 and the 
> implementation differ, but this time it's the other way around: PEP 634 says 
> about types which accept a single positional subpattern (int(x), str(x) etc.) 
> "for these types no keyword patterns are accepted." Mark's example `case 
> int(real=0, imag=0):` makes me think this requirement is wrong and I would 
> like to amend PEP 634 to strike this requirement. Fortunately, this is not 
> what is implemented. E.g. `case int(1, real=1):` is accepted and works, as 
> does `case int(real=0):`.
> 
> Calling out Brandt to get his opinion. And thanks to Mark for finding these!

The current implementation will reject any attribute being looked up more than 
once, by position *or* keyword. It's actually a bit tricky to do, which is why 
the `MATCH_CLASS` op is such a beast... it needs to look up positional and 
keyword attributes all in one go, keeping track of everything it's seen and 
checking for duplicates.

I believe this behavior is a holdover from PEP 622:

> The interpreter will check that two match items are not targeting the same 
> attribute, for example `Point2d(1, 2, y=3)` is an error.

(https://www.python.org/dev/peps/pep-0622/#overlapping-sub-patterns)

PEP 634 explicitly disallows duplicate keywords, but as far as I can tell it 
says nothing about duplicate `__match_args__` or keywords that also appear in 
`__match_args__`. It looks like an accidental omission during the 622 -> 634 
rewrite.

(I guess I figured that if somebody matches `Spam(foo, y=bar)`, where 
`Spam.__match_args__` is `("y",)`, that's probably a bug in the user's code. 
Ditto for `Spam(y=foo, y=bar)` and `Spam(foo, bar)` where `Spam.__match_args__` 
is `("y", "y")` But it's not a hill I'm willing to die on.)

I agree that self-matching classes should absolutely allow keyword matches. I 
had no idea the PEP forbade it.
___
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/EKXKRZBJAUWVJVMF3MCNJA6I7HLLL26B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Terry Reedy]

On 4/2/2021 12:02 AM, Guido van Rossum wrote:
On Thu, Apr 1, 2021 at 8:01 PM Terry Reedy 


The current near-Python code does not have such a check.




Again, I'm not sure what "the current near-Python code" refers to. From 
context it seems you are referring to the pseudo code in Mark's PEP 653.



Yes, the part I read was legal Python + $ variables + FAIL.  I should 
have included 'pseudo'.


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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Guido van Rossum]

On Thu, Apr 1, 2021 at 8:01 PM Terry Reedy  wrote:

> On 4/1/2021 9:38 PM, Guido van Rossum wrote:
>
> > On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon  > > wrote:
> > Almost all the changes come from requiring __match_args__ to be a
> tuple
> > of unique strings.
>
> The current posted PEP does not say 'unique' and I agree with Guido that
> it should not.
>

(Of course, "the current PEP" is highly ambiguous in this context.)

Well, now I have egg on my face, because the current implementation does
reject multiple occurrences of the same identifier in __match_args__. We
generate an error like "TypeError: C() got multiple sub-patterns for
attribute 'a'". However, I cannot find this uniqueness requirement in PEP
634, so I think it was a mistake to implement it.

Researching this led me to find another issue where PEP 634 and the
implementation differ, but this time it's the other way around: PEP 634
says about types which accept a single positional subpattern (int(x),
str(x) etc.) "for these types no keyword patterns are accepted." Mark's
example `case int(real=0, imag=0):` makes me think this requirement is
wrong and I would like to amend PEP 634 to strike this requirement.
Fortunately, this is not what is implemented. E.g. `case int(1, real=1):`
is accepted and works, as does `case int(real=0):`.

Calling out Brandt to get his opinion. And thanks to Mark for finding these!


> > Ah, *unique* strings. Not sure I care about that. Explicitly checking
> > for that seems extra work,
>
> The current near-Python code does not have such a check.
>

Again, I'm not sure what "the current near-Python code" refers to. From
context it seems you are referring to the pseudo code in Mark's PEP 653.


> > and I don't see anything semantically suspect in allowing that.
>
> If I understand the current pseudocode correctly, the effect of 's'
> appearing twice in 'C.__match_args__ would be to possibly look up and
> assign C.s to two different names in a case pattern.
>
> I would not be surprised if someone someday tries to do this
> intentionally.  Except for the repeated lookup, it would be similar to a
> = b = C.s.  This might make sense if C.s is mutable.  Or the repeated
> lookups could yield different values.
>

Yes, and this could even be a valid backwards compatibility measure, if a
class used to have two different attributes that would in practice never
differ, the two attributes could be merged into one, and someone might have
a pattern capturing both, positionally. That should keep working, and
having a duplicate in __match_args__ seems a clean enough solution.

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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Terry Reedy]

On 4/1/2021 9:38 PM, Guido van Rossum wrote:

On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon > wrote:

Almost all the changes come from requiring __match_args__ to be a tuple
of unique strings.


The current posted PEP does not say 'unique' and I agree with Guido that 
it should not.


Ah, *unique* strings. Not sure I care about that. Explicitly checking 
for that seems extra work,


The current near-Python code does not have such a check.


and I don't see anything semantically suspect in allowing that.


If I understand the current pseudocode correctly, the effect of 's' 
appearing twice in 'C.__match_args__ would be to possibly look up and 
assign C.s to two different names in a case pattern.


I would not be surprised if someone someday tries to do this 
intentionally.  Except for the repeated lookup, it would be similar to a 
= b = C.s.  This might make sense if C.s is mutable.  Or the repeated 
lookups could yield different values.


--
Terry Jan Reedy

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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Guido van Rossum]

On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon  wrote:

> On 31/03/2021 9:53 pm, Guido van Rossum wrote:
> > On Wed, Mar 31, 2021 at 12:08 PM Mark Shannon  > > wrote:
>
> [snip]
>
> > Apart from that, I think the semantics are so similar once you've
> added
> > __match_seq__/__match_map__  to PEP 634 that is hard to
> > claim one is better than the other.
> > My (unfinished) implementation of PEP 653 makes almost no changes to
> > the test suite.
> >
> > I'd like to see where those differences are -- then we can talk about
> > which is better. :-)
>
> Almost all the changes come from requiring __match_args__ to be a tuple
> of unique strings.
>

Ah, *unique* strings. Not sure I care about that. Explicitly checking for
that seems extra work, and I don't see anything semantically suspect in
allowing that.


> The only other change is that
>
> case int(real=0+0j, imag=0-0j):
>
> fails to match 0, because `int` is `MATCH_SELF` so won't match attributes.
>

Oh, but that would be a problem. The intention wasn't that "self" mode
prevents keyword/attribute matches. (FWIW real and imag should attributes
should not be complex numbers, so that testcase is weird, but it should
work.)


>
> https://github.com/python/cpython/compare/master...markshannon:pep-653-implementation?expand=1#diff-490b4f3b911cb4ca281e9ca6ff814bc10d331f0421f6c6971b08d9f29020620b
>


-- 
--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/6QGOH4PQXPFLRUHYX5VXQN37YFQXGESV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Mark Shannon]

Hi Guido,

On 31/03/2021 9:53 pm, Guido van Rossum wrote:
On Wed, Mar 31, 2021 at 12:08 PM Mark Shannon > wrote:




[snip]


Apart from that, I think the semantics are so similar once you've added
__match_seq__/__match_map__  to PEP 634 that is hard to
claim one is better than the other.
My (unfinished) implementation of PEP 653 makes almost no changes to
the
test suite.


I'd like to see where those differences are -- then we can talk about 
which is better. :-)


Almost all the changes come from requiring __match_args__ to be a tuple 
of unique strings.


The only other change is that

case int(real=0+0j, imag=0-0j):

fails to match 0, because `int` is `MATCH_SELF` so won't match attributes.

https://github.com/python/cpython/compare/master...markshannon:pep-653-implementation?expand=1#diff-490b4f3b911cb4ca281e9ca6ff814bc10d331f0421f6c6971b08d9f29020620b

Cheers,
Mark.
___
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/IKJXKRO5MFUKKEB347X7TSXFVWWLDJYB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Mark Shannon]

On 31/03/2021 11:31 pm, Brandt Bucher wrote:

Guido van Rossum wrote:

On Wed, Mar 31, 2021 at 2:14 PM Brandt Bucher brandtbuc...@gmail.com
wrote:

(One change from my last email: it doesn't allow `__match_map__` /
`__match_seq__` to be set to `False`... only `True`. This prevents some
otherwise tricky multiple-inheritance edge-cases present in both of our
flagging systems that I discovered during testing. I don't think there are
actual use-cases for unsetting the flags in subclasses, but we can revisit
that later if needed.)

That's surprising to me. Just like we can have a class that inherits from
int but isn't hashable, and make that explicit by setting `__hash__ =
None`, why couldn't I have a class that inherits from something else that
happens to inherit from Sequence, and say "but I don't want it to match
like a sequence" by adding `__match_sequence__ = False`? AFAIK all Mark's
versions would support this by setting `__match_kind__ = 0`.


The issue isn't when *I* set `__match_seq__ = False` or `__match_container__ = 
0`. It's when *one of my parents* does it that things become difficult.


Maybe you can show an example edge case where this would be undesirable?


Good idea. I've probably been staring at this stuff for too long to figure it 
out myself. :)

As far as I can tell, these surprising cases arise because a bit flag can only be either 
0 or 1. For us, "not specified" is equivalent to 0, which can lead to ambiguity.

Consider this case:

```
class Seq:
 __match_seq__ = True
 # or __match_container__ = MATCH_SEQUENCE

class Parent:
 pass

class Child(Parent, Seq):
 pass
```

Okay, cool. `Child` will match as a sequence, which seems correct. But what 
about this similar case?

```
class Seq:
 __match_seq__ = True
 # or __match_container__ = MATCH_SEQUENCE

class Parent:
 __match_seq__ = False
 # or __match_container__ = 0

class Child(Parent, Seq):
 pass
```

Here, `Child` will *not* match as a sequence, even though it probably should. The only 
workarounds I've found (like allowing `None` to mean "this is unset, don't inherit 
me if another parent sets this flag", ditching tp_flags entirely, or not inheriting 
these attributes) feel a bit extreme just to allow some users to do the moral equivalent 
of un-subclassing `collections.abc.Sequence`.


This is just a weird case, so I don't think we should worry about it too 
much.




So, my current solution (seen on the branch linked in my earlier email) is:

- Set the flag if the corresponding magic attribute is set to True in the class 
definition
- Raise at class definition time if it's set to anything other than True
- Otherwise, set the flag if any of the parents set have the flag set

As far as I can tell, this leads to the expected (and current, as of 3.10.0a6) 
behavior in all cases. Plus, it doesn't break my mental model of how 
inheritance works.


Inheritance in Python is based on the MRO (using the C3 linearization 
algorithm) so my mental model is that Child.__match_container__ == 0.


Welcome the wonderful world of multiple inheritance :)

If Parent.__match_container__ == 0 (rather than just inheriting it) then 
it is explicitly stating that it is *not* a container.

Seq explicitly states that it *is* a sequence.

So Child is just broken. That it is broken for pattern matching is 
consistent with it being broken in general.


Cheers,
Mark.



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

[Python-Dev] Re: Weird io.OpenWrapper hack to use a function as method

[Inada Naoki]

On Thu, Apr 1, 2021 at 11:52 AM Brett Cannon  wrote:
>
> On Wed., Mar. 31, 2021, 18:56 Inada Naoki,  wrote:
>>
>> Do we need _pyio at all?
>> Does PyPy or any other Python implementation use it?
>
> https://www.python.org/dev/peps/pep-0399/ would suggest rolling back Python 
> support is something to avoid.
>

Thank you.
If we obey PEP 399, we need an easy way to keep consistency between
Python function and C function.

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