[Python-Dev] reducing self.x=x; self.y=y; self.z=z boilerplate code

[Ralf W. Grosse-Kunstleve]

Josiah Carlson wrote:
> Now, don't get me wrong, definining __slots__ can be a pain in the
> tookus, but with a proper metaclass, that metaclass can define the
> __slots__ attribute based on the argument list for __init__().
> 
> There you go.

Where? The meta-class idea sounds interesting. Could you work it out?

> A syntax change is wholly unnecessary.

I wonder why everybody gets so agitated about a syntax enhancement
proposal. I am not proposing a syntax change!

I know enhancing the syntax is work, but shouldn't a syntax leading to
less code clutter be the higher value? IMO a long-term gain counts for
much more than avoiding a one-time investment implementing a useful
feature. Take, for example, the syntax enhancement supporting "import
foo as bar". I could just as easily write:

  import foo
  bar = foo
  del foo

"A syntax change is wholly unnecessary."
Why was it important enough anyway? It was a good enhancement because
it is clearly more expressive and reduces clutter.

In my experience the self.x=x; self.y=y etc. problem arises much more
often than the problem solved by "import foo as bar". IMO a *built-in*
solution is much more important in practice. Why does everybody have to
reinvent the adopt_init_args/initialize wheel, or have to sheepishly
type self.x=x...?

I am not wedded to the .x idea, but counter-proposals should be at
least approximately as powerful as what I propose.

>     class grouping:
>         def __init__(self, _x, _y, _z):
>             initialize(self, locals())

The "_x" alternative looks interesting but is problematic: it doesn't
have a special meaning so far, but it is also not a syntax error.
You are also not getting rid of the odd (from a learner's viewpoint)
requirement to stick in "locals()".

Remember where Python comes from: it goes back to a teaching language,
enabling non-geeks to write programs. "initialize(self, locals())"
doesn't fit that bill, especially if you have to import initialize
first. In contrast

          def __init__(self, .x, .y, .z):
                       ^^^^^^^^
almost looks like      ^^^^^^
                       self.x

and should therefore be easy to learn and remember.
I'd also be happy with

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

which wouldn't be too different from unpacking tuples (and is currently
a syntax error).
However, remember, elegance = power/length. .x above has the same power
as self.x, but is shorter, therefore more elegant. :)

Hoping-that-this-leads-to-some-consensus-for-a-*built-in*-solution-ly yours,
        Ralf