PEP-0472 revisited - draft
For those interested in the new draft of ex PEP-0472 (which has joined the choir invisible), I opened a draft PR https://github.com/python/peps/pull/1579 This first draft contains only the revisited motivation and background. I'll add the technical decisions etc in the upcoming nights. -- Kind regards, Stefano Borini
Thanks -- good to get this written down! Question: it strikes me that the use case of [] for type hints is logically quite different than for indexing. So do they need to use the same syntax / dunder? I think that type hints are used in specific places, and thus the interpreter could know if a given [] was a type hint or an indexing operation, and thus could dispatch it differently. Would that be desirable? I'm not sure -- but as type hints' use of [] is logically quite different, it might make sense to have it use different rules. There is precedent -- after all, () used to create a tuple follows different rules than () used to call a function. If it's not technically possible to make the distinction, then it's a non-issue, but if it is, it may be worth considering. -CHB On Tue, Sep 1, 2020 at 12:40 AM Stefano Borini <stefano.borini@gmail.com> wrote:
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Sep 1, 2020 at 11:21 AM Christopher Barker <pythonchb@gmail.com> wrote:
How would we differentiate what the caller means by the subscript invocation? Put another way: would the distinction be: A) between 1. objects of the type `type` (class objects), and 2. non-type objects...? B) between WHERE the innovation occurs in the code? To explain further, A) looks like: dict[ x, y ] ...calls: dict.__type_subscript__( ( x, y ) ) ...because dict is a class object, but: d = dict(0 d[ x, y ] ...calls: d.__getitem__( ( x, y ) ) ...because d is not a class object? Or B), so that for either of these: d: dict[x, y] ...or this: def f() -> dict[ x, y ]: ... ...the type checker calls (no effect at runtime): dict.__type_subscript__( ( x, y ) ) ...but this would still call __getitem__ at runtime: class C: ...
C[ x, y ]
...simply calls: C.__getitem__(( x, y )) ...because the C[x,y] invocation occurs outside of a type hint location...? B) at least seems like it isn't an option, since it's probably impossible to determine what things are type hints and what things aren't simply based on where they appear in code:
MyType = C[x,y] # this will be a type hint my_value = C[x,y] # looking up a key on object C
--- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Tue, Sep 1, 2020 at 8:20 AM Christopher Barker <pythonchb@gmail.com> wrote:
Type hints are indeed dispatched differently, but this is done based on information that is only available at runtime. Since PEP 560, for `x[y]`, if no `__getitem__` method is found, and `x` is a type (class) object, and `x` has a class method `__class_getitem__`, that method is called. Extending this with keyword args is straightforward. Modifying the compiler to generate different bytecode for this case is essentially impossible. See https://github.com/python/cpython/blob/6844b56176c41f0a0e25fcd4fef5463bcdbc7... for the code (it's part of PyObject_GetItem). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Tue, Sep 1, 2020 at 9:51 AM Guido van Rossum <guido@python.org> wrote:
Thanks -- then that answers my question -- no it's not technically possible. Oh well. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Thanks -- good to get this written down! Question: it strikes me that the use case of [] for type hints is logically quite different than for indexing. So do they need to use the same syntax / dunder? I think that type hints are used in specific places, and thus the interpreter could know if a given [] was a type hint or an indexing operation, and thus could dispatch it differently. Would that be desirable? I'm not sure -- but as type hints' use of [] is logically quite different, it might make sense to have it use different rules. There is precedent -- after all, () used to create a tuple follows different rules than () used to call a function. If it's not technically possible to make the distinction, then it's a non-issue, but if it is, it may be worth considering. -CHB On Tue, Sep 1, 2020 at 12:40 AM Stefano Borini <stefano.borini@gmail.com> wrote:
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Sep 1, 2020 at 11:21 AM Christopher Barker <pythonchb@gmail.com> wrote:
How would we differentiate what the caller means by the subscript invocation? Put another way: would the distinction be: A) between 1. objects of the type `type` (class objects), and 2. non-type objects...? B) between WHERE the innovation occurs in the code? To explain further, A) looks like: dict[ x, y ] ...calls: dict.__type_subscript__( ( x, y ) ) ...because dict is a class object, but: d = dict(0 d[ x, y ] ...calls: d.__getitem__( ( x, y ) ) ...because d is not a class object? Or B), so that for either of these: d: dict[x, y] ...or this: def f() -> dict[ x, y ]: ... ...the type checker calls (no effect at runtime): dict.__type_subscript__( ( x, y ) ) ...but this would still call __getitem__ at runtime: class C: ...
C[ x, y ]
...simply calls: C.__getitem__(( x, y )) ...because the C[x,y] invocation occurs outside of a type hint location...? B) at least seems like it isn't an option, since it's probably impossible to determine what things are type hints and what things aren't simply based on where they appear in code:
MyType = C[x,y] # this will be a type hint my_value = C[x,y] # looking up a key on object C
--- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Tue, Sep 1, 2020 at 8:20 AM Christopher Barker <pythonchb@gmail.com> wrote:
Type hints are indeed dispatched differently, but this is done based on information that is only available at runtime. Since PEP 560, for `x[y]`, if no `__getitem__` method is found, and `x` is a type (class) object, and `x` has a class method `__class_getitem__`, that method is called. Extending this with keyword args is straightforward. Modifying the compiler to generate different bytecode for this case is essentially impossible. See https://github.com/python/cpython/blob/6844b56176c41f0a0e25fcd4fef5463bcdbc7... for the code (it's part of PyObject_GetItem). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Tue, Sep 1, 2020 at 9:51 AM Guido van Rossum <guido@python.org> wrote:
Thanks -- then that answers my question -- no it's not technically possible. Oh well. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
participants (5)
-
Christopher Barker -
Greg Ewing -
Guido van Rossum -
Ricky Teachey -
Stefano Borini