Mailman 3 November 2019 - Typing-sig

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

Wintel Engineer jobs
by ravi fieldengineer 26 Jan '20

26 Jan '20

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 17 Nov '19

17 Nov '19

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 12 Nov '19

12 Nov '19

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 11 Nov '19

11 Nov '19

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 10 Nov '19

10 Nov '19

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 07 Nov '19

07 Nov '19

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 07 Nov '19

07 Nov '19

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

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

2022

2021

2020

2019

2018

Typing-sig November 2019