Mailman 3 January 2020 - Typing-sig

Runtime Access to Type Parameters
by Saul Shanabrook June 7, 2023

June 7, 2023

I would like to propose being able to access, at runtime, the type parameters in classmethods and in constructors. I wrote up a draft PEP on this to capture the thinking here: https://github.com/saulshanabrook/peps/blob/master/pep-9999.md It seems easier to add them to classmethods, so even that addition alone would be very welcome! It could be added to Guido's existing draft PR for pep 585, by making a small change in the getattr function (https://github.com/python/cpython/pull/18239/files#diff-a34ae826f869897e56e…), to first do a `__getattribute__` and check if the result is a descriptor (has a `__get__` attribute), and if so passing the generic class itself in as the class, instead of the origin class. I wrote up a little example of that in the PEP. To make it available in the constructor, I proposed adding a global function `get_parameters` to `typing` which returns the parameters in the constructor. I also provide a little mock implementation of that. Note that work is only for custom classes which inherit from `typing.Generic` not for any built in collections.

5 6

Explicit Type Aliases
by Shannon Zhu Aug. 17, 2022

Aug. 17, 2022

Hi everyone, I’d like to continue the discussion from our last typing summit on explicit type aliases. A quick summary of the current state and the proposal -- Current state: ``` from typing import List x = List[int] # considered a type alias y : Type[List[int]] = List[int] # considered an expression z : Any # considered a type alias z : x = [] # fine z : y = [] # invalid type error ``` Proposal (with explicit aliases): ``` from typing import List, TypeAlias x = TypeAlias[List[int]] # considered a type alias y = List[int] # considered an expression z : Any # considered an expression z = TypeAlias[Any] # considered a type alias reveal_type(x) # Type[List[int]] reveal_type(y) # Any (return type of __getitem__) z : x = [] # fine z : y = [] # invalid type error ``` Some of the benefits we’re hoping to gain from explicit type aliases: * Clearly distinguish between an unannotated global assignment and a type alias, especially when parsing forward-referencing string annotations. * Avoid the confusing case of type aliases in which some part of the type is invalid or undefined. This would facilitate warnings on invalid types at the alias definition rather than later on when the alias is used. * Make valid and invalid types more intuitive to Python programmers by shifting from delineation of non-aliases with a meta annotation toward delineation of aliases with `TypeAlias`. * Remove special treatment of values annotated as `Any`, which currently break all type aliasing rules. This will also allow us to clean up some of the distinctions we maintain between unannotated values and explicit Anys. Note: We also considered denoting the alias as an annotation (e.g. `x: TypeAlias = int`) as an alternative to the syntax above. I’m interested to hear your thoughts and suggestions on making type aliasing explicit going forward – we’d like to start implementing a version of this in Pyre soon! Shannon

7 10

Bay Area Typing Meetup 9/20
by Dominik Gabi June 1, 2020

June 1, 2020

Jukka and Ivan will be visiting the Bay Area in September and we'd like to organize another meetup. Here are the proposed (tentative) logistics: Date: Friday, Sept. 20 Time: 1pm - 5pm Location: Facebook in Menlo Park (building and room TBD) So far Ivan, Jukka, Guido, Rebecca, Martin (?), and myself have committed to attending. I'm also volunteering the rest of the Pyre team. Please let us know in advance if you plan on attending so that we can book an adequately sized room. Also now's the time to think about topics to discuss or presentations you want to give. – Dominik

4 3

PEP 593: Flexible function and variable annotations
by Till March 4, 2020

March 4, 2020

Hi, We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion. Best, Till

9 45

PEP 612: Parameter Specification Variables
by Mark Mendoza Feb. 21, 2020

Feb. 21, 2020

