Python and Schools
me at mikerobin.com
Sat Apr 12 23:23:09 CEST 2003
First of all, I love Python, but a bit of devil's advocacy...
This would all be icing on the cake of consistency, except when
seemingly innocent constructs like:
x = 42
def foo(): self.x += 1
exist that can lookup & bind a name in a two different scopes
(probably not intended) - from a class to an instance.
If you really want this behavior, you should have to say "self.x = C.x
+ 1" if x is not bound (the first time that foo() is executed) and the
current version thereafter. (Or even better, put set self.x = C.X in
In the face of ambiguity, refuse the temptation to guess
Explicit is better than implicit
...that way may not be obvious at first unless you're Dutch.
There are really two explict vs. implict issues here - the
variable and the binding to self.x without explicit knowlege that "x"
should in fact be a member of C, given that there are no decl's and
the slot is currently unbound -- but the latter is an important and
useful part of Python parlance, __slots__ and varible-name typos
Rule#1 is of course in the eye of the beholder, and there must be a
balance between explicit uglyness and implicit beauty (or is it the
other way around?) - but in this case I think we'd vote for the extra
typing for the class accessor, just as we don't mind "self.".
"Andrew Dalke" <adalke at mindspring.com> wrote in message news:<b76ult$plu$1 at slb5.atl.mindspring.net>...
> Mads Orbesen Troest wrote:
> > > but really; all the self me here and self me there is - to me at last -
> > > exceedingly clumsy and a constant source of frustration.
> Peter Hansen
> > >>> import this
> ... from the interpreter and you'll see a list of 'Pythonic' guidelines.
> More specifically, "explicit is better than implicit". See the 'self'
> and you know where the variable comes from. Compare to C++
> where you don't know (without some looking) if the variable is
> an attribute or a variable in the compilation unit.
> dalke at dalkescientific.com
More information about the Python-list