An 'actual need' for optional protocol members

PEP 544 includes a Support optional protocol members section which says:

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.

I wanted to call out an ‘actual need’ here in the falcon package (which is in the process of adding typing).

It has a duck typed ‘resource’ which provides optional methods for the HTTP verbs (on_get, on_post, etc.). Accordingly it has exactly the semantics given in the PEP:

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.

Perhaps we can collect other such use cases here as a motivation to implement optional protocol members in the future.


See Optional class and protocol fields and methods · Issue #601 · python/typing · GitHub for prior discussions. Optional protocol member would especially be useful for I/O protocols, where implementations often check before using methods like seek().