py3k feature proposal: field auto-assignment in constructors
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Sun Jan 27 20:47:18 EST 2008
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 an appropriate place for it.
> Not sure where though. If there were a classtools module....
-1/2
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.
I suppose you could write __foo for a private name, and ___foo for a
*really* private name, relying on the decorator to strip one of the
underscores. But counting all those underscores is a PITA, and what
happens if you don't actually want that private name set as an instance
attribute?
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 annotations
(in Python3), *args and **kwargs, _ private names, and now we want to add
auto-assignment.
If we do get syntax support, I vote +1 on &foo, +1/2 on @foo, -1 on .foo
and -1 on self.foo. (It's explicit, but it's long...).
--
Steven
More information about the Python-list
mailing list