Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code)

Discussion in 'Python' started by Ralf W. Grosse-Kunstleve, Jul 11, 2005.

  1. --- Bengt Richter <> wrote:
    > >I still think it's too specialized. What would, hypothetically, this do?
    > >
    > >class Bar: pass
    > >
    > >class Foo:
    > > x = Bar()
    > > def method_1(self, x.y):
    > > pass
    > >
    > >It's hard to explain that you can autoassign self.y but not x.y.
    > >

    > 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.

    "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.

    I think it would be fantastic if we could push through the

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

    syntax, with the explicit limitation that only the first argument can be used
    on the left side of the dot. I'd also happily settle for a decorator approach,
    __autoinit__ or over variations, as long as they are built-in and easy to
    remember/use/explain to a novice. However, to me the self.x approach seems to
    be "just right" because:

    1. It is a good compromise between "redundant" and "explicit"; i.e.:

    too redundant:

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

    middle ground:

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

    the other extreme:

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

    I am thinking people can understand the "middle ground" approach even
    without looking at release notes and will not be surprised if unrelated.y
    doesn't work.

    2. This approach is open to full optimization for runtime performance
    and should therefore be faster than the redundant conventional
    approach. I.e. the arguments can directly be inserted into the
    desired dictionary (or slot), without ever being added to locals().

    3. The user can always write "grouping(x=1,y=2,z=3)". I.e. how the
    arguments are used is strictly an implementation detail, as it
    should be.

    Cheers,
    Ralf




    ____________________________________________________
    Sell on Yahoo! Auctions – no fees. Bid on great items.
    http://auctions.yahoo.com/
     
    Ralf W. Grosse-Kunstleve, Jul 11, 2005
    #1
    1. Advertising

  2. Ralf W. Grosse-Kunstleve

    Mike Meyer Guest

    Re: __autoinit__

    "Ralf W. Grosse-Kunstleve" <> writes:

    > --- Bengt Richter <> 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 <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Jul 12, 2005
    #2
    1. Advertising

  3. Ralf W. Grosse-Kunstleve

    Dan Sommers Guest

    Re: __autoinit__

    On Mon, 11 Jul 2005 19:37:03 -0400,
    Mike Meyer <> wrote:

    > 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


    Python already implements let*; it's called "tuple unpacking":

    Python 2.3.3 (#1, Mar 9 2004, 14:21:31)
    [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x, x['abc'] = {}, 3
    >>> print x

    {'abc': 3}
    >>> x, x['abc'], x['abc'][4] = {}, range(10), -9999
    >>> print x

    {'abc': [0, 1, 2, 3, -9999, 5, 6, 7, 8, 9]}

    Regards,
    Dan

    --
    Dan Sommers
    <http://www.tombstonezero.net/dan/>
     
    Dan Sommers, Jul 12, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dwok
    Replies:
    2
    Views:
    474
    Lucas Tam
    May 11, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    586
    Lonnie Princehouse
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    18
    Views:
    599
    Bengt Richter
    Jul 11, 2005
  4. falcon
    Replies:
    0
    Views:
    379
    falcon
    Jul 31, 2005
  5. Nick Coghlan

    Reducing import try/except boilerplate

    Nick Coghlan, Dec 21, 2005, in forum: Python
    Replies:
    1
    Views:
    324
    Bengt Richter
    Dec 21, 2005
Loading...

Share This Page