[Tutor] [Fwd: Re: what do you use @staticmethod for?]

[spir]

[forwarded to the list]

Thank you for your answers. I found Tim's example below especially helpful.
Still, I am a bit surprised. Would you agree with the following:

-1- Methods are usually defined as functions "bound to" an object, often called
'owner', meaning especially that the object is then available from insidethe
method for operations to apply on it, or with it. Static methods aren't bound,
no object is passed as arg, so they are not methods in fact. Simply the calling
  syntax looks like a method call because of the prefix. From this point of
view, static methods may alternatively be called "class functions" instead.

-2- The differences between a standard function (defined e.g. at module level)
and a static method are that the latter is defined inside a class's scope, and
called using the class name as prefix. This can be appropriate, or even
relevant, for the developper or reader.

-3- Semantically speaking: at the process/python level, there is no real
difference, behind the scene a static method actually is a function. At the
programmer's level, defining a static method is (can be) meaningful, for it
matches the problem, his/her point of view, or design choice. In short: it
makes sense.

If this is True ;-), then it is the first Python feature I notice that simply
exists for such a (relevant, imo) reason. Now, I will probably find many
appropriate use cases for static methods.

Denis


Tim Golden a écrit :
> spir wrote:
>> Good night,
>>
>> I have not yet found any use for this feature.
>>
>> Also, I do not really understand the difference with @classmethod,
>> from the programmer's points of view (even if I get the difference on
>> the python side).
>> As I see it, a classmethod is a very ordinary method, except its
>> 'owner' is a type. [But we cannnot express its definition with
>> standard syntax, because it conflicts with instance method definition
>> syntax.]
>>
>> I would be pleased to read your views about staticmethods, and the use
>> cases you have for them -- that could not be done (the same way) with
>> classmethods.
>
> For me, the difference is a somewhat conceptual one: I use class methods
> when the operation they're performing is not (possibly cannot be) tied
> to a specific instance of that class. The canonical application is as a
> class
> factory. So I have classmethods called things like .from_string which
> return an instance of the class which is their first parameter. This will
> therefore work from subclasses.
>
> On the other side of the coin, static methods don't (and can't) even
> rely on the class they're in so they're not very different from, say,
> module
> global functions. I use them if they are in concept a part of whatever
> functionality the class is offering, but don't (and shouldn't) depend on
> any instance or any class data. Examples in my own code include a
> method which returns login sessions from the Windows LSA within an LSA
> class: you don't need any kind of LSA policy handle to enumerate logons,
> but it fits conceptually within the idea of an LSA class whose other
> operations do rely on a policy handle, so I left it there and made it
> static.
>
> HTH
>
> TJG