py3k feature proposal: field auto-assignment in constructors

[Torsten Bronger]

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 two lines, e.g.
>> 
>>     def __init__(self, id, kind, person, feedname):
>>         self.id, self.kind, self.person = id, kind, person
>
> It's not the number of lines that is important, but the amount of
> redundant code, and the amount of redundant code is identical
> whether you write it in one line or three.

I doubt that there is redunancy.  Don't be misled by the fact that
the string "id" appears twice.  The expession is minimal in both
cases.  The only difference is that in one case you have the string
"id" twice, and in the other case you have a special syntax or even
a new identifier.  The information contents is the same.

> The problem is that instance initialization frequently and
> regularly breaks the principle "Don't Repeat Yourself". [...]

I don't see why.  It say "I want *this* parameter be turned into an
instance variable of the same name".  Why is this repeating myself?

In my opinon, it would be repeating yourself if in *all* __init__s
you want to have *all* parameters turned into instance variables of
the same name.  However, we all know that sometimes the names should
be different, or you want to do some trivial transformation before
the assignment.

Granted that it's a frequent use case which may justify syntactic
sugar, but the straightforward solution is so simple that I think a
new syntax would make the language just slightly more complicated
without simplifying anything really.

> [...]
>
> Here's a thought... why assume that the convention is a prefix? What 
> about a suffix?
>
> @autoassign
> def __init__(self, spam_, ham_, eggs):
>     pass
>
> [...]  Since Python has very few reserved words, and they rarely
> make good argument names, there should be far fewer conflicts with
> an underscore suffix rather than a prefix.

I use them rather frequently, and I see them regularly in the
stdlib, so I think this would cause confusion.

> I'd still prefer compiler support, preferably with a leading & as
> syntax.

Please, no!  ;-)  I like that Python tries to avoid hacker
characters in the code in favour of english words.

Please bear in mind that it is a frequent use case, so you will have
it in virtually every __init__ in fresh Python code.  I prefer to
see instance variables be defined in an brain-friendly explicit way
rather than single characters that hide it.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger at jabber.org
               (See http://ime.webhop.org for further contact info.)