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

[Rob Cliffe via Python-Dev]

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


```
    USE_POLAR = "polar"
    USE_RECT = "rect"
```
Now we would like to be able to replace those literals with the
corresponding names throughout our code and have everything work like
before:
```
    match t:
        case (USE_RECT, real, imag):
            return complex(real, imag)
        case (USE_POLAR, r, phi):
            return complex(r * cos(phi), r * sin(phi))
```
Alas, the compiler doesn’t know that we want `USE_RECT` to be a
constant value to be matched while we intend `real` and `imag` to be
variables to be given the corresponding values captured from the
subject. So various clever ways have been proposed to distinguish the
two cases.
I apologise for posting a second message re the same idea, but I can't 
contain my enthusiasm for it:-)

and I want to make sure it's not overlooked:
*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:



If this really is a deal-breaker after all other issues have been
settled, we could go back to considering some special markup for
load-and-compare of simple names (even though we expect this case to
be very rare). But there’s no pressing need to decide to do this now
-- we can always add new markup for this purpose in a future version,
as long as we continue to support dotted names without markup,
since that *is* a commonly needed case.


Except that if this idea were taken to its logical conclusion,
    mod.var        would be a capture variable (contrary to the PEP)
    ==mod.var    would be a load-and-compare value
Which may be controversial, but seems to have more overall consistency.
___
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/LRCZBUEULXZN2OZWVUHKH5RJ6LICUMEA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 9/07/20 3:30 am, Luciano Ramalho wrote:

I strongly favor the option of aligning the `else` clause with
`match`, because `else` is a special clause therefore it should look
special.


But on the other hand, it's semantically equivalent to 'case _:',
so it's not all that special.

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

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

[Ethan Furman]

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


If there's a bunch, then SimpleNamespace can be used:


```
def foo(x, spam):
L = SimpleNamespace(**locals)
match x:
case Point(p, q, context=L.spam):
# Match
```


So there we have it -- two ways to do it!  ;-)

--
~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/RFFG4UDD4BGSYPS4YCFQ7ADDV773LPBR/
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 5:46 AM M.-A. Lemburg  wrote:
> - the fact that the encode APIs encoding from a Unicode buffer
>   to a bytes object; this is an important fact, since the removal
>   removes access to this codec functionality for extensions
>
> - PyUnicode_AsEncodedString() is not a proper alternative, since
>   it requires to create a temporary PyUnicode object, which is
>   inefficient and wastes memory

I wrote your points in the "Alternative Idea > Replace Py_UNICODE*
with Py_UCS4* "
section. I wrote "User can encode UCS-4 string in C without creating
Unicode object." in it.

https://www.python.org/dev/peps/pep-0624/#replace-py-unicode-with-py-ucs4

Note that the current Py_UNICODE* encoder APIs create temporary
PyUnicode objects.
They are inefficient and wastes memory now. Py_UNICODE* may be UTF-16 on some
platforms (e.g. Windows) and builtin codecs don't support UTF-16 input.


>
> - the maintenance effect mentioned in the PEP does not really
>   materialize, since the underlying functionality still exists
>   in the codecs - only access to the functionality is removed
>

In the same section, I described the maintenance cost as below.

* Other Python implementations may not have builtin codec for UCS-4.
* If we change the Unicode internal representation to UTF-8, we need
to keep UCS-4 support only for these APIs.

> - keeping just the generic PyUnicode_Encode() API would be a
>   compromise
>
> - if we remove the codec specific PyUnicode_Encode*() APIs, why
>   are we still keeping the specisl PyUnicde_Decode*() APIs ?
>

OK, I will add "Discussions" section. (I don't like "FAQ" because some question
are important even if it is not "frequently" asked.)

Quick answer is:

* They are stable ABI. (Py_UNICODE is excluded from stable ABI).
* Decoding from char* is more common and generic use case than encoding from
  Py_UNICODE*.
* Other Python implementations using UTF-8 as internal representation
can implement
  it easily.

But I'm not opposite to remove it (especially for minor UTF-7 codec).
It is just out of scope of this PEP.


> - the deprecations were just done because the Py_UNICODE data
>   type was replaced by a hybrid type. Using this as an argument
>   for removing functionality is not really good practice, when
>   these are ways to continue exposing the functionality using other
>   data types.

I hope the "Replace Py_UNICODE* with Py_UCS4* " section describe this.

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/N4F5WLSNYUWQO4FEPIOOUCHG4ZFLQVLI/
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: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[David Mertz]

On Wed, Jul 8, 2020, 1:50 PM Paul Sokolovsky

> > I admit I do not really understand what gain dynamic languages get from
> constants. I pretty uniformly use a common convention of ALLCAPS for
> constant names
>
> > I can easily imagine that a VM might gain speed with that information,
> but that alone does not feel like enough reason for a language change.
>
> If people are satisfied with Python's performance story as presented by
> CPython, perhaps. Because otherwise, having a formal constants in the
> code allows for simple and obvious optimizations: instead of looking up
> value by name at runtime, you can use literal value at the compile time.
>

Most "obvious" optimizations in the history of Python have not wound up
speeding up CPython. If you have a fork that can convince Victor of a
noteworthy speed up, my perspective would definitely shift.

Stipulating such a win exists (and amounts to more than 1-2%), deciding
syntax would be the next question. My personal feeling would be that
enshrining the ALLCAPS convention would be nice. That could potentially
make existing code become magically faster. Of course, not all code uses
that convention, and some violates the constant-ness only sometimes. So
deprecation periods and __future__ import, etc.
___
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/Z74N67QHYO7HQ2DVQERIFQSDC3YAVEZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 59

[Hugh Fisher]

> Date: Wed, 8 Jul 2020 20:00:44 +0300
> From: Paul Sokolovsky 
> Subject: [Python-Dev] Re: Python is the only language with lack of

[ munch ]

> Right. So, if someone would like to add something to this thread, I'd
> humbly suggest to concentrate on the lack of, and need for, of
> const-ness in the Python language core (in comparison to other languages
> or not), and usecases it enables, and not on criteria for "popularness".
>

My view is that the informal Python "don't mess with anything all in
upper case" coding convention works at least as well as any more
formal language notation for nearly all cases. It conveys intention
very well with minimum effort, and does not require programmers
to think about the language they're using rather than the problem
they are trying to solve.

I can see the case for a const annotation/keyword for simple
scalar values, almost always numbers, but am dubious about
the benefits. If someone really wants to write
IMPORTANT_SIN30 = math.sin(45)
there's only so much a compiler/interpreter can do to stop them.
"If we just provide enough detail we can catch every error" is
a mirage that's lured away so much effort for many decades.