Hi All, I want to announce the submission of a new typing PEP, for ParameterSpecifications (https://github.com/python/peps/pull/1259). We discussed this concept at the last typing summit (presentation can be found here https://github.com/facebook/pyre-check/blob/master/docs/Variadic_Type_Varia…), and there seemed to be general consensus on the utility of this idea, and the appropriateness of the particular solution. One note that I know there was some disagreement on was the name for the feature itself, with some folks preferring ArgSpec. I wrote up a brief note in the PEP itself why we're not as big fans of that name, but I'd love to hear all of your opinions on this issue, as well as on anything else in the PEP. Best, Mark Mendoza

5 18

PEP 613: Explicit Type Aliases
by Shannon Zhu Feb. 5, 2020

Feb. 5, 2020

Hi everyone, I'm emailing to flag the submission of PEP 613 to formally define the motivation and syntax for explicit type alias. https://github.com/python/peps/pull/1278/files [https://avatars3.githubusercontent.com/u/6366891?s=400&v=4]<https://github.com/python/peps/pull/1278/files> PEP 613: Initial submission by shannonzhu · Pull Request #1278 · python/peps<https://github.com/python/peps/pull/1278/files> Note: Python CLA has been signed but is pending the check at https://check-python-cla.herokuapp.com/ github.com The original discussion on this topic occurred on this list last August (https://mail.python.org/archives/list/typing-sig@python.org/thread/MWRJOBEE…), and the conclusions we reached were hashed out again in the most recent typing meetup at Facebook late last year. Thoughts and opinions on the PEP draft are appreciated! Thanks, Shannon

3 5

Discussion of PEP 585: Type Hinting Generics In Standard Collections
by Guido van Rossum Jan. 30, 2020

Jan. 30, 2020

** I would really like a response from Łukasz, the PEP author. ** I accidentally started a thread with a similar subject but accidentally "PEP 505" instead of "PEP 585". A quick summary of points from that email to which I'm not returning below: - The proxy type will have a name: types.GenericAlias. - list == list[str] should be false. - isinstance([1, 2], list[int]) should raise TypeError. - Make re.Pattern, re.Match, io.IO generic. - I don't know whether we should make typing.List be the same object as builtins.list or not (and ditto for all generic classes in typing). - I'm stuck making type[int] work (this is needed so builtins.type[x] works like typing.Type[x]). A few other simple points: - Let's disallow isinstance(x, list[int]) and issubclass(C, list[int]). - We are making re.Match, re.Pattern and io.IO generic. Since that thread I've got some more ideas. 1. We should rename __parameters__ to __args__, there's no reason to deviate from typing.py here. 2. We can relatively easily add a new __parameters__ attribute (lazily computed) that returns only the subset of __args__ that are type vars, and make it so that e.g. dict[str, T][int] works (and returns dict[str, int]) and list[int][int] is disallowed. This is what __parameters__ means in typing.py. It will fix 2 out of the 3 current test_typing.py failures. 3. We *could* easily change GenericAlias.__call__ to set __orig_class__ on the new instance if it works, ignoring the error (e.g. if the class uses __slots__ or overrides __setattr__), but I see a downside: it adds an extra entry to self.__dict__ for each instance. While typing.py currently does this (and there's a test for it), I think it's a high cost to pay for making a class generic. And the purpose of `__orig_class__` is questionable -- why have it at all? (This is the third failure in test_typing.py -- if we decide not to do this, we should disable the failing parts of that test.) 4. We should probably arrange for list[int] == list[int] by defining GenericAlias.__eq__. (But list != list[int].) 5. Should we touch typing.py at all? Or just leave it be? Though the proposed silent deprecation will encourage people who *want* to do runtime introspection to ignore the changes, and then they will be in for a bad surprise 5 years hence. -- --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-…>

3 3

Discussion of PEP 505: Type Hinting Generics In Standard Collections
by Guido van Rossum Jan. 30, 2020

Jan. 30, 2020

PEP 585: https://www.python.org/dev/peps/pep-0585/ With the help of Ethan Smith (and some code review by Serhiy) I have started a prototype of PEP585. You can see my code at https://github.com/python/cpython/pull/18239 (a PR to CPython) or directly in my branch (where I take PRs too): https://github.com/gvanrossum/cpython/tree/pep585. I am cautiously optimistic that we can get this integrated into Python 3.9. Based on this work in progress I have a bunch of questions and suggestions for PEP 585. 1. The PEP says that e.g. list[str][str] should be forbidden. But there's at least one example where we currently allow chained subscript operations. This currently works (in mypy as well as at runtime): import typing T = typing.TypeVar("T") D = typing.Dict[str, T] # Now D is a generic type x: D[int] # Now x has type dict[str, int] But if, in my branch, we replace Dict with dict, we get an error on the last line: import typing T = typing.TypeVar("T") D = dict[str, T] x: D[int] # E: TypeError: 'GenericAlias' object is not subscriptable The last line raises a TypeError. 2. The PEP says that isinstance([1, 2, 3], list[int]) should be True. I think this is wrong -- with typing.List[int] it currently raises a TypeError, and I think we should keep forbidding this. Similar with issubclass. 3. The PEP says that list == list[str]. This currently returns false in my branch (apparently this doesn't use __getattribute__ to get the __eq__ operation), and I think I like that better. It also matches the behavior of typing.List. 4. The PEP doesn't provide a name for the proxy type. I propose to name it GenericAlias and to add it to the types.py module, so it can be imported as types.GenericAlias (note: types; not typing). 5. I think the following classes should also be made generic: re.Pattern, re.Match, io.IO. 6. How far should we go with replacing everything in typing.py that shadows something that has become generic due to the PEP's changes? (collections, collections.abc, contextlib, re, io). I expect this to be somewhat controversial (Ivan may have some ideas) and difficult to keep compatible with 3.8. 7. I haven't figured out yet how to support type[x] (which should have the same meaning as typing.Type[x]) without it also enabling int[x], which we would like to prevent. (We don't want to just add object.__class_getitem__!) 8. I have a tricky bug remaining where inheriting from Tuple[something] causes problems. Take this example: class C(Tuple[int]): pass If we now examine C.__mro__, we see that it is (C, tuple, typing.Generic, object). IOW, inheriting from typing.Tuple causes builtins.tuple to be inserted into the MRO. The problem is that in my branch, tuple.__class_getitem__ overrides Generic.__class_getitem__, whereas the latter is needed to satisfy some tests for typing.py (and presumably to enable certain special behavior). I'm mostly looking for suggestions on how to make those failing tests work (see https://github.com/python/cpython/commit/35cd5f477c9da985880130d72297335e01… ). -- --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-…>

4 10

Implementation work for PEP 585 (Type Hinting Generics In Standard Collections)
by Guido van Rossum Jan. 28, 2020

Jan. 28, 2020

I'm beginning implementation work for PEP 585. I've got a little pure Python class that I'll use to guide me. (See attached proxy.py.) Then I'll start the work, roughly like this: - Create a cpython fork (gvanrossum/pep585 where to do the work). - Write a simple _Py_Class_GetItem(origin, parameters) function that just returns origin (after INCREF). - Add that function to list, tuple and dict to show it works. - Write some tests. - Write a simple Proxy object to hold origin and parameters and return it from _Py_Class_GetItem. - Update tests. - Add __repr__ implementation and getattr forwarding functionality. - Update tests. - Deploy more widely to other builtin classes (set, frozenset, type). - Update tests. - Add specific methods that are supposed to fail (__class_getitem__, __instancecheck__, __subclasscheck__). - Update tests. At this point we're ready to start using the proxy class in typing.py, instead of the current implementation of _GenericAlias. We'll need to debate whether all the error checks we currently have in typing.py we *really* need to keep (usually these will also be detected by running a static type checker, so there's little harm in allowing nonsense like `list[1, 2, 3]`). Alternatively I'll need volunteers to implement those checks. I expect the implementation work to result in proposed improvements to PEP 585. (I already have some -- I don't think `isinstance(x, list[int])` should work, and I don't think we should strive for `list[int] == list`.) -- --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-…>

6 13

PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0
by Victor Stinner Jan. 28, 2020

Jan. 28, 2020

Hi, When the "PEP 563 -- Postponed Evaluation of Annotations" was accepted and implemented in Python 3.7, the feature was introduced as an opt-in choice, and the switch to enable it by default was scheduled for Python 4.0. I dislike scheduling too many incompatible changes in Python 4.0, and I would prefer to have them happening earlier :-) Would you be ok to have annotations as string by default in Python 3.10, or even in Python 3.9? If Python 3.9 is picked, the change must be done before "3.9.0 beta 1: Monday, 2020-05-18 (No new features beyond this point.)" and 3.9.0 final is scheduled for Monday, 2020-10-05 (PEP 596). Is it too early? See https://bugs.python.org/issue38605 for the previous discussion. -- Example: # from __future__ import annotations def func(x: int): pass print((func.__annotations__)) Currently (Python 3.7 and 3.8), we get: {'x': <class 'int'>} PEP 563 annotations (if you uncomment the __future__) gives: {'x': 'int'} Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0