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

[Terry Reedy]

"Dan Sommers" <me at privacy.net> wrote in message 
news:m2ll4euv02.fsf at unique.fully.qualified.domain.name.yeah.right...
> On Sun, 10 Jul 2005 16:26:24 -0400,
> "Terry Reedy" <tjreedy at udel.edu> wrote:
>> I have a suggestion I don't remember seeing for flagging which vars to
>> autoinit without new syntax: use '_' instead of '.'.  I have never seen
>> local vars with a leading '_'.  So, in combination with whatever other
>> mechanism (metaclass, __init__ decorator?)
>
>>    def __init__(self, _x, y, _z) :
>
>> would automatically do self.x = _x, self.z = _z, but not self.y = y.
>
>> Terry J. Reedy
>
> That's a pretty big change; now all formal parameters beginning with an
> underscore have a brand new meaning.

As I said, 'in combination with whatever other mechanism', meaning one that 
one has to intentionally invoke.  So there would be no code breaking: the 
suggestion is for a convention used with currently available mechanism 
(assuming that such is possible) that would give the fine-grained control 
not so easily possible with the current update_dict_with_locals idiom.

It would be easier to write the decorator if it were passed the (quoted) 
names of the parameters to be 'attributed'.  But then the user would have 
to write and keep in synchrony two lists, one a (quoted) subset of the 
other.  So I thought it better to have the decorator writer and decorator 
function work a little harder to introspect and interpret one list with 
some items marked somehow in a currently legal but unusual manner.

> How about this:
>
>    def __init__(self, self.x, y, self.z):
>        # self.x, self.z from first and third explicit parameters

This is new syntax that is not currently legal.  My suggestion was for a 
solution that avoided that difficulty and that could, I believe, be 
implemented now, in less time that this thread has been going on, rather 
than maybe some years from now.

Terry J. Reedy