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: Noneexpected 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