(That said, I'd be in favour of adding math.PI and similar
names because even I find it slightly disturbing that I can write
math.pi = 3.0
and it doesn't look wrong.)

Even for simple numbers, constness can be argued. Is the
value determined when the code is written, or when run?
A lot of mutable variables in Pascal/C/Ada programs are really
constants, but the value is "number of CPU cores" or something
else that can't be determined until first use. So those other
languages that supposedly have constness are actually often
more like Python.

Once you go beyond scalar values, it's just a mess. If I write
const myd = { "answer" : 42 }
do I mean that myd will always be a reference to that object,
or that the object being pointed to has constant members?

To see what can happen if you try and build this into the
language, look at C++. It has the const keyword for objects
and object references. But then the "mutable" keyword got
added to describe object members, because programmers
needed to be able to modify the internal values of "const"
objects! So now "const" in C++ for objects just means you
don't intend to change the internal state, but it might do
so anyway.

Again, I can see a case in embedded systems for "const"
meaning "this can be put in ROM". But I don't think that
use case is common enough to justify adding to the core
language.

-- 

cheers,
Hugh Fisher
___
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/B6UBKV6D3C3NLD6WIDSWSFZLYOGPSJI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Henk-Jaap Wagenaar]

On Wed, 8 Jul 2020 at 21:44, Guido van Rossum  wrote:

> It works for me. Did you click on the box where the logs are supposed to
> appear? It will only show the logs when you click there.
>
>
I did click on that before, but I suddenly had a thought (I should have had
long ago): it seems my combination of Ghostery and uBlock on Chrome does
not play nicely with mybinder (which is why the logs were empty). Not sure
why Safari had the same/a different issue: I do not normally use it or have
anything installed on it.

Apologies for the noise.

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

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

[M.-A. Lemburg]

Hi Inada-san,

I am currently too busy with EuroPython to participate in longer
discussions. FWIW: I intend to continue after EuroPython.

In any case, thanks for writing up the PEP. Could you please add my
points about:

- the fact that the encode APIs encoding from a Unicode buffer
  to a bytes object; this is an important fact, since the removal
  removes access to this codec functionality for extensions

- PyUnicode_AsEncodedString() is not a proper alternative, since
  it requires to create a temporary PyUnicode object, which is
  inefficient and wastes memory

- the maintenance effect mentioned in the PEP does not really
  materialize, since the underlying functionality still exists
  in the codecs - only access to the functionality is removed

- keeping just the generic PyUnicode_Encode() API would be a
  compromise

- if we remove the codec specific PyUnicode_Encode*() APIs, why
  are we still keeping the specisl PyUnicde_Decode*() APIs ?

- the deprecations were just done because the Py_UNICODE data
  type was replaced by a hybrid type. Using this as an argument
  for removing functionality is not really good practice, when
  these are ways to continue exposing the functionality using other
  data types.

I am still strongly -1 on removing all encoding APIs without
at least some upgrade path for existing code to use and keeping
the API symmetric.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/


On 07.07.2020 17:17, Inada Naoki wrote:
> Hi, folks.
> 
> Since the previous discussion was suspended without consensus, I wrote
> a new PEP for it. (Thank you Victor for reviewing it!)
> 
> This PEP looks very similar to PEP 623 "Remove wstr from Unicode",
> but for encoder APIs, not for Unicode object APIs.
> 
> URL (not available yet): https://www.python.org/dev/peps/pep-0624/
> 
> ---
> 
> PEP: 624
> Title: Remove Py_UNICODE encoder APIs
> Author: Inada Naoki 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 06-Jul-2020
> Python-Version: 3.11
> 
> 
> Abstract
> 
> 
> This PEP proposes to remove deprecated ``Py_UNICODE`` encoder APIs in
> Python 3.11:
> 
> * ``PyUnicode_Encode()``
> * ``PyUnicode_EncodeASCII()``
> * ``PyUnicode_EncodeLatin1()``
> * ``PyUnicode_EncodeUTF7()``
> * ``PyUnicode_EncodeUTF8()``
> * ``PyUnicode_EncodeUTF16()``
> * ``PyUnicode_EncodeUTF32()``
> * ``PyUnicode_EncodeUnicodeEscape()``
> * ``PyUnicode_EncodeRawUnicodeEscape()``
> * ``PyUnicode_EncodeCharmap()``
> * ``PyUnicode_TranslateCharmap()``
> * ``PyUnicode_EncodeDecimal()``
> * ``PyUnicode_TransformDecimalToASCII()``
> 
> .. note::
> 
>`PEP 623  `_ propose to remove
>Unicode object APIs relating to ``Py_UNICODE``. On the other hand, this PEP
>is not relating to Unicode object. These PEPs are split because they have
>different motivation and need different discussion.
> 
> 
> Motivation
> ==
> 
> In general, reducing the number of APIs that have been deprecated for
> a long time and have few users is a good idea for not only it
> improves the maintainability of CPython, but it also helps API users
> and other Python implementations.
> 
> 
> Rationale
> =
> 
> Deprecated since Python 3.3
> ---
> 
> ``Py_UNICODE`` and APIs using it are deprecated since Python 3.3.
> 
> 
> Inefficient
> ---
> 
> All of these APIs are implemented using ``PyUnicode_FromWideChar``.
> So these APIs are inefficient when user want to encode Unicode
> object.
> 
> 
> Not used widely
> ---
> 
> When searching from top 4000 PyPI packages [1]_, only pyodbc use
> these APIs.
> 
> * ``PyUnicode_EncodeUTF8()``
> * ``PyUnicode_EncodeUTF16()``
> 
> pyodbc uses these APIs to encode Unicode object into bytes object.
> So it is easy to fix it. [2]_
> 
> 
> Alternative APIs
> 
> 
> There are alternative APIs to accept ``PyObject *unicode`` instead of
> ``Py_UNICODE *``. Users can migrate to them.
> 
> 
> =
> ==
> Deprecated APIAlternative APIs
> =
> ==
> ``PyUnicode_Encode()``

[Python-Dev] Re: PEP 622 (match statement) playground

[Guido van Rossum]

It works for me. Did you click on the box where the logs are supposed to
appear? It will only show the logs when you click there.

On Wed, Jul 8, 2020 at 1:36 PM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

