On 2020-09-12 at 09:57:10 +1000, Cameron Simpson wrote:

So, consider:

@classmethod def func(cls, foo): print(foo)

A linter will warn you that "cls" is unused. With a static method:

@staticmethod def func(foo): print(foo)

a linter will be happy.

Think of @classmethod and @staticmethod as ways to write "clean" functions with no extraneous cognitive noise.

I concur with all of Cameron's technical details and explanations. But no extraneous cognitive noise? By definition, methods appear inside a class definition, and then I have to process the @staticmethod decorator. Effectively, the decorator "cancels" the class method status of the function. I can accomplish the same thing with clean module-level function, modulo the specific namespace in which the function is created. So, in a module m: class X: @staticmethod def f(x): print(x) and def f(x): print(x) m.X.f and m.f are interchangeable. IMO, m.f has less cognitive load than m.X.f, at their definitions and at call sites. Full disclosure: I consider most of Object Oriented Programming to be extraneous cognitive noise. In other languages (*cough* Java *cough*), there are no functions outside of classes, and static methods fill that role.

Dan, I should preface this by saying I don't substantially disagree with you, I just work differently and want to show how and why. On 11Sep2020 21:24, Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

On 2020-09-12 at 09:57:10 +1000, Cameron Simpson wrote:

...

So, consider:

@classmethod def func(cls, foo): print(foo)

A linter will warn you that "cls" is unused. With a static method:

@staticmethod def func(foo): print(foo)

a linter will be happy.

Think of @classmethod and @staticmethod as ways to write "clean" functions with no extraneous cognitive noise.

I concur with all of Cameron's technical details and explanations.

But no extraneous cognitive noise?

Specificly in the sense that the @classmethod example has an unused "cls" parameter. For a three line function this is trivial to ignore, but for a substantial function I'd be devoting annoying brainpower to understanding where it was used, and if it didn't appear, _should_ it be used? Thus noise. With the static method it is instantly clear that no instance or class context is used.

By definition, methods appear inside a class definition, and then I have to process the @staticmethod decorator. Effectively, the decorator "cancels" the class method status of the function.

For me, I have to process either the @staticmethod or @classmethod decorators equally - they just have different meanings. But at least they're up the front - I see them and their meaning for the function context is instantly available to me instead of needing to be deduced.

I can accomplish the same thing with clean module-level function, modulo the specific namespace in which the function is created.

So, in a module m:

class X: @staticmethod def f(x): print(x)

and

def f(x): print(x)

m.X.f and m.f are interchangeable.

Yes, technically. Let me say up front that I write plenty of module elvel plain functions. However I do have plenty of use cases for @staticmethod in class definitions. They tend to be class utility functions, either for some common function used in the class methods, _or_ a common method meant to be available for outside use - particularly for a common pattern for outside use. Here's an example of the former: @staticmethod def pick_value(float_value, string_value, structured_value): ''' Chose amongst the values available. ''' if float_value is None: if string_value is None: return structured_value return string_value return float_value @property def value(self): ''' Return the value for this `Tag`. ''' return self.pick_value( self.float_value, self.string_value, self.structured_value ) This is from a tag library of mine, where the tags live in a database and there are three fields: a float, a string and a JSON blob. Only one will be nonNULL. This supports a remarkable flexibility in tagging things. It is common in the class to pick amongst them, thus the static method. It is also not unreasonable to work with such a choice outside the class (so it might not be a private method/function). On review, I've actually got relatively few examples of the latter category - methods for use outside the class - they are almost entirely @classmethods. The few which are static methods live in the class for purposes of conceptual hierarchy. My commonest example is the transcription method from a binary structure module I have. Data structures each have a class which implements them, and all subclass a base class. This gets me a common API for parsing the structure and also for writing it back out. When implementing a particular structure one always has a choice between implementing one of two "transcribe" methods. For a simple thing with a single "value" (eg an int) you'd implement "transcribe_value(value)", a static method. For something more complex you implement "transcribe()", a class or instance method depending. In the abstract base class each method calls the other - the subclass must provide a concrete implementation of one method. Anyway, back to the static method: if is pretty common to want to write out a value using the transcription from a class, example: value = 9 bs = BSUInt.transcribe_value(value) without going to any hassle of instantiating an instance of BSUInt - we just want to convert from the Python type to bytes. There's a similar example for parsing. The beauty here is that you have the same pattern of classname.transcribe_value(value) to use whatever binary format you want. And that's a static method because it doesn't need a class or instance for context - it just transcribes the data.

IMO, m.f has less cognitive load than m.X.f, at their definitions and at call sites. Full disclosure: I consider most of Object Oriented Programming to be extraneous cognitive noise.

Whereas I use OOP a lot. Hugely.

In other languages (*cough* Java *cough*), there are no functions outside of classes, and static methods fill that role.

Aye. I agree that is an example where static methods exist for language definition reasons instead of functionality. OTOH, the language design is deliberately like that to force encapsulation as a universal approach, which has its own benefits in terms of side effect limitation and code grouping, so there's an ulterior purpose there. Cheers, Cameron Simpson

On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote:

The default (an instance method) requires "self" to perform.

Of course, this is only the default if the method is a function object. If it is a different callable class, the default is effectively staticmethod. Perhaps there should be an @instancemethod?

On Sat, Sep 12, 2020 at 07:25:30PM -0400, Eric V. Smith wrote:

On 9/12/2020 7:13 PM, Random832 wrote:

...

On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote:

...

The default (an instance method) requires "self" to perform. Of course, this is only the default if the method is a function object. If it is a different callable class, the default is effectively staticmethod.

Perhaps there should be an @instancemethod?

What would that let us do that we can't currently achieve?

We already have an instancemethod, it's just spelled differently: py> from types import MethodType And while it is not useful as a decorator, it is *really* useful for adding methods to an individual instance rather than the class: py> class K: ... pass ... py> obj = K() py> obj.method = lambda self, x: (self, x) py> obj.method('arg') # Fails Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: <lambda>() missing 1 required positional argument: 'x' But this works: py> obj.method = MethodType(lambda self, x: (self, x), obj) py> obj.method('arg') (<__main__.K object at 0x7f67a4e051d0>, 'arg') So an instancemethod decorator would be a waste of time, but the instancemethod type, spelled types.MethodType, is very useful. -- Steve

On Sun, Sep 13, 2020 at 12:32:54AM -0400, Random832 wrote:

This isn't what I was suggesting - I meant something like this:

class instancemethod: def __init__(self, wrapped): self.wrapped = wrapped def __get__(self, obj, objtype): if obj is None: return self.wrapped else: return MethodType(self.wrapped, obj)

this wouldn't be useful for functions, but would give other callables the same functionality as functions, automatically creating the bound method object, e.g.:

class D: def __init__(self, obj, *args): ...

class C: foo = instancemethod(D)

You want a method which does absolutely nothing at all but delegate to a class constructor or callable object (but not a function), with no docstring and no pre-processing of arguments or post-processing of the result. Seems like an awfully small niche for this to be in the stdlib. But having said that, I might have a use for that too. Except... I would need a docstring. And pre- and post-processing. Hmmm. *shrug* Seems to me that this might be useful in theory, but in practice we might never use it, preferring this instead: class C: def foo(self, *args): """Doc string.""" return D(self, *args) with appropriate pre- and post-processing as needed. Interesting suggestion though, I may have to play around with it. -- Steve

On 12/09/20 12:21 pm, Guido van Rossum wrote:

I had heard of this concept in another language (C++? Smalltalk?)

Probably C++ or Java. Smalltalk doesn't have static methods, only a form of class method. IMO, static methods are a kludge only needed in languages that make classes do double duty as modules, and also can't have class methods because classes aren't first-class objects. I've never felt the need for one in Python. -- Greg