__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

[Ralf W. Grosse-Kunstleve]

--- Bengt Richter <bokr at oz.net> wrote:
> >I still think it's too specialized. What would, hypothetically, this do?
> >
> >class Bar: pass
> >
> >class Foo:
> >    x = Bar()
> >    def method_1(self, x.y):
> >        pass
> >
> >It's hard to explain that you can autoassign self.y but not x.y.
> >
> No, that limitation wouldn't exist, so you wouldn't have to explain it ;-)
> I.e., the above would act like
> 
>  class Foo:
>      x = Bar()
>      def method_1(self, _anonymous_arg_1):
>          x.y = _anonymous_arg_1
> 
> and would do whatever it would do now (probably look for a global x or a
> closure cell x, but
> it wouldn't find the class variable in a normal method call)

I am a bit afraid of opening a door for weird side effects. E.g.

class unrelated: pass
u = unrelated()

class grouping:
  def __init__(self, self.x, u.y, self.z):
    pass

Is this really a good thing to allow? I am afraid it will be abused. My prime
concern was to provide a good solution for a very common problem. If we stray
too far from this most important goal we may get nothing in the end.

"self" (or whatever people prefer as a name for the first argument of a bound
function) *is* special. I think therefore it deserves special support.

I think it would be fantastic if we could push through the

  def __init__(self, self.x, y, self.y)

syntax, with the explicit limitation that only the first argument can be used
on the left side of the dot. I'd also happily settle for a decorator approach,
__autoinit__ or over variations, as long as they are built-in and easy to
remember/use/explain to a novice. However, to me the self.x approach seems to
be "just right" because:

  1. It is a good compromise between "redundant" and "explicit"; i.e.:

      too redundant:

        def __init__(self, x, y, z):
          self.x = x
          self.y = y
          self.z = z

      middle ground:

        def __init__(self, self.x, self.y, self.z):
          pass

      the other extreme:

        def __init__(self, .x, .y, .z):
          pass

    I am thinking people can understand the "middle ground" approach even
    without looking at release notes and will not be surprised if unrelated.y
    doesn't work.

  2. This approach is open to full optimization for runtime performance
     and should therefore be faster than the redundant conventional
     approach. I.e. the arguments can directly be inserted into the
     desired dictionary (or slot), without ever being added to locals().

  3. The user can always write "grouping(x=1,y=2,z=3)". I.e. how the
     arguments are used is strictly an implementation detail, as it
     should be.

Cheers,
        Ralf



		
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/