Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Support total=False for protocols #5504

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ilevkivskyi opened this issue Aug 18, 2018 · 4 comments
Closed

Support total=False for protocols #5504

ilevkivskyi opened this issue Aug 18, 2018 · 4 comments
Labels
feature priority-1-normal topic-protocols

Comments

@ilevkivskyi
Copy link
Member

ilevkivskyi commented Aug 18, 2018 •
edited
Loading

I have heard few requests to allow this:

class SomeDimensions(Protocol, total=False):
    x: float
    y: float
    z: float
    ct: float

with exactly the same semantics as for TypedDicts (including subclassing so that only part of members can be optional).

This is quite straightforward to implement. I am just leaving this here so we will not forget about this feature request.
@intgr intgr mentioned this issue Feb 23, 2023
Open
@intgr
Copy link
Contributor

intgr commented Feb 23, 2023

Supporting PEP 655 NotRequired[] for Protocols would also be very cool and more flexible.

PEP 544 currently states about this:

We can come up with examples where it would be handy to be able to say that a method or data attribute does not need to be present in a class implementing a protocol, but if it is present, it must conform to a specific signature or type. One could use a hasattr() check to determine whether they can use the attribute on a particular instance.

Languages such as TypeScript have similar features and apparently they are pretty commonly used. The current realistic potential use cases for protocols in Python don’t require these. In the interest of simplicity, we propose to not support optional methods or attributes. We can always revisit this later if there is an actual need.

@intgr intgr mentioned this issue Feb 23, 2023
Merged
@intgr intgr mentioned this issue Mar 20, 2024
Merged
@intgr
Copy link
Contributor

intgr commented Mar 20, 2024

Related discussion in python/typing project:

@JukkaL
Copy link
Collaborator

JukkaL commented May 9, 2025

This requires a PEP or a typing council decision, so closing this for now. The issue will be tracked in the python/typing repository.

@JukkaL JukkaL closed this as completed May 9, 2025
@tekumara
Copy link

tekumara commented May 9, 2025

See python/typing#601

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature priority-1-normal topic-protocols
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tekumara @intgr @JukkaL @ilevkivskyi