Attack a sacred Python Cow
castironpi
castironpi at gmail.com
Mon Jul 28 14:16:28 EDT 2008
On Jul 28, 2:26 am, Nikolaus Rath <Nikol... at rath.org> wrote:
> castironpi <castiro... at gmail.com> writes:
> >> I think you misunderstood him. What he wants is to write
>
> >> class foo:
> >> def bar(arg):
> >> self.whatever = arg + 1
>
> >> instead of
>
> >> class foo:
> >> def bar(self, arg)
> >> self.whatever = arg + 1
>
> >> so 'self' should *automatically* only be inserted in the function
> >> declaration, and *manually* be typed for attributes.
>
> > There's a further advantage:
>
> > class A:
> > def get_auxclass( self, b, c ):
> > class B:
> > def auxmeth( self2, d, e ):
> > #here, ...
> > return B
>
> In auxmeth, self would refer to the B instance. In get_auxclass, it
> would refer to the A instance. If you wanted to access the A instance
> in auxmeth, you'd have to use
>
> class A:
> def get_auxclass(b, c ):
> a_inst = self
> class B:
> def auxmeth(d, e ):
> self # the B instance
> a_inst # the A instance
> return B
>
> This seems pretty natural to me (innermost scope takes precedence),
> and AFAIR this is also how it is done in Java.
True. Net keystrokes are down in this method. Consider this:
class A:
def get_auxclass(b, c ):
a_inst = self
class B:
@staticmethod #<--- change
def auxmeth(d, e ):
self # -NOT- the B instance
a_inst # the A instance
return B
What are the semantics here? Error, No 'self' allowed in staticmethod-
wrapped functions. Or, the a instance, just like a_inst?
Do you find no advantage to being able to give 'self' different names
in different cases?
More information about the Python-list
mailing list