[issue32070] Clarify the behavior of the staticmethod builtin

Andrés Delfino added the comment: Also see #34085 that deals with the same issue in functions.rst. -- nosy: +adelfino ___ Python tracker ___ ___

[issue32070] Clarify the behavior of the staticmethod builtin

Change by Raymond Hettinger : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-

[issue32070] Clarify the behavior of the staticmethod builtin

Raymond Hettinger added the comment: ISTM the current wording is correct and aims to describe how staticmethods differ from regular methods. With a regular methods we have "c.m(*a) -> type(c).m(c, *a)" and "C.m(*a) -> C.m(*s)". With a class method, only the first of those changes to "c.m(*

[issue32070] Clarify the behavior of the staticmethod builtin

New submission from Jesse SHapiro : It looks like the original staticmethod docstring might have been based on the classmethod docstring, and it seems like the current description might not be accurate. Current string: ...It can be called either on the class (e.g. C.f()) or on an instance (e.