Mailman 3 March 2019 - Typing-sig

Please register for the PyCon typing summit

by Guido van Rossum

With Ewa's and Dropbox's help I've arranged a room at PyCon for the typing summit. *When: Thursday May 2nd, 1-5 pm* *Where: Room 6 at PyCon in Cleveland* If you're planning to attend, please fill out this form: https://goo.gl/forms/rG9dVTBbgyBgDK8H2 *If you already emailed me about attending, please still fill out the form!* In a few days I'll send the same info to python-dev -- make sure to reserve your space now! -- --Guido van Rossum (python.org/~guido)

2 years, 9 months

1
1
0 0

PEP 586 Discussion

by Mark Mendoza

Moving discussion from https://github.com/Michael0x2a/peps/pull/1 as requested @Michael0x2a Sorry, missed that response, Github's threading confuses me sometimes :). I think you just about captured my concern, which was that you would have something like this ``` from typing import TypeVar, Generic from typing_extensions import Literal, Final T = TypeVar("T") class G(Generic[T]): ... def foo(x: T) -> G[T]: ... def takesGOfInt(x: G[int]) -> None: ... def takesGOfLiteral7(x: G[Literal[7]]) -> None: ... def bar() -> None: x = foo(7) # 7 inferred to be Literal[7], typevar rules means that returns G[Literal[7]] reveal_type(x) # should this be G[Literal[7]] or G[int]? # arbitrarily far later takesGOfLiteral7(x) # error here? takesGOfInt(x) # or here? ``` Mypy currently (0.670) errors on `takesGOfLiteral7` which seems to violate the idea that literals are just another subclass of int etc. I'm not sure that we'd want to force this behavior in the spec, as it seems to necessitate having inference depend on the type of the parameter it's called on, which can get confusing quickly (especially with overloads etc.). There seems to be an inherent tension between two goals of the spec, having Literals be just like any other subclass of int (or string etc.) and having backwards compatibility in all cases. Is there another way to avoid that spec-wise other than removing the hard requirement of maintaining backwards compatibility in all cases? - Mark Mendoza

2 years, 9 months

3
4
0 0

Yet another Python type checker: pyright

by Gregory P. Smith

https://github.com/Microsoft/pyright / https://news.ycombinator.com/item?id=19473631 (odd that the announcement wasn't cc'd here?)

2 years, 10 months

1
0
0 0

notes on aliases

by Michael Sullivan

I was asked to write up some notes on what was discussed regarding aliases at the meetup the other week. Here is my best recollection of the salient points: --- The pyre team wants a more syntatically distinguished way to declare type aliases, for typechecker performance reasons. Łukasz Langa will be proposing (in a draft pep), syntax like `Foo: Alias[Bar]`. This has the advantages that (when using from __future__ import annotations) it needn't be executed and the names don't need to be imported at runtime. It has the disadvantage that such an alias can't be used in situations where a runtime type is actually required, such as using it as a base class (including as a type argument). It is also (in my opinion, at least) uglier. Another option brought up is `Foo = Alias[Bar]`. This can be implemented to allow using it as a base type, etc. One hiccup in this planning is that the current type alias syntax is in PEP 484 and widely used. It could be deprecated, but I think it is unlikely that mypy will drop support it? -- One thing that adding an explicit syntax for declaring aliases will allow us to do is create syntax for declaring a generic type alias that does not use all its type variables, or that uses them in a different order than they appear in the aliased type. mypy currently supports an undocumented version of this, "FlexibleAlias". `Foo = FlexibleAlias[T, U, V, Bar]` creates a type alias Foo with type parameters T, U, and V and type Bar, regardless of which of those variables occur in Bar or in what order. Currently we use this in mypy to allow changing certain types to Any under certain configuration flags: T = TypeVar('T') if MYPYC: Bogus = FlexibleAlias[T, Any] else: Bogus = FlexibleAlias[T, T] -Michael Sullivan (sully)

2 years, 10 months

3
2
0 0

Invitation: Bay Area Typing Meetup Tue 3/12 1-5pm Google Sunnyvale

by Guido van Rossum

** PLEASE RSVP TO REBECCA CHEN (CC'ED TO THIS MESSAGE) ** We are having another Python Typing Meetup in the Bay Area. Everyone interested in static type checking for Python is invited, but we need to have an approximate guest list by 3/9 so our gracious host can make sure there's room for all. Anyone who would like to make a short presentation please send me your topic and the amount of time you expect to need, so I can create a draft agenda (this worked pretty well last time). Location: Google's TC3 building: https://goo.gl/maps/sxgWnUgC7jL2 Date/time: Tue March 12, 2019, from 1-5 pm Please arrive early to allow everybody to check in with Google's front desk -- --Guido van Rossum (python.org/~guido)

2 years, 10 months

6
8
0 0

Typing Summit at PyCon?

by Guido van Rossum

There's a lot of interesting material to discuss at PyCon, probably more than we can fit into a series of BoF meetings. How would people feel if we organized a typing summit at PyCon? The best time would be the day before the conference, i.e. the day after the language summit. I'd limit it to a half day (probably the afternoon so people can recover from travel). I haven't asked the PyCon organizers for a room yet, but I imagine we will be able to swing this -- I'm mostly asking who would actually show up. -- --Guido van Rossum (python.org/~guido)

2 years, 10 months

5
6
0 0

Bay Area Typing Meetup Planning

by Guido van Rossum

Hey Bay Area typing enthusiasts! (If you're not local please mute this thread.) Jukka and Ivan are going to be in town March 11-15. Like the last time they visited, it would be nice to have an in-person meeting with the pytype, pyre and mypy teams. Last time Dropbox hosted the meetup. We could probably host again, but perhaps another team wants to host this time? (IIRC the team at Facebook offered.) In terms of preferred dates, unfortunately Ivan has a flight that departs early Friday evening, so it would be better not to do this Friday afternoon; and I would prefer not to have it on a Thursday. That leaves Mon-Wed, or Friday morning. Who wants to host? -- --Guido van Rossum (python.org/~guido)

2 years, 10 months

4
11
0 0

2022

2021

2020

2019

2018

Typing-sig March 2019