[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim Baker]

On Thu, Jul 9, 2020 at 1:42 PM Eric Nieuwland 
wrote:

> Much of the discussion seems to focus on how to distinguish between a
> variable as a provider of a value and a variable as receiver of a matched
> value.
>
> In normal Python syntax a variable in an expression provides a value,
> please let’s keep that unchanged.
>

For patterns, these are no different than parameters for a function (either
a lambda expression or with `def`); or target assignments in unpacking
assignments. So just like I wouldn't wonder where `a` and `b` materialized
in the parameters for the function definition below

def sum2(a, b):
  return a + b

I think it will be straightforward to understand this in the context of a
`case` using a capture pattern:

match x:
  case (a, b):
 return a + b
   ...

(This commonality between cases and function definitions is further used in
Scala for example, but I don't see that approach for defining an idea of
partial functions -- not like functools.partial functions! -- as being that
useful in Python.)


> So it seems to me we should explicitly mark a variable to receive a
> matched value.
> I have seen ‘?’ suggested as a prefix to do this, ‘\’ would also do fine.
>
> This would solve the single variable issue, too:
> case foo:
> matches the value of ‘foo’, while
> case \foo:
> matches anything and stores it in ‘foo’.
>
>
Explicit namespacing (if a constant) or using a guard (if a variable) seems
to be the right solution, as Ethan demonstrated earlier. No need for . or ^
or  \ or ... to disambiguate. Also it seems to me that structural pattern
matching will build on two common usages of namespaces for constants:

1. Constants used from other modules are almost always used in the module
namespace. Eg, socket.AF_UNIX or signal.SIGTERM.
2. New code often tends to use constants defined within an Enum namespace.
Hopefully we will see more of this convention in usage.

(Very much an aside: Interestingly with the socket module we see both used
- it defines its constants with IntEnum and exports them traditionally. The
namespace specifics it uses with IntEnum._convert_ to make this happen  --
strictly speaking EnumMeta._convert, not documented, and a bit hard to
follow -- might be possibly debatable, but it works out quite well in
practice in providing backwards compatibility while continuing to work with
a C source of these constants.)


> This would also mean
> case Point(x=\x, y=\y):
> should be used to obtain x and y from the Point instance.
> ___
> 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/3MC2ZKDVRSDYRBZSYSFDR4M6GKQXITO2/
> 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/OE355Z6VWOAZZSUMILSBNHLUDFFWN37V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

Yes, you’ve got that exactly right! I think the pep has an example for
tuple((x, y)).

On Thu, Jul 9, 2020 at 13:08 Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> One thing I don't understand about the PEP:
>
>  case [x,y]:
>
> IIUC matches any 2-element sequence.
> How would you match specifically a 2-item list (say)?
> Would it be
>
>  case list([x,y]):
>
> I would appreciate it if some kind person could enlighten me.
> TIA
> 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/NJLVOPNAZIDOCYYGJ2RJKK23ZK5FCLXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/27JPO3DSAPYDL5TN6OVIOOW4WATEIYGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jakub Stasiak]

> On 9 Jul 2020, at 17:49, Federico Salerno  wrote:
> 
> On 09/07/2020 01:27, Ethan Furman wrote:
>> On 07/08/2020 10:44 AM, Ethan Furman wrote: 
>> 
>>> So namespaced variables only...  is there a recommendation on handling 
>>> global() and local() type variables? 
>> 
>> Okay, some off-list discussion clarified that for me: 
>> 
>> - easiest way is to use a guard 
>> 
>> 
>>> ``` 
>>> def foo(x, spam): 
>>> match x: 
>>> case Point(p, q, context=c) if c == spam: 
>>> # Match 
>>> ``` 
> I like this one. Doesn't it also solve the issue of store vs. load? 
> Everything is stored but the guard clause can look-up.

I have to say I find this to be the most satisfactory solution – everything 
else (dot previously, no dot now, any other single character hypotheticaly) 
provides users with IMO too big of a footgun to shoot themselves with.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

One thing I don't understand about the PEP:

    case [x,y]:

IIUC matches any 2-element sequence.
How would you match specifically a 2-item list (say)?
Would it be

    case list([x,y]):

I would appreciate it if some kind person could enlighten me.
TIA
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/NJLVOPNAZIDOCYYGJ2RJKK23ZK5FCLXT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Eric Nieuwland]

Much of the discussion seems to focus on how to distinguish between a variable 
as a provider of a value and a variable as receiver of a matched value.

In normal Python syntax a variable in an expression provides a value, please 
let’s keep that unchanged.

So it seems to me we should explicitly mark a variable to receive a matched 
value.
I have seen ‘?’ suggested as a prefix to do this, ‘\’ would also do fine.

This would solve the single variable issue, too:
case foo:
matches the value of ‘foo’, while
case \foo:
matches anything and stores it in ‘foo’.

This would also mean
case Point(x=\x, y=\y):
should be used to obtain x and y from the Point instance.
___
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/3MC2ZKDVRSDYRBZSYSFDR4M6GKQXITO2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Federico Salerno]

On 09/07/2020 01:27, Ethan Furman wrote:

On 07/08/2020 10:44 AM, Ethan Furman wrote:

So namespaced variables only...  is there a recommendation on 
handling global() and local() type variables?


Okay, some off-list discussion clarified that for me:

- easiest way is to use a guard



```
    def foo(x, spam):
    match x:
    case Point(p, q, context=c) if c == spam:
    # Match
```
I like this one. Doesn't it also solve the issue of store vs. load? 
Everything is stored but the guard clause can look-up.
___
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/NSO2QZ7DSLREPJL5OJCSZTUWWXREM76S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Wed, Jul 8, 2020 at 7:23 PM Rob Cliffe  wrote:

