Mailman 3 September 2021 - Typing-sig

typing-extensions/backport: Dropping support for Python 2.7, 3.4, and 3.5
by Sebastian Rittau 09 Sep '21

09 Sep '21

We plan to drop support for Python 2.7, 3.4, and 3.5 for typing-extensions. [1] These Python versions have reached end-of-life for at least a year and tooling starts to be a problem. The Python 2 version of the library already has some omissions compared to the Python 3 version. Older versions (up to 3.10.0.2) will remain available for these Python versions. We also plan to drop the typing backport for Python 2.7 and 3.4. [2] This is what later became the typing module in Python proper. The Python 2 module had its last commit in 2019 and the Python 3 module was made obsolete with the introduction of typing in Python 3.5. Of course, old packages will remain available, but we will make no new releases. If you have any concerns, please voice them either here or in the linked GitHub issues. - Sebastian [1] https://github.com/python/typing/issues/867 [2] https://github.com/python/typing/issues/877

1 0

Viability of letting TypedDict classes inherit from Generic without a PEP change
by isamodya＠gmail.com 09 Sep '21

09 Sep '21

Hello typing-sig, I have started couple of threads before about adding `Generic` support for `TypedDict`. But this thread is specifically to get an idea about the viability to let `TypedDict` classes inherit from `Generic` **without a PEP change**. Specifically the impact on type checker implementations. The discussion was started in https://bugs.python.org/issue44863 (and associated PR: https://github.com/python/cpython/pull/27663). Copied (with minor edits) my reasoning from https://bugs.python.org/issue44863 :: TypedDict PEP-589 says: A TypedDict cannot inherit from both a TypedDict type and a non-TypedDict base class. So the current run time implementation has: `if type(base) is not _TypedDictMeta: raise TypeError(...)` This restricts the user from defining generic TypedDicts in the natural class based syntax: `class Pager(TypedDict, Generic[T]): ...` Although PEP 589 doesn't explicitly state generic support. I believe it is complete in covering all semantic details even with Generics. Even structural subtyping because it says: "Value types behave invariantly, since TypedDict objects are mutable." I have tried putting together a PEP from guidance of typing-sig <https://github.com/sransara/py-generic-typeddict/blob/master/pep-9999.rst>. There is not much new contributions by that draft, except for specifying the alternative syntax and being more explicit about Generics: 1. relaxing this line from PEP-589 and be explicit to include Generic: "A TypedDict cannot inherit from both a TypedDict type and a non-TypedDict base class." (IMO by thinking `Generic` as a mixin even this is not needed) 2. may be syntax for generic in the alternative syntax (side note: collecting typevars from the values is hard to implement because of forward refs) 3. Some explicit generic examples for good measure So I'm wondering if it would be possible to relax the constraint: TypedDict inheritance to include Generic. In my point of view `Generic` is more of a mixin, so it doesn't go against the PEP 589. Or is this change really big enough to warrant a new PEP or PEP update? My understanding was that during initial implementation this was not done for the sake of implementation simplicity (days before PEP-560). All that said, a new PEP would be a good way to notify the type checkers of this capability. Please let me know your thoughts.

2 1

Definition-site variance for TypeVar
by Sergei Lebedev 07 Sep '21

07 Sep '21

Hi everyone, Type variables allow to specify their variance at construction time, i.e variance is currently a property of a type variable. This is problematic for cases when a type variable is used outside of a generic class. For example, T_co = TypeVar("T", covariant=True) def callback(value: T_co): ... or ListT = list[T_co] I am curious, if we could instead deprecate the variance parameters and make variance local to the generic class definition. Specifically, * all type variables are created invariant; * a type variable can be annotated as covariant and contravariant using unary + and - operators respectively; * these operators are only allowed when a type variable is referenced in the bases of a class definition. For example, here T = TypeVar("T") class Source(Generic[+T]): ... the class Source is covariant in T. Wdyt? Sergei

2 1

Re: Definition-site variance for TypeVar
by Gobot1234 07 Sep '21

07 Sep '21

There is a pep currently being written to support this, go to https://github.com/python/typing/issues/813 for the discussion about this.

1 0

How to extend Type or how to type a wrapper class
by Patrick Arminio 05 Sep '21

05 Sep '21

Hi everyone! I'm trying to type a decorator that returns a Wrapper class of another class. The idea is that I have a wrapper class that only adds a couple of properties to the original class, something like this: ```python from typing import Type, TypeVar, Generic _T = TypeVar("_T") class Wrapper(Generic[_T]): wrap: Type[_T] enhanced: bool = True def __init__(self, cls: Type[_T]) -> None: self.wrap = cls def __call__(self, *args, **kwargs): ... def enhance(cls: Type[_T]) -> Type[_T]: return Wrapper(cls) # type: ignore class X: ... EnhanceX = enhance(X) reveal_type(EnhanceX) reveal_type(EnhanceX.enhanced) ``` The user using the class doesn't really need to know that it has been "enhanced", as it should work as it was before. My initial idea was to extend `Type` from typings, but that's not possible. What would you suggest to do here? Should I type all the methods on `Wrapper` to basically behave as if they were from `self.wrap`? not sure if that's actually possibile There's also a possibility where I'm doing something silly with what I'm trying to do, but it should make sense for my use case 😊

2 1