Mailman 3 April 2019 - Typing-sig

PEP 591 discussion: final
by Michael Sullivan May 7, 2019

May 7, 2019

I've submitted PEP 591 to the PEPs repository. This PEP proposes a "final" qualifier to be added to the ``typing`` module---in the form of a ``final`` decorator and a ``Final`` type annotation---to serve three related purposes: * Declaring that a method should not be overridden * Declaring that a class should not be subclassed * Declaring that a variable or attribute should not be reassigned Discussion on the PEP happens here in typing-sig@. Minor things can be fixed directly as PRs. Here is the full PEP draft: https://www.python.org/dev/peps/pep-0591/ A reference implementation exists in mypy, whose documentation is here: https://mypy.readthedocs.io/en/stable/final_attrs.html (though the PEP takes precedence) -sully

4 10

Numerical stack proposal - how to follow its progress?
by Rebecca Chen May 1, 2019

May 1, 2019

Hello! I was wondering where work/discussion on the numerical stack type system improvements <https://paper.dropbox.com/doc/Type-system-improvements--AZLqIRRyLF5wU14B5le…> from the last typing meetup is happening. A couple of TensorFlow folks (cc'd) are looking to implement static checking of TensorFlow code and would like to explore whether it makes sense to align their efforts with the proposed type system changes. Specifically, they're interested in learning some details about how broadcasting and shape checking will be handled. Where should I point them for more information? Best, Rebecca

5 6

Type operators in Python
by Vincent Siles May 1, 2019

May 1, 2019

Hi ! I'm currently thinking on ways to improved numpy numerical stack typing (dtype mostly), when it comes to mixing the types. For example if you add an int32 to a float64, you'll get a float64. There is a quick and dirty way to deal with all this: use overloading, but I won't see it scaling at all (think pytorch / tensorflow that are using numpy dtypes and defining a ton of new functions). Also if we want to abstract over these dtype, for example with something like def my_add(x : dtype0, y: dtype1) -> ???: In this case, overloading won't help. So I was thining of maybe adding a type operator, something like def my_add(x: dtype0, y:dtype1) -> typing.numpy.join(dtype0, dtype1): I'm not sure that the right approach too, but since I'm new to python typing, I wondered if such "type" operators already existed in the wild ? Best, Vincent

2 1

Tentative program for the Typing Summit
by Guido van Rossum April 29, 2019

April 29, 2019

I've constructed a very tentative program for the Typing Summit at PyCon (Thursday 1-5pm). Here's the link: https://paper.dropbox.com/doc/Typing-Summit-Schedule--AcKOzMdYY4PzOt4dYxJ7J… If you're listed as a speaker, feel free to send me an update to your title, abstract, and/or requested time. If you're not listed but you'd like to speak, drop me a note. *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 -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

1 0

PEP 589 discussion: TypedDict
by Jukka Lehtosalo April 25, 2019

April 25, 2019

Hi everyone, I've submitted PEP 589 to the PEPs repository. This PEP proposes a new kind of type, TypedDict, for representing dictionaries with a fixed set of keys. These can be be used to represent JSON objects, for example. Discussion on the PEP happens here in typing-sig@. Minor things can be fixed directly as PRs. Here is the full PEP draft: https://www.python.org/dev/peps/pep-0589/ Mypy supports TypedDict and the relevant documentation may also be helpful (but the PEP takes priority over mypy documentation): https://mypy.readthedocs.io/en/latest/more_types.html#typeddict Jukka

2 1

Please register for the PyCon typing summit
by Guido van Rossum April 24, 2019

April 24, 2019

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)

1 1

Include docstrings in stubs?
by Matan Gover April 17, 2019

April 17, 2019

It seems that the status quo is to not include docstrings in type stubs. The type stub PEP draft [1] and typeshed contributing guidelines [2] explicitly say 'Do not include docstrings'. If docstrings are not included in stubs, tools/editors wishing to prove documentation in hovers and completions would still have to evaluate the code of the actual module (which might be a C module) and do non-standard merging between docs in *.py and types in *.pyi. This will make these tools slower and more difficult to implement. In order to improve code editing I suggest to allow or encourage the inclusion of docstrings in type stubs, perhaps also specifying a standardized format. In TypeScript, for example, documentation is often included in stubs, and has a standardized format [3]. What are your thoughts on the subjects? (Discussion moved from the PEP issue tracker [4].) [1] https://github.com/srittau/type-stub-pep/blob/5291660/pep-9999.rst [2] https://github.com/python/typeshed/blob/4cd9a8e/CONTRIBUTING.md [3] https://github.com/Microsoft/tsdoc [4] https://github.com/srittau/type-stub-pep/issues/38

2 3

PEP 586 Discussion
by Mark Mendoza April 16, 2019

April 16, 2019

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

3 4