[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Hi Neil, Le mar. 23 juin 2020 à 03:47, Neil Schemenauer a écrit : > Thanks for putting work into this. You're welcome, I took some ideas from your tagged pointer proof of concept ;-) I recall that we met the same C API issues in our experiments ;-) > Changes must be made for > well founded

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

On Tue, 23 Jun 2020 11:18:37 +0200 Victor Stinner wrote: > > Pseudo-code: > > void iterate(PyObject *obj) > { > PyObjectPP_View view; > > if (PyObjectPP_View_Get(, obj)) { > // fast-path: the object provides a PyObject** view > for (Py_ssize_t i=0; i < view.len; i++ { > PyObject *item

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On 2020-06-22 14:10, Victor Stinner wrote: Hi, PEP available at: https://www.python.org/dev/peps/pep-0620/ This PEP is the result of 4 years of research work on the C API: https://pythoncapi.readthedocs.io/ It's the third version. The first version (2017) proposed to add a "new C API" and

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On Tue, Jun 23, 2020 at 11:33 AM Victor Stinner wrote: > Hi Neil, > > Le mar. 23 juin 2020 à 03:47, Neil Schemenauer > > > One aspect of the API that could be improved is memory management > > for PyObjects. The current API is quite a mess and for no good > > reason except legacy, IMHO. The

[Python-Dev] (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

Le mar. 23 juin 2020 à 03:47, Neil Schemenauer a écrit : > One final comment: I think even if we manage to cleanup the API and > make it friendly for other Python implementations, there is going to > be a fair amount of overhead. If you look at other "managed > runtimes" that just seems

[Python-Dev] Re: Draft PEP: Remove wstr from Unicode

Le mar. 23 juin 2020 à 04:02, Inada Naoki a écrit : > Legacy unicode representation is using wstr so legacy unicode support > is removed with wstr. > PyUnicode_READY() will be no-op when wstr is removed. We can remove > calling of PyUnicode_READY() since then. > > I think we can deprecate

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Le mar. 23 juin 2020 à 15:56, Petr Viktorin a écrit : > > Adding or removing members of C structures is causing multiple backward > > compatibility issues. > > > > Adding a new member breaks the stable ABI (PEP 384), especially for > > types declared statically (e.g. ``static PyTypeObject MyType

[Python-Dev] New optional dependency

Hi all, I am looking at getting TkDND support into tkinter, and have created issue40893. However, we are currently considering the practicalities of adding a new optional dependency to Python and I was hoping someone could help answer the question of: is there a procedure for this? The problem

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

Victor Stinner schrieb am 23.06.20 um 11:18: > Maybe an object can > generate a temporary PyObject** view which requires to allocate > resources (like memory) and the release function would release these > resources. I agree that this is more explicit when it comes to resource management, but

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Hi Victor, thanks for your continued work on improving the C-API. I'll comment on the PEP inline. Victor Stinner schrieb am 22.06.20 um 14:10: > PEP available at: https://www.python.org/dev/peps/pep-0620/ > [...] > Motivation > == > > The C API blocks CPython evolutions >

[Python-Dev] Re: New optional dependency - TkDND

On 2020-06-23 12:14, Elisha Paine wrote: Hi all, I am looking at getting TkDND support into tkinter, and have created issue40893. However, we are currently considering the practicalities of adding a new optional dependency to Python and I was hoping someone could help answer the question of: is

[Python-Dev] Re: Cython and incompatible C API changes

Hi, Le 22/06/2020 à 11:21, Stefan Behnel a écrit : > [...] > > Basically, for maintained packages, I consider shipping the generated C > code the right way. Less hassle, easier debugging, better user experience. > For unmaintained packages, regenerating the C code at build time *can* > extend

[Python-Dev] PEP 622: Structural Pattern Matching

I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Many people have thought about extending Python with a form of pattern matching similar to that found in Scala, Rust, F#, Haskell and other

[Python-Dev] Re: New optional dependency

On Tue, Jun 23, 2020 at 7:41 AM Elisha Paine wrote: > Hi all, > > I am looking at getting TkDND support into tkinter, and have created > issue40893. However, we are currently considering the practicalities of > adding a new optional dependency to Python and I was hoping someone > could help

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

On 06/23/2020 09:01 AM, Guido van Rossum wrote: Very nice! I am totally in favor (with some bike-shedding, of course). First, a formatting comment: A new sentence immediately following formatted code needs more space -- it looks like the same sentence otherwise. Will putting two spaces

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

I will say that trying to follow https://github.com/python/peps/blob/master/pep-0622.rst#runtime-specification was really hard. Any chance of getting some pseudo-code that shows how a match is performed? Otherwise all of that wording tries so hard to be a spec that I found it hard to follow in

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On Tue, 23 Jun 2020 16:34:28 +0200 Victor Stinner wrote: > Le mar. 23 juin 2020 à 15:56, Petr Viktorin a écrit : > > > Adding or removing members of C structures is causing multiple backward > > > compatibility issues. > > > > > > Adding a new member breaks the stable ABI (PEP 384), especially

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

On Tue, 23 Jun 2020 at 17:07, Guido van Rossum wrote: > > I'm happy to present a new PEP for the python-dev community to review. This > is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. > > Many people have thought about extending Python with a form of pattern > matching

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

On Jun 23, 2020, at 09:01, Guido van Rossum wrote: > I'm happy to present a new PEP for the python-dev community to review. This > is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Congratulations to the authors. This is a well written, complex PEP for a powerful

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

On 2020-06-23 17:01, Guido van Rossum wrote: I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Many people have thought about extending Python with a form of pattern matching similar to that

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

Some comments: * What you call "Constant Value Patterns" can really refer to any local or non-local name, regardless of how complex the referred object is, right? Also, __eq__ is called in that case, not __match__? * If I understand correctly, these: case b"": print("it's an

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On 2020-06-23, Thomas Wouters wrote: > I think the ability for per-type allocation/deallocation routines isn't > really about efficiency, but more about giving more control to embedding > systems (or libraries wrapped by extension modules) about how *their* > objects are allocated. It doesn't make

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Le mar. 23 juin 2020 à 20:37, Neil Schemenauer a écrit : > My thinking is that, eventually, we would like to allow CPython to > use something other than reference counting for internal PyObject > memory management. In other systems with garbage collection, the > memory allocator is typically

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

(I'm replying to several messages in one reply. But there is too much to respond to so this is merely the first batch.) On Tue, Jun 23, 2020 at 10:10 AM MRAB wrote: > Why are: > > case ._: > > not OK? > > In this: > > case .BLACK: > ... > case BLACK: > ... > >

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

On 2020-06-23 22:53, Emily Bowman wrote: On Tue, Jun 23, 2020 at 2:10 PM MRAB > wrote: I think that's done for consistency. '_' is a wildcard and you can have:      case (_, _): to match any 2-tuple, so:      case _: would match any

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

On 2020-06-23 22:50, Barry Warsaw wrote: On Jun 23, 2020, at 14:31, Chris Angelico wrote: I can't find it among the rejected alternatives, but was it considered to use "..." as the wildcard, rather than "_"? It carries similar meaning but its special case of "this will never be bound" is

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

On Tue, Jun 23, 2020 at 3:06 PM Emily Bowman wrote: > Can you have case (x,x): ? I haven't tried the implementation, but it's > not addressed in the PEP that I see, and if that's legal, then _ is > effectively just a style choice, rather than a functional one, and there's > no reason it

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

On 06/23/2020 09:01 AM, PEP 622 wrote: from enum import Enum class Color(Enum): BLACK = 1 RED = 2 BLACK = 1 RED = 2 match color: case .BLACK | Color.BLACK: print("Black suits every color") case BLACK: # This will just assign a new value to BLACK. ... As

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

On 06/23/2020 10:31 PM, Chris Angelico wrote: On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote: On 06/23/2020 09:01 AM, PEP 622 wrote: from enum import Enum class Color(Enum): BLACK = 1 RED = 2 BLACK = 1 RED = 2 match color: case .BLACK | Color.BLACK: print("Black

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

On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote: > > On 06/23/2020 09:01 AM, PEP 622 wrote: > > > from enum import Enum > > > > class Color(Enum): > > BLACK = 1 > > RED = 2 > > > > BLACK = 1 > > RED = 2 > > > > match color: > > case .BLACK | Color.BLACK: > > print("Black

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

On 23/06/2020 17:01, Guido van Rossum wrote: You can combine several literals in a single pattern using `|` ("or"): ```py         case 401|403|404:             return "Not allowed" The PEP is great, but this strikes me as horribly confusing, given that 401|403|404 is already legal syntax.

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

On 06/23/2020 12:49 PM, Barry Warsaw wrote: Maybe the PEP could support this syntax: case in 401, 403, 404: That seems like it would be both unambiguous and semantically obvious. Unfortunately, that means: Is the object a three-tuple with the values 401, 403, and 404? -- ~Ethan~

[Python-Dev] Re%3A Re%3A New optional dependency - TkDND=<45fe0089-6c26-4238-9e7c-ec38f719d781%40gmail.com>

> What's the advantage of having TkDND bindings in the standard library 1. I think there is enough demand for the feature to make it worth adding to the stdlib (and the actual bindings are not that large so won’t require much maintenance). There are several threads on Stack Overflow where using

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

On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev wrote: > > The PEP is great, but this strikes me as horribly confusing, given that > 401|403|404 is already legal syntax. > IIUC any legal expression can come between `case` and `:`, but expressions > that contain `|` at their outermost

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

On Jun 23, 2020, at 12:27, Rob Cliffe via Python-Dev wrote: > > On 23/06/2020 17:01, Guido van Rossum wrote: >> >> You can combine several literals in a single pattern using `|` ("or"): >> >> ```py >> case 401|403|404: >> return "Not allowed" > The PEP is great, but this

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

On 6/23/2020 5:56 PM, Barry Warsaw wrote: match: expression case arm1: pass case arm2: pass else: pass nicely mirrors try/except and if/elif/else constructs so it looks quite natural. Agreed as to the look of the form. Some

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

On Wed., 24 Jun. 2020, 2:07 am Guido van Rossum, wrote: > I'm happy to present a new PEP for the python-dev community to review. > This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and > Talin. > Very nice! As with some others, the main thing that gives me pause is the

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

On 2020-06-23 20:27, Rob Cliffe via Python-Dev wrote: On 23/06/2020 17:01, Guido van Rossum wrote: You can combine several literals in a single pattern using `|` ("or"): ```py         case 401|403|404:             return "Not allowed" The PEP is great, but this strikes me as horribly

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

On Tue, Jun 23, 2020 at 2:10 PM MRAB wrote: > I think that's done for consistency. '_' is a wildcard and you can have: > > case (_, _): > > to match any 2-tuple, so: > > case _: > > would match any value, and can thus already serve as the default. > > I wouldn't object to 'else',

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

On 06/23/2020 02:48 PM, Barry Warsaw wrote: On Jun 23, 2020, at 13:50, Ethan Furman wrote: On 06/23/2020 12:49 PM, Barry Warsaw wrote: Maybe the PEP could support this syntax: case in 401, 403, 404: That seems like it would be both unambiguous and semantically obvious. Unfortunately,

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

On 2020-06-23 18:20, Antoine Pitrou wrote: Some comments: * What you call "Constant Value Patterns" can really refer to any local or non-local name, regardless of how complex the referred object is, right? Also, __eq__ is called in that case, not __match__? * If I understand correctly,

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

On Wed, Jun 24, 2020 at 2:04 AM Guido van Rossum wrote: > def http_error(status): > match status: > case 404: > return "Not found" > case 418: > return "I'm a teapot" > case _: > return "Something else" > > Note the last block: the

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

Hi, I read the PEP, and a few thoughts: - I think one of the examples is some lib2to3 code? I think the matcher syntax is really great for that case (parse trees). The matcher syntax is definitely an improvement over the litany of helper functions and conditionals otherwise needed. That

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

On Jun 23, 2020, at 14:31, Chris Angelico wrote: > I can't find it among the rejected alternatives, but was it considered > to use "..." as the wildcard, rather than "_"? It carries similar > meaning but its special case of "this will never be bound" is simply > preventing an error, rather than

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

On Jun 23, 2020, at 13:50, Ethan Furman wrote: > > On 06/23/2020 12:49 PM, Barry Warsaw wrote: > >> Maybe the PEP could support this syntax: >> case in 401, 403, 404: >> That seems like it would be both unambiguous and semantically obvious. > > Unfortunately, that means: > > Is the

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

On Jun 23, 2020, at 14:34, Richard Levasseur wrote: > I agree with not having flat indentation. I think having "case" indented from > "match" makes it more readable overall. I don’t know whether my suggestion to use `match:` and putting the expression inside this stanza can be accomplished,

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit : > > Adding a new member breaks the stable ABI (PEP 384), especially for > > types declared statically (e.g. ``static PyTypeObject MyType = > > {...};``). In Python 3.4, the PEP 442 "Safe object finalization" added > > the ``tp_finalize``

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

On Tue, Jun 23, 2020 at 5:21 PM Ethan Furman wrote: > On 06/23/2020 04:26 PM, Guido van Rossum wrote: > > On Tue, Jun 23, 2020 at 11:41 AM Ethan Furman wrote: > > > > Testing my understanding -- the following snippet from the PEP > > > > match group_shapes(): > > case

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

On Wed, Jun 24, 2020 at 10:11 AM Guido van Rossum wrote: > > On Tue, Jun 23, 2020 at 4:41 PM MRAB wrote: >> >> On 2020-06-23 22:50, Barry Warsaw wrote: >> > On Jun 23, 2020, at 14:31, Chris Angelico wrote: >> > >> >> I can't find it among the rejected alternatives, but was it considered >> >>

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

On Tue, Jun 23, 2020 at 4:41 PM MRAB wrote: > On 2020-06-23 22:50, Barry Warsaw wrote: > > On Jun 23, 2020, at 14:31, Chris Angelico wrote: > > > >> I can't find it among the rejected alternatives, but was it considered > >> to use "..." as the wildcard, rather than "_"? It carries similar > >>

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

On 06/23/2020 04:26 PM, Guido van Rossum wrote: On Tue, Jun 23, 2020 at 11:41 AM Ethan Furman wrote: Testing my understanding -- the following snippet from the PEP      match group_shapes():          case [], [point := Point(x, y), *other]: will succeed if group_shapes()

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

On 2020-06-24 01:09, Guido van Rossum wrote: On Tue, Jun 23, 2020 at 4:41 PM MRAB > wrote: [snip] However, what if you wanted to match Ellipsis? This could lead to bugs:  >>> ... Ellipsis  >>> Ellipsis = 0  >>> Ellipsis 0  

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

This is awesome! What I love about this is that it strongly encourages people not to do EAFP with types (which I've seen many times), which causes problems when doing type annotations. Instead, if they use pattern matching, they're essentially forced to do isinstance without even realizing it.

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

On Tue, Jun 23, 2020 at 9:45 PM Neil Girdhar wrote: > This is awesome! > > What I love about this is that it strongly encourages people not to do > EAFP with types (which I've seen many times), which causes problems when > doing type annotations. Instead, if they use pattern matching, they're >

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

def whereis(point): > match point: > case MovingPoint(0, 0): > print("Origin") > case MovingPoint(0, y): > print(f"Y={y}") > case MovingPoint(x, 0): > print(f"X={x}") > case MovingPoint(1, 1): > print("Diagonal at