> On Wed, 1 Jul 2020 at 17:09, Guido van Rossum  wrote:
>
>> If you are interested in learning more about how PEP 622 would work in
>> practice, but don't feel like compiling a Python 3.10 fork from source,
>> here's good news for you.
>>
>> In a hurry?
>> https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb
>>
>
> I could not get this to work yesterday and today. It will eventually say:
>
> "Your session is taking longer than usual to start! Check the log messages
> below to see what is happening."
>
> But the logs are empty. Is that just me or anybody else too?
>
> I tried Chrome (Windows 10 & macOS) and Safari (macOS).
>
>
>>
>> This will open a Binder instance that runs a Jupyter kernel built from
>> Brandt Bucher's fork of Python 3.10 that includes the match statement. This
>> is a complete implementation of the PEP. (Note that we've already made some
>> design changes in response to feedback, but the basic syntax is still the
>> same. Expect a new draft within a week.)
>>
>> The code for the playground was contributed by Fernando Perez, Matthias
>> Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams
>> for Binder and Jupyter and all the infrastructure that made this playground
>> possible, and we thank gesis.org for hosting.
>>
>> For details, see https://github.com/gvanrossum/patma/tree/master/binder
>>
>> --
>> --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/47YR2LUTLWA4SGDHE66AXERVHW5EDK6I/
>> 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/4IUCFYIUFBOL6S4KLJVDPVWUV43EERSY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XGBJN6K7KEJCBOXNA67AHERELPFHD2XM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Henk-Jaap Wagenaar]

On Wed, 1 Jul 2020 at 17:09, Guido van Rossum  wrote:

> If you are interested in learning more about how PEP 622 would work in
> practice, but don't feel like compiling a Python 3.10 fork from source,
> here's good news for you.
>
> In a hurry?
> https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb
>

I could not get this to work yesterday and today. It will eventually say:

"Your session is taking longer than usual to start! Check the log messages
below to see what is happening."

But the logs are empty. Is that just me or anybody else too?

I tried Chrome (Windows 10 & macOS) and Safari (macOS).


>
> This will open a Binder instance that runs a Jupyter kernel built from
> Brandt Bucher's fork of Python 3.10 that includes the match statement. This
> is a complete implementation of the PEP. (Note that we've already made some
> design changes in response to feedback, but the basic syntax is still the
> same. Expect a new draft within a week.)
>
> The code for the playground was contributed by Fernando Perez, Matthias
> Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams
> for Binder and Jupyter and all the infrastructure that made this playground
> possible, and we thank gesis.org for hosting.
>
> For details, see https://github.com/gvanrossum/patma/tree/master/binder
>
> --
> --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/47YR2LUTLWA4SGDHE66AXERVHW5EDK6I/
> 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/4IUCFYIUFBOL6S4KLJVDPVWUV43EERSY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Wed, 8 Jul 2020 20:08:34 +0200
Antoine Pitrou  wrote:
> On Wed, 8 Jul 2020 18:38:12 +0100
> Rhodri James  wrote:
> > On 08/07/2020 16:02, Guido van Rossum wrote:  
> > > Today I’m happy (and a little trepidatious) to announce the next
> > > version of PEP 622, Pattern Matching.
> > 
> > Thank you very much to everyone who has been working on this, it is much 
> > appreciated.  I have one suggestion for the text: could the section on 
> > Capture Patterns emphasise that only simple (i.e not dotted) names are 
> > capture patterns?  The simplified grammar is (fairly) clear and the 
> > later section on Constant Value Patterns should make it obvious, but 
> > somehow when reading version 1 I still managed to miss it.  I was quite 
> > surprised when it was pointed out that
> > 
> > case (point.x, point.y):
> > 
> > wasn't going to do what I expected!  
> 
> Why did you expect?  It's not clear to me what it should do at all :-)

Sorry: /what/ did you expect?

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

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

[Rhodri James]

On 08/07/2020 19:27, Gustavo Carneiro wrote:

Forgive the intrusion, in case this wasn't already mentioned (I only read a
fraction of emails on this), we could say that name enclosed in parenthesis
would mean loading a constant, instead of storing in a variable:


It's discussed as the third bullet point under "Alternatives for 
constant value pattern": https://www.python.org/dev/peps/pep-0622/#id74 
Basically it looks odd and we may need parentheses to manage grouping in 
patterns.


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

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

[Rhodri James]

On 08/07/2020 19:08, Antoine Pitrou wrote:

On Wed, 8 Jul 2020 18:38:12 +0100
Rhodri James  wrote:

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

Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.


Thank you very much to everyone who has been working on this, it is much
appreciated.  I have one suggestion for the text: could the section on
Capture Patterns emphasise that only simple (i.e not dotted) names are
capture patterns?  The simplified grammar is (fairly) clear and the
later section on Constant Value Patterns should make it obvious, but
somehow when reading version 1 I still managed to miss it.  I was quite
surprised when it was pointed out that

 case (point.x, point.y):

wasn't going to do what I expected!


Why did you expect?  It's not clear to me what it should do at all :-)


I was expecting it to unpack a 2-tuple(/sequence?) into the x and y 
attributes of this point object I happened to have in my back pocket 
(assuming it matched, of course).  It actually matches a 2-tuple against 
the values of those attributes (i.e. they are constant value patterns). 
It's obvious enough once you have time to read the PEP properly -- I 
blame only having so many minutes of reading time in my 
compile/download/test cycle!


To use code(ish) examples rather than confusable words, suppose we have:

class Point:
 def __init__(self):
 self.x = 0
 self.y = 0

point = Point()
INCOMING = (1, 2)

match INCOMING:
case (point.x, point.y):
   print("Point @", point.x, point.y)
case _:
   print("Default")

I expected printout of:

Point @ 1 2

but I would actually get

Default

If on the other hand INCOMING was (0, 0), I would get

Point @ 0 0

because the first case is in fact the equivalent of

case (0, 0):

Obviously this is a pointless example (pun intended) because you would 
use a class pattern if you really wanted to do something like what I 
first thought of.


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

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

[Gustavo Carneiro]

*facepalm* this is right there in the PEP, already, as one possible
alternative.  Apologies for the noise. :-/

On Wed, 8 Jul 2020 at 19:27, Gustavo Carneiro  wrote:

