Mailman 3 March 2023 - Typing-sig

Re: Typing Meetup
by S Pradeep Kumar Sept. 19, 2023

Sept. 19, 2023

Updating the Typing Meetup date to Wednesday as there were some conflicts. Let me know if there are any major time conflicts. Date: *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) [1] + Remaining questions about Callable syntax (Steven) + Non-required Protocol fields (Sebastian Rittau?) [2] + Type support for sealed classes (Adrian Freund?) [3] + 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 >>>> 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 >>>> _______________________________________________ >>>> Typing-sig mailing list -- typing-sig(a)python.org >>>> To unsubscribe send an email to typing-sig-leave(a)python.org >>>> https://mail.python.org/mailman3/lists/typing-sig.python.org/ >>>> Member address: guido(a)python.org >>> >>> Links: [1] Typing **kwargs using TypedDict: https://mail.python.org/archives/list/typing-sig@python.org/thread/IUCXT2IQ… [2] Non-required Protocol fields: https://mail.python.org/archives/list/typing-sig@python.org/thread/P6FCGRJU… [3] Sealed classes: https://mail.python.org/archives/list/typing-sig@python.org/thread/QSCT2N4R… -- S Pradeep Kumar

10 60

Type narrowing for TypeGuard in the negative case
by Eric Traut Aug. 4, 2023

Aug. 4, 2023

Since the introduction of PEP 647 (User-defined Type Guards), we've received a steady stream of input from users saying that they don't like the limitation that type narrowing is applied only in the positive case and is not applied in the negative case. In general, type narrowing is not safe to perform if a user-defined type guard returns False, so I've stood by the original decision not to provide type narrowing in the negative case, but there are cases where such narrowing is safe and desirable. Here's a recent thread where this was discussed in some detail: https://github.com/python/typing/issues/996#issuecomment-1002716830 In this discussion, Ilya Kamen proposed a solution. The proposal is to extend the existing `TypeGuard` to support an optional second type argument. If present, the second argument indicates the narrowed type in the negative type narrowing situation. Here's a simple (admittedly contrived) example: ```python def is_str(val: str | int) -> TypeGuard[str, int]: return isinstance(val, str) def func(val: str | int): if is_str(val): reveal_type(val) # str else: reveal_type(val) # int ``` I've implemented this proposal in the latest published version of pyright (1.1.202) so folks can experiment with it and see if they like it. If there's general consensus that it's the right approach, I can file an amendment for the existing PEP 647 to include this functionality. It was trivial to add to pyright, so I'm optimistic that it would likewise be easy to add to the other type checkers. Another common request for PEP 647 is the desire for an "assert" form of TypeGuard — a way to indicate that a function performs runtime validation of a type, raising an exception if the type is incorrect. It occurred to me that this two-argument form of `TypeGuard` could also be used to handle this use case. The second argument would be specified as a `NoReturn`. I've provisionally implemented this in pyright as well (although it's not in the currently-published version — you'll need to wait until 1.1.203 is published). Here's what this would look like: ```python def validate_sequence(val: Sequence[_T | None]) -> TypeGuard[Sequence[_T], NoReturn]: """Verifies that the sequence contains no None values""" if len([x for x in val if x is not None]) > 0: raise Exception() return True def func(val: Sequence[int | None]): validate_sequence(val) reveal_type(val) # Sequence[int] ``` I'm interested in input on these proposals. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

7 8

Any way to express that a dict is expected to have a key(s) but don't care about other keys?
by Brett Cannon June 20, 2023

June 20, 2023

Looking at TypedDict it seems that it does not like the idea of superfluous keys existing in a dict. In my case I have a REST call returning JSON for an error and all I'm guaranteed is to get an "error" key. But there may be extra keys that provide more details about the specific error. Unfortunately I don't know the exhaustive list of keys so I can't use a TypedDict with `totality == False` to try to be complete. I can't think of any way to somehow say "require/expect this one key, but other keys are OK". Am I missing anything that would let me do this?

17 35

Inline syntax for TypedDict
by Никита Соболев June 14, 2023

June 14, 2023

