Mailman 3 November 2021 - Typing-sig

PEP 613 and type aliases in nested scope
by Shantanu Jain Nov. 20, 2021

Nov. 20, 2021

Hello everybody :-) Linking https://www.python.org/dev/peps/pep-0613/#scope-restrictions PEP 613 appears to disallow explicit type aliases in nested scopes: > With explicit aliases, [...] the inner assignment can either be a valid local variable or a clear error [...] It also maybe seem to not allow for the possibility of type aliases in nested scope at all: > [...] because type aliases cannot be defined inside a nested scope If this was the intention of the PEP, this restriction feels unnecessary to me. Type aliases in nested scope are a valid use case. mypy previously never considered assignments in nested scopes to be type aliases, and we've had multiple issues concerning this. Eric mentioned that as a result of this wording, Pyright errors for explicit type aliases in nested scope, but allows implicit type aliases. I propose we loosen the wording in PEP 613. If type checkers don't wish to add support for type aliases in nested scope that seems fine, but I see no reason to prohibit this via PEP. The following code seems very clear to me in its intention (as a result of PEP 613!) and type checkers should be free to follow that intention: ``` import typing T = typing.NewType('T', int) class C: V: typing.TypeAlias = T x: C.V = C.V(5) ``` Conversely, if this proves controversial and we decide we do actually want to prohibit type aliases in nested scopes, we should probably amend PEP 484 to mention this. Thanks to Nipunn for bringing this up!

5 12

Dataclass Transform
by Eric Traut Nov. 19, 2021

Nov. 19, 2021

A while back, I posted a draft proposal for a new typing construct called `dataclass_transform`. Here's a link to the full spec: https://github.com/microsoft/pyright/blob/main/specs/dataclass_transforms.md I released a reference implementation in pyright. A couple of popular libraries (`attrs` and `pydantic`) have provisionally adopted it. Several other use cases for it have also been proposed, including support for dataclass decorator aliases, discussed in this mypy issue thread: https://github.com/python/mypy/issues/5383. I'm interested in opinions from the broader typing community. Is there enough interest to justify a formal PEP and moving it through the standards process? I'd be happy to present the proposal in the next Typing Meetup if there are available slots. -- Eric Traut Contributor to Pyright & Pylance Microsoft

2 1

Introducing support for Intersection
by Patrick Arminio Nov. 17, 2021

Nov. 17, 2021

Hi folks! I'm sending this email because I'd love to work on introduction support for Intersection to python's typing capabilities. I'd love to know if someone is already working on this and if not, I'd like to try and work on it, but I'd need some support if possible ^^ I've sketched out a basic plan[0], basically the initial idea is to write an initial PEP based on the discussion[1] around typing.Intersection, make a prototype implementation and then try to get feedback on the PEP and implementation. Does that make sense? Would someone be able to help me with this? And, again, if someone is already working on this, let me know, I'm ok with that too :D [0] My rough plan and basic notes: https://hackmd.io/0ymmrUtGTG-CEiw32qVfiQ [1] Issues regarding typing.Intersection: https://github.com/python/typing/issues/213

5 6

Re%3A Want to work on Pylance%3F&In-Reply-To=<11D68351-38C7-4EB4-A8EA-79522F7057F8%40microsoft.com>
by Angelo Kontaxis Nov. 16, 2021

Nov. 16, 2021

Hi Graham, i would possibly be interested in the position, are there any further requirements for the position, i presume a knowledge of typescript, python and static typing is needed at the very least. Thanks, Angelo

1 0

Where to discuss typing features
by Sebastian Rittau Nov. 15, 2021

Nov. 15, 2021

