Re: py3k feature proposal: field auto-assignment in constructors

Hi, I appreciate everyone's feedback on the topic. Having reflected on what has been said here, I now realize that creating more complexity is not the way to go. I would rather favor something that relies on existing language features, something like the default keyword argument assignment in fun

Re: py3k feature proposal: field auto-assignment in constructors

"André" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |Here's a version that |1. does not require new syntax |2. does not *necessarily* override the "_" prefix convention 'self_' is way too bulky and intrusive. Putting '_' at the end of the word is nearly as easy to detect and co

Re: py3k feature proposal: field auto-assignment in constructors

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I don't like the name convention. _name already has a perfectly good | convention: it's a private name, don't mess with it. That includes in | function/method signatures. With your convention, _foo is public. Since l

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 10:27 pm, Tim Chase <[EMAIL PROTECTED]> wrote: > > I've modified my little decorator (see Test1, Test2, Test3 for > > usage). I'll post it later on the cookbook if there seems to be no > > bugs and noone raises valid point against it:) > > One other area that was mentioned obliquely: p

Re: py3k feature proposal: field auto-assignment in constructors

> I've modified my little decorator (see Test1, Test2, Test3 for > usage). I'll post it later on the cookbook if there seems to be no > bugs and noone raises valid point against it:) One other area that was mentioned obliquely: preservation of docstrings (and other function attributes) I could

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 4:08 pm, "André" <[EMAIL PROTECTED]> wrote: [...] > If I may suggest, I would extend this so that autoassign's signature > would be as follows: > > autoassign(all=True, include_only=None, exclude=None) > > Either one of include_only or exclude could be a list of function to > which the a

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 4:30 am, Tim Chase <[EMAIL PROTECTED]> wrote: > I've seen some folks import inspect/functools, but from my > testing, the __init__ method in question has a .func_code object > that already has the varnames in it. in py3k f.func_code gives way to f.__code__, this is why inspect may be pr

Re: py3k feature proposal: field auto-assignment in constructors

Paddy a écrit : (snip) > Is it not possible to write a function that queries its call stack > when run to find the name of all arguments and locals() of the level > above > so you could write: > > class test(object): > def __init__(self, x, y): > arg2inst() > > and automatically assign se

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 11:45 am, Steven Bethard <[EMAIL PROTECTED]> wrote: > Arnaud Delobelle wrote: > > Sligthly improved (not for performance! but signature-preserving and > > looks for default values) > > > from functools import wraps > > from inspect import getargspec > > from itertools import izip, chain

Re: py3k feature proposal: field auto-assignment in constructors

Arnaud Delobelle wrote: > Sligthly improved (not for performance! but signature-preserving and > looks for default values) > > from functools import wraps > from inspect import getargspec > from itertools import izip, chain > > def autoassign(*names): > def decorator(f): > fargnames,

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 4:47 am, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Sun, 27 Jan 2008 23:51:28 -0200, Arnaud Delobelle > <[EMAIL PROTECTED]> escribió: > > > Nice! I've got a slight variation without magic argument names: > > > class Test(object): > > @autoassign('foo', 'bar') > > def

Re: py3k feature proposal: field auto-assignment in constructors

