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 -- http://mail.python.org/mailman/listinfo/python-list