Background Historically, new typing features were discussed on the issues of the GitHub typing repository (https://github.com/python/typing/issues). After typing-sig was started, discussion about new features was supposed to shift there, but there are multiple issues with using a mailing list: * It doesn't offer the same features as other, markdown-based discussion forums offer, e.g. code formatting and syntax highlighting. * It's hard to have long-running discussions. In the issues we have some proposals that are several years old, but still sensible, and still get occasional comments. * It's impossible to "close" suggestions and get a list of "still open" proposals. Proposal and Alternatives I propose to go back to using the GitHub issues for ideas and discussions about new typing features. typing-sig can still be used for announcements, discussions about concrete proposals (e.g. for PEP feedback) and for other typing issues. I strongly suggest that we don't use a third place for these kinds of discussions. * typing issues are established. We still get regular new issues suggesting new features, which indicates that the typing repository can be found. Even if we moved somewhere else, we would need to redirect these people there (as we did with redirecting people to typing-sig), creating extra workload. * These are lots of existing and useful discussions already in the typing issues. They would either need to be moved or recreated in the new place. Existing crosslinks would get lost. * I don't think "discussions"-style forums like GitHub Discussions or Discourse lend themselved well to feature requests, as they are more geared to open ended discussions or Q&A: o While the thread format can be useful from time to time, usually in these discussions a chronological order makes more sense as discussions evolve. Especially in GitHub Discussions, each top-level "answer" stands out as its own thing, which itself has responses. Order of the answers (but not the responses) can be affected by voting. o While there are ways to mark a thread as "resolved" in GitHub Discussions, this is more geared towards Q&A formats. Usually there is no easy way to filter by unresolved issues. Often, the creator of a thread can mark a thread as "resolved". The ability to mark an answer an "accepted" also makes no sense. o Discussion threads are not as easily linkable as issues, and cross-referencing threads is harder. There are no automatic back-links from other issues and git commit AFAIK. It also does have no built-in support for "meta" issues Possible Issues The typing issues have lots of old, outdated discussions, so some people suggested a fresh start. Another problem is "notification overload". The typing repository is also used for typing-extensions and the typing documentation. Subscribing to the repo means you get notifications for all these issues as well. Implementation I propose to do the following to the typing issues: 1. Add a new label "feature" for feature discussions. 2. Add issue templates for new features (and a few other issue types) so that the correct label gets applied automatically. 3. I volunteer to do housekeeping and go through the old issues in the typing repository, closing out outdated ones and applying the proper labels. 4. As a first step, set up a bot that sends a weekly(?) mail to typing-sig with the titles and links to new feature issues and a list of feature issues that got new comments since the last mail. 5. See how that works out. This plan has the advantage of mostly keeping the status quo, just in a cleaner manner, instead of trying out something new and then potentially having to revert that if it turns out to be inadequate. (And then have three places where suggestions have been made.) Please let me know your thoughts. - Sebastian

4 9

Opened and changed typing issues week 2021-W45
by Typing Bot Nov. 15, 2021

Nov. 15, 2021

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were opened last week: #928 Add a `import type` feature (like typescript) opened by @KotlinIsland https://github.com/python/typing/issues/928 #930 Request: an AssertingTypeGuard type for TypeGuard-like semantics opened by @sirosen https://github.com/python/typing/issues/930 --------------------------------------------------- The following issues and pull requests were updated last week: #182 Define a JSON type opened by @brettcannon https://github.com/python/typing/issues/182 #802 Wrapper/Proxy Generic Type opened by @hatal175 https://github.com/python/typing/issues/802 #926 Change PEP 647 to allow for narrowing in the negative case opened by @Zomatree https://github.com/python/typing/issues/926 --------------------------------------------------- All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

Announcement: typing-extensions 4.0.0 has been released
by Jelle Zijlstra Nov. 14, 2021

Nov. 14, 2021

I just released typing-extensions 4.0.0. Highlights include: - Support for Required/NotRequired (PEP 655) and Self (PEP 673) - Dropped support for Python 2.7 and 3.5 - Switch to semantic versioning

1 0

Typing :: typed classifier
by rakshith.bhyravabhotla＠gmail.com Nov. 5, 2021

Nov. 5, 2021

Hi, What are the implications of using a Typing :: typed classifier? Is it simply "the package has typing"? Or does it have a more extensive implication?

1 0

Thoughts on a typing.Self?
by gobot1234yt＠gmail.com Nov. 2, 2021

Nov. 2, 2021

I would like to draft a PEP for a typing.Self class which would perform similarly to rust's Self keyword in function annotations. Examples ```python from typing import TypeVar F = TypeVar("F", bound="Foo") class Foo: def parse(self: F, data: bytes) -> F: ... return self ``` vs ```python from typing import Self class Foo: def parse(self, data: bytes) -> Self: ... return self ``` Another example of where this could be useful is classmethods: ```python class Foo: @classmethod def bar(cls: type[F], *args: Any, **kwargs: Any) -> F: return cls() ``` vs ```python class Foo: @classmethod def bar(cls, *args: Any, **kwargs: Any) -> Self: return cls() ``` Implementation wise it would be a copy of NoReturn, i.e. not subscriptable, a _SpecialForm and should only be valid as a return type. I haven't seen any discussion of the idea on the mailing list, so I wanted to run it by everyone. Thanks, James.

12 27

Want to work on Pylance?
by Graham Wheeler Nov. 1, 2021

Nov. 1, 2021

Hi all It looks like we may have a position opening up on the Pylance team at Microsoft. Seems like no better place to look for possible candidates than over in this SIG, especially as the ideal candidate is someone who can participate in the discussions in this SIG in a meaningful way :-). If you have any interest, please reach out to me directly so we can chat. Thanks Graham

1 0