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

[Ralf W. Grosse-Kunstleve]

--- Kay Schluehr <kay.schluehr at gmx.net> wrote:

>  > I stripped your code down to the essence. See attachment.
> > For the user your approach then becomes:
> >
> >   class grouping:
> >     __metaclass__ = autoattr
> >     def __init__(self, x, y, z):
> >       pass
> 
> No. This is clearly NOT what I had in mind. I translated your original
> proposal which introduced a punctuation syntax '.x' for constructor
> parameters forcing the interpreter to create equally named object
> attributes into a naming convention that can be handled by a metaclass
> customizer.

I see.

> The grouping.__init__ above does exacly nothing according
> to my implementation. I would never accept dropping fine-tuning
> capabilities. The "auto_" prefix is all the declarative magic.

I got only negative feedback regarding the fine-tuning idea, e.g.
http://mail.python.org/pipermail/python-list/2005-July/288833.html. After
thinking about it for a while I also came to the conclusion that runtime
performance and simplicity is indeed the higher value for a general-purpose
solution. Without a supporting syntax change (the idea received almost hysteric
opposition) I don't think fine-tuning can be supported without a noticeable
runtime-penalty.

My syntax-change proposal was meant not to change the user interface. I.e. it
was meant to preserve "grouping(x=1,y=2,z=3)", no matter how x,y,z are handled
in the constructor. Under your proposal the decision to use "auto init" becomes
 a visible part of the user interface and may therefore be irreversible in
practical applications.

> > My __autoinit__ suggestion would result in (assuming object supports
> > this by default):
> >
> >   class grouping(object):
> >     def __autoinit__(self, x, y, z):
> >       pass
> >
> > I think that's far more intuitive.
> 
> Being intuitive is relative to someones intuition. 

If someone looks at the code there is no question he/she knows immediately what
is going on. In contrast, the __metaclass__ statement is potentially separated
from the __init__ definition by unrelated code, leading to surprises (on top of
intimidation for beginners). I don't think that's the best style. It is
generally better if the framework doesn't allow for artificial separations in
the first place.

Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com