>
>
> On Wed, 8 Jul 2020 at 16:05, Guido van Rossum  wrote:
>
>> Today I’m happy (and a little trepidatious) to announce the next
>> version of PEP 622, Pattern Matching. As authors we welcome Daniel F
>> Moisset in our midst. Daniel wrote a lot of the new text in this
>> version, which introduces the subject matter much more gently than the
>> first version did. He also convinced us to drop the `__match__`
>> protocol for now: the proposal stands quite well without that kind of
>> extensibility, and postponing it will allow us to design it at a later
>> time when we have more experience with how `match` is being used.
>>
>> That said, the new version does not differ dramatically in what we
>> propose. Apart from dropping `__match__` we’re dropping the leading
>> dot to mark named constants, without a replacement, and everything
>> else looks like we’re digging in our heels. Why is that? Given the
>> firestorm of feedback we received and the numerous proposals (still
>> coming) for alternative syntax, it seems a bad tactic not to give up
>> something more substantial in order to get this proposal passed. Let
>> me explain.
>>
>> Language design is not like politics. It’s not like mathematics
>> either, but I don’t think this situation is at all similar to
>> negotiating a higher minimum wage in exchange for a lower pension,
>> where you can definitely argue about exactly how much lower/higher
>> you’re willing to go. So I don’t think it’s right to propose making
>> the feature a little bit uglier just to get it accepted.
>>
>> Frankly, 90% of the issue is about what among the authors we’ve dubbed
>> the “load/store” problem (although Tobias never tires to explain that
>> the “load” part is really “load-and-compare”). There’s a considerable
>> section devoted to this topic in the PEP, but I’d like to give it
>> another try here.
>>
>> In case you’ve been avoiding python-dev lately, the problem is
>> this. Pattern matching lets you capture values from the subject,
>> similar to sequence unpacking, so that you can write for example
>> ```
>> x = range(4)
>> match x:
>> case (a, b, *rest):
>> print(f"first={a}, second={b}, rest={rest}")  # 0, 1, [2, 3]
>> ```
>> Here the `case` line captures the contents of the subject `x` in three
>> variables named `a`, `b` and `rest`. This is easy to understand by
>> pretending that a pattern (i.e., what follows `case`) is like the LHS
>> of an assignment.
>>
>> However, in order to make pattern matching more useful and versatile,
>> the pattern matching syntax also allows using literals instead of
>> capture variables. This is really handy when you want to distinguish
>> different cases based on some value, for example
>> ```
>> match t:
>> case ("rect", real, imag):
>> return complex(real, imag)
>> case ("polar", r, phi):
>> return complex(r * cos(phi), r * sin(phi))
>> ```
>> You might not even notice anything funny here if I didn’t point out
>> that `"rect"` and `"polar"` are literals -- it’s really quite
>> natural for patterns to support this once you think about it.
>>
>> The problem that everybody’s been concerned about is that Python
>> programmers, like C programmers before them, aren’t too keen to have
>> literals like this all over their code, and would rather give names to
>> the literals, for example
>> ```
>> USE_POLAR = "polar"
>> USE_RECT = "rect"
>> ```
>> Now we would like to be able to replace those literals with the
>> corresponding names throughout our code and have everything work like
>> before:
>> ```
>> match t:
>> case (USE_RECT, real, imag):
>> return complex(real, imag)
>> case (USE_POLAR, r, phi):
>> return complex(r * cos(phi), r * sin(phi))
>> ```
>>
>
> Forgive the intrusion, in case this wasn't already mentioned (I only read
> a fraction of emails on this), we could say that name enclosed in
> parenthesis would mean loading a constant, instead of storing in a variable:
>
> match t:
> case ((USE_RECT), real, imag):  # matches the constant USE_RECT
> literal value
> return complex(real, imag)
> case (USE_POLAR, r, phi):  # the USE_POLAR portion matches
> anything and stores in a USE_POLAR variable
> return complex(r * cos(phi), r * sin(phi))
>
> Advantages: in Python (and most programming languages), (x) is the same
> thing as x.  So, no new syntax, or weird symbols, need to be introduced.
>
> But the parser can distinguish (I hope), and guide the match statement
> generation to the appropriate behaviour.
>
> Yes, it's more typing, but hopefully the case is uncommon enough that the
> extra typing is not a lot of burden.
>
> Yes, it's easy to type USE_RECT when you really meant (USE_RECT).
> Hopefully linters can 

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

[Brandt Bucher]

Ethan Furman wrote:
> Why is this no longer an issue?  My apologies if I missed it in the PEP.

This problem was an artifact of the default `object.__match__` implementation, 
which allowed one positional argument by default when `__match_args__` was 
missing or `None`. Since we've removed `__match__` from the proposal (and 
therefore the default `__match__` implementation from `object`), this issue no 
longer exists.

(Note that most common built-in types like `int` and `tuple` will still work 
this way, but this behavior is not inherited by *all* objects anymore).
___
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/NFP22VPMLZ4EERYU6KEB2KO7KQQ7ETA5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gustavo Carneiro]

On Wed, 8 Jul 2020 at 16:05, Guido van Rossum  wrote:

> Today I’m happy (and a little trepidatious) to announce the next
> version of PEP 622, Pattern Matching. As authors we welcome Daniel F
> Moisset in our midst. Daniel wrote a lot of the new text in this
> version, which introduces the subject matter much more gently than the
> first version did. He also convinced us to drop the `__match__`
> protocol for now: the proposal stands quite well without that kind of
> extensibility, and postponing it will allow us to design it at a later
> time when we have more experience with how `match` is being used.
>
> That said, the new version does not differ dramatically in what we
> propose. Apart from dropping `__match__` we’re dropping the leading
> dot to mark named constants, without a replacement, and everything
> else looks like we’re digging in our heels. Why is that? Given the
> firestorm of feedback we received and the numerous proposals (still
> coming) for alternative syntax, it seems a bad tactic not to give up
> something more substantial in order to get this proposal passed. Let
> me explain.
>
> Language design is not like politics. It’s not like mathematics
> either, but I don’t think this situation is at all similar to
> negotiating a higher minimum wage in exchange for a lower pension,
> where you can definitely argue about exactly how much lower/higher
> you’re willing to go. So I don’t think it’s right to propose making
> the feature a little bit uglier just to get it accepted.
>
> Frankly, 90% of the issue is about what among the authors we’ve dubbed
> the “load/store” problem (although Tobias never tires to explain that
> the “load” part is really “load-and-compare”). There’s a considerable
> section devoted to this topic in the PEP, but I’d like to give it
> another try here.
>
> In case you’ve been avoiding python-dev lately, the problem is
> this. Pattern matching lets you capture values from the subject,
> similar to sequence unpacking, so that you can write for example
> ```
> x = range(4)
> match x:
> case (a, b, *rest):
> print(f"first={a}, second={b}, rest={rest}")  # 0, 1, [2, 3]
> ```
> Here the `case` line captures the contents of the subject `x` in three
> variables named `a`, `b` and `rest`. This is easy to understand by
> pretending that a pattern (i.e., what follows `case`) is like the LHS
> of an assignment.
>
> However, in order to make pattern matching more useful and versatile,
> the pattern matching syntax also allows using literals instead of
> capture variables. This is really handy when you want to distinguish
> different cases based on some value, for example
> ```
> match t:
> case ("rect", real, imag):
> return complex(real, imag)
> case ("polar", r, phi):
> return complex(r * cos(phi), r * sin(phi))
> ```
> You might not even notice anything funny here if I didn’t point out
> that `"rect"` and `"polar"` are literals -- it’s really quite
> natural for patterns to support this once you think about it.
>
> The problem that everybody’s been concerned about is that Python
> programmers, like C programmers before them, aren’t too keen to have
> literals like this all over their code, and would rather give names to
> the literals, for example
> ```
> USE_POLAR = "polar"
> USE_RECT = "rect"
> ```
> Now we would like to be able to replace those literals with the
> corresponding names throughout our code and have everything work like
> before:
> ```
> match t:
> case (USE_RECT, real, imag):
> return complex(real, imag)
> case (USE_POLAR, r, phi):
> return complex(r * cos(phi), r * sin(phi))
> ```
>

