Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code

[Gregory K. Johnson]

On Sat, Jul 02, 2005 at 03:04:09AM -0700, Ralf W. Grosse-Kunstleve wrote:
[...]
> Minimal proposal
> ----------------
> 
> My minimal proposal is to add an enhanced version of ``adopt_init_args()``
> as a standard Python built-in function (actual name secondary!)::
> 
>     class grouping:
> 
>         def __init__(self, x, y, z):
>             adopt_init_args()
>             # real code
[...]
> Enhanced syntax proposal
> ------------------------
> 
> The exclusion problem suggests these alternatives::
> 
>   class grouping:
> 
>       def __init__(self, self.keep_this, self.and_this, but_not_this,
> self.but_this_again):
>           # real code right here
[...]
> A shorter alternative (my personal favorite since minimally redundant)::
> 
>   class grouping:
> 
>       def __init__(self, .keep_this, .and_this, but_not_this, .but_this_again):
>           # real code right here
[...]
> P.S.: If you reply to this message, please clearly separate
> naming/syntax issues from the core issue of providing built-in support
> designed to reduce clutter.

I share many of the qualms of those who responded to your earlier post.
(Is this really a problem? Can't a good editor save you the typing?
Explicit is better than implicit, and all that.)

But it also occurs to me to ask: Is a function-definition syntax
extension really appropriate when it's only likely usefulness is for the
particular function called __init__()? That seems more un-Pythonic to me
than straightforward, idiomatic, but somewhat verbose boilerplate.

An adoptargs([excluded=None]) builtin or similar seems much more viable.
(Although even there I don't feel any pressing need: I'm content with
"self.x = x".)

-- 
Gregory K. Johnson