Mailman 3 October 2021 - Typing-sig

PEP 646: Type suffixes of *args
by Matthew Rahtz Oct. 25, 2021

Oct. 25, 2021

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 https://mail.python.org/archives/list/python-dev@python.org/thread/K76H6C5J… ) *Intro* 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? def foo( *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] *The problem* You might think the answer is: def foo( *args: *Ts, final_arg: int, ) -> 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: def foo( first_arg: int, *args: *Ts, ) -> Tuple[*Ts]: ... *Proposed solution* We think the way of encoding what we want most consistent with the rest of PEP 646 would be something like: def foo( *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 `Ts`". *Use cases?* 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 complexity? 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? --- Thanks! Matthew

3 5

Steering Council message
by Guido van Rossum Oct. 20, 2021

Oct. 20, 2021

This message from the SC to python-dev seems important to this community: https://mail.python.org/archives/list/python-dev@python.org/message/SZLWVYV… -- --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-…>

1 0

Static type checking for sentinel values (PEP 661)
by Tal Einat Oct. 19, 2021

Oct. 19, 2021

Hi typing folks, I'm continuing to pursue adding a tool for defining sentinel values to the standard library. See PEP 616 [1], previous discussion [2] and previous thread on this mailing list [3], 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 copying/unpickling. Old: MISSING = object() New: 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 and maintainers? 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 [1] https://www.python.org/dev/peps/pep-0661/ [2] https://discuss.python.org/t/pep-661-sentinel-values/9126 [3] https://mail.python.org/archives/list/typing-sig@python.org/thread/NDEJ7UCD…

6 10

Typing Meetup
by S Pradeep Kumar Oct. 15, 2021

Oct. 15, 2021

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 needed. 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

1 0

Next tensor typing meeting
by Matthew Rahtz Oct. 12, 2021

Oct. 12, 2021

Hi all, Our next tensor typing meeting is supposed to be next Monday (the 11th). There are no updates from my end this month (we're just waiting for PEP 646 to be re-reviewed by the steering council); does anyone else have something they want to present? Thanks! Matthew

2 3

Accept Final as indicating ClassVar for dataclasses
by Gregory Beauregard Oct. 10, 2021

Oct. 10, 2021

PEP 591 for Final states "Type checkers should infer a final attribute that is initialized in a class body as being a class variable. Variables should not be annotated with both ClassVar and Final." ClassVar is used to indicate library behavior in dataclasses. Therefore, I propose accepting the Final attribute as an indicator of a ClassVar in dataclass class bodies in order to be better compatible with the Final PEP. One edge case that would need to be handled is when someone might explicitly mark a dataclass field Final: a: Final[int] = dataclasses.field(init=False, default=10) Because it would change a library, I've opened an issue as well, but I'm copying here since it affects type checkers: https://bugs.python.org/issue45384 I appreciate your time, Gregory Beauregard

1 1

Meetup to discuss Callable Syntax
by S Pradeep Kumar Oct. 8, 2021

Oct. 8, 2021

Hello all, User-friendly Callable syntax is something we all want to see. However, there has been no real movement on the discussion in the last one month. People have had differing opinions based on design principles, stats, and personal experience. This has led to half a dozen proposals with some subtle and not-so-subtle differences [1]. And Guido pointed out that we want to settle on a full proposal instead of going for a partial PEP now and settling on the remaining details in a later PEP. How about we meet up over a zoom call and discuss some of the key concerns? Things proceed noticeably faster when people from the typing community are able to get in the same (virtual) room (I saw that with PEP 646 and the typing summit). We don't have to reach a consensus in the first meeting itself. It's more a way to break the deadlock and make progress. Date: 10 am San Francisco time (6 pm UK time), Monday, September 13, 2021. Date is flexible. Duration: 1 hour. If there is enough interest, I can set up the video call and share the link and agenda. If you're interested in presenting pros and cons for your favorite proposal, reply to this mail. [1]: Document containing the various proposals and use cases: https://docs.google.com/document/d/11VkNk9N8whxS1SrBv2BNN1Csl5yeTlgG7WyLrCB… -- S Pradeep Kumar

9 33

Making lengthy types legible in editors
by rsoklaski＠gmail.com Oct. 7, 2021

Oct. 7, 2021

I have encountered the following legibility problem in two libraries that I work on. I will: - describe the issue I am facing - ask for guidance - describe a hack that I have played with & my ideal-solution THE PROBLEM ----------- One of the parameters in my most used, user-facing functions has a "lengthy" annotation; e.g. _T = TypeVar("_T", bound=Callable) Wrapper = Callable[[_T], _T] ValidWrapper = A[Wrapper] | B[Wrapper] | C[Wrapper] | Wrapper | None | str def my_func(x: ValidWrapper | Sequence[ValidWrapper]): ... Viewing the signature of `my_func` in, via tooltip, in IPython, Jupyter, VSCode, or PyCharm reveals an absolute mess. Consider that A, B, and C are generics that are defined in a deeply-nested module of my library and their paths are included in the signature... You can see screenshots from these editors here: https://github.com/mit-ll-responsible-ai/hydra-zen/pull/125 This legibility issue is a major concern to me. Some of my users (including high school students) are rightfully bewildered when they bring up the signature in their editor via a tooltip (or Shift+Tab in Jupyter). However, accurate annotations are obviously important to help to guide them away from making mistakes. GUIDANCE -------- Does anyone have any advice for dealing with this legibility issue? Is there a mechanism in typing that I have overlooked? It occurs to me (as I write this) that perhaps moving to type-stubs could circumvent this. MY ATTEMPT AT A SOLUTION ------------------------ The ideal solution that I can think of is something with the form-factor MyType = Alias("MyType", true_type=ActualType) Where MyType is exactly the same as ActualType, but it provides a string field (that returns "MyType" here), that editors/tools can hook into to inform how they print the type - a purely aesthetic mechanism. I have attempted to experiment with NewType, Alias, and TypeVar to see if I could manage this legibility issue with the current typing capabilities. I have one hack that cleans up the experience for Jupyter users: if TYPE_CHECKING: ValidWrapper = # Actual, correct annotation else: ValidWrapper = TypeVar("ValidWrapper") This coerces Juptyer to render the annotation as `Union[~ValidWrapper , Sequence[~ValidWrapper ]]`. Clearly, this is an abuse of TypeVar, and I am generally not happy with this approach. It also has no improvement for VSCode and PyCharm. Thank you for your time! Ryan Soklaski

3 5

seeking feedback on a proposed deprecation library to be used at type checking time (in pytype)
by Yilei Yang Oct. 5, 2021

Oct. 5, 2021

Hi everyone, I'm working on a proposal to introduce a deprecation library. It is intended to be used at type checking time, and will be supported by pytype. The primary benefit (over DeprecationWarning at runtime) is to provide deprecation signals at static analysis time (think type checking, linting, IDE support). **The gist of the deprecation library** ============================ The gist of the deprecation library is to use a data class Deprecated wrapped in a typing.Annotated to mark variables/methods/functions as deprecated. Here are a couple of examples: # API: @dataclasses.dataclass class Deprecated: reason: str # Usages: my_constant: Annotated[int, Deprecated("my_constant is deprecated.")] = 123 def do_something(name: str, arg: Annotated[Any, Deprecated("`arg` is deprecated.")] = None) -> None: # The parameter `arg` is deprecated def my_function(name: str) -> Annotated[str, Deprecated("my_function is deprecated.")]: # Putting Deprecated in the return value type marks the method/function as deprecated. class MyClass: def __init__(self) -> Annotated[None, Deprecated("MyClass is deprecated.")]: # Marking __init__ as deprecated makes the class deprecated It is a no-op at runtime, and per PEP 593 it should be ignored by type checkers that don't support it. We also intend to include a higher-level decorator that will be turned into the lower-level annotations at type checking time. Here is an example: # API: def deprecated(message: str, stacklevel: int = 2) -> Callable[[_T], _T]: def decorator(wrapped): @functools.wraps(wrapped) def wrapper(*args, **kwargs): warnings.warn(message, DeprecationWarning, stacklevel=stacklevel) return wrapped(*args, **kwargs) return wrapper return decorator # Usage: @deprecated("my_func is deprecated") def my_func(name): print(f"Called my_func with {name}") At type checking time, it turns the function to def my_func(name) -> Annotated[?, Deprecated("my_func is deprecated")]. ? is either a concrete type if the type checker can infer its return type, or Any if not. At runtime, it raises a DeprecationWarning whenever my_func is called. **Feedback I'm looking for** ====================== Above isn't very detailed nor a finalized design. But I hope the idea is just clear enough to seek some initial feedback. The things I'm specifically looking for are: * Would the use of these APIs cause issues for other type checkers? Per my interpretation of PEP 593, it shouldn't. I tested with pytype, mypy, pyright, and pyre, one hiccup I found is pyre thinks annotating __init__ with Annotated[None, Deprecated("")] is an error (Incompatible constructor annotation [17]: __init__ is annotated as returning typing.Annotated[None], but it should return None.) * Is there interest from other type checkers to support such a deprecation library, so that static analysis tooling can provide better support detecting the use of deprecated APIs? Thanks, Yilei

5 6

"Asserting" type casts
by Stephen Rosen Oct. 1, 2021

Oct. 1, 2021

Hi all, I've been reading about the TypeGuards coming in 3.10 (and I'm excited!). I have a question which is related to guards and casts. One use-case I have is parsing data from some external source (e.g. JSON from a web API), but then presenting the result as a well-typed-value. For example: def get_error_code(error_data: Dict[str, Any]) -> str: code = error_data["code"] if isinstance(code, str): return code raise ValueError("bah! bad code!") The type of a value from an untrustworthy source should be checked at runtime, and we raise an error if the type is not correct. There are a few other ways of writing this, but with pitfalls of varying levels of obviousness. e.g. return cast(str, error_data["code"]) or code = error_data["code"] assert isinstance(code, str) return code The cast has no runtime check, and any `assert` gets removed if optimization is used. The `cast` "says what I mean" most succinctly, but by design doesn't include a runtime check. This seems like something which could be made the responsibility of `typing` in 3.11 or later. For example, an 'asserting_cast' variant which takes a (TypeGuard | Type) and lets the above examples be written as code = error_data["code"] return asserting_cast(code, str) or, to clarify the TypeGuard case, def is_str(x: Any) -> TypeGuard[str]: return isinstance(x, str) ... code = error_data["code"] return asserting_cast(code, is_str) I think the implementation would be quite simple, but IMO there's value in stdlib `typing` providing a pre-built solution which has thought about odd cases like non-runtime-checkable protocols. I'd be more than happy to work on adding something like this to `typing` if it seems reasonable. It would be a "safer but slower" alternative to cast and can raise a custom error, e.g. FailedTypeCastError(ValueError) . My biggest two questions are... Have I missed something obvious in `typing` or maybe `typing-extensions` which already covers this? Is this a bad idea, and if so can someone help me understand why? Thanks in advance, -Stephen

1 0