Forgive the intrusion, in case this wasn't already mentioned (I only read a
fraction of emails on this), we could say that name enclosed in parenthesis
would mean loading a constant, instead of storing in a variable:

match t:
case ((USE_RECT), real, imag):  # matches the constant USE_RECT
literal value
return complex(real, imag)
case (USE_POLAR, r, phi):  # the USE_POLAR portion matches anything
and stores in a USE_POLAR variable
return complex(r * cos(phi), r * sin(phi))

Advantages: in Python (and most programming languages), (x) is the same
thing as x.  So, no new syntax, or weird symbols, need to be introduced.

But the parser can distinguish (I hope), and guide the match statement
generation to the appropriate behaviour.

Yes, it's more typing, but hopefully the case is uncommon enough that the
extra typing is not a lot of burden.

Yes, it's easy to type USE_RECT when you really meant (USE_RECT).
Hopefully linters can catch this case and warn you.

OK, that's it, I just thought it was worth throwing yet another idea into
the pot :-)

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-Dev mailing 

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

[Antoine Pitrou]

On Wed, 8 Jul 2020 18:38:12 +0100
Rhodri James  wrote:
> On 08/07/2020 16:02, Guido van Rossum wrote:
> > Today I’m happy (and a little trepidatious) to announce the next
> > version of PEP 622, Pattern Matching.  
> 
> Thank you very much to everyone who has been working on this, it is much 
> appreciated.  I have one suggestion for the text: could the section on 
> Capture Patterns emphasise that only simple (i.e not dotted) names are 
> capture patterns?  The simplified grammar is (fairly) clear and the 
> later section on Constant Value Patterns should make it obvious, but 
> somehow when reading version 1 I still managed to miss it.  I was quite 
> surprised when it was pointed out that
> 
> case (point.x, point.y):
> 
> wasn't going to do what I expected!

Why did you expect?  It's not clear to me what it should do at all :-)

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

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

[Ethan Furman]

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


Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.


All in all I like it a lot!


As authors we welcome Daniel F
Moisset in our midst


Welcom, Daniel, and thank you!


That said, the new version does not differ dramatically in what we
propose. Apart from dropping `__match__` we’re dropping the leading
dot to mark named constants,


Excellent!


without a replacement,


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

The only thing I didn't see addressed was the concern raised by Pablo:


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.


Why is this no longer an issue?  My apologies if I missed it in the PEP.

--
~Ethan~


P.S.  Thanks for all your hard work!  I am very much looking forward to using 
this.
___
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/O65RJZG7OOIKIU5PB7KR4UT4KJR6YI4D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Wed, 8 Jul 2020 13:15:19 -0400
David Mertz  wrote:

> On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky
> 
> > Right. So, if someone would like to add something to this thread,
> > I'd humbly suggest to concentrate on the lack of, and need for, of
> > const-ness in the Python language core (in comparison to other
> > languages or not), and usecases it enables, and not on criteria for
> > "popularness". 
> 
> I admit I do not really understand what gain dynamic languages get
> from constants. I pretty uniformly use a common convention of ALLCAPS
> for constant names (knowing they are not really const in Python or
> bash, where I tend to use them).

Roughly speaking, it's the same "gain" as e.g. (type) annotations.
Indeed, const'ness is a kind of simple type annotation.

> I think that clarifies intent in an important way.

The talk is about formalizing specification of this intent beyond just
stylistic conventions, like case of names. E.g.:


def foo():
pass

bar = foo  # bar is a variable which stores a reference to a function
   # (can be reassigned with another function) 

baz: const = foo  # baz is an alias for foo()

> But checking it
> feels like a job for linters, or perhaps for a future mypy or other
> type checker.
> 
> I can easily imagine that a VM might gain speed with that
> information, but that alone does not feel like enough reason for a
> language change.

If people are satisfied with Python's performance story as presented by
CPython, perhaps. Because otherwise, having a formal constants in the
code allows for simple and obvious optimizations: instead of looking up
value by name at runtime, you can use literal value at the compile time.

If anything, lack of const in Python looks like an accidental gap
(https://en.wikipedia.org/wiki/Accidental_gap): there're general
annotations "with almost arbitrary" syntax, but there's no simple
annotation with very obvious and useful semantics. There's support for
"dict versions" (PEP 509), so you could catch cases when something was
changed behind your back, and no means to say that something just
should not change behind your back. There's a "meta-tracing" JIT and a
number of failed corporate projects, and no means to develop a simple
effective JIT, where user in control of making it more optimal (just
mark things const and you don't need all those dict versions and
runtimes guards, which take space in your instruction cache and put
limit on how fast things can be).

Finally, there's pattern matching PEP 622, which initially proposed a
funny syntax, and now accidental-gap's matching by non-namespaced
constants.

All this gives feeling that Python skipped development of a simple and
useful notion (const'ness, again), and its lack leads to more skips and
unbeautiful workarounds with more complex features in the language.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/X7QM5WVVPHZDJGX5TB4V2D3LQPOXD2MA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Peters]

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

"..." is also a mnemonic for "OK, here I want to match ... umm ... let
me think ... I know!  A fixed value." ;-)
___
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/TPTECZKGQY53L7ZKIQOVOXOTMQE6A447/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Rémi Lapeyre]

> Le 8 juil. 2020 à 19:15, David Mertz  a écrit :
> 
> On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky 
> Right. So, if someone would like to add something to this thread, I'd humbly 
> suggest to concentrate on the lack of, and need for, of const-ness in the 
> Python language core (in comparison to other languages or not), and usecases 
> it enables, and not on criteria for "popularness".
> 
> I admit I do not really understand what gain dynamic languages get from 
> constants. I pretty uniformly use a common convention of ALLCAPS for constant 
> names (knowing they are not really const in Python or bash, where I tend to 
> use them).
> 

This is what I see most, and sometimes beginner misunderstand constness with 
not re-binded names e.g.:

LOGGER = logging.getLogger(__name__)

> I think that clarifies intent in an important way. But checking it feels like 
> a job for linters, or perhaps for a future mypy or other type checker.
> 