> *Use '==' to mark* (when necessary) *load-and-compare items*:
> match t:
> case (==USE_RECT, real, imag):
> return complex(real, imag)
> case (==USE_POLAR, r, phi):
> return complex(r * cos(phi), r * sin(phi))
>
> allowing incidentally a possible future extension to other relational
> operators:
> case Point(x, >YMAX):
> case >= 42:
>

The problem with this is that value patterns don't just appear at the top
level.
Consider this example from the PEP's deferred ideas section:

  case BinaryOp(left=Number(value=x), op=op, right=Number(value=y)):

Using your notation, this would become:

  case BinaryOp(left=Number(value===x), op===op,
right=Number(value===y)):

The tokenizer, which is eager, would interpret '===' as '==' followed by
'=' and it would treat this as a syntax error. Also, it looks a lot like a
JavaScript equivalency (?) operator.

A single '=' prefix suffers from pretty much the same thing -- Python's
tokenizer as well as the tokenizer in most people's heads would read
'x==op' as containing '=='.

Please drop it.

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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

[Inada Naoki]

On Thu, Jul 9, 2020 at 10:13 PM Jim J. Jewett  wrote:
>
> Unless I'm missing something, part of M.-A. Lemburg's objection is:
>
> 1.  The wchar_t type is itself an important interoperability story in C.  
> (I'm not sure if this includes the ability, at compile time, to define 
> wchar_t as either of two widths.)
>

Of course.  But wchar_t* is not the only way to use Unicode in C.
UTF-8 is the most common way to use Unicode in C in recent days.
(except Java, .NET, and Windows API)
So the importance of wchar_t* APIs are relative, not absolute.

In other words, why don't we have an encode API with direct UTF-8 input?
Is there any evidence wchar_t* is much more important than UTF-8?


> 2.  The ability to work directly with wchar_t without a round-trip in/out of 
> python format is an important feature that CPython has provided for C 
> integrators.
>

Note that current API *does* the round-trip:
For example: 
https://github.com/python/cpython/blob/61bb24a270d15106decb1c7983bf4c2831671a75/Objects/unicodeobject.c#L5631-L5644

Users can not use the API without initializing Python VM.
Users can not avoid time and space for the round-trip.
So removing these APIs doesn't reduce any ability.


> 3.  The above support can be kept even without the wchar_t* member ... so 
> saving the extra space on each string instance does not require dropping this 
> support.
>

This is why I split PEP 623 and PEP 624.  I never said removing the
wchar_t* member is motivation for PEP 624.

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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

[Jim J. Jewett]

Unless I'm missing something, part of M.-A. Lemburg's objection is:

1.  The wchar_t type is itself an important interoperability story in C.  (I'm 
not sure if this includes the ability, at compile time, to define wchar_t as 
either of two widths.)

2.  The ability to work directly with wchar_t without a round-trip in/out of 
python format is an important feature that CPython has provided for C 
integrators.

3.  The above support can be kept even without the wchar_t* member ... so 
saving the extra space on each string instance does not require dropping this 
support.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Federico Salerno]

On 08/07/2020 12:30, Rhodri James wrote:
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. 


I meant catch-all as in "case _:" (or "else:"). I apologise for the lack 
of clarity.


On 08/07/2020 17:02, Guido van Rossum wrote:


There’s one other issue where in the end we could be convinced to
compromise: whether to add an `else` clause in addition to `case
_`. In fact, we probably would already have added it, except for one
detail: it’s unclear whether the `else` should be aligned with `case`
or `match`. If we are to add this we would have to ask the Steering
Council to decide for us, as the authors deadlocked on this question.
Thanks for the write-up. What were the arguments in support of aligning 
else with case? I expect it has to be with aesthetics, but for what 
concerns semantics, it seems to me that "match...else", interpreted as 
"no match was found" would make the most sense; aligning it with case 
would look like the else has to do with whatever case was last.
Unless both match and all cases are on the same indentation level. Here 
an example:


match:
    variable
case "some constant":
    # ...
case x if x == guard_clause:
    # ...
else:
    # ...

I know at least Elm indents the match variable on a separate line.

On 08/07/2020 19:44, Tim Peters wrote:

One microscopic point:

[Guido]

...
(if `.x` is unacceptable, it’s unclear why `^x` would be any
better),

As Python's self-appointed spokesperson for the elderly, there's one
very clear difference:  a leading "." is - literally - one microscopic
point, all but invisible.  A leading caret is far easier to see, on a
variety of devices and using a variety of fonts.  Indeed, I missed the
leading dot in ".x" in your email the first two times I read that
sentence.

But a caret is harder to type.  So here's an off-the-wall idea:  use
an ellipsis. If you're still using a maximal-munch lexer, ellipsis
followed by an identifier is currently a syntax error.  "...x" is far
easier to see than ".x', easier to type than "^x", and retains the
mnemonic connection that "something is a named load pattern if and
only if it has dots".


+1 on a simple dot being hard to see.

Alternative idea: if we really ought to have a mark for references¹, why 
not use the & symbol, which already signifies something like "reference" 
in C(++) and Rust?


¹: I know marking "store" instead of "load" has been suggested before; 
I'm still on the fence on which I prefer but I would even accept marking 
both (with = and == respectively, for example).

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

[Python-Dev] Request for code review

[Mark Shannon]

Hi,

Would someone be kind enough to review 
https://github.com/python/cpython/pull/20803, please?


It cleans up tracking and introspection of frame state.

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