Attack a sacred Python Cow

castironpi castironpi at gmail.com
Mon Jul 28 20:16:28 CEST 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