Mypy has Final 
(https://mypy.readthedocs.io/en/stable/final_attrs.html#final-names):


from typing_extensions import Final

RATE: Final = 3000

class Base:
DEFAULT_ID: Final = 0

RATE = 300  # Error: can't assign to final attribute
Base.DEFAULT_ID = 1  # Error: can't override a final attribute



> I can easily imagine that a VM might gain speed with that information, but 
> that alone does not feel like enough reason for a language change.
> ___
> 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/HZD7TNMZHO2URXVCJLPCJLOF4Q6L7GJW/
> 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/AGDYR6WD4GXA3ZIEQFOMX27PBIX7FZ3V/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

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

Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.


Thank you very much to everyone who has been working on this, it is much 
appreciated.  I have one suggestion for the text: could the section on 
Capture Patterns emphasise that only simple (i.e not dotted) names are 
capture patterns?  The simplified grammar is (fairly) clear and the 
later section on Constant Value Patterns should make it obvious, but 
somehow when reading version 1 I still managed to miss it.  I was quite 
surprised when it was pointed out that


   case (point.x, point.y):

wasn't going to do what I expected!

(PS: I'm still pushing for an "else" clause, and I can see arguments for 
it going at either indentation level.  Since putting the clause at the 
wrong level would be a syntax error, I don't see it being a particularly 
big issue where it goes.)


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

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[David Mertz]

On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky

> Right. So, if someone would like to add something to this thread, I'd
> humbly suggest to concentrate on the lack of, and need for, of
> const-ness in the Python language core (in comparison to other languages
> or not), and usecases it enables, and not on criteria for "popularness".
>

I admit I do not really understand what gain dynamic languages get from
constants. I pretty uniformly use a common convention of ALLCAPS for
constant names (knowing they are not really const in Python or bash, where
I tend to use them).

I think that clarifies intent in an important way. But checking it feels
like a job for linters, or perhaps for a future mypy or other type checker.

I can easily imagine that a VM might gain speed with that information, but
that alone does not feel like enough reason for a language change.

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

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Wed, 8 Jul 2020 12:37:05 -0400
David Mertz  wrote:

> On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky
> 
> > popular VHLL/scripting languages which doesn't support defining of
> > constants in the core language:
> >
> > JavaScript has "const foo = 1;"
> > PHP has "const foo = 1;"
> > Perl has "use constant foo => 1;"
> > Lua has "local foo  = 1"
> > -
> >  
> > > - Mathematica
> > > - Scheme
> > > - Powershell and other scripting languages like bash
> > > - Applescript and Hyperscript
> > > - Ruby  
> 
> 
> I'm pretty sure some on Steven's list are more *popular* than some on
> Paul's list. What methodology for ranking popularity you use might
> change details. But none of Steven's are rate, obscure, vanity
> languages.

Right. So, if someone would like to add something to this thread, I'd
humbly suggest to concentrate on the lack of, and need for, of
const-ness in the Python language core (in comparison to other languages
or not), and usecases it enables, and not on criteria for "popularness".


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/PBH32KIBMHZO7JEM75VOQ3FNPMEWRFZ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[David Mertz]

On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky

> popular VHLL/scripting languages which doesn't support defining of
> constants in the core language:
>
> JavaScript has "const foo = 1;"
> PHP has "const foo = 1;"
> Perl has "use constant foo => 1;"
> Lua has "local foo  = 1"
> -
>
> > - Mathematica
> > - Scheme
> > - Powershell and other scripting languages like bash
> > - Applescript and Hyperscript
> > - Ruby


I'm pretty sure some on Steven's list are more *popular* than some on
Paul's list. What methodology for ranking popularity you use might change
details. But none of Steven's are rate, obscure, vanity languages.
___
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/ARKEN6LVGI4YLXYQ34ZYTW44OECECCHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Thu, 9 Jul 2020 01:22:48 +1000
Steven D'Aprano  wrote:

> Whenever someone says "Python is the only language..." it really

Yeah, the original message in this sub-thread was
https://mail.python.org/archives/list/python-dev@python.org/message/YPP2TWYONFL4BOR3MJHGTHWSPMQNP7J7/
 ,
and started with:

-
With the advent of Lua 5.4, Python appears to be the only of the
popular VHLL/scripting languages which doesn't support defining of
constants in the core language:

JavaScript has "const foo = 1;"
PHP has "const foo = 1;"
Perl has "use constant foo => 1;"
Lua has "local foo  = 1"
-

The reply cut off that part, then a request to switch subject came in,
and you can fit only so many characters in an email subject, so words
"appears to be" and "popular" got skipped.

> turns out to be the case. Python is very rarely as unusual as people
> often make out.
> 
> To my knowledge, there are quite a few other languages that don't
> have constants, some of them are even moderately well known languages:
> 
> - Mathematica
> - Scheme
> - Powershell and other scripting languages like bash
> - Applescript and Hyperscript
> - Ruby (the compiler only issues a warning if you re-assign 
>   to one, it doesn't enforce the constantness).

Thanks for mentioning Ruby, dunno how I forgot to look it up. And I'm
not surprised that they did something about const'ness, even though
they seem to fall into half-measures.

> I daresay there are many others.
>
> I'm not arguing here for or against constantness, but only pointing
> out that Python is in good company when it comes to lack of constants.

There's unlimited number of scripting languages which don't offer
const'ness. Any freshman student writing their own first language would
make it such.

The point made is that among general-purpose, popular scripting
languages, many adopted a concept of const'ness to the language core,
with Python, sadly, being at the tail.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/O73WUSYTEFZSNRNDLVTGWVFDKVUZS5BR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Steven D'Aprano]

On Thu, Jul 09, 2020 at 01:22:48AM +1000, Steven D'Aprano wrote:
> Whenever someone says "Python is the only language..." it really turns 
> out to be the case. Python is very rarely as unusual as people often 
> make out.

Gah, embarrasing typo! That was meant to be *rarely* turns out to be the 
case, sorry for any confusion.


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

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

[Ethan Furman]

On 07/08/2020 08:30 AM, Luciano Ramalho wrote:


As I first read a `match` statement, and I see an `else` clause, I
know for sure that *something* will happen. If no `else` clause is
present, I know it's possible nothing will happen. It's the same thing
with `else` in `if`, `while`, `for`, `try` statements, where the
`else` is aligned with the opening keyword.


If `else` is added, I agree with aligning with `match`, for the same reasons -- 
especially if we can nest match statements.

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

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

[Tim Golden]

[... snip explanation of key sticking points ...]

Thank you for an excellent write-up combining background context with 
possible solutions. Now I need to actually read the PEP ;)


TJG

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

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

[Luciano Ramalho]

Thanks for explaining the open issues so well, Guido.

My 2¢ on the `else` matter:

On Wed, Jul 8, 2020 at 12:05 PM Guido van Rossum  wrote:
> [...] it’s unclear whether the `else` should be aligned with `case`
> or `match`.

I strongly favor the option of aligning the `else` clause with
`match`, because `else` is a special clause therefore it should look
special.

"Designers need to ensure that controls and displays for different
purposes are significantly different from one another."
—Donald Norman, The Design of Everyday Things

As I first read a `match` statement, and I see an `else` clause, I
know for sure that *something* will happen. If no `else` clause is
present, I know it's possible nothing will happen. It's the same thing
with `else` in `if`, `while`, `for`, `try` statements, where the
`else` is aligned with the opening keyword.


Cheers,

Luciano


-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/VNFVA3FTTZ7KESBDG5A7PQHSRW7GE2F5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Emily Bowman]

