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:
bar = 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
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 ^^^^^^
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. :)