__autoinit__

[Mike Meyer]

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> --- Bengt Richter <bokr at oz.net> wrote:
>> No, that limitation wouldn't exist, so you wouldn't have to explain it ;-)
>> I.e., the above would act like
>> 
>>  class Foo:
>>      x = Bar()
>>      def method_1(self, _anonymous_arg_1):
>>          x.y = _anonymous_arg_1
>> 
>> and would do whatever it would do now (probably look for a global x or a
>> closure cell x, but
>> it wouldn't find the class variable in a normal method call)
>
> I am a bit afraid of opening a door for weird side effects. E.g.
>
> class unrelated: pass
> u = unrelated()
>
> class grouping:
>   def __init__(self, self.x, u.y, self.z):
>     pass
>
> Is this really a good thing to allow? I am afraid it will be abused. My prime
> concern was to provide a good solution for a very common problem. If we stray
> too far from this most important goal we may get nothing in the end.

Remember that what we're suggesting is just syntactic sugar. You can
abuse things the same way by writing:

class grouping:
    def __init__(self, self.x, u_y, self.z):
       u.y = u_y
       del u_y
       pass

Why is this acceptable, but your usage not?

> "self" (or whatever people prefer as a name for the first argument of a bound
> function) *is* special. I think therefore it deserves special support.

Yes, but is it special enough to justify adding a special case to
another construct?

I'm not sure I like the idea of allowing "self.x" yet. But if you're
going to allow it, I don't think it should be restricted.

The question is - how far are you really willing to carry this? What
do you think of allowing arbitrary lvalues, with the assumption that
the previous arguments are all defined (ala let*)? So you could do:

class grouping:
    def __init__(self, x, x['abc']):
        pass

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.