On Wed, Jul 8, 2020 at 7:03 AM Kerwin Sun  wrote:

> I tried with this code:
>
[...]

> def whereis(point):
> case w:
>  print("Not the answer, local w")
> case z:
>  print("The answer")
> case _:
>  print("other")
> whereis(42)


 w, z and _ are all equivalent here, therefore it will take the first
matching branch. The very first post about 622 contained a caveat that case
_: will never be reached if case identifier: exists instead. Equivalent
branches are only ignored, not illegal.
___
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/2Y2GROC3IRLGUMXHHVFPODOZG35KYBOE/
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: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Steven D'Aprano]

Whenever someone says "Python is the only language..." it really turns 
out to be the case. Python is very rarely as unusual as people often 
make out.

To my knowledge, there are quite a few other languages that don't have 
constants, some of them are even moderately well known languages:

- Mathematica
- Scheme
- Powershell and other scripting languages like bash
- Applescript and Hyperscript
- Ruby (the compiler only issues a warning if you re-assign 
  to one, it doesn't enforce the constantness).

I daresay there are many others.

I'm not arguing here for or against constantness, but only pointing out 
that Python is in good company when it comes to lack of constants.


-- 
Steven
___
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/6UNUE5HUPNI64XT454CUV4OKNRLGY553/
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] PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching. As authors we welcome Daniel F
Moisset in our midst. Daniel wrote a lot of the new text in this
version, which introduces the subject matter much more gently than the
first version did. He also convinced us to drop the `__match__`
protocol for now: the proposal stands quite well without that kind of
extensibility, and postponing it will allow us to design it at a later
time when we have more experience with how `match` is being used.

That said, the new version does not differ dramatically in what we
propose. Apart from dropping `__match__` we’re dropping the leading
dot to mark named constants, without a replacement, and everything
else looks like we’re digging in our heels. Why is that? Given the
firestorm of feedback we received and the numerous proposals (still
coming) for alternative syntax, it seems a bad tactic not to give up
something more substantial in order to get this proposal passed. Let
me explain.

Language design is not like politics. It’s not like mathematics
either, but I don’t think this situation is at all similar to
negotiating a higher minimum wage in exchange for a lower pension,
where you can definitely argue about exactly how much lower/higher
you’re willing to go. So I don’t think it’s right to propose making
the feature a little bit uglier just to get it accepted.

Frankly, 90% of the issue is about what among the authors we’ve dubbed
the “load/store” problem (although Tobias never tires to explain that
the “load” part is really “load-and-compare”). There’s a considerable
section devoted to this topic in the PEP, but I’d like to give it
another try here.

In case you’ve been avoiding python-dev lately, the problem is
this. Pattern matching lets you capture values from the subject,
similar to sequence unpacking, so that you can write for example
```
x = range(4)
match x:
case (a, b, *rest):
print(f"first={a}, second={b}, rest={rest}")  # 0, 1, [2, 3]
```
Here the `case` line captures the contents of the subject `x` in three
variables named `a`, `b` and `rest`. This is easy to understand by
pretending that a pattern (i.e., what follows `case`) is like the LHS
of an assignment.

However, in order to make pattern matching more useful and versatile,
the pattern matching syntax also allows using literals instead of
capture variables. This is really handy when you want to distinguish
different cases based on some value, for example
```
match t:
case ("rect", real, imag):
return complex(real, imag)
case ("polar", r, phi):
return complex(r * cos(phi), r * sin(phi))
```
You might not even notice anything funny here if I didn’t point out
that `"rect"` and `"polar"` are literals -- it’s really quite
natural for patterns to support this once you think about it.

The problem that everybody’s been concerned about is that Python
programmers, like C programmers before them, aren’t too keen to have
literals like this all over their code, and would rather give names to
the literals, for example
```
USE_POLAR = "polar"
USE_RECT = "rect"
```
Now we would like to be able to replace those literals with the
corresponding names throughout our code and have everything work like
before:
```
match t:
case (USE_RECT, real, imag):
return complex(real, imag)
case (USE_POLAR, r, phi):
return complex(r * cos(phi), r * sin(phi))
```
Alas, the compiler doesn’t know that we want `USE_RECT` to be a
constant value to be matched while we intend `real` and `imag` to be
variables to be given the corresponding values captured from the
subject. So various clever ways have been proposed to distinguish the
two cases.

This discussion is not new to the authors: before we ever published
the first version of the PEP we vigorously debated this (it is Issue 1
in our tracker!), and other languages before us have also had to come
to grips with it. Even many statically compiled languages! The reason
is that for reasons of usability it’s usually deemed important that
their equivalent of `case` auto-declare the captured variables, and
variable declarations may hide (override) like-named variables in
outer scopes.

Scala, for example, uses several different rules: first, capture
variable names must start with a lowercase letter (so it would
handle the above example as intended); next, capture variables
cannot be dotted names (like `mod.var`); finally, you can enclose any
variable in backticks to force the compiler to see it as a load
instead of a store. Elixir uses another form of markup for loads: `x`
is a capture variable, but `^x` loads and compares the value of `x`.

There are a number of dead ends when looking for a solution that works
for Python. Checking at runtime whether a name is defined or not is
one of these: there are numerous reasons why this could be confusing,
not the least of which being that 

[Python-Dev] Re: Why does _ need to be special ?

[Brandt Bucher]

Henk-Jaap Wagenaar wrote:
> The not binding is there only to allow the main way in which "_" is special 
> in match/case: ...

The non-binding behavior is useful in other ways:

match range(HUGE_INT):
case [*_, last]:
print(last)
___
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/2BYZQUCYIJKJSS6DRDVLRWI5B767S6ZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Stefan Krah]

On Wed, Jul 08, 2020 at 07:53:00AM -, Kerwin Sun wrote:
> I tried with this code:
> ```
> from dataclasses import dataclass
> 
> @dataclass
> class Point:
> x: int
> y: int
> 
> z = 41
> 
> def whereis(point):
> w = 23
> match point:
> case Point(0, 0):
> print("Origin")
> case Point(0, y):
> print(f"Y={y}")
> case Point(x, 0):
> print(f"X={x}")
> case Point():
> print("Somewhere else")
> case 23:
> print("Not the answer")
> case w:
>  print("Not the answer, local w")
> case z:
>  print("The answer")
> case _:
>  print("other")
> whereis(42)
> ```
> 
> It retuend:
> ```
> Not the answer, local w

That looks like the correct answer, "w" is a new binding.  This is the same in
Standard ML and OCaml:


# let whereis point =
let w = 23 in
  match point with
23 -> "Not the answer"
  | w -> "Correct answer"
  | _ -> "Unreachable";;
Warning 26: unused variable w.
Warning 11: this match case is unused.
val whereis : int -> string = 
# whereis 42;;
- : string = "Correct answer"
# 



Stefan Krah

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

[Python-Dev] Re: PEP 622 (match statement) playground

[Kerwin Sun]

I tried with this code:
```
from dataclasses import dataclass

