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

Bengt Richter bokr at oz.net
Sun Jul 3 21:50:29 CEST 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