On Mon, 28 Jan 2008 19:21:48 +1100, Ben Finney wrote: > In fact, here's a variation that doesn't even need a language > change:: > > >>> class Foo(object): > ... def __init__(self, spam, eggs, beans): > ... self.__dict__.update(dict( > ... (name, value) for

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 12:21 am, Ben Finney <[EMAIL PROTECTED]> wrote: > "Russ P." <[EMAIL PROTECTED]> writes: > > OK, then how about a special function that could be called from > > inside the constructor (or anywhere else for that matter) to > > initialize a list of data members. For example, > > > self.__se

Re: py3k feature proposal: field auto-assignment in constructors

Hallöchen! Steven D'Aprano writes: > On Mon, 28 Jan 2008 08:04:05 +0100, Torsten Bronger wrote: > >>> Are you referring to the alternate syntax or to the decorator? Either >>> way, you could be saving 4 or 5 or more lines, if you have enough >>> arguments. >> >> Mostly, I write them in one or tw

Re: py3k feature proposal: field auto-assignment in constructors

"Russ P." <[EMAIL PROTECTED]> writes: > OK, then how about a special function that could be called from > inside the constructor (or anywhere else for that matter) to > initialize a list of data members. For example, > > self.__set__(host, port, protocol, bufsize, > timeout) > > This would b

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 11:47 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Mon, 28 Jan 2008 08:04:05 +0100, Torsten Bronger wrote: > >> Are you referring to the alternate syntax or to the decorator? Either > >> way, you could be saving 4 or 5 or more lines, if you have enough > >> argu

Re: py3k feature proposal: field auto-assignment in constructors

On Mon, 28 Jan 2008 08:04:05 +0100, Torsten Bronger wrote: >> Are you referring to the alternate syntax or to the decorator? Either >> way, you could be saving 4 or 5 or more lines, if you have enough >> arguments. > > Mostly, I write them in one or two lines, e.g. > > def __init__(self, id,

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 5:06 pm, coldpizza <[EMAIL PROTECTED]> wrote: > There is a pattern that occurs fairly often in constructors in Python > and other OOP languages. > > Let's take an example: > > class Server(object): > def __init__(self, host, port, protocol, bufsize, timeout): > self.host = ho

Re: py3k feature proposal: field auto-assignment in constructors

Hallöchen! Dustan writes: > On Jan 27, 12:41 pm, Torsten Bronger <[EMAIL PROTECTED]> > wrote: > >> [...] >> >> Well, you save one or two lines per class. Not enough in my >> opinion. > > Are you referring to the alternate syntax or to the decorator? > Either way, you could be saving 4 or 5 or mo

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 7:33 pm, Ben Finney <[EMAIL PROTECTED]> wrote: > "Russ P." <[EMAIL PROTECTED]> writes: > > On Jan 27, 5:13 pm, Wildemar Wildenburger > > <[EMAIL PROTECTED]> wrote: > > > class Server(object): > > > def __init__(self, self.host, self.port, > > > self.protocol, self.

Re: py3k feature proposal: field auto-assignment in constructors

En Sun, 27 Jan 2008 23:51:28 -0200, Arnaud Delobelle <[EMAIL PROTECTED]> escribió: > Nice! I've got a slight variation without magic argument names: > > class Test(object): > @autoassign('foo', 'bar') > def __init__(self, baz): > print 'baz =', baz > En Mon, 28 Jan 2008 00:0

Re: py3k feature proposal: field auto-assignment in constructors

> This is neat. :) Could that maybe be extended to only assign selected > args to the instance and let others pass unchanged. So that, for instance: > > @autoassign("foo", "bar") > def __init__(self, foo, bar, baz): > super(baz) I've seen some folks import inspect/functools, but from my tes

Re: py3k feature proposal: field auto-assignment in constructors

"Russ P." <[EMAIL PROTECTED]> writes: > On Jan 27, 5:13 pm, Wildemar Wildenburger > <[EMAIL PROTECTED]> wrote: > > class Server(object): > > def __init__(self, self.host, self.port, > > self.protocol, self.bufsize, self.timeout): > > pass > > > > ? > > That makes s

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 10:57 pm, Paul Rubin wrote: > Wildemar Wildenburger <[EMAIL PROTECTED]> writes: > > class Server(object): > > def __init__(self, self.host, self.port, > > self.protocol, self.bufsize, self.timeout): > > pass > > ? > > That could

Re: py3k feature proposal: field auto-assignment in constructors

Wildemar Wildenburger <[EMAIL PROTECTED]> writes: > class Server(object): > def __init__(self, self.host, self.port, > self.protocol, self.bufsize, self.timeout): > pass > ? That could temporarily bind those attributes but it shouldn't persistently mutate the object

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 5:13 pm, Wildemar Wildenburger <[EMAIL PROTECTED]> wrote: > Ben Finney wrote: > > "André" <[EMAIL PROTECTED]> writes: > > >> Personally, I like the idea you suggest, with the modification that I > >> would use "." instead of "@", as in > > >> class Server(object): > >> def __init__(s

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 9:47 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Sun, 27 Jan 2008 19:13:27 -0500, Terry Reedy wrote: > > [snip] > > > class Test(object): > > @autoassign > > def __init__(self, _foo, _bar, baz): > > print 'baz =', baz > > [snip] > > > I think

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 1:47 am, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: [...] > As nice as this feature would be, and I vote +2 on the functionality, I > wonder whether the amount of line noise in method definitions now will be > approaching Perlish levels? We've got default values, type

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 6:32 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Wildemar Wildenburger schrieb: > > > André wrote: > >> Personally, I like the idea you suggest, with the modification that I > >> would use "." instead of "@", as in > > >> class Server(object): > >>     def __init__(self, .host, .

Re: py3k feature proposal: field auto-assignment in constructors

On Sun, 27 Jan 2008 19:13:27 -0500, Terry Reedy wrote: [snip] > class Test(object): > @autoassign > def __init__(self, _foo, _bar, baz): > print 'baz =', baz [snip] > I think this version, with this name convention, is nice enough to > possibly go in the stdlib if there were

Re: py3k feature proposal: field auto-assignment in constructors

Paul McGuire wrote: > I thought at one time there was to be a "decorators" module in the > stdlib for just this kind of useful item. At minimum, you could post > this to the Python wiki at http://wiki.python.org/moin/PythonDecoratorLibrary. Please take the idea to the Python developer list. Seve

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 28, 1:01 am, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Mon, 28 Jan 2008 00:39:02 +0100, Wildemar Wildenburger wrote: > > Dustan wrote: > >>> Well, you save one or two lines per class. Not enough in my opinion. > > >> Are you referring to the alternate syntax or to t

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 6:13 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > > I think this version, with this name convention, is nice enough to possibly > go in the stdlib if there were an appropriate place for it.  Not sure where > though.  If there were a classtools module > > tjr +1 I thought at one t

Re: py3k feature proposal: field auto-assignment in constructors

Ben Finney wrote: > "André" <[EMAIL PROTECTED]> writes: > >> Personally, I like the idea you suggest, with the modification that I >> would use "." instead of "@", as in >> >> class Server(object): >> def __init__(self, .host, .port, .protocol, .bufsize, .timeout): >> pass > > -1. >

Re: py3k feature proposal: field auto-assignment in constructors

On Mon, 28 Jan 2008 00:39:02 +0100, Wildemar Wildenburger wrote: > Dustan wrote: >>> Well, you save one or two lines per class. Not enough in my opinion. >> >> Are you referring to the alternate syntax or to the decorator? Either >> way, you could be saving 4 or 5 or more lines, if you have enou

Re: py3k feature proposal: field auto-assignment in constructors

"André" <[EMAIL PROTECTED]> writes: > Personally, I like the idea you suggest, with the modification that I > would use "." instead of "@", as in > > class Server(object): > def __init__(self, .host, .port, .protocol, .bufsize, .timeout): > pass -1. That leading dot is too easy to m

Re: py3k feature proposal: field auto-assignment in constructors

"André" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] If one goes back to the original idea instead, the decision of using automatic assignment should depend on the signature of the __init__ function. Here's an implementation (using "_" instead of "." as it would lead to a syntax e

Re: py3k feature proposal: field auto-assignment in constructors

Dustan wrote: >> Well, you save one or two lines per class. Not enough in my >> opinion. > > Are you referring to the alternate syntax or to the decorator? Either > way, you could be saving 4 or 5 or more lines, if you have enough > arguments. OK, but then again, every decent IDE should give you

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 12:41 pm, Torsten Bronger <[EMAIL PROTECTED]> wrote: > Hallöchen! > > > > Wildemar Wildenburger writes: > > André wrote: > > >> Personally, I like the idea you suggest, with the modification > >> that I would use "." instead of "@", as in > > >> class Server(object): > >> def __init_

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 2:48 pm, Wildemar Wildenburger <[EMAIL PROTECTED]> wrote: > Diez B. Roggisch wrote: > > Just for the fun of it, I implemented a decorator: > > > from functools import * > > from inspect import * > > > def autoassign(_init_): > > @wraps(_init_) > > def _autoassign(self, *args, **k

Re: py3k feature proposal: field auto-assignment in constructors

Diez B. Roggisch wrote: > Just for the fun of it, I implemented a decorator: > > from functools import * > from inspect import * > > def autoassign(_init_): > @wraps(_init_) > def _autoassign(self, *args, **kwargs): > argnames, _, _, _ = getargspec(_init_) > for name, valu

Re: py3k feature proposal: field auto-assignment in constructors

Hallöchen! Wildemar Wildenburger writes: > André wrote: > >> Personally, I like the idea you suggest, with the modification >> that I would use "." instead of "@", as in >> >> class Server(object): >> def __init__(self, .host, .port, .protocol, .bufsize, .timeout): >> pass > > I like

Re: py3k feature proposal: field auto-assignment in constructors

Wildemar Wildenburger schrieb: > André wrote: >> Personally, I like the idea you suggest, with the modification that I >> would use "." instead of "@", as in >> >> class Server(object): >> def __init__(self, .host, .port, .protocol, .bufsize, .timeout): >> pass >> > I like :) > > Howev

Re: py3k feature proposal: field auto-assignment in constructors

André wrote: > Personally, I like the idea you suggest, with the modification that I > would use "." instead of "@", as in > > class Server(object): > def __init__(self, .host, .port, .protocol, .bufsize, .timeout): > pass > I like :) However, you can probably cook up a decorator for

Re: py3k feature proposal: field auto-assignment in constructors

On Jan 27, 1:06 pm, coldpizza <[EMAIL PROTECTED]> wrote: > There is a pattern that occurs fairly often in constructors in Python > and other OOP languages. > > Let's take an example: > > class Server(object): > def __init__(self, host, port, protocol, bufsize, timeout): > self.host = ho

py3k feature proposal: field auto-assignment in constructors

There is a pattern that occurs fairly often in constructors in Python and other OOP languages. Let's take an example: class Server(object): def __init__(self, host, port, protocol, bufsize, timeout): self.host = host self.port = port self.protocol = protocol se