@dataclass
class Point:
x: int
y: int

z = 41

def whereis(point):
w = 23
match point:
case Point(0, 0):
print("Origin")
case Point(0, y):
print(f"Y={y}")
case Point(x, 0):
print(f"X={x}")
case Point():
print("Somewhere else")
case 23:
print("Not the answer")
case w:
 print("Not the answer, local w")
case z:
 print("The answer")
case _:
 print("other")
whereis(42)
```

It retuend:
```
Not the answer, local w
<>:23: SyntaxWarning: unguarded name capture pattern makes remaining cases 
unreachable
<>:23: SyntaxWarning: unguarded name capture pattern makes remaining cases 
unreachable
:23: SyntaxWarning: unguarded name capture 
pattern makes remaining cases unreachable
  case w:
```

It seems not the return I except.
___
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/SFY23W4UTT7VJZAW6WLPJ3UQEHUCXMQB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Kerwin Sun]

I tried with this code:
```
from dataclasses import dataclass

@dataclass
class Point:
x: int
y: int

z = 41

def whereis(point):
w = 23
match point:
case Point(0, 0):
print("Origin")
case Point(0, y):
print(f"Y={y}")
case Point(x, 0):
print(f"X={x}")
case Point():
print("Somewhere else")
case 23:
print("Not the answer")
case w:
 print("Not the answer, local w")
case z:
 print("The answer")
case _:
 print("other")
whereis(42)
```

The output is:
```
Not the answer, local w
<>:23: SyntaxWarning: unguarded name capture pattern makes remaining cases 
unreachable
<>:23: SyntaxWarning: unguarded name capture pattern makes remaining cases 
unreachable
:23: SyntaxWarning: unguarded name capture 
pattern makes remaining cases unreachable
  case w:
```

I except this function to return "other", But it seems not.
___
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/463BWHAOQAK4E5FWKYNZYSXXVGWB2T2Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why does _ need to be special ?

[Henk-Jaap Wagenaar]

On Wed, 8 Jul 2020 at 14:30, Paul Svensson  wrote:

> On Wed, 8 Jul 2020, Rhodri James wrote:
>
> > 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.
>
> Does "_" really deserve that special treatment ?
> If you don't want to bind to it, you can just use some other dummy,
> same way you don't use "case print:" if you don want to bind that.
>

The not binding is there only to allow the main way in which "_" is special
in match/case:

case [_, _]:

is legal

case [x, x]:

is illegal (under the last PEP I have seen) and you would instead use

case [x, y] if x == y:

See "Algebraic matching of repeated names":
https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names
See "Guards" https://www.python.org/dev/peps/pep-0622/#id6
___
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/RKE7AIR7MKVG2TLWCZZ57SX2BBJEZ3OB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Why does _ need to be special ?

[Paul Svensson]

On Wed, 8 Jul 2020, Rhodri James wrote:


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.


Does "_" really deserve that special treatment ?
If you don't want to bind to it, you can just use some other dummy,
same way you don't use "case print:" if you don want to bind that.

/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/KGCQDEFXKOPKPXFF7F6LYZKYFCHGVW5X/
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] Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Wed, 08 Jul 2020 12:45:09 +1200
Greg Ewing  wrote:

> On 8/07/20 5:30 am, Paul Sokolovsky wrote:
> > from __future__ import const
> > 
> > FOO: const = 1
> > 
> > match val:
> >  case FOO:  # obviously matches by constant's value  
> 
> This would make it *more* difficult to distinguish constants from
> assignment targets when looking at the match statement, unless you
> choose names which "look constant-like" somehow.

Sure, the talk was about good technical means to distinguish symbolic
constants and variables for pattern matching. These technical means
alone are no replacement for stylistic conventions which improve
readability of the code. In this regard, it's no different than e.g.
conventions of naming classes vs variables.

> It also has the general problem of const-declarations in Python.
> Currently the compiler only has to analyse one module at a time;
> this would require it to also look inside imported modules to
> determine whether things were declared const.

Indeed, adding some "const" at the core language level would give many
benefits, which certainly would be utilized by (even simple, as
embedded in CPython) compilers. E.g. better inter-module scope
resolution and optimization, an example of which you give. In terms of
complexity, that would be minor comparing to e.g. introducing a parser
with unbound memory usage, as done in
https://www.python.org/dev/peps/pep-0617 . 

> 
> -- 
> Greg

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/WV2UA4AKXN5PCDCSTWIUHID25QWZTGMS/
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] I plan to accept PEP 623 "Remove wstr from Unicode" next week

[Victor Stinner]

Hi,

As the PEP delegate of the PEP 623, I plan to accept PEP 623 "Remove
wstr from Unicode" next week. As far as I know, all previous remarks
have been taken in account.

https://www.python.org/dev/peps/pep-0623/

I worked with INADA-san to adjust his PEP 623 plan:

* DeprecationWarning warnings will be emitted as soon as Python 3.10
to help developers detect the deprecation at runtime, rather than only
announcing the deprecation with compiler warnings and in the
documentation.

* Developers have two Python releases (3.10 and 3.11) with these
runtime warnings before functions are removed

* The PEP lists all APIs which will be removed in Python 3.12.

* The PEP gives links to past discussions and issues.

About the "size > 0" condition in "PyUnicode_FromUnicode(NULL, size)
and PyUnicode_FromStringAndSize(NULL, size) emit DeprecationWarning
when size > 0". INADA-san made sure that Cython avoids
PyUnicode_FromUnicode(NULL, 0) to create an empty string: it's already
fixed! The fix will be part of the next Cython 0.29.x release (it
should be 0.29.21). But it will take time until popular extension
modules using Cython will distribute a new release with updated
generated C code.

INADA-san checked popular PyPI projects. The majority of projects
impacted by the PEP are using Cython and so are easy to fix: just
regenerate C code with the fixed Cython. He added: "A few projects,
pyScss and Genshi are not straightforward. But it is not too hard and
I will help them." We have time before Python 3.12 final to update
these projects.

The PEP 623 is backward incompatible on purpose. If needed, it remains
possible to use a single code base working on Python 2.7 and Python
3.12 using #ifdef. But Python 3.12 will not be released before 2023:
three years after Python 2 end of life, so I think that it's
reasonable for extension modules to consider dropping Python 2 support
to implement the PEP 623 (stop using these deprecated C APIs).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/VQKDIZLZ6HF2MLTNCUFURK2IFTXVQEYA/
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/