Updating the Typing Meetup date to Wednesday as there were some conflicts.
Let me know if there are any major time conflicts.
*Wednesday, November 03, 2021.*Time: 10 am San Francisco time (UTC-7) / 5
pm London time (UTC)
Duration: 1 hour
Potential discussion topics:
+ Typing **kwargs using a TypedDict (Franek Magiera?, Pradeep) 
+ Remaining questions about Callable syntax (Steven)
+ Non-required Protocol fields (Sebastian Rittau?) 
+ Type support for sealed classes (Adrian Freund?) 
+ Safe, typed JSON validation
+ Type system documentation (Shannon?)
If you're working on these or any other topics and would like to start a
discussion at the meetup, reach out to me.
If you have interesting topics you'd like to see discussed, share them too.
Once we have topics, we can always start a discussion even if there's no
proposer yet. We will probably have time for 3-4 topics in this session.
On Fri, Oct 15, 2021 at 12:55 PM S Pradeep Kumar <gohanpra(a)gmail.com> wrote:
>>>> Hello all,
>>>> We plan to hold a virtual Typing Meetup to discuss key typing-related
>>>> issues in real-time. The idea is that we can make progress on important or
>>>> controversial discussions, get early feedback on in-progress PEPs, and
>>>> gauge interest in new proposals.
>>>> A virtual meetup will be more accessible to people in other timezones
>>>> than Bay Area in-person meetups. It should also help consolidate
>>>> discussions that are often spread out across mailing lists or Github repos.
>>>> The tentative plan is to have a monthly meetup, but we can change that as
>>>> Date: Monday, November 01, 2021.
>>>> Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC)
>>>> Duration: 1 hour
>>>> Time and date are flexible. I'll share the zoom link and agenda the
>>>> week before. I'll also record the meetup and share afterwards.
>>>> If you're interested in presenting a new proposal or your work on some
>>>> existing proposal, please respond here. We can shoot for 15 minutes per
>>>> presentation. I know there are quite a few interesting threads on
>>>> typing-sig that haven't seen much activity in a while :)
>>>> S Pradeep Kumar
>>>> Typing-sig mailing list -- typing-sig(a)python.org
>>>> To unsubscribe send an email to typing-sig-leave(a)python.org
>>>> Member address: guido(a)python.org
 Typing **kwargs using TypedDict:
 Non-required Protocol fields:
 Sealed classes:
S Pradeep Kumar
Hello everybody :-)
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:
T = typing.NewType('T', int)
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!
I would like to draft a PEP for a typing.Self class which would perform similarly to rust's Self keyword in function annotations.
from typing import TypeVar
F = TypeVar("F", bound="Foo")
def parse(self: F, data: bytes) -> F:
from typing import Self
def parse(self, data: bytes) -> Self:
Another example of where this could be useful is classmethods:
def bar(cls: type[F], *args: Any, **kwargs: Any) -> F:
def bar(cls, *args: Any, **kwargs: Any) -> Self:
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.
I was thinking about Joren Hammudoglu's proposed pep adding `+T`/`-T`
syntax for TypeVar variance and had a crazy idea: what if we had syntactic
support for other kinds of TypeVar customization too?
For bounds we could overload the <= operator:
from typing import TypeVar, SupportsAbs
T = TypeVar("T")
def largest_in_absolute_value(*xs: T <= SupportsAbs[float]) -> T:
return max(xs, key=abs)
And for value restrictions we could use `in`:
def concat(x: T in (str, bytes), y: T) -> T:
return x + y
(Examples taken from https://mypy.readthedocs.io/en/stable/generics.html)
The first use of the TypeVar in the function definition would have the
bound or constraints, and other uses would then follow the constraint set
in the first use. Using in or <= on the same TypeVar more than once in a
function definition is an error.
The nice thing about this syntax is that it puts all the information about
the function definition in one place. You no longer have to create a named
(and usually awkwardly named) TypeVar for each possible bound.
The syntax is reminiscent of that used in languages like Scala and
TypeScript, although in those you would write something like `def
largest_in_absolute_value<T <= SupportsAbs[float]>(*xs: T) -> T:`, which
would require new syntax in Python.
I'm curious if other people think this would be a useful enhancement to the
Regardless of whether we pick shorthand, longhand or hybrid form, we need
to decide on what the repr() of such an object would be. E.g. in an
interactive session, if I print a callable type object, what will it print?
>>> a = (int, int) -> int
(int, int) - int
(__0: int, __1: int, /) -> int
callable[[int, int], int]
<callable: (int, int) -> int>
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
In the last tensor typing meeting we realised there's something missing
from PEP 646: the ability to split off suffixes from *args. (Thanks for
Pradeep for pointing this out, based on discussions with Eric Traut and
this question on python-dev
To recap, PEP 646 allows us to bind the types of *args into a TypeVarTuple:
Ts = TypeVarTuple('Ts')
def foo(*args: *Ts): ...
foo(1, '2') # Ts is bound to Tuple[int, str]
But what if we wanted to do something like the following?
*args: [types of all positional args but the last bound to Ts; type of
last positional arg should be int]
) -> Tuple[*Ts]: ...
x = foo(True, 1.0, 2) # x should have type Tuple[bool, float]
You might think the answer is:
) -> Tuple[*Ts]: ...
But note that this means something different; all arguments after *args
must be specified as keywords:
> foo(True, 1.0, 2)
TypeError: foo() missing 1 required keyword-only argument: 'final_arg'
Note that this is an only an issue for suffixes of variadic argument lists;
prefixes are fine:
) -> Tuple[*Ts]: ...
We think the way of encoding what we want most consistent with the rest of
PEP 646 would be something like:
*args: *Tuple[*Ts, int],
) -> Tuple[*Ts]: ...
Why? Well, when we say `*args: *Ts`, we're saying "Put all the types of
`args` into the thing that comes after the starred part of the annotation".
So here, we're saying "Put all the types of `args` into Tuple[*Ts, int]" -
that is, doing some pattern matching, "Put all types but the last into
This is (for me) an unintuitive enough construction that I think our first
question should be, does this have plausible enough use cases to support
The only one I can think off of the top of my head is something like:
def log_with_logger(*args: *Tuple[*Ts, Logger]): ...
log_with_logger('foo', 'bar', logger_inst)
But here the issue could be worked around by just moving the position of
the logger argument:
def log_with_logger(logger: Logger, *args: *Ts): ...
So I'm not sure I really believe this example.
Can anyone else think of any use cases for this?
Hi typing folks,
I'm continuing to pursue adding a tool for defining sentinel values to the
standard library. See PEP 616 , previous discussion  and previous
thread on this mailing list , for more background and details.
The gist of the proposal is to add a function or class, e.g. Sentinel(),
for defining sentinels in a standard way, providing nice properties such as
clear reprs, support for strict type signatures and surviving
MISSING = object()
MISSING = Sentinel("MISSING")
Besides allowing use in the stdlib, having this be defined in a PEP and
included in the stdlib means that we can agree how static type analysis
would handle such sentinels.
So here are some questions, where I especially would like input from people
implementing static type analyzers:
1. The PEP currently suggests using Literal[MISSING] in type signatures. Is
this reasonable? What would this require of static type analyzer authors
2. What would the type signature used during definition look like? I
couldn't be MISSING: Literal[MISSING] = Sentinel["MISSING"], right? Would
just using MISSING = Sentinel("MISSING") be fine, relying on type
inference? I assume this would require special-casing in type checkers?
3. How does Final play into this? Note that the currently proposed
implementation does NOT require that the variable name be identical to the
string passed to Sentinel, nor that the Sentinel object can be found using
the given name in the module's namespace in order for copying/unpickling to
work. Is this reasonable or should it be changed?
I'd like to add 1-2 paragraphs about type checking to the PEP, addressing
the above, and anything else you think is important to have well defined.
- Tal Einat
We plan to hold a virtual Typing Meetup to discuss key typing-related
issues in real-time. The idea is that we can make progress on important or
controversial discussions, get early feedback on in-progress PEPs, and
gauge interest in new proposals.
A virtual meetup will be more accessible to people in other timezones than
Bay Area in-person meetups. It should also help consolidate discussions
that are often spread out across mailing lists or Github repos. The
tentative plan is to have a monthly meetup, but we can change that as
Date: Monday, November 01, 2021.
Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC)
Duration: 1 hour
Time and date are flexible. I'll share the zoom link and agenda the week
before. I'll also record the meetup and share afterwards.
If you're interested in presenting a new proposal or your work on some
existing proposal, please respond here. We can shoot for 15 minutes per
presentation. I know there are quite a few interesting threads on
typing-sig that haven't seen much activity in a while :)
S Pradeep Kumar