Mailman 3 October 2019 - Typing-sig

Explicit Type Aliases
by Shannon Zhu 17 Aug '22

17 Aug '22

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 01 Jun '20

01 Jun '20

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 03 Mar '20

03 Mar '20

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

What are people's feelings about a DefinitelyTyped for Python?
by Brett Cannon 07 Nov '19

07 Nov '19

Working at Microsoft means I get asked semi-regularly about why the Python community has not set up a [DefinitelyTyped](https://definitelytyped.org/) equivalent, and I have historically said 🤷‍♂️. I have now been asked this enough times that I'm asking all of you if there's a specific reason beyond lack of time and resources so I can give a more informed answer next time this question comes up? I found https://github.com/python/typeshed/issues/2491 which didn't suggest any particular issue with the idea other than time and resources. Or I guess another way to phrase the question is if someone created a site like DefinitelyTyped where things were highly automated and anyone could provide type stubs for any project on PyPI -- and maybe even automated initial type stubs -- would people be interested in such a thing or see any reasons why people would balk at it or not use it?

9 27

Type School
by Sebastian Rittau 31 Oct '19

31 Oct '19

Since we are currently talking about the future of typeshed, there is another idea that's been floating around, and which was somewhat discussed in the past. In an ideal world, packages would maintain and ship their own type stubs (using the py.typed marker). At the moment is not realistic at all. I would categorize package projects into three groups: * Projects that already ship their own type stubs and have the knowledge to do so. Perfect. * Projects that are not interested in type stubs and have no interest in maintaining them. This is fine and their stubs can be maintained and distributed with typeshed. * Projects that are interested in shipping their own stubs, but are lacking the knowledge or tools to do so. The third group is what this idea is aimed at: I'd like to provide some kind of "Type School", where interested maintainers can ask for reviews of the stubs they want to add to their own project by typeshed maintainers or other interested and skilled parties. This way, we could nudge projects towards the first group and at the same time increase the user experience for end users, by not needing to install a type package. The easiest way to implement this is probably to add a issue template to typeshed for exactly that purpose. People could then review the linked PR and close the issue in typeshed. More sophisticated solutions are also possible, of course. I wonder what other people think about this. - Sebastian

5 6

Asymmetry w.r.t. issubclass for protocols with (non-)method members and classes that have been registered via Protocol.register
by Dominik Vilsmeier 22 Oct '19

22 Oct '19

PEP 544 introduces `typing.Protocol` for declaring interfaces that work with structural subtyping. Nevertheless since `abc.ABCMeta` is in the MRO of `type(Protocol)` we can still use the plain old `Protocol.register` for registering subtypes. This seems to override the "normal" instance and subclass checks performed by `Protocol` since we can register any non-conforming class. For example: from typing_extensions import Protocol, runtime_checkable @runtime_checkable class Foo(Protocol): def foo(self) -> int: raise NotImplementedError @Foo.register class Bar: # This class does not conform to the 'Foo' interface but we register it nevertheless. def bar(self) -> int: return 1 print(isinstance(Bar(), Foo)) # True print(issubclass(Bar, Foo)) # True Here both checks, instance and subclass, pass which suggests that the default behavior has been overridden by `(a)Foo.register`. However when using a `Protocol` with non-method members the [sanity checks](https://github.com/python/cpython/blob/aa909b6b1242b4969b20bb0250ac… still seem to take precedence: @runtime_checkable class Foo(Protocol): foo : int @Foo.register class Bar: # This class does not conform to the 'Foo' interface but we register it nevertheless. bar = 1 print(isinstance(Bar(), Foo)) # True print(issubclass(Bar, Foo)) # TypeError: Protocols with non-method members don't support issubclass() This produces a `TypeError: Protocols with non-method members don't support issubclass()` for the subclass check. Since for the methods-only-members case (and for the instance checks) `register` allows us to register subtypes completely at will it feels strange that for the non-methods-members case `Protocol` claims to know better and intercepts this attempt. Am I mistaken here or should the subclass check prefer the `ABCMeta` behavior over the custom checks implemented by `Protocol`? The current behavior seems asymmetric for methods-only and non-methods members protocols.

2 1

Discussions-To PEP-0604: Explore extensions of isinstance() and issubclass()
by Philippe Prados 04 Oct '19

04 Oct '19

Hello everybody, After the previous discussions, a new simplified version of PEP-0604 <https://www.python.org/dev/peps/pep-0604/> was published. I propose to add a similar syntax of Scala 3 <https://dotty.epfl.ch/docs/reference/new-types/union-types.html> in Python, to accept an or operator. # Operator for Union assert( int | str == Union[int,str]) The isinstance() and issubclass() were extended to accept this new syntax: isinstance(int, int | str) *It's not really explored.* To accept this evolution, the object Union (and dependencies) now be available as a builtin. Your remarks are welcome. Philippe

4 8

Discussions-To PEP-0604: Complementary syntax for Union[] and Optional[]
by Philippe Prados 01 Oct '19

01 Oct '19

Hello everybody, I just publish the PEP-0604 <https://www.python.org/dev/peps/pep-0604/> for discussions (https://www.python.org/dev/peps/pep-0604/). Scala 3 propose a new syntax for Union type. See here <https://dotty.epfl.ch/docs/reference/new-types/union-types.html>. I propose to add a similar syntax in Python. # Operator for Union assert( int | str == Union[int,str]) assert( int | str | float == Union[int,str,float]) # Operator for Optional assert( ~int == Optional[int]) Now, it's possible to write: def fn(bag:List[int | str], option: ~int = None) -> float | str: ... in place of def fn(bag:List[Option[int,str]], option: Optional[int] = None) -> Union[float,str]: ... The discussion on python-new(a)python.org here <https://mail.python.org/archives/list/python-ideas@python.org/thread/FCTXGD…> have emerged the idea of extending also issubclass() and isinstance(). isinstance(int, int | str) I think these syntaxes are more clear, and can help with the adoption of typing. I test and implement these ideas in a two fork : One for CPython <https://github.com/pprados/cpython/tree/updage_isinstance> and one for MyPy <https://github.com/pprados/mypy/tree/add_INVERT_to_types>. See the branches add_OR_to_types (for Union syntax), add_INVERT_to_types (for Union and Optional syntax) or updage_isinstance (for new isinstance() and issubclass()). How I implement that ? I add the operators __or__ and __revert__ to PyType_Type. The C code is similar of : from typing import * def type_or(self,right): return Union[self,right] type(type).__or__ = type_or with some check before return Union. Actually, the accepted BNF syntax for typing is : annotation: name_type name_type: NAME (args)? args: '[' paramslist ']' paramslist: annotation (',' annotation)* [','] I propose to extend the BNF syntax to : annotation: ( name_type | or_type | invert_type ) name_type: NAME (args)? args: '[' paramslist ']' paramslist: annotation (',' annotation)* [','] or_type: name_type '|' annotation invert_type: '~' annotation Your remarks are welcome. Philippe Prados

10 27