Python and Schools

[Michael Robin]

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:

class C:
    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
__init__)

This violates
    In the face of ambiguity, refuse the temptation to guess
    Explicit is better than implicit
and perhaps:
    ...that way may not be obvious at first unless you're Dutch.

There are really two explict vs. implict issues here - the
class-scoped
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
notwithstanding.

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.".

thanks, mike



"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.
> 
>                     Andrew
>                     dalke at dalkescientific.com