Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code
Bengt Richter
bokr at oz.net
Sun Jul 3 15:50:29 EDT 2005
On Sat, 02 Jul 2005 13:50:25 GMT, "Andrew Koenig" <ark at acm.org> wrote:
>"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message
>news:mailman.1236.1120298654.10512.python-list at python.org...
>
>> class grouping:
>>
>> def __init__(self, .x, .y, .z):
>> # real code right here
>
>> Emulation using existing syntax::
>
>> def __init__(self, x, y, z):
>> self.x = x
>> del x
>> self.y = y
>> del y
>> self.z = z
>> del z
>
>I think this is a bad idea, for a subtle reason.
>
>In Python, unlike many other languages, the names of formal parameters are
>part of a function's interface. For example:
>
> def f(x, y):
> return x-y
>
>Now f(3, 4) is -1 and f(y=3,x=4) is 1.
>
>The names of instance variables are generally not part of a class'
>interface--they are part of its implementation.
>
>This proposed feature, whenever used, would tie a class' implementation to
>the interface of every method that uses the feature. As far as I can see,
>it is impossible to use the feature without constraining the implementation
>in this way.
>
>For this reason, I would much rather have the mapping between parameter
>names and instance variables be explicit.
>
>
What if parameter name syntax were expanded to allow dotted names as binding
targets in the local scope for the argument or default values? E.g.,
def foometh(self, self.x=0, self.y=0): pass
would have the same effect as
def foometh(self, self.y=0, self.x=0): pass
and there would be a persistent effect in the attributes of self
(whatever object that was), even with a body of pass.
I'm not sure about foo(self, **{'self.x':0, 'self.y':0}), but if
you didn't capture the dict with a **kw formal parameter, IWT you'd
have to be consistent and effect the attribute bindings implied.
(Just a non-thought-out bf here, not too serious ;-)
Regards,
Bengt Richter
More information about the Python-list
mailing list