[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

I think we are storing up trouble unless we
    1) Allow arbitrary expressions after `case`, interpreted *as now*
    2) Use *different* syntaxes, not legal in expressions, for
            alternative matching values (i.e. not `|` or `or`) (NB 
simply stacking with multiple `case` lines is one possibility)

            templates such as `Point(x, 0)`
            anything else particular to `match`
I am reminded of the special restrictions for decorator syntax, which 
were eventually removed.


On 24/06/2020 20:38, Guido van Rossum wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Tobias Kohn]

 Hi Rob,

 You are right: the grammar should probably read `suite` rather
than `block` (i.e. the `pass` is necessary).  Thanks for catching
this!

 As for the second question, I assume there might be a slight
oversight on your part.  The last line in the example replaces the
string `"_"` rather than the variable `_`.  The not-binding of `_`
thus has no influence on the last line.

 I think I will leave it for Mark himself to name the two bugs rather
than start a guessing game.  However, in an earlier version we had
left out the `if value` for the first case, accidentally translating
the `len(value) > 1` as a `len(value) >= 1` instead.

 Kind regards,
Tobias

Quoting Rob Cliffe via Python-Dev :


[...]

_First question_: Sometimes no action is needed after a case  
clause.  If the Django example had been written
if ( isinstance(value, (list, tuple)) and len(value) > 1 and  
isinstance(value[-1], (Promise, str)) ): *value, label =  
value else: label = key.replace('_', ' ').title()  the  
replacement code would/could be  match value: case [*value,  
label := (Promise() | str())] if value: pass case _:  
label = key.replace('_', ' ').title()  AFAICS the PEP does not  
*explicitly* state that the 'pass' line is necessary (is it?), i.e.  
that the block following `case` cannot (or can?) be empty. The term  
`block` is not defined in the PEP, or in  
https://docs.python.org/3/reference/grammar.html. But an empty block  
following a line ending in `:` would AFAIK be unprecedented in  
Python.  I think it is worth clarifiying this.  _Second question_:  
in the above example replacement, if `case _:` does not bind to `_`,  
does that mean that the following line will not work? Is this one of  
the "two bugs" that Mark Shannon alluded to?  (I have read every  
message in the threads and I don't remember them being spelt out.)  
And I'm curious what the other one is (is it binding to a variable  
`v`?).  Best wishes Rob Cliffe
___
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/4MNGTBKIXNMMVAIFOLR2W62SLK637OY5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

On 24/06/2020 20:38, Guido van Rossum wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


(Prefatory remarks:  I am sure you get a lot of questions to which the 
answer is basically "Read the PEP".  I myself have been guilty in this 
regard.  But I fear this is inevitable when the PEP is so long and there 
is so much new stuff to absorb.  Apologies if this is yet another one.)


_First question_: Sometimes no action is needed after a case clause.  If 
the Django example had been written


if (
isinstance(value, (list, tuple)) and
len(value) > 1 and
isinstance(value[-1], (Promise, str))
):
*value, label = value
else:
label = key.replace('_', ' ').title()

the replacement code would/could be

match value:
case [*value, label := (Promise() | str())] if value:
pass
case _:
label = key.replace('_', ' ').title()

AFAICS the PEP does not *explicitly* state that the 'pass' line is necessary 
(is it?), i.e. that the block following `case` cannot (or can?) be empty.
The term `block` is not defined in the PEP, or in 
https://docs.python.org/3/reference/grammar.html.
But an empty block following a line ending in `:` would AFAIK be unprecedented 
in Python.  I think it is worth clarifiying this.

_Second question_: in the above example replacement, if `case _:` does not bind 
to `_`, does that mean that the following line will not work?
Is this one of the "two bugs" that Mark Shannon alluded to?  (I have read every 
message in the threads and I don't remember them being spelt out.)
And I'm curious what the other one is (is it binding to a variable `v`?).

Best wishes
Rob Cliffe

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

Without arguing for or against allowing a capture variable, IMO rather 
than syntax like

    match  into :
it would be far better (and not require a new keyword) to write this as
    with  as match :
Rob Cliffe

On 24/06/2020 20:38, Guido van Rossum wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

On 08/07/2020 16:15, MRAB wrote:

On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:

Why not use '=' to distinguish binding from equality testing:
      case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.

This would allow a future (or present!) extension to other relative
operators:
      case Point(x, >y):
(although the syntax doesn't AFAICS naturally extend to specifying a
range, i.e. an upper and lower bound, which might be a desirable thing
to do.
Perhaps someone can think of a way of doing it).

Whether
      case =42:
      case 42:
would both be allowed would be one issue to be decided.

In Python, '=' is assignment and '==' is equality. Using '=' for 
equality could lead to confusion.

Fair enough.  In that case use `==` instead:
    case Point(x, ==y): # if matches a Point with the given y-value, 
bind to x


___
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/KYUZQRZNDOVFEOC5XBYOFXKTPK7LAZI4/

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Greg Ewing]

On 9/07/20 3:26 am, Brandt Bucher wrote:

match :
 case  | : ...
 case  |  if : ...
 case  | : ...
```

It's safe to use the same decision tree for  through , but it must be rebuilt for 
 and , since  could have done literally *anything*.


I think you're being overly cautious here. To my mind, the guards
should be regarded as part of the pattern matching process, and so
people shouldn't be writing code that depends on them having side
effects.

As a nice consequence of adopting that rule, we would be able
to say that these are equivalent:

case C(a.b): ...

case C(x) if x == a.b: ...

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Brandt Bucher]

Inada Naoki wrote:
> Since this is very new system, can we have some restriction to allow 
> aggressive optimization than regular Python code?

The authors were just discussing a related question yesterday (more 
specifically, can the compiler fold `C() | C()` -> `C( | )`). 
The answer we arrived at is "yes"; in general patterns may take reasonable 
shortcuts, and should not be expected to follow all the same rules as 
expressions. This means that users should never count on 
`__contains__`/`__getitem__`/`__instancecheck__`/`__len__`/`__match_args__` or 
other attributes being looked up or called more than once with the same 
arguments, and that name lookups *may* be "frozen", in a sense. We don't feel a 
need to cater to code that relies on these side-effecty behaviors (or doing 
even nastier things like changing local/global name bindings); in the eyes of 
the authors, code like that is buggy.

However, these rules only apply as long as we are still in "pattern-land", 
meaning all of our knowledge about the world is invalidated as soon as we hit a 
guard or stop matching.

In practice, I am currently experimenting with building decision-trees at 
compile-time. Given a match block of the following form:

```
match :
case  | : ...
case  |  if : ...
case  | : ...
```

It's safe to use the same decision tree for  through , but it must be 
rebuilt for  and , since  could have done literally *anything*.
___
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/XY3FXVB7HDYJIVKSOOBHW5BV2UB522FL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[MRAB]

On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:

Why not use '=' to distinguish binding from equality testing:
      case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.

This would allow a future (or present!) extension to other relative
operators:
      case Point(x, >y):
(although the syntax doesn't AFAICS naturally extend to specifying a
range, i.e. an upper and lower bound, which might be a desirable thing
to do.
Perhaps someone can think of a way of doing it).

Whether
      case =42:
      case 42:
would both be allowed would be one issue to be decided.

In Python, '=' is assignment and '==' is equality. Using '=' for 
equality could lead to confusion.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Richard Damon]

On 7/7/20 10:08 PM, Rob Cliffe via Python-Dev wrote:
> Why not use '=' to distinguish binding from equality testing:
>     case Point(x, =y): # matches a Point() with 2nd parameter equal to
> y; if it does, binds to x.
>
> This would allow a future (or present!) extension to other relative
> operators:
>     case Point(x, >y):
> (although the syntax doesn't AFAICS naturally extend to specifying a
> range, i.e. an upper and lower bound, which might be a desirable thing
> to do.
> Perhaps someone can think of a way of doing it).
>
> Whether
>     case =42:
>     case 42:
> would both be allowed would be one issue to be decided.
> Rob Cliffe 
My preference would be that we mark where to bind as opposed to what is
a constant. Forgetting to mark a constant that has been bound to a name
runs the risk of changing that 'constant' (since Python doesn't support
marking a name as a constant). Forgetting to mark a name to bind may
likely cause a run time error if it hasn't been bound yet, or at the
very least probably fails in a 'safer' way. I think forgetting to add a
special mark is a much more likely error than adding a mark by mistake
(unless the mark is just havig a dot in the name).

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Chris Angelico]

On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki  wrote:
>
> On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico  wrote:
> >
> >
> > These two I would be less averse to, but the trouble is that they make
> > the semantics a bit harder to explain. "Dotted names are looked up if
> > not already looked up, otherwise they use the same object from the
> > previous lookup". If you have (say) "case
> > socket.AddressFamily.AF_INET", does it cache "socket",
> > "socket.AddressFamily", or both?
> >
>
> I meant "It is implementation detail" and "User must not rely on side effects
> of attribute access."
>

Fair enough. I wouldn't mind that, it seems like a nice optimization
that would only harm code that would be extremely confusing to read
anyway. But only within one matching - caching beyond that seems more
dangerous.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Inada Naoki]

On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico  wrote:
>
>
> These two I would be less averse to, but the trouble is that they make
> the semantics a bit harder to explain. "Dotted names are looked up if
> not already looked up, otherwise they use the same object from the
> previous lookup". If you have (say) "case
> socket.AddressFamily.AF_INET", does it cache "socket",
> "socket.AddressFamily", or both?
>

I meant "It is implementation detail" and "User must not rely on side effects
of attribute access."


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rhodri James]

On 08/07/2020 11:05, Federico Salerno wrote:
What I don't like is the use of _ as catch-all, which is different and 
not interdependent with its use as throwaway.


Any name used as a pattern is a catch-all.  The only difference between 
"case dummy:" and "case _:" is that "_" doesn't bind to the thing being 
matched, but "dummy" does bind to it.


--
Rhodri James *-* Kynesim Ltd
___
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/ZU6MJDE4CMMQDYYAJLKWTA2FOAIR5IPG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Federico Salerno]

On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote:
I used to be in this "camp", however, a (I think valid) point was 
raised that "else:" is not a (full) alternative. Due to the 
restriction on repeated names (e.g. Point(x, x) is illegal), if you 
want to "throw away" intermediate matches, you will have to either 
have to come up with new names (Point(unused_1, unused_2)) or use the 
"_" as currently instituted (Point(_, _)) and "else:" does not cover 
that insofar as I can tell.


Personally I think using _ as throwaway name is perfectly fine, as it is 
in the rest of Python. The only exception would then be that _ is 
allowed to be repeated, whereas other identifiers aren't. I'd be ok with 
that.


What I don't like is the use of _ as catch-all, which is different and 
not interdependent with its use as throwaway.


On 08/07/2020 07:26, Steven Barker wrote:

To sum up, I feel like using constructor and keyword-argument syntax 
to access attributes is an abuse of notation. I'd much prefer a new 
syntax for matching classes and their attributes that was not so 
likely to be confusing due to imperfect parallels with class construction.

+1

Ideally something like Datetime.year=x would be in my opinion clear at a 
glance (and reference vs. assignment could be accomplished simply by 
having == for reference and = for assignment), but it's problematic when 
it comes to mentioning multiple attributes.

A couple ideas:

1. Datetime[year=x, months==3, days==SOME_CONST]

2. (Datetime.year=x, months==3, days==SOME_CONST)

3. Datetime.year=x .months==3 .days==SOME_CONST

4. Datetime.year=x, .months==3, .days==SOME_CONST

With no class, this would perhaps favour usage of = and/or == before 
names to resolve the reference vs. assignment dispute.


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Chris Angelico]

On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki  wrote:
>
> Since this is very new system, can we have some restriction
> to allow aggressive optimization than regular Python code?
>
> # Class Pattern
>
> Example:
>
> match val:
> case Point(0, y): ...
> case Point(x, 0): ...
> case Point(x, y): ...
>
> * Can VM cache the "Point" at first execution, and never lookup in
> next time? (e.g. function executed many times)

I'd prefer not - that seems very confusing.

> # Constant value pattern
>
> Example:
>
> match val:
> case Sides.SPAM: ...
> case Sides.EGGS: ...
>
> * Can VM cache the value of "Sides.SPAM" and "Sides.EGGS" for next execution?
>

Similar, but with the additional consideration that you can create a
"pre-baked pattern" by using a dict, so if you're worried about
performance, use the slightly uglier notation (assuming that
Sides.SPAM and Sides.EGGS are both hashable - and if they're not, the
risk of prebaking is way too high).

> * Can VM lookup "Point" only once per executing `match`, instead three times?
> * Can VM lookup "Sides" only once, instead of two?

These two I would be less averse to, but the trouble is that they make
the semantics a bit harder to explain. "Dotted names are looked up if
not already looked up, otherwise they use the same object from the
previous lookup". If you have (say) "case
socket.AddressFamily.AF_INET", does it cache "socket",
"socket.AddressFamily", or both?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Inada Naoki]

Since this is very new system, can we have some restriction
to allow aggressive optimization than regular Python code?

# Class Pattern

Example:

match val:
case Point(0, y): ...
case Point(x, 0): ...
case Point(x, y): ...

* Can VM lookup "Point" only once per executing `match`, instead three times?
* Can VM cache the "Point" at first execution, and never lookup in
next time? (e.g. function executed many times)


# Constant value pattern

Example:

match val:
case Sides.SPAM: ...
case Sides.EGGS: ...

* Can VM lookup "Sides" only once, instead of two?
* Can VM cache the value of "Sides.SPAM" and "Sides.EGGS" for next execution?

Regards,

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Steven Barker]

On Sun, Jun 28, 2020 at 8:44 AM Jim J. Jewett  wrote:

> I actually like that it looks like instantiation; it seems to be saying
> "Do we have the sort of object we would get from this instantiation?"
>
> Unfortunately, this does aggravate the confusion over whether a variable
> is being used as a filter, vs binding to something from the matched object.
>

The constructor-like syntax for class patterns is the part I like least
about this proposal. It seems to expect that there is a one-to-one
correspondence between constructor arguments and instance attributes. While
that might be common, especially for DataClass-like types, it's certainly
not always the case. Some attributes might be computed from multiple
arguments (or looked up elsewhere), and some arguments may never be saved
in their original form. I fear it will be extremely confusing if an
attribute being matched by a class pattern doesn't correspond at all to an
argument in a valid constructor call. For example, this class would make
things very confusing:

class Foo:
def __init__(self, a, b):
self.c = a + b

You could match an instance of the class with `case Foo(c=x)` and it would
work, but that might come as a surprise to anyone familiar with the class
constructor's argument names.

Even when attributes and constructor arguments do line up, the class
pattern syntax also seems a bit awkward when you are not required to match
against all of the non-optional constructor arguments. I imagine `case
datetime.datetime(year=2020):` would be a valid (and even useful!) class
pattern, but you can't construct a datetime instance in that way since the
class has three required arguments.

To sum up, I feel like using constructor and keyword-argument syntax to
access attributes is an abuse of notation. I'd much prefer a new syntax for
matching classes and their attributes that was not so likely to be
confusing due to imperfect parallels with class construction.
___
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/7LXFWX5LPLJBRVUK7OEPB3KGJQNB3AO6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

Why not use '=' to distinguish binding from equality testing:
    case Point(x, =y): # matches a Point() with 2nd parameter equal to 
y; if it does, binds to x.


This would allow a future (or present!) extension to other relative 
operators:

    case Point(x, >y):
(although the syntax doesn't AFAICS naturally extend to specifying a 
range, i.e. an upper and lower bound, which might be a desirable thing 
to do.

Perhaps someone can think of a way of doing it).

Whether
    case =42:
    case 42:
would both be allowed would be one issue to be decided.
Rob Cliffe
___
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/MENII4GJ66JHWBKNTNJSJOYCMSMLSIRO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching - followup

[Eric Nieuwland]

I wrote:
> 
> Guido van Rossum wrote:
> 
>> Eric Nieuwland wrote:
>> 
>>> I have some doubt about the keyword: ‘match' seems to be at odds with
>>> 'for', 'while', 'with', 'if' as it is more of an action.
>>> It's more like 'try' but that statement has a completely different
>>> structure.
>> 
>> Well, 'try' is also an action. :-) Many people have tried to come up with a
>> different keyword here, but nothing has been found that comes even close to
>> the simplicity of match. Plus, several other languages (Scala, Rust) use it
>> too (which is further evidence that it's a natural fit).
> 
> It may also be evidence for not being able to come up with a more accurate 
> keyword.
> 
> Reading through the PEP once more I noticed I was understanding
> 
>   match X:
>   case Y:
>   Z
> 
> as
> 
>   when X:
>   matches Y:
>   Z
> 
> which also to me seems to reflect the close relation to an if-elif-elif… 
> construction.
> 
> This would almost naturally imply the possibility of:
> 
>   when X:
>   matches Y:
>   Z
>   ...
>   else:
>   Q
> 
> And maybe also an additional operator:
> 
>   if X matches Y:
>   Z
> 
> 
>>> Not a native speaker I don't have a reasonable alternative, though.
>> 
>> Me neither, but I speak it quite fluently now, and 'match' really feels
>> like it fits well here.
> 
> Trying ;-)


Thinking of this over the weekend, I think the following might be even more 
flexible and powerful:


when X:
 Y1:
Z1
 Y2:
Z2
…
else:
Q

which would be the same as:

if X  Y1:
Z1
elif X  Y2:
Z2
…
else:
Q

Furthermore

when X:
 Y1 if C1:
Z1
 Y2 if C2:
Z2
…
else:
Q

would be the same as:

if X  Y1 and C1:
Z1
elif X  Y2 and C2:
Z2
…
else:
Q

and so the PEP would need to define:
- the 'when’ keyword
- the 'matches' comparison


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Jim J. Jewett]

I actually like that it looks like instantiation; it seems to be saying "Do we 
have the sort of object we would get from this instantiation?"  

Unfortunately, this does aggravate the confusion over whether a variable is 
being used as a filter, vs binding to something from the matched object.
___
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/CBFTL4NGOC5FWZTMALWUWI42DC63A4IY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[salernof11]

What about `case for Point(x, 0):`? It reads very naturally, the presence of 
"for" hints against Point() being a call to the class, and "for" is an existing 
keyword that would make no other sense in that position.
Examples with other formats such as `case for [x, 0]:` seem to work just as 
well.
___
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/RAKL3WGR3CJLRVNGZQUAWSJAR3TT4VDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Nick Coghlan]

On Thu., 25 Jun. 2020, 5:41 am Guido van Rossum,  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>

I'm not sure if it's a separate point or not, but something I would like to
see the PEP take into account is whether or not the destructuring syntax
(especially for mappings) could become the basis for a future proposed
enhancement to assignment statements that effectively allowed an assignment
statement to be a shorthand for:

match RHS:
case LHS:
   pass # Just doing a destructuring assignment
else:
raise ValueError("Could not match RHS to LHS")


In "y, x = x, y" the fact the names are being used as both lvalues and
rvalues is indicated solely by their appearing on both sides of the
assignment statement.

This is the strongest existing precedent for all names in case expressions
being lvalues by default and having a separate marker for rvalues.

However, I believe it's also a reasonably strong argument *against* using
"." as that rvalue marker, as in "obj.x, obj.y = x, y" the dotted
references remain lvalues, they don't implicitly turn into rvalues.

Interestingly though, what those points suggest is that to be forward
compatible with a possible extension to assignment statements, the PEP is
correct that any syntactic marker would need to be on the *rvalues* that
are constraining the match, putting any chosen symbol (e.g. "?") squarely
in the wildcard role rather than the "lvalue marker" role.

y,? = returns_2_tuple()
y,?None = returns_2_tuple() # Exception if 2nd element is not == None
y,?sentinel = returns_2_tuple() # Exception if 2nd element is not ==
sentinel
y,*? = returns_iterable()

The main mindset shift this approach would require relative to the PEP as
currently written is in explicitly treating the case expression syntax as
an evolution of the existing lvalue syntax in assignment statements rather
than treating it as the introduction of a third independent kind of
expression syntax.

Cheers,
Nick.


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Daniel Moisset]

This one is new but I think unrelated and unmentioned:

Why is the mapping match semantics non-strict about keys? Besides the
"asymmetry" with sequence matches, I think a strict match should be useful
sometimes (quickly deconstructing JSON data comes to my mind, where I want
to know that I didn't get unexpected keys). I cannot get that behaviour
with the current pep. But if we make key strictness the default, I can
always add **_ to my mapping pattern and make it non strict (that's
currently forbidden but the restriction can be lifted). Is there an
assumption (or even better, data evidence) that non-strict checks are much
much more common?

A similar but weaker argument can be made for class patterns (although I
can imagine non-strict matches *are* more common in that case).

Mostly but not completely unrelated to the above, and purely syntactic
sugar bikeshedding, but I think having "..." as an alias for "*_" or "**_"
(depending on context, and I'd say it's *both* inside a class pattern)
could make these patterns slightly more readable.

Best,
D.

On Wed, 24 Jun 2020 at 20:44, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> 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/DS26FCVJ2FCQBRK6OQEBIKYBZPXIIY5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Emily Bowman]

On Fri, Jun 26, 2020 at 3:47 AM Paul Moore  wrote:

> For me, this prompts the question (which I appreciate is more about
> implementation than design) - would there be any (significant)
> performance difference between [...]


> In C, the switch statement was explicitly intended to be faster by
> means of doing a computed branch. In a higher level language, I can
> see the added features of match meaning that it's *slower* than a
> series of if tests for simple cases. But I have no intuition about the
> performance of this proposal. I'd like to believe that the choice
> between the 2 alternatives above is purely a matter of preferred
> style, but I don't know. If match is significantly slower, that could
> make it a bit of an attractive nuisance.
>

Each case essentially compiles down to an equivalent if structure, already.
There's no penalty that I'm seeing. There's actually much more room for
optimizing eventually, since the test is bound to a single element instead
of any arbitrary if expression, and a Cython or PyPy could work some magic
to detect a small set of primitive types and optimize for that.
___
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/7U7VAG2NVWZFBIOH36KVEJC5PCSHZ2R7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Paul Moore]

On Fri, 26 Jun 2020 at 11:29, Daniel Moisset  wrote:
>
> I think roughly half of the uses will actually be for "the switch statement 
> we never had", where all branches would be constants. I've been writing a lot 
> of code like that these last couple of weeks, so I may be biased (although 
> the PEP authors may have been writing AST visitors this last week and may be 
> biased the other way ;-) )
>
> As a sub point, I can understand if the PEP authors argue "match is not for 
> that, use if/elif/dicts of functions in that case like you did before and 
> ignore this PEP", but if that's the case, that should be explicit in the PEP.

For me, this prompts the question (which I appreciate is more about
implementation than design) - would there be any (significant)
performance difference between

match var:
case 1:
print("Got 1")
case 2:
print("Got 2")
case _:
print("Got another value")

and

if var == 1:
print("Got 1")
elif var == 2:
print("Got 2")
else:
print("Got another value")

?

In C, the switch statement was explicitly intended to be faster by
means of doing a computed branch. In a higher level language, I can
see the added features of match meaning that it's *slower* than a
series of if tests for simple cases. But I have no intuition about the
performance of this proposal. I'd like to believe that the choice
between the 2 alternatives above is purely a matter of preferred
style, but I don't know. If match is significantly slower, that could
make it a bit of an attractive nuisance.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Daniel Moisset]

[apologies for the duplicate to Guido, used reply instead of reply to all]

To summarize my previous unanswered post, I posted a +1 to the "defaulting
to binding vs interpreting NAME as a constant" is a dangerous default. And
I submitted a couple of alternate syntactic ways to denote "capture is
desired" (the angle brackets, and the capture object). I think both are
reasonably readable, and one of them doesn't even add any unusual syntax
(not even the "dot prefix")

As an elaboration on that, after reading the discussion and trying to not
repeat what has previously been said:


   - I think there's a mismatch between an assumption made by the authors
   vs what many of us are posting here, which is explicitly stated in "
   
https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern;
   : Quoting the PEP: «the name patterns are more common in typical code, so
   having special syntax for common case would be weird». Even if I think a
   popular use case would be analysing and deconstructing complex nested
   structures (like ASTs), I think roughly half of the uses will actually be
   for "the switch statement we never had", where all branches would be
   constants. I've been writing a lot of code like that these last couple of
   weeks, so I may be biased (although the PEP authors may have been writing
   AST visitors this last week and may be biased the other way ;-) )
  - As a sub point, I can understand if the PEP authors argue "match is
  not for that, use if/elif/dicts of functions in that case like you did
  before and ignore this PEP", but if that's the case, that should be
  explicit in the PEP.
   - I am fairly sure (as much as one can be of the future in these things)
   that with this PEP approved as is, linters will add new rules like "you
   have more than a top level name pattern, only the first one will match.
   Perhaps you wanted constant patterns?" and "your pattern captures shadow an
   existing name" and "a name you bound in a pattern isn't used inside the
   pattern". These will definitely help, but for me "how many new linter rules
   will be needed if this language change is introduced" is a good measure of
   how unelegant it is.
  - Perhaps arguing against myself, I know that, thanks to my regular
  usage of linters, I personally won't suffer much from this problem (once
  they get updated). But I also teach Python to people, and I feel that I'd
  have to add this to the list of "gotchas to avoid" if the PEP
passes as is.


Again, I can't write this email without saying that this feature is great,
that the effort put in this PEP is really palpable, that I'd love to find
the way to get it accepted, and that even if I'm normally conservative
upgrading python versions and waiting my environment to support it fully,
this will likely be the first time that I upgrade just for a language
feature :)


On Wed, 24 Jun 2020 at 20:44, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> 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/NZAQQOXM4K2G4ID4FNWZ6KRDEWFSWDMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Greg Ewing]

On 26/06/20 6:21 am, Pablo Galindo Salgado wrote:
Which means that users can do a positional match against the proxy with 
a name pattern:


match input:
     case datetime.date(dt):
         print(f"The date {dt.isoformat()}"


I think that would be an incorrect way for matching on datetime
to behave. Since datetime has a constructor that takes positional
arguments, it should have a __match__ and/or __match_args__
that agrees.

This suggests that there will be a burden on many existing types
to ensure they implement appropriate matching behaviour, as the
default behaviour provided by object will be wrong for them.

I'm wondering whether the default "single positional match"
behaviour is a bad idea. I.e. the only thing that should work
by default is

   case someclass():

and not

   case someclass(instance):

Classes such as int with constructors that can take a single
argument should be required to implement the corresponding
match behaviour explicitly.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Greg Ewing]

On 26/06/20 12:31 pm, Brandt Bucher wrote:

I'd imagine that we either find some straightforward way of > opting-in to the 
current default behavior


Maybe special-case 'self' in __match_args__ to mean the
object being matched?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Brandt Bucher]

Ethan Furman wrote:
> Ouch.  That seems like a pretty serious drawback.  Will this issue be 
> resolved?

It's currently being revisited.

Realistically, I'd imagine that we either find some straightforward way of 
opting-in to the current default behavior (allowing one arg to be positionally 
matched against the proxy), or lose the nice behavior altogether. Obviously the 
former is preferable, since it's not trivial to reimplement yourself.
___
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/UZ77WPWH4DK3IK3ANKQYOCXKVW4AERIE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Ethan Furman]

On 06/25/2020 04:07 PM, Brandt Bucher wrote:

Pablo Galindo Salgado wrote:

...users can do a positional match against the proxy with a name pattern:

match input:
 case datetime.date(dt):
 print(f"The date {dt.isoformat()}"

...if 'datetime.date' were updated to implement a non-default __match_args__, 
allowing individual fields to be pulled out of it like this, then the first 
block would be valid, correct code before the change, but would raise an 
ImpossibleMatch after the change because 'dt' is not a field in __match_args__. 
Is this argument misinterpreting something about the PEP or is missing some 
important detail?


Well yeah, it's actually a fair bit worse than you describe. Since dt is matched 
positionally, it wouldn't raise during matching - it would just succeed as before, but 
instead binding the year attribute (not the whole object) to the name "dt". So 
it wouldn't fail until later, when your method call raises a TypeError.


Ouch.  That seems like a pretty serious drawback.  Will this issue be resolved?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Brandt Bucher]

Pablo Galindo Salgado wrote:
> ...users can do a positional match against the proxy with a name pattern:
>
> match input:
> case datetime.date(dt):
> print(f"The date {dt.isoformat()}"
>
> ...if 'datetime.date' were updated to implement a non-default __match_args__, 
> allowing individual fields to be pulled out of it like this, then the first 
> block would be valid, correct code before the change, but would raise an 
> ImpossibleMatch after the change because 'dt' is not a field in 
> __match_args__. Is this argument misinterpreting something about the PEP or 
> is missing some important detail?

Well yeah, it's actually a fair bit worse than you describe. Since dt is 
matched positionally, it wouldn't raise during matching - it would just succeed 
as before, but instead binding the year attribute (not the whole object) to the 
name "dt". So it wouldn't fail until later, when your method call raises a 
TypeError.
___
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/Y7DJJA2ONIRJSMMA6PYKAYCZSYIECY4D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Emily Bowman]

On Wed, Jun 24, 2020 at 12:46 PM Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>

I don't think combining assignment and wildcard will help. '_' is fine for
that. I could get used to '?' as an assignment or a wildcard, but it would
always be a double-take if it was both.

I've seen languages that use '>foo' to indicate assignment, but I can't for
the life of me remember which now, aside from shell redirection. '=foo'
might be more obvious. In the end I think it's only important that there's
some assignment operator, and we'll all get used to whatever you choose.
___
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/QSJRX2QAPA45KMJOZHW2WYPJWRPRFL65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Pablo Galindo Salgado]

I was talking with a colleague today about the PEP and he raised a couple
of question regarding the match protocol and the proxy result.

One question is that taking into account that 'case object(x)' is valid for
every object, but it does (could do) something different for objects
that have a non-None __match_args__ it seems that implementing
__match_args__ will break Liskov substitutability as you could not
substitute
the child in a context where you expect a parent.

Even if you don't care about Liskov substitutability seems that introducing
a __match_args__ for a class will almost always be backwards
incompatible. For example, let's say that 'datetime.date' doesn't have a
custom matching defined, so it inherits the default object.__match__,
 which does:

class object:
@classmethod
def __match__(cls, instance):
if isinstance(instance, cls):
return instance

The PEP notes that:
> The above implementation means that by default only match-by-name and a
single positional match by value against the proxy will work

Which means that users can do a positional match against the proxy with a
name pattern:

match input:
case datetime.date(dt):
print(f"The date {dt.isoformat()}"

Imagine that later, someone notices that it would be reasonable to support
structural pattern matching for the fields of a 'datetime.date' so that
users could do:

match birthday:
case datetime.date(year) if year == 1970:
print("You were born in 1970")

But, if 'datetime.date' were updated to implement a non-default
__match_args__, allowing individual fields to be pulled out of it like
this, then the first block would be valid,
correct code before the change, but would raise an ImpossibleMatch after
the change because 'dt' is not a field in __match_args__.

Is this argument misinterpreting something about the PEP or is missing some
important detail?

On Wed, 24 Jun 2020 at 20:47, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> 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/T32GEZA43AE6LDSAG35I3F2ITXJ5SPTJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Russell Davis]

> '?foo' or 'foo?' to mark a variable binding

I like that idea a lot, with a strong inclination for the '?foo' variant.
Seeing the '?' first makes it clear right away that it's a special context.
And it keeps it more distinct from the None-aware operators (from PEP 505,
in case that gets adopted).
___
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/OOE4GZH4YLN6F7V2CK7ZHOW7NU3WY4E6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rhodri James]

On 25/06/2020 10:15, Chris Angelico wrote:

On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou  wrote:


On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum  wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please add
your issue *concisely* to this new thread. Note that the following issues
are already open and will be responded to separately; please don't bother
commenting on these until we've done so:

- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
variable binding and '?' for a wildcard.)


I don't know if you read it, so I'll reiterate what I said :-)

"""
Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.



AIUI, the case clauses are far more akin to *assignment targets* than
they are to expressions. If you see something like this:

[x, y] = foo()

then you don't expect it to look up x or y in the current scope, nor
to construct a list.


That argument works for name patterns, but not for class patterns. 
"Cls(x,y)" does not look like an assignment target at all.


--
Rhodri James *-* Kynesim Ltd
___
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/XRKDUCQXHKHV3L4XJPF23BPHKGDBMBAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

Without arguing for or against allowing a capture variable, IMO rather 
than syntax like

    match  into :
it would be far better (and not require a new keyword) to write this as
    with  as match :
Rob Cliffe
PS:  Or
     = match 

On 24/06/2020 20:38, Guido van Rossum wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


--
--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 topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
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/JXIY4GKRDAOCMNAVLDACC3S5O5CZ4NQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Chris Angelico]

On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou  wrote:
>
> On Wed, 24 Jun 2020 12:38:52 -0700
> Guido van Rossum  wrote:
> > Everyone,
> >
> > If you've commented and you're worried you haven't been heard, please add
> > your issue *concisely* to this new thread. Note that the following issues
> > are already open and will be responded to separately; please don't bother
> > commenting on these until we've done so:
> >
> > - Alternative spellings for '|'
> > - Whether to add an 'else' clause (and how to indent it)
> > - A different token for wildcards instead of '_'
> > - What to do about the footgun of 'case foo' vs. 'case .foo'
> >
> > (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> > variable binding and '?' for a wildcard.)
>
> I don't know if you read it, so I'll reiterate what I said :-)
>
> """
> Overall, my main concern with this PEP is that the matching semantics
> and pragmatics are different from everything else in the language.
> When reading and understanding a match clause, there's a cognitive
> overhead because suddently `Point(x, 0)` means something entirely
> different (it doesn't call Point.__new__, it doesn't lookup `x` in the
> locals or globals...).  Obviously, there are cases where this is
> worthwhile, but still.
>

AIUI, the case clauses are far more akin to *assignment targets* than
they are to expressions. If you see something like this:

[x, y] = foo()

then you don't expect it to look up x or y in the current scope, nor
to construct a list.

Is there any way to make the syntax look more like assignment? Or
maybe this won't even matter - people will simply get used to it with
a bit of experience, same as "for x, y in stuff" has an assignment
target in it.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Antoine Pitrou]

On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum  wrote:
> Everyone,
> 
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
> 
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
> 
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)

I don't know if you read it, so I'll reiterate what I said :-)

"""
Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.

It may be useful to think about different notations for these new
things, rather than re-use the object construction notation.
"""

Regards

Antoine.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Joao S. O. Bueno]

On Wed, 24 Jun 2020 at 16:40, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>

I'd like also to see considerations about the issue of an alternative
spelling that would
not resemble a class instantiation, brought first by Antoine Pitrou:
```

case Point with (x, y):
 print(f"Got a point with x={x}, y={y}")
 ```

And somewhere on the other thread, someone pointed
the possibility of all assignments in a case be well
delimited, even with angle parentheses - (yes, that
addresses the "foot gun" again, but it is a step beyond
dot or not dot in instant-readability:

```
case Point with (, ):
 print(f"Got a point with x={x}, y={y}")
```

(AFAIC, the "dot" thing falls in the category of speckles on Tim's monitor)

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[David Mertz]

I gave a longer example, but the short version is that I cannot tell from
the Class Pattern or Runtime section how class patterns interact with
properties (i.e. when access changes state).

On Wed, Jun 24, 2020, 3:45 PM Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> 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/N7HOQYIAFT7QDCM4MBSZ5723VFRANNQL/
Code of Conduct: http://python.org/psf/codeofconduct/