[Tutor] what do you use @staticmethod for?

[ALAN GAULD]

Forwarded to group.

> Would you mind telling me what you think of the following?
> 
> /Inside/ class definition, conflict may happen between class 
> an instance attributes.
> Non-callable attributes (say, properties) are diffenreciated using the 
> syntactic convention that instance properties are prefixed with a special 
> placeholder (usually self) taking the place of future instance name:

Its not merely a syntactic convention. self is a very real local 
variable within the method. It is no different to any other local variable.

> For methods, the same convention applies at method call:
> * class        : Clas.method(args)
> * instance    : self.method(ergs)
> Strangely enough (from my point of view), this nice rule is broken 
> at method definition:
> * class        : None            expected def method(args)
> * instance    : def method(self,args)    expected def self.method(args)

But self is not defined at the class level. It is not just a naming feature, 
self is a real local variable with a value assigned at call time just like 
any other function/method parameter. It does not exist outside of a
method definition. In fact the self parameter of each method is different:

class C:
   def m1(self): pass
   def m2(this): pass
   def m3(xyz): pass

self, xyz and this are all independant and equally valid names for 
the instance reference that will be passed in when the method is called.
Indeed the following is perfectly valid code:

c = C()
C.m3(c)     # same as c.m3()

> As I see it, the syntax for instance method definition conflicts with 'regular' 
> class method def. 

Regular class method definition is not regular. Thats the real issue!
We define instance methods far more often thabn class methods so that
has been optimised. The class method definition has been simplified 
as far as possible by the decorator but it is admittedly "differenmt" to 
the normal function definition protocol. But...

> If 'self' (or any other word) would be used as prefix for method def, 

this would be very irregular. It would not fit well with normal function 
definition. An instance method definition currently looks exactly like
(and operates like) a normal function except its inside a class. It just 
happens to have some syntactic sugar added to make the calling 
usage more convenient.

> could define class methods normally. 

We do define them normally but we assign them as class methods 
as an extra step. Its not the definition of the method that is different 
its the step of assigning them to be class methods thats awkward.

> Additionally, this would allow instance attributes to be present at class 
> top-level scope, not only inside methods. Which may be good for readibility

Perhaps, but would you still allow instanc attributes to be assigned 
outside of the class definition, for that too is possible:

class D: pass

d = D()
d.foo = 42   # add an attribute to the instance
print d.foo

> allowing to clearly show for instance objects fields, which presently are 
> randomly created here and there inside methods. 

Or as above, outside methods.
Object instances are just data structures like any other, so we can 
add to them at any time once created.

> programmers use __init__ as field list declaration by doing false 
> initialisations:
> def __init__(self, arg1):
>     self.arg1 = arg1     # real init
>     self.arg2 = 0        # false init 'showing' arg2


Yes, that's a matter of taste, and to a large extent background.
Personally I like it but many don't do that.

Remember that class methods, and indeed class attributes, are used 
so rarely that this is simply not an issue for most programmers. 
If you come from another OOP language it can seem, a bit odd 
in Python initially but it does have an elegant simplicity that 
exposes the underlying implementation while retaining ease of 
use. When you read Python code it's very easy to see how the 
underlying dictionary upon which classes and objects are built 
are being used.

HTH

Alan G