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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