Hi everyone! ## Problem Dicts are fundamental to Python programming. And today I found myself writing this piece of code (again): ```python def process_user(user_dict: User) -> ModifiedUser: ... class User(TypedDict): ... class ModifiedUser(User): ... ``` While in reality it was as simple as: `{'user_id': int}` -> `{'user_id': int, 'external_id': int}` What really bothers me is that I have to either: 1. Create a new whole class for it 2. Create a new type variable in a form of `User = TypedDict('User', {...})` I think that it hurts the readability quite a lot, because the definition of this type might not be near with a function that uses it. Another problem is that due to the nature of `TypedDict`s there are quite a lot of them in a regular web application, because of json. The biggest problem (for me personally) is that you cannot simply nest TypedDict. So, if you have a nested dict that you want to use, like `{'user': {'email': str}}`? You have to define *two* classes. And the final touch: it looks like many TypedDict are just used in one place. They are just like throw-away definitions. And don't forget that classes cannot have all keys in their body: `return`, `@1`, etc are all not allowed. ## Proposal To solve all the problems above, I propose adding "inline" syntax for typed dicts: ```python def get_user_data(arg: {'user': {'email': str}}) ->{'email': str}: return user['user'] ``` It has great potential: 0. Grammar already allows that with no changes from our side 1. `Required` and `NotRequired` can be used to enforce the presence of keys and values 2. Dicts can be nested with ease, just like in my example. Even multiline nesting is supported: ```python >>> def multiline() -> { ... 'user': { ... 'email': str, ... }, ... }: ... ... ... ``` 3. The intent is pretty clear: any user familiar with dicts would be able to read and understand this code 4. Other languages already have this feature, TS example: https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAcwKZQPogM6oE4YAm… 5. Existing tooling continues to work, see this example: ```python >>> import typing >>> def get_user_data(arg: {'user': {'email': str}}) ->{'email': str}: ... ... >>> get_user_data.__annotations__ {'arg': {'user': {'email': <class 'str'>}}, 'return': {'email': <class 'str'>}} >>> typing.get_type_hints(get_user_data) {'arg': {'user': {'email': <class 'str'>}}, 'return': {'email': <class 'str'>}} ``` And: ```python >>> import typing >>> class Some: ... a: {'x': int} = {'x': 1} ... def method(self, arg: {'x': int}) -> {'x': int, 'y': int}: ... return {'x': 1, 'y': 2} ... >>> Some.__annotations__ {'a': {'x': <class 'int'>}} >>> Some.method.__annotations__ {'arg': {'x': <class 'int'>}, 'return': {'x': <class 'int'>, 'y': <class 'int'>}} >>> typing.get_type_hints(Some) {'a': {'x': <class 'int'>}} >>> typing.get_type_hints(Some.method) {'arg': {'x': <class 'int'>}, 'return': {'x': <class 'int'>, 'y': <class 'int'>}} ``` 6. It is just a regular dict! No new things to create :) ## Extra We can also discuss the variable syntax change from: ```python X = TypedDict('X', {'a': int}) ``` To: ```python X: TypeAlias = {'a': int} ``` Because again, it is simpler: no need to duplicate the name and values can be nested. ## Problems The most important problem I see is that it is just a syntax to solve a problem with an existing solution. But, I think it is a good addition overall. ## Typecheckers From what I know, it would not be too hard to support this in mypy. We would need to add new logic to generate names from context (instead of an explicit name). Nesting needs to be tested, we might have some troubles here. I cannot speak for other typecheckers. ## Feedback This is a very rough idea for now. But, what do you think? Is that a problem you face in your projects? I would be glad to hear the feedback from the Python's typing community :) Best, Nikita Sobolev

14 28

Runtime Access to Type Parameters
by Saul Shanabrook June 7, 2023

June 7, 2023

I would like to propose being able to access, at runtime, the type parameters in classmethods and in constructors. I wrote up a draft PEP on this to capture the thinking here: https://github.com/saulshanabrook/peps/blob/master/pep-9999.md It seems easier to add them to classmethods, so even that addition alone would be very welcome! It could be added to Guido's existing draft PR for pep 585, by making a small change in the getattr function (https://github.com/python/cpython/pull/18239/files#diff-a34ae826f869897e56e…), to first do a `__getattribute__` and check if the result is a descriptor (has a `__get__` attribute), and if so passing the generic class itself in as the class, instead of the origin class. I wrote up a little example of that in the PEP. To make it available in the constructor, I proposed adding a global function `get_parameters` to `typing` which returns the parameters in the constructor. I also provide a little mock implementation of that. Note that work is only for custom classes which inherit from `typing.Generic` not for any built in collections.

5 6

Extending published stubs
by Irv Lustig April 26, 2023

April 26, 2023

I'm the leader of the pandas-stubs project. In pandas, users can extend the library by creating their own accessor via `(a)pd.api.extensions.register_dataframe_accessor` (see https://pandas.pydata.org/docs/reference/api/pandas.api.extensions.register…). So for a `DataFrame`, if you do `(a)pd.api.extensions.register_dataframe_accessor("xyz")`, you now have `DataFrame.xyz` returning the class you annotated. Now suppose you want to create a stub for your new accessor, that would extend the existing pandas-stubs. AFAIK, there isn't a way to do something like this in a stub: ``` from pandas import DataFrame @typing.extend class DataFrame: def xyz(self) -> MyXyzClass: ... ``` The idea here is that there is a class (in this case, `DataFrame`) that already has stubs, and you want to add a method to it. Has this idea been discussed anywhere?

6 11

Opened and changed typing issues week 2023-W12
by Typing Bot March 27, 2023

March 27, 2023

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 updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #688 advanced SimpleNamespace typing opened by @itajaja https://github.com/python/typing/issues/688 #1371 Proposal: Programmatically create types opened by @NeilGirdhar https://github.com/python/typing/issues/1371 --------------------------------------------------- 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

Reminder
by Shalok Shalom March 23, 2023

March 23, 2023

Hi there. I send an email to this mailing list several days ago, and it seems like the admins of this list are either busy, or it got lost. Can you confirm, its one of those two? Thanks

2 1

How can I annotate class variables and instance variables with different types?
by Chihiro Sakai March 23, 2023

March 23, 2023

I want means to annotate class variables and instance variables with distinct types. I'm using the well-known ORM library SQLAlchemy. With entity declaration, class variables are representations of table columns, while instance variables are the actual values of each record. Thus, because of this behaviour, I cannot write fully-typed code. For example, with the class declaration shown below: ``` class Entity(Base): __tablename__ = 'entity' column_1 = Column('column_1', BIGINT(unsigned=True), primary_key=True, autoincrement=True) ``` The actual type of the class variable `Entity.column_1` is `Column`, but on the other hand, the instance variable `Entity().column_1` is `int`. As far as I know, today, we cannot annotate variables like `Entity.column_1` with correct types, but I want to achieve those codes fully typed.

4 7

Support Algebraic Data Types with @sealed
by John Hagen March 20, 2023

March 20, 2023

The original (superseded) PEP 622 proposed adding a @sealed decorator so that users could define algebraic data types (ADTs) that static type checkers could verify are `match`ed exhaustively: - https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types There is a somewhat fairly-upvoted question about ADTs in Python, indicating interest in this area: - https://stackoverflow.com/questions/16258553 @sealed would be very valuable towards making ADT usage within Python more type-safe. Is there any historical discussion about why @sealed was dropped from the final pattern matching PEP? What would be the next steps needed to push this forward? Would writing a new PEP be the next step?

15 32

Opened and changed typing issues week 2023-W11
by Typing Bot March 20, 2023

March 20, 2023

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: #1371 Proposal: Programmatically create types opened by @NeilGirdhar https://github.com/python/typing/issues/1371 #1372 Add PartialApplication opened by @NeilGirdhar https://github.com/python/typing/issues/1372 --------------------------------------------------- The following issues and pull requests were updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #802 Wrapper/Proxy Generic Type opened by @hatal175 https://github.com/python/typing/issues/802 #1273 Type mappings for generics opened by @jonathanslenders https://github.com/python/typing/issues/1273 #1362 Union of empty tuple should return `Never` opened by @randolf-scholz https://github.com/python/typing/issues/1362 --------------------------------------------------- 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

PyCon 2023 Typing Summit: Interest form
by S Pradeep Kumar March 16, 2023

March 16, 2023

Hello all, PyCon 2023 is just a few months out. Jelle and I are looking forward to organizing the Typing Summit this year. We plan to be in-person in Salt Lake City, as we did last year. We have confirmed the Typing Summit with PyCon and will announce the exact date soon (tentatively a day before the main conference talks). We will try to record the event for those who cannot make it. For those who haven't attended before, the Typing Summit is a 3-4 hour event with a series of presentations and group discussions related to type checking. You can find the 2022 summit here: https://youtu.be/BNTkWQfqP_c If you are interested in attending, please fill out this form: https://forms.gle/yv1WnDoAVscg21vW8. This way, we can get a sense of the expected number of attendees and the topics you want to hear about. In a few weeks, we will send out another mail to typing-sig calling for presenters. Let us know if you have any questions. Best, Jelle Zijlstra Pradeep Kumar Srinivasan

1 2

`__class_getitem__` returning a mix of GenericAlias and concrete classes?
by Sebastian Berg March 16, 2023

March 16, 2023

Hi all, In NumPy, we have `np.dtype` as a superclass for all DTypes. This implements `__class_getitem__` for typing to allow `np.dtype[Any]` or `np.dtype[np.float64]` returning a `GenericAlias`. Now, `np.dtype[Any]` probably must return a GenericAlias. Maybe `np.dtype[something_that_makes_little_sense]` also. However, `np.dtype[np.float64]` is well defined, there is a concrete runtime subclass of `np.dtype` representing exactly that construct. This would be the same as `array.array['l']` if `array.array` had concrete subclasses implementation for each supported type. My question is: would it be possible or even better to returning the concrete class (probably only when it exists)? Or would that just confuse the typing step, e.g. because we cannot actually type that `np.dtype[np.float64] -> np.types.Float64DType`. (Also, this isn't a fixed set in theory, users can create new subclasses in principle.) Hopefully this is very obvious in one direction, but unfortunately, I have no idea. Thanks and Cheers, Sebastian

5 16

type hint of function exceptions
by david.froger＠mailoo.org March 13, 2023

March 13, 2023

Hi everyone, I've read https://stackoverflow.com/questions/44282268/python-type-hinting-with-excep… and especially the https://jonathan-scholbach.github.io/2023/02/06/what-does-it-mean-to-be-exc… blog post, but I want to keep coding with exceptions rather than returning `Ok | Err`. Here is a simple pattern I'm thinking to use, to let a function indicate the `Exception`s it may raised, which can be used: - by the developper as documentation, - by the static type checker for exhaustiveness ```python from typing import NoReturn, cast, TypeAlias class SomeError(Exception): ... class AnotherError(Exception): ... class StillAnotherError(Exception): ... FooError: TypeAlias = ValueError | SomeError | AnotherError def assert_never(value: NoReturn) -> NoReturn: # This also works at runtime as well assert False, f"This code should never be reached, got: {value}" def foo(i: int): if i == 0: raise ValueError("Must not be zero") elif i == 1: raise SomeError("Must not be one") elif i == 2: raise AnotherError("Must not be two") print("that's ok") try: foo(0) except Exception as e: e = cast(FooError, e) if isinstance(e, ValueError): print("value error") elif isinstance(e, SomeError): print("some error") else: assert_never(e) raise ``` It's far from being perfect, but it's simple and not too much intrusive nor obscure. In the above example, `mypy` can tell me which exception I forgot to manage: ``` foo.py:43: error: Argument 1 to "assert_never" has incompatible type "AnotherError"; expected "NoReturn" [arg-type] Found 1 error in 1 file (checked 1 source file) ``` What do you thing of this? Here is a proposal where the exception are annotated in the return type, and the try/except would directly check for exhaustiveness: ``` from typing import NoReturn, Annotated class SomeError(Exception): ... class AnotherError(Exception): ... class StillAnotherError(Exception): ... def assert_never(value: NoReturn) -> NoReturn: # This also works at runtime as well assert False, f"This code should never be reached, got: {value}" def Raises(exceptions): ... # TODO class NeverException(Exception): ... # TODO def foo(i: int) -> Annotated[None, Raises(ValueError | SomeError | AnotherError)]: if i == 0: ¦ raise ValueError("Must not be zero") elif i == 1: ¦ raise SomeError("Must not be one") elif i == 2: ¦ raise AnotherError("Must not be two") print("that's ok") try: foo(0) except ValueError: print("value error") except SomeError: print("some error") except NeverException: # static type checker warns here that AnotherError is not managed raise ``` and here is another fictive example with one intermediary function managing one of the 3 exceptions: ```python from typing import NoReturn, Annotated class SomeError(Exception): ... class AnotherError(Exception): ... class StillAnotherError(Exception): ... def assert_never(value: NoReturn) -> NoReturn: # This also works at runtime as well assert False, f"This code should never be reached, got: {value}" def Raises(exceptions): ... # TODO class NeverException(Exception): ... # TODO def foo(i: int) -> Annotated[None, Raises(ValueError | SomeError | AnotherError)]: if i == 0: ¦ raise ValueError("Must not be zero") elif i == 1: ¦ raise SomeError("Must not be one") elif i == 2: ¦ raise AnotherError("Must not be two") print("that's ok") def bar(i: int) -> Annotated[None, Raises(ValueError | SomeError)]: try: ¦ foo(i) except AnotherError: ¦ print("another error") try: foo(0) except ValueError: print("value error") except SomeError: print("some error") except NeverException: # no errer reported by the static type checker raise ``` Thanks!

3 4

How is `__hash__` typing supposed to work?
by Steven Troxler March 13, 2023

March 13, 2023

Do we have any docs or past discussions (I didn't find anything from a quick search) on the expected behavior of Hashable and `__hash__` typing rules. As far as I can tell, state of the art in typeshed is that: - object defines `__hash__` (I can see why, it's true at runtime for actual object types) - unhashable types explicitly "un-define" `__hash__` by setting a `ClassVar[None]` It appears to me that Mypy, Pyre, and Pyright both support this in the sense that they will type a list's `__hash__` attribute as `None`. But because upcasting list to object should be safe, all three type checkers say (a) you can do that and (b) `__hash__` is definitely not `None` once you do that. They diverge as to whether a list is a valid dict key (in the absence of upcasting); MyPy and Pyre both treat it as okay whereas Pyright says list is not hashable. I don't really have strong opinions about how this ought to work, but I'm a little surprised that I didn't easily find any discussion about both (a) declaring `object` to be hashable even though it has unhashable subtypes (b) the use of `ClassVar[None]` to declare incompatible overrides that introduce unsoundness My github PR search skills aren't great, so it may be this was discussed in typeshed PRs. It does look like at least in the past there was a decision not to really enforce hashability anyway at least in MyPy: https://github.com/python/typeshed/pull/6244. ------- Here are all three type checkers on a snippet illustrating: - directly asking about the type of `list.__hash__` (all of them say `None`) - passing `list` to a function taking an `object` and asking if `__hash__` is non-None (all of them say yes) - directly trying to create a dict with list keys (Mypy and Pyre both allow it, Pyright does not) Mypy: https://mypy-play.net/?mypy=latest&python=3.11&gist=174be7c81c486062cd662a1… Pyright: https://pyright-playground.decorator-factory.su/?gzip=H4sIAD1mDmQC_2VPzQrCM… Pyre: https://pyre-check.org/play?input=def%20takes_hashable(o%3A%20object)%20-%3…

2 1

Opened and changed typing issues week 2023-W10
by Typing Bot March 13, 2023

March 13, 2023

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: #1362 Union of empty tuple should return `Never` opened by @randolf-scholz https://github.com/python/typing/issues/1362 --------------------------------------------------- The following issues and pull requests were updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #1039 Annotate function which return a specific module (e.g. `-> Literal[np]`) opened by @Conchylicultor https://github.com/python/typing/issues/1039 --------------------------------------------------- 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

Opened and changed typing issues week 2023-W09
by Typing Bot March 6, 2023

March 6, 2023

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 updated last week: #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #1160 Allow `float("inf")` and `float("-inf")` in literals opened by @antonagestam https://github.com/python/typing/issues/1160 --------------------------------------------------- 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

Modeling functions with attributes
by Thomas Kehrenberg March 4, 2023

March 4, 2023

Consider this decorator from django: def csrf_exempt(view_func): """Mark function as being exempt from the CSRF view protection.""" # wrapping not strictly necessary here but is good practice @wraps(view_func) def wrapper_view(*args, **kwargs): return view_func(*args, **kwargs) wrapper_view.csrf_exempt = True # set function attribute return wrapper_view This kind of pattern is quite common in Python since PEP 232 added the ability to assign attributes to functions. But how should this be typed? If we annotate the return type simply as "Callable", we lose the information that `.csrf_exempt` has been set. The current way to annotate this is to use a callback protocol: P = ParamSpec("P") R = TypeVar("R", covariant=True) class CSRFExempt(Protocol[P, R]): csrf_exempt: bool # here is the attribute def __call__(self, *args: P.args, **kwargs: P.kwargs) -> R: ... def csrf_exempt(view_func: Callable[P, R]) -> CSRFExempt[P, R]: @wraps(view_func) def wrapper_view(*args: P.args, **kwargs: P.kwargs) -> R: return view_func(*args, **kwargs) wrapper_view.csrf_exempt = True return cast(CSRFExempt[P, R], wrapper_view) This will result in the right types when decorating *functions*, but it will not result in the right types for *methods*. That is because callable classes are not bound as methods; only real functions are. But in our annotation, the return type of csrf_exempt() is not a function but a callable object. So, type checkers will mistakenly think that the function is not bound as a method when it actually is. You can try to solve this problem by making csrf_exempt() return a descriptor object when called on a method, but that leads to other problems as discussed here for example: https://mail.python.org/archives/list/typing-sig@python.org/thread/QZX5WN4N… Besides, at runtime there aren't actually any descriptor objects involved, so it would be nice if we could actually describe what happens at runtime. My proposal is to introduce a new `FunctionProtocol` type (alternative names `AttributedFunction` or `FunctionWithAttributes`) to accurately describe *functions* (not callable objects) with attributes. For the above example, it would look like this: class CSRFExempt(FunctionProtocol[P, R]): # now `FunctionProtocol` csrf_exempt: bool @staticmethod def __call__(*args: P.args, **kwargs: P.kwargs) -> R: ... A FunctionProtocol describes only real functions that can optionally have attributes. It is similar to TypedDict in that it cannot be used at runtime in any way. So, in contrast to Protocol, not even subclasses of FunctionProtocol can be instantiated and there will be no @runtime_checkable decorator. One problem is that there is no syntax in Python for specifying attribues on a function in the definition of the function itself. That is, we have to write: def a() -> None: pass a.publish = True instead of something like def a() with (publish = True) -> None: pass so, type checkers will unfortunately have to do extra work in keeping track of attributes: class Publishable(FunctionProtocol): publish: bool @staticmethod def __call__() -> None: ... def a() -> None: pass a.publish = True # type checker has to note that an attribute was set f: Publishable = a # this assignment is valid This creates a kind of spooky action at a distance, but I don't see a good way to avoid this (except to introduce new syntax). The example from above then becomes: class CSRFExempt(FunctionProtocol[P, R]): csrf_exempt: bool @staticmethod def __call__(*args: P.args, **kwargs: P.kwargs) -> R: ... def csrf_exempt(view_func: Callable[P, R]) -> CSRFExempt[P, R]: @wraps(view_func) def wrapper_view(*args: P.args, **kwargs: P.kwargs) -> R: return view_func(*args, **kwargs) wrapper_view.csrf_exempt = True return wrapper_view # type checker can verify that this is valid And this decorator will then work as expected with methods as well as functions. FunctionProtocol will inherit all the attributes that functions have: ('__module__', '__name__', '__qualname__', '__doc__', '__annotations__') Just as with TypedDict, you can create subtypes, that add even more attributes. One could even re-use the NotRequired[] annotation from TypedDicts to express that an attribute might not be set (but if it was set, it would have the specified type). Callable objects are incompatible with FunctionProtocol: class SimpleFunc(FunctionProtocol): # you can use `@staticmethod` here or add a `self`; both are fine def __call__(self) -> None: ... class MyCallable: def __call__(self) -> None: print("Hello, world!") f: SimpleFunc = MyCallable() # type error! g: SimpleFunc = lambda: None # OK The main concern I see with this proposal is the spooky action at a distance that type checkers will have to implement. I can't really say how difficult it would be. Best, Thomas

2 3

Re: Inline syntax for TypedDict
by Frodo821 March 4, 2023

March 4, 2023

This proposal is pretty wanted, but I have a trivial question: the syntax you proposed conflicts with the dict literal, but how to distinguish between TypedDict type literal and existing dict literal? Or do you mean to treat some kind of dict as a type? -- chihiro sakai

1 0