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

--- falcon <[EMAIL PROTECTED]> wrote: > Hello python-list, > > As I Understood, semantic may be next: > > def qwerty(a,a.i,b,b.i,f.j): > pass > > Would work like: > > def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5): > > (a,a.i,b,b.i,f.j)=(anonymous1,anonymo

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

Hello python-list, As I Understood, semantic may be next: def qwerty(a,a.i,b,b.i,f.j): pass Would work like: def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5): (a,a.i,b,b.i,f.j)=(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5) del anonymous1

Re: __autoinit__

--- Mike Meyer <[EMAIL PROTECTED]> wrote: > Remember that what we're suggesting is just syntactic sugar. BTW: That's true for all high-level language constructs. You could do everything in machine language. A good language is the sum of lots of syntactic sugar... selected with taste. :) > You can

Re: __autoinit__

On Mon, 11 Jul 2005 19:37:03 -0400, Mike Meyer <[EMAIL PROTECTED]> 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 gro

Re: __autoinit__

"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes: > --- Bengt Richter <[EMAIL PROTECTED]> 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): >

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

e 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

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

On Mon, 11 Jul 2005 15:37:35 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >Dan Sommers wrote: > >> Without thinking it all the way through, I suppose these: >> >>def method_1(self, *self.l): >>pass >>def method_2(self, **self.d): >>pass >> >> could act as if the

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

On Mon, 11 Jul 2005 01:44:07 -0400, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > >"Bengt Richter" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Me too. I liked the leading _, but on second thought it is a weird >> language change >> re names in a special context. Probably not so

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

Dan Sommers wrote: > Without thinking it all the way through, I suppose these: > >def method_1(self, *self.l): >pass >def method_2(self, **self.d): >pass > > could act as if they were these: > > def method_1(self, *args): > self.l = args > del args >

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

On Mon, 11 Jul 2005 08:34:45 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > Kay Schluehr wrote: >> Dan Sommers schrieb: >> >>> How about this: >>> >>> def __init__(self, self.x, y, self.z): >>> # self.x, self.z from first and third explicit parameters >>> do_something_with_y() >> >> Ca

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

Reinhold Birkenfeld schrieb: > Kay Schluehr wrote: > > Dan Sommers schrieb: > > > >> How about this: > >> > >> def __init__(self, self.x, y, self.z): > >> # self.x, self.z from first and third explicit parameters > >> do_something_with_y() > > > > Can you tell me in which way it

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

Kay Schluehr wrote: > Dan Sommers schrieb: > >> How about this: >> >> def __init__(self, self.x, y, self.z): >> # self.x, self.z from first and third explicit parameters >> do_something_with_y() > > Can you tell me in which way it is anyhow better than the original > proposal

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

"Bengt Richter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Me too. I liked the leading _, but on second thought it is a weird > language change > re names in a special context. Probably not so good. To repeat: while my '_' proposal could have been for a language change (in 3

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

Dan Sommers schrieb: > How about this: > > def __init__(self, self.x, y, self.z): > # self.x, self.z from first and third explicit parameters > do_something_with_y() Can you tell me in which way it is anyhow better than the original proposal def __init__(self, .x, y, .z)

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

On 10 Jul 2005 16:07:40 -0700, Paul Rubin wrote: >Dan Sommers <[EMAIL PROTECTED]> writes: >> def __init__(self, self.x, y, self.z): >> # self.x, self.z from first and third explicit parameters >> do_something_with_y() > >Hey, I like that. Me too. I l

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

On Sun, 10 Jul 2005 20:11:38 -0400, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Dan Sommers" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> That's a pretty big change; now all formal parameters beginning with >> an underscore have a brand new meaning. > As I said, 'in combinat

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

"Dan Sommers" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, 10 Jul 2005 16:26:24 -0400, > "Terry Reedy" <[EMAIL PROTECTED]> wrote: >> I have a suggestion I don't remember seeing for flagging which vars to >> autoinit without new syntax: use '_' instead of '.'. I have neve

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

Dan Sommers <[EMAIL PROTECTED]> writes: > def __init__(self, self.x, y, self.z): > # self.x, self.z from first and third explicit parameters > do_something_with_y() Hey, I like that. -- http://mail.python.org/mailman/listinfo/python-list

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

On Sun, 10 Jul 2005 16:26:24 -0400, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > I have a suggestion I don't remember seeing for flagging which vars to > autoinit without new syntax: use '_' instead of '.'.

AST decoration vs byte-code-munging (Was: Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code))

On Sun, 10 Jul 2005 16:26:24 -0400, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > >"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] > >I have a suggestion I don't remember seeing for flagging which vars to >autoinit without new syntax: use '_' instead of '.'.

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

"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I have a suggestion I don't remember seeing for flagging which vars to autoinit without new syntax: use '_' instead of '.'. I have never seen local vars with a leading '_'. So, in combination with whatever

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

ed in the constructor. Under your proposal the decision to use "auto init" becomes a visible part of the user interface and may therefore be irreversible in practical applications. > > My __autoinit__ suggestion would result in (assuming object supports > > this by default):

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

mentation. I would never accept dropping fine-tuning capabilities. The "auto_" prefix is all the declarative magic. > My __autoinit__ suggestion would result in (assuming object supports > this by default): > > class grouping(object): > def __autoinit__(self, x, y, z): &g

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

--- Scott David Daniels <[EMAIL PROTECTED]> wrote: > Should be: > class autoinit(object): > def __init__(self, *args, **keyword_args): > for name, value in zip(self.__autoinit__.im_func.func_code. >

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

it__(self, *args, **keyword_args): > self.__dict__.update( > zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args)) > self.__dict__.update(keyword_args) > self.__autoinit__(*args, **keyword_args) Should be: class autoinit(object): def __init__(self, *args, *

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

plain_adopt_grouping: def __init__(self, x, y, z): plain_adopt() class autoinit(object): def __init__(self, *args, **keyword_args): self.__dict__.update( zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args)) self.__dict__.update(keyword_args) self.__autoinit__

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

--- Kay Schluehr <[EMAIL PROTECTED]> wrote: > Ralf, if you want to modify the class instantiation behaviour you I don't. I simply want to give the user a choice: __init__(self, ...) # same as always (no modification) or __autoinit__(self, ...) # self.x=x job done aut

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

Ralf W. Grosse-Kunstleve schrieb: > My initial proposal > (http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't > exactly get a warm welcome... Well ... yes ;) Ralf, if you want to modify the class instantiation behaviour you should have a look on metaclasses. That's what they

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

My initial proposal (http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't exactly get a warm welcome... And Now for Something Completely Different: class autoinit(object): def __init__(self, *args, **keyword_args): self.__dict__.update( zip(self.__autoi