Mailman 3 November 2019 - Typing-sig

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 May 31, 2020

May 31, 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 3, 2020

March 3, 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

Wintel Engineer jobs
by ravi fieldengineer Jan. 26, 2020

Jan. 26, 2020

When PCs or laptops based on the Intel microprocessor run a Microsoft Windows operating system, we generically refer to such architectures as Wintel. People who work in such environments by supporting users and resolving their issues are Wintel Engineers. These engineers configure and install all server hardware, including the Windows OS and products procured from third-parties, onto the systems. They build, configure, assess, and recommend hardware and software. They should possess above average analytical and fixing skills. Engineers own and run an issue with minimal intervention from others ensuring all relevant parties are informed on time. More info : https://www.fieldengineer.com/skills/wintel-engineer

2 1

PEP 589: no way to tell if a key is optional at runtime?
by Zac Hatfield-Dodds Nov. 17, 2019

Nov. 17, 2019

Hi All I'm a core developer of Hypothesis, and largely responsible for our `from_type()` strategy. As the name suggests, it takes a type and returns an object that can generate instances of it, including for things in the `typing` module that aren't really types at runtime. So far, so good! For obvious reasons, I'm looking to support TypedDict too, but I've run into a snag: I can't see any way to distinguish between optional and required keys at runtime! It's not actually *incorrect* to treat all keys as required, but we'll miss test cases that could have exposed real bugs. Consider the following cases: ```python class A(typing.TypedDict): a: int # a is required class B(A, total=False): b: bool # a is required, b is optional class C(B): c: str # a is required, b is optional, c is required again ``` The PEP is clear about the semantics, and this is obvious enough when reading the code. At runtime the __annotations__ attribute of each class gives us the set of allowed keys and the type of each corresponding value, but we have a problem: - C has __total__==True, but b is not actually required. - B has __total__==False, but a *is* required. - I can't see any way to get the parent classes of a TypedDict class! The _TypedDictMeta metaclass updates the attributes, but leaves no record of the parent type - at runtime A, B, and C all appear to inherit directly from dict. Is there a way to directly determine which keys are required and which are optional at runtime? If not, is there a way to determine the parent class(es) of a TypedDict? If not, can we please add one - preferably the former - for 3.8.1? If there's an agreed design I'd be happy to implement it - as a concrete suggestion, I'd add two frozensets, __required_keys__ and __optional_keys__. Obvious, useful, orthogonal to current attributes, and easy to fall back to treating all keys as required. Best, Zac Hatfield-Dodds

3 2

Want to Contribute to Numpy (Dependent) Types
by Teddy Liu Nov. 12, 2019

Nov. 12, 2019

Hi! I'm a student at Harvard studying CS right now. For my thesis, I'm really interested in adding types to numpy as well as general capabilities for extending the Python system with "dependent" types. I want to add the feature of statically determining the alignment of array dimensions. Let me know how I can get started on this project! Sincerely, Teddy

4 5

PEP 585
by Nils Kattenbeck Nov. 11, 2019

Nov. 11, 2019

Hello, after being told in issue 38756 of the python bug tracker that PEP 585 will add generic typing to many standard collections/containers I looked at which types will get generic versions. I noticed that collections from weakref were not included (WeakDictionary, WeakSet etc). WeakKeyDictionary and WeakValueDictionary should probably automatically be generic as they extend _collections_abc.MutableMapping but WeakSet does not. Would it be possible to clarify that WeakDictionaries or subclasses in general will become generic but more importantly I think it should be worth considering add WeakSet to the PEP I would like to hear your thoughts on this topic... Greetings Nils Kattenbeck

3 2

Add a new Chr type to typing.
by Brandt Bucher Nov. 10, 2019

Nov. 10, 2019

Whelp, this one bit me again today, so I finally decided to come forward with a concrete proposal: how to handle the fact that strings are themselves sequences of length-one strings. I know that this has been discussed at some length, but most of the other proposals I've found are a bit too complicated for the relative simplicity of the problem. My proposal is to add a public `Chr` type to the `typing` module, defined as `Chr = NewType("Chr", str)`. That's it. typeshed will be modified to type `str` as a `Sequence[Chr]`, rather than a `Sequence[str]`. Other parts of typeshed (`builtins.ord`, `builtins.chr`, `os.sep`, and `os.pathsep` are a couple that come to mind) can be updated as well with either the new `Chr`, or something like `TypeVar("Str", Chr, str)`. The beauty of this is proposal is that type checkers will be able to properly check the `str`/`Chr` relationship without any additional special handling (beyond that already required for `str` types). While they have the option of being stricter (for example, issuing warnings when a `Chr` is used as a `str`), the type system does not require it, because it mirrors the reality that at runtime, a `Chr` is just a special-case of `str`. I know it's not perfect, but it certainly seems better than the status quo. I just thought that I would start here to gather feedback, and see if anybody is interested in co-sponsoring a more formal proposal. Brandt

4 6

spambots have found the list - lock it down?
by Gregory P. Smith Nov. 7, 2019

Nov. 7, 2019

Can the typing-sig list owners lock the list down to not allow non-subscribers to post? and if those spambots were subscribed, require moderation for the first couple posts from new members? (I don't know what options mailman3 provides or who owns the list - it won't tell me :) -Greg

3 2

What to do with "Describe a way of annotating decorated declarations"
by Guido van Rossum Nov. 7, 2019

Nov. 7, 2019

There's a PR for PEP 484 in the peps repo that has quite a bit of discussion in it: https://github.com/python/peps/pull/242 The basic idea is to have a way to declare the type of a decorated function *after it's been decorated*, to serve as either documentation or a type hint in the case the decorator is untyped. This is the full text of the paragraph that's being proposed as an addition to PEP 484: Decorators ---------- Decorators can modify the types of the functions or classes they decorate. Use the ``decorated_type`` decorator to declare the type of the resulting item after all other decorators have been applied:: from typing import ContextManager, Iterator, decorated_type from contextlib import contextmanager class DatabaseSession: ... @decorated_type(Callable[[str], ContextManager[DatabaseSession]]) @contextmanager def session(url: str) -> Iterator[DatabaseSession]: s = DatabaseSession(url) try: yield s finally: s.close() The argument of ``decorated_type`` is a type annotation on the name being declared (``session``, in the example above). If you have multiple decorators, ``decorated_type`` must be topmost. The ``decorated_type`` decorator is invalid on a function declaration that is also decorated with ``overload``, but you can annotate the implementation of the overload series with ``decorated_type``. This has been a "Work in Progress" PR since 2017. There are 40 comments but the last one is over two years old. I'm not sure that anybody really cares that much about this problem any more. Maybe we should just close it? Thoughts? -- --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