On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:

I often find myself writing __init__ methods of the form:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

This seems a little wordy and uses a lot of vertical space on the screen.

It does, and while both are annoying, in the grand scheme of things they're a very minor annoyance. After all, this is typically only an issue once per class, and not even every class, and vertical space is quite cheap. In general, the barrier for accepting new syntax is quite high, and "minor annoyance" generally doesn't reach it. I'm completely with you about the annoyance factor here. It is especially annoying during the early stages of development when the __init__ method is evolving rapidly (parameters are being renamed, added or removed). One work-around is this pattern: def __init__(self, spam, ham, eggs, cheese, aardvark): vars(self).update(locals()) del self.self ... which is cute but I've never quite been brave enough to use it in production. But I don't think the annoyance factor is high enough, or common enough, to justify syntactic sugar to "fix" it.

Occasionally, I have considered something like:

def __init__(self, foo, bar, baz, spam, ham): self.foo, self.bar, self.baz, self.spam, self.ham = \ foo, bar, baz, spam, ham

... just to make it a bit more compact [...] When I do that I'm torn because I know it has a runtime impact to create and unpack the implicit tuples and I'm also introducing a style asymmetry in my code just because of the number of parameters a method happens to have.

I'm not too worried about the performance impact unless I've profiled my code and it is actually significant. As far as the style asymmetry, if we use your proposed syntax, that's introducing style asymmetry too.

So why not have an augmented assignment operator for object attributes?

Wrong question. Don't ask "why not add this feature?". The question to ask is "why add this feature?" Every new feature has cost, whether it is run-time cost, development cost, feature bloat, learning curve cost, etc, so the feature must be justified as adding sufficiently more value than it costs. Here are a few reasons why this feature fails to meet the barrier for new syntax. - This feature doesn't add any new capability to the language. There's nothing that this feature allows you to do which you couldn't do before. - It has quite narrow applicability. It's really only useful inside a small proportion of __init__ methods. - In my experience, it is very rare to have a whole set of unadorned assignments in the way you show it. MUCH more common is to have some sort of pre-processing of the argument before assignment, or for the assignment target to be different from the parameter name: def __init__(self, spam, eggs, cheese, aardvark, ...): # type checks if not isinstance(spam, Foo): raise TypeError self._spam = spam # not all parameters are public attributes # value checks if eggs < 0: raise ValueError self.eggs = eggs # replacement of None if cheese is None: cheese = make_cheese() self.cheese = cheese # other pre-processing self.mammals = [aardvark, get_weasel()] which reduces the applicability of this syntax even further. - Having big parameter lists is something of a mild code smell. As the parameter list gets bigger, the smell gets worse. Having so many parameters that this feature becomes attractive should be painful, because its a warning that maybe your class has too many parameters.

It addresses one of the same broad issues that the other augmented assignment operators were introduced for (that of repeatedly spelling names).

The suggestion therefore is:

def __init__(self, foo, bar, baz, spam, ham): self .= foo, bar, baz, spam, ham

But there's a major difference between this and the other augmented assignment operators, so major that the analogy between them doesn't hold up. In augmented assignment, the target can be any valid target, and the RHS can be any expression mylist[0].attr['key'] += (some_value() or another) + 99 Your suggestion is very different: there are *many* targets, and the RHS must be a comma-separated list of identifiers. They're quite different kinds of assignment. And unlike augmented assignment, which calls one of the __iop__ methods, this would have to be handled purely as syntax.

This is purely syntactic sugar for the original example:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

... so if any of the attributes have setters, then they are called as usual. It's purely a syntactic shorthand. Any token which is not suitable on the RHS of the dot in a standard "obj.attr =" assignment is a syntax error (no "self .= 1").

Right. And that *seriously* limits the applicability of this. Yes, I've written classes with a dozen or twenty parameters. But especially with long parameter lists, invariably at least *some* of those arguments are pre-processed before assignment to an attribute: self.spam = spam + 1 or are assigned to a different name: self._spam = spam or both: self.foods = [spam, eggs, cheese] So my expectation is that even if this syntax was accepted, I wouldn't use it, because by the time I've processed those assignments, the ones that are left are too few to bother with the special syntax. The bottom line is that I think you've identified a very real, but minor, annoyance, but the applicability of the solution is too low to justify new syntax. -- Steve

On 25 April 2017 at 03:53, Steven D'Aprano wrote:

On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:

...

I often find myself writing __init__ methods of the form:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

This seems a little wordy and uses a lot of vertical space on the screen.

It does, and while both are annoying, in the grand scheme of things they're a very minor annoyance. After all, this is typically only an issue once per class, and not even every class, and vertical space is quite cheap. In general, the barrier for accepting new syntax is quite high, and "minor annoyance" generally doesn't reach it.

I suspect that with a suitably creative use of inspect.signature() you could write a decorator for this: @auto_attrs def __init__(self, a, b, c): # Remaining init code, called with self.a, self.b and self.c set I don't have time to experiment right now, but will try to find time later. If nothing else, such a decorator would be a good prototype for the proposed functionality, and may well be sufficient for the likely use cases without needing a syntax change. Paul

2017. ápr. 25. de. 10:04 ezt írta ("Paul Moore" ): On 25 April 2017 at 03:53, Steven D'Aprano wrote:

On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:

...

I often find myself writing __init__ methods of the form:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

This seems a little wordy and uses a lot of vertical space on the screen.

It does, and while both are annoying, in the grand scheme of things they're a very minor annoyance. After all, this is typically only an issue once per class, and not even every class, and vertical space is quite cheap. In general, the barrier for accepting new syntax is quite high, and "minor annoyance" generally doesn't reach it.

I suspect that with a suitably creative use of inspect.signature() you could write a decorator for this: @auto_attrs def __init__(self, a, b, c): # Remaining init code, called with self.a, self.b and self.c set I don't have time to experiment right now, but will try to find time later. If nothing else, such a decorator would be a good prototype for the proposed functionality, and may well be sufficient for the likely use cases without needing a syntax change. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ Hi, such a decorator would be very grateful ;-) in the standard as for example I use class parameters this way too in more than 90% of the cases. BR George

On 25.04.2017 20:16, Mike Miller wrote:

Also, I did find the decorator proposal intriguing, though have to say I probably wouldn't bother to use it unless it were a builtin or I had a dozen parameters to deal with.

Same here. And practical experience tells me that the usage of this decorator wouldn't last long. In Steven's "early stages of development", the day will come where there is a need for a parameter which must not be an attribute on self. So I prefer the "annoyance" since it's bloody easy to read AND to change. Sven

On 2017-04-25 14:15, Brice PARENT wrote:

But, any of these proposals, mine and yours, if you really need this to shorten the code writing time or vertical space only, is not a better idea than to propose a macro to your IDE editor, or a pull request if it's open source. Such a macro would generate automatically those long-to-write lines, and maybe implement some code folding if vertical space is an issue.

I'm personally not bothered by vertical space, but rather typing the same thing three times with self's and ='s. That's more boilerplate than Java. ;)

On 25 April 2017 at 22:27, Mike Miller wrote:

On 2017-04-25 14:15, Brice PARENT wrote:

...

But, any of these proposals, mine and yours, if you really need this to shorten the code writing time or vertical space only, is not a better idea than to propose a macro to your IDE editor, or a pull request if it's open source. Such a macro would generate automatically those long-to-write lines, and maybe implement some code folding if vertical space is an issue.

I'm personally not bothered by vertical space, but rather typing the same thing three times with self's and ='s. That's more boilerplate than Java. ;)

Well, class MyClass: @auto_args def __init__(self, a, b, c=None): pass seems ideal for you then (using the auto_args decorator from https://twitter.com/judy2k/status/854330478068977664 - a 13-line function including the import of inspect and some comments). (Arguing for auto_args to be in the stdlib may be a better option than arguing for new syntax, BTW...) Paul

On 25/04/17 23:05, Paul Moore wrote:

1. Writing out the assignments "longhand" is an unacceptable burden.

There are reasons why augmented assignment was implemented. One of them was to make the code easier to read: foil = foil + 1 foil = foi1 + 1 foil += 1 Should one be silly enough to have a "foil" and "foi1" variable in scope, only one of those is clearly incrementing a variable without requiring a slightly harder look ;) It's not about the time taken to type the line. It's about the clarity of what the line is expressing.

2. Using a decorator (which can be written directly in your project, doesn't even need to be an external dependency) is unacceptable.

All of the decorators (or other language tricks that modify the object's dict) suggested so far assume that ALL of the method's arguments are to be assigned. I do not want that. I want to be able to say: def __init__(self, foo, bar, baz, spam): self .= foo, bar, spam self.baz = baz * 100 It's all still explicit inside the body of the method.

Add to that the fact that these people would be arguing "I want the ability to avoid writing out the assignments, but I don't want that capability enough to use a decorator"

As I said above, it's not about the effort writing it out. It's about the effort (and accuracy) of reading the code after it has been written. And as I also said above, decorators don't cut it anyway (at least not those proposed) because they blindly assign ALL of the arguments. I'm more than happy to hear of something that solves both of those problems without needing syntax changes though, as that means I can have it today ;) E.

On Tue, Apr 25, 2017 at 4:31 PM, Erik wrote:

On 25/04/17 22:15, Brice PARENT wrote:

...

it may be easier to get something like this (I think, as there is no new operator involved) :

No new operator, but still a syntax change, so that doesn't help from that POV.

...

def __init__(self, *args, **kwargs): self.* = *args self.** = **kwargs

What is "self.* = *args" supposed to do? For each positional argument, what name in the object is it bound to?

E.

For what it's worth, that's what I don't really like about the initially proposed syntax too ... self .= foo, bar, baz works OK, but: tup = foo, bar, baz self .= tup doesn't work. Admittedly, that could be part of the definition of this feature, but it feels really unexpected to all of a sudden give my tuple a temporary name and have the code behave in a dramatically different fashion.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Matt Gilson | Pattern Software Engineer getpattern.com https://www.getpattern.com?utm_source=email&utm_medium=email&utm_campaign=signature-matt

On Wed, Apr 26, 2017 at 10:05 AM, Ryan Gonzalez wrote:

FWIW I always liked Dart's/Ruby's/Crystal's/(Coffee|Moon)Script's/WhateverElse's style:

class Cls { Cls(this.a); // IT'S MAGIC }

but the Python equivalent is admittedly weirder:

def ___init__(self, self.attr):

In a sense, what you have is this (modulo keyword arguments): def __init__(*args): self, self.attr = args which is perfectly legal, albeit weird. So it needn't actually be magic per se, just a change in the definition of an argument name (from NAME to whatever is legal as an assignment target). I don't think it's particularly useful, though. ChrisA

On Tue, Apr 25, 2017 at 6:09 PM, Paul Moore wrote:

(Arguing for auto_args to be in the stdlib may be a better option than arguing for new syntax, BTW...)

Having such a decorator in the stdlib would allow IDEs and syntax highlighters to know what's going on. -- Juancarlo *Añez*

Why not simply do this : class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value) def __init__(self, a, b, c): self._set_multiple(a=a, b=b, c=c) -> No new syntax, no inspection, simple to read, parse and understand, and explicit. And you could directly do some simple cleanings or not define a variable, like : class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value) def __init__(self, a, b, c): self._set_multiple(a=a * 2, b=clean_field(b)) - Brice Le 25/04/17 à 03:08, Erik a écrit :

Hi. I suspect that this may have been discussed to death at some point in the past, but I've done some searching and I didn't come up with much. Apologies if I'm rehashing an old argument ;)

I often find myself writing __init__ methods of the form:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

This seems a little wordy and uses a lot of vertical space on the screen. Occasionally, I have considered something like:

def __init__(self, foo, bar, baz, spam, ham): self.foo, self.bar, self.baz, self.spam, self.ham = \ foo, bar, baz, spam, ham

... just to make it a bit more compact - though in practice, I'd probably not do that with a list quite that long ... two or three items at most:

def __init__(self, foo, bar, baz): self.foo, self.bar, self.baz = foo, bar, baz

When I do that I'm torn because I know it has a runtime impact to create and unpack the implicit tuples and I'm also introducing a style asymmetry in my code just because of the number of parameters a method happens to have.

So why not have an augmented assignment operator for object attributes? It addresses one of the same broad issues that the other augmented assignment operators were introduced for (that of repeatedly spelling names).

The suggestion therefore is:

def __init__(self, foo, bar, baz, spam, ham): self .= foo, bar, baz, spam, ham

This is purely syntactic sugar for the original example:

def __init__(self, foo, bar, baz, spam, ham): self.foo = foo self.bar = bar self.baz = baz self.spam = spam self.ham = ham

... so if any of the attributes have setters, then they are called as usual. It's purely a syntactic shorthand. Any token which is not suitable on the RHS of the dot in a standard "obj.attr =" assignment is a syntax error (no "self .= 1").

The comma-separators in the example are not creating a tuple object, they would work at the same level in the parser as the import statement's comma-separated lists - in the same way that "from pkg import a, b, c" is the same as saying:

import pkg a = pkg.a b = pkg.b c = pkg.c

... "self .= a, b, c" is the same as writing:

self.a = a self.b = b self.c = c

E. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Oleg Broytman Sent: Wednesday, April 26, 2017 7:33 AM To: python-ideas@python.org Subject: Re: [Python-ideas] Augmented assignment syntax for objects.

On Wed, Apr 26, 2017 at 01:12:14PM +0200, Brice PARENT wrote:

...

def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

self.__dict__.update(kwargs)

Touching __dict__ feels dirty to me.

Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 25 April 2017 at 19:30, Erik wrote:

And as I also said above, decorators don't cut it anyway (at least not those proposed) because they blindly assign ALL of the arguments. I'm more than happy to hear of something that solves both of those problems without needing syntax changes though, as that means I can have it today ;)

Sorry - a decorator won't "blindly assign all argments" - it will do that just if it is written to do so. It is perfectly feasible to have a decorator to which you can simply pass a list of not wanted auto-parameters, or that will just auto-assign parameters that have been declared on the class body, or even inspect the function signature and check for special annotations - there are tens of ways we could spec a list of exceptions to such a decorator, and still avouid typing three times each name. That said, I am all in favor of the addition of such a decorator to the stdlib. js -><-

I was wondering that if there are so many arguments to a function that it *looks* ugly, that it might just *be* ugly. For one, too many required arguments to a function (constructor, whatever) is already strange. Binding them as attributes of the object, unmodified in a constructor also seems to be rare. Matplotlib, for example, might take 8 (optional keyword) arguments for a Figure ( https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/figure.p...), but then at a bare minimum, the vertical space required is *doubled* by the need for pesky if-blocks and logic. Self-assignment is a pittance. Are there any better examples of where adding new syntax could help readability for programmers, both new and old? On Wed, Apr 26, 2017 at 9:59 AM, Erik wrote:

On 26/04/17 13:19, Joao S. O. Bueno wrote:

...

On 25 April 2017 at 19:30, Erik wrote:

...

decorators don't cut it anyway (at least not those proposed) because they blindly assign ALL of the arguments. I'm more than happy to hear of something that solves both of those problems without needing syntax changes though, as that means I can have it today ;)

Sorry - a decorator won't "blindly assign all argments" - it will do that just if it is written to do so.

Right, and the three or four variants suggested (and the vars(self).update() suggestion) all do exactly that. I was talking about the specific responses (though I can see my language is vague).

[FWIW I've been using Python the whole time that decorators have existed and I've yet to need to write one - I've _used_ some non-parameterized ones though - so I guess I'd forgotten that they can take parameters]

E.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 26 April 2017 at 16:17, Erik wrote:

On 26/04/17 08:59, Paul Moore wrote:

...

It should be possible to modify the decorator to take a list of the variable names you want to assign, but I suspect you won't like that

Now you're second-guessing me.

Sorry :-)

...

class MyClass: @auto_args('a', 'b') def __init__(self, a, b, c=None): pass

I had forgotten that decorators could take parameters. Something like that pretty much ticks the boxes for me.

Cool. Glad you liked the idea. Paul

On 2017-04-26 04:12, Brice PARENT wrote:

Why not simply do this :

class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

def __init__(self, a, b, c): self._set_multiple(a=a, b=b, c=c)

If the goal is to not have to type out argument names three times (in DRY fashion), this doesn't quite fit the bill. -Mike

On 2017-04-26 18:46, Mike Miller wrote:

On 2017-04-26 04:12, Brice PARENT wrote:

...

Why not simply do this :

class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

def __init__(self, a, b, c): self._set_multiple(a=a, b=b, c=c)

If the goal is to not have to type out argument names three times (in DRY fashion), this doesn't quite fit the bill.

An alternative is to use a special comment, for example: class MyClass: def __init__(self, a, b, c): #> a, b, c And then use, say, a Python script to expand it to: class MyClass: def __init__(self, a, b, c): #> a, b, c self.a = a self.b = b self.c = c #< The Python script could be called from the editor. If you want to add or remove an argument, edit the comment and then run the script again. (Hopefully it'll be smart enough to make the necessary changes).

Le 26/04/17 à 19:46, Mike Miller a écrit :

On 2017-04-26 04:12, Brice PARENT wrote:

...

Why not simply do this :

class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

def __init__(self, a, b, c): self._set_multiple(a=a, b=b, c=c)

If the goal is to not have to type out argument names three times (in DRY fashion), this doesn't quite fit the bill.

-Mike

You still save some typing (no need for /self./ for every assignment), and a lot of vertical space. Also, it allows you to use any dict (like **kwargs) as well as doing very common things like : class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value) def __init__(self, a, b, c): self._set_multiple(a=a, _b=b) which is equivalent to the following really common pattern : class MyClass: def __init__(self, a, b, c): self.a = a self._b = b (well, I didn't try it, but it should work) This means your public API (the signature of the constructor here) has no incidence on the way the class works on the inside. Meaning an attribute can become a property, which is something that occurs from time to time, and you just need to update your constructor (self._set_multiple(a=a, b=b) becomes self._set_multiple(a=a, _b=b)) and you're done. And if at some point your community doesn't think "a" is a good name for your variable, you can update it to something every user will understand without any significant change to your class (self._set_multiple(a=way_better, _b=b)). -Brice

On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:

def ___init__(self, self.attr):

I'm not a python developer, I'm just a developer that uses python. That said, I really like this form. It eliminates most of the redundancy, while still being explicit. It's true that you have to repeat the 'self' name, but it feels like the right balance in my mind. It seems like anyone who's familiar with python function definitions would immediately grasp what's going on. -- Jerry

On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:

The background is that what I find myself doing a lot of for private projects is importing data from databases into a structured collection of objects and then grouping and analyzing the data in different ways before graphing the results.

So yes, I tend to have classes that accept their entire object state as parameters to the __init__ method (from the database values) and then any other methods in the class are generally to do with the subsequent analysis (including dunder methods for iteration, rendering and comparison etc).

You may want to try designing your objects as namedtuples. That gives you a lot of what you're looking for. ChrisA

On 26 April 2017 at 21:51, Erik wrote:

It doesn't make anything more efficient, however all of the suggestions of how to do it with current syntax (mostly decorators) _do_ make things less efficient.

Is instance creation the performance bottleneck in your application? That seems unusual. I guess it's possible if you're reading a large database file and creating objects for each row. But in that case, as Chris A says, you may be better with something like a named tuple. In any case, optimising for performance is not what generic solutions are good at, so it's not surprising that a generic decorator involves a performance hit. Paul

On 26/04/2017 21:50, Chris Angelico wrote:

On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:

...

The background is that what I find myself doing a lot of for private projects is importing data from databases into a structured collection of objects and then grouping and analyzing the data in different ways before graphing the results.

So yes, I tend to have classes that accept their entire object state as parameters to the __init__ method (from the database values) and then any other methods in the class are generally to do with the subsequent analysis (including dunder methods for iteration, rendering and comparison etc).

You may want to try designing your objects as namedtuples. That gives you a lot of what you're looking for.

ChrisA

Something like https://docs.python.org/3/library/sqlite3.html#row-objects ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 26/04/17 19:15, Mike Miller wrote:

As the new syntax ideas piggyback on existing syntax, it doesn't feel like that its a complete impossibility to have this solved. Could be another "fixed papercut" to drive Py3 adoption. Taken individually not a big deal but they add up.

*sigh* OK, this has occurred to me over the last couple of days but I didn't want to suggest it as I didn't want the discussion to fragment even more. But, if we're going to bikeshed and there is some weight behind the idea that this "papercut" should be addressed, then given my previous comparisons with importing, what about having 'import' as an operator: def __init__(self, a, b, c): self import a, b self.foo = c * 100 Also allows renaming: def __init__(self, a, b, c): self import a, b, c as _c Because people are conditioned to think the comma-separated values after "import" are not tuples, perhaps the use of import as an operator rides on that wave ... (I do realise that blurring the lines between statements and operators like this is probably not going to work for technical reasons (and it just doesn't quite read correctly anyway), but now we're bikeshedding and who knows what someone else might come up with in response ...). E.

Yes, I like it too. Removes the triple repetition, and has precedent in the other languages. On 2017-04-26 12:54, Jerry Hill wrote:

On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:

...

def ___init__(self, self.attr):

I'm not a python developer, I'm just a developer that uses python. That said, I really like this form. It eliminates most of the redundancy, while still being explicit. It's true that you have to repeat the 'self' name, but it feels like the right balance in my mind.

On 2017-04-26 23:29, Erik wrote:

On 26/04/17 19:15, Mike Miller wrote:

...

As the new syntax ideas piggyback on existing syntax, it doesn't feel like that its a complete impossibility to have this solved. Could be another "fixed papercut" to drive Py3 adoption. Taken individually not a big deal but they add up.

*sigh* OK, this has occurred to me over the last couple of days but I didn't want to suggest it as I didn't want the discussion to fragment even more.

But, if we're going to bikeshed and there is some weight behind the idea that this "papercut" should be addressed, then given my previous comparisons with importing, what about having 'import' as an operator:

def __init__(self, a, b, c): self import a, b self.foo = c * 100

Also allows renaming:

def __init__(self, a, b, c): self import a, b, c as _c

Because people are conditioned to think the comma-separated values after "import" are not tuples, perhaps the use of import as an operator rides on that wave ...

(I do realise that blurring the lines between statements and operators like this is probably not going to work for technical reasons (and it just doesn't quite read correctly anyway), but now we're bikeshedding and who knows what someone else might come up with in response ...).

If we're going to bikeshed, then: def __init__(self, a, b, c): for self import a, b self.foo = c * 100 and: def __init__(self, a, b, c): for self import a, b, c as _c

*cough* I'll just drop this here a sec *cough*: https://code.activestate.com/recipes/580790-auto-assign-self-attributes-in-_... On Thu, Apr 27, 2017 at 10:24 AM, Nick Coghlan wrote:

On 25 April 2017 at 11:08, Erik wrote:

...

Hi. I suspect that this may have been discussed to death at some point in the past, but I've done some searching and I didn't come up with much.

Hi Erik,

Offering more concise ways of writing more powerful class definitions is certainly a common topic of exploration in Python development.

A couple of folks have already mentioned Hynek Schlawack's `attrs` packages, which pairs up a class decorator with particular kinds of values set as class level attributes:

from attr import attrs, attrib

@attrs class MyClass: foo = attrib() bar = attrib() baz = attrib() ...

Here, the `attrs` decorator not only writes __init__ for you, but also __repr__, comparison operators, pickle support, and a range of other things. Glyph Lefkowitz put together a good post last year describing just how much functionality attrs implicitly adds to a typical class definition, all while making it shorter and less repetitive: https://glyph.twistedmatrix.com/2016/08/attrs.html

So I think if Python were to make any changes to the default toolset in this area, it would be more along the lines of how `attrs` works (i.e. offering a more declarative approach to the high level task of defining structured data containers), than it would be along the lines of a low level syntactic solution that only benefited `__init__` and `__new__` without addressing any of the other repetitive aspects of writing comprehensive class definitions.

For example, if we decided we wanted to go down that path, we could add a new `autoclass` module and write the equivalent of the above as:

from autoclass import make, field

@make class MyClass: foo = field() bar = field() baz = field() ...

That would provide us with a clear terminological distinction between autoclass fields and class attributes in general, while still letting people eliminate a lot of the boilerplate currently involved in writing classes that produce nice and easy to use instances.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com/

On Wed, Apr 26, 2017 at 11:29:19PM +0100, Erik wrote:

But, if we're going to bikeshed and there is some weight behind the idea that this "papercut" should be addressed, then given my previous comparisons with importing, what about having 'import' as an operator:

def __init__(self, a, b, c): self import a, b self.foo = c * 100

[snarky] If we're going to randomly choose arbitrary keywords with no connection to the operation being performed, can we use `del` instead of `import` because it's three characters less typing? [/snarky] *wink* But seriously, I hate this idea. `import` has certain semantics that don't apply here: - import goes through the full import system (sys.modules, reading files from disk, sys.path, etc.); this "self import ..." does not; - import creates local variables; this "self import ..." does not. The semantics are very different and there's little or no connection between importing a module and setting an attribute on self. If we're going to discuss pie-in-the-sky suggestions, here is an only semi-serious suggestion. A statement that injects identifiers into an explicitly given name space: inject spam, eggs as cackleberry, cheese into self (If you don't like "inject", I'm okay with "load" or even "push".) This would be equivalent to: self.spam = spam self.cackleberry = eggs self.cheese = cheese Presumably it would be implemented a little more efficiently, e.g. only a single lookup for self, etc. Note that the target is completely general: you can inject into any object which will accept setting attributes: inject spam, eggs into namespace If the "inject as" form is used, the value can be any expression: inject x + 1 as y into namespace otherwise the value must be a valid identifier but not necessarily a local variable. If I were designing a language from scratch, one with a maximalist approach to syntax, I'd take this seriously. But Python has relatively minimal syntax and keywords, and the problem this solves isn't big or important enough for the disruption of adding a new keyword. -- Steve

On Wed, Apr 26, 2017 at 03:54:22PM -0400, Jerry Hill wrote:

On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:

...

def ___init__(self, self.attr):

I'm not a python developer, I'm just a developer that uses python. That said, I really like this form. It eliminates most of the redundancy, while still being explicit. It's true that you have to repeat the 'self' name, but it feels like the right balance in my mind. It seems like anyone who's familiar with python function definitions would immediately grasp what's going on.

I don't like it, not even a bit. It's not general, "self" is effectively a special case. Consider: What happens if you use this syntax in a top-level function rather than a method? (Or a static method?) def function(x, y, x.attr): ... (And don't forget that behind the scenes, methods *are* functions.) What would this syntax even mean? Or if you use some other name other than the first parameter? def method(self, spam, foo.eggs): ... Conceptually, it is mixing up two distinct tasks: - declaring the parameter list of the function/method; - running part of the body of the method. The parameter list of the method is the *interface* to the method: it tells you the public names and default values (and possibly types, if you use type annotations) of the method parameters. But this syntax overloads the parameter list to show part of the *implementation* of the method (namely, that some parameters are assigned directly to attributes of self). Every time the implementation changes, the parameter list will change too. For instance, if you decide to add some argument validation to your arguments (checking that their values and types are correct), using the self.attr form is inappropriate. And while it looks okay in the toy example shown by Ryan: def ___init__(self, self.attr): it doesn't look so good in larger, more realistic cases, especially with other syntax. Here's a parameter list taken from some real code of mine, with the "self." syntax added: class BinnedData(object): def __init__(self, self.number:int, self.start:float=None, self.end:float=None, self.width:float=None, *, self.policy=None, self.mark=False ): The repetition of "self" is not only tedious and verbose, it adds noise to the parameter list and pushes the reader's attention away from the important part (the name of the parameter, e.g. "width") and to something irrelevant to the interface ("self"). And I am not looking forward to having to explain to beginners to Python why this doesn't work: data = BinnedData(self.number = 8, self.start = 0, self.end = 20) -- Steve

On Wed, Apr 26, 2017 at 08:02:39AM -0400, tritium-list@sdamon.com wrote:

...

self.__dict__.update(kwargs)

Touching __dict__ feels dirty to me.

Indeed. The right way is: vars(self).update(kwargs) although that doesn't work if self is written to use __slots__ instead of having a __dict__. You can even (almost) get this same effect and still have named parameters: def __init__(self, fe, fi, fo, fum, spam, eggs, foo, bar, baz): vars(self).update(locals()) del self.self -- Steve

On Fri, Apr 28, 2017 at 09:54:55AM +1000, Chris Angelico wrote:

On Fri, Apr 28, 2017 at 9:21 AM, Steven D'Aprano wrote:

...

What happens if you use this syntax in a top-level function rather than a method? (Or a static method?)

def function(x, y, x.attr): ...

(And don't forget that behind the scenes, methods *are* functions.) What would this syntax even mean?

Or if you use some other name other than the first parameter?

def method(self, spam, foo.eggs):

Exactly the same thing as:

def function(*args): x, y, x.attr = args

def method(*args): self, spam, foo.eggs = args

Obviously we can define syntax to do anything we like, but what is the logical connection between the syntax and the semantics? What part of "function parameter list" suggests "assign attributes to arbitrary objects"? Do we support arbitrary targets in their full generality? def function(arg, (name if name is not None else other).the_object.attr[0].method(foo)['key'].argument ): ... Of course, there are lots of things which are technically allowed but if someone is silly enough to do it, we say "don't do that". However, even the simple case is problematic: def trigonometry(x, y, math.pi) We could make that parameter declaration have the side-effect of assigning to math.pi, but that's a pretty surprising change to function declarations. Everything else declared inside a parameter list is local to the function: parameters themselves are local variables, default values and annotations are stored in the function not externally. The only thing which is not local is that default values may be arbitrary expressions, which may have side-effects, but that is not a declaration, its an expression evaluated for its value. What's the connection between parameter declarations and this sort of external side-effect? It seems pretty arbitrary to be a built-in part of the language, like having def function(x) automatically print x, or pickle it and upload the file to the cloud. (Obviously the side-effect doesn't occur until the function is called, but still, it is part of the parameter list declaration, not the body of the function.) I have grave doubts that people will find this obvious, let alone useful. Having a function declaration, the parameter list, have side-effects outside of the function seems like both a surprising and a bad idea to me.

It's well-defined - at least for positional args. Not sure what keyword arg handling would be though.

Why would it be any different? If it makes sense to allow: def function(spam, eggs, something.foo) assign to something.foo, then why should it matter whether it was called by keyword or positional? Or declared as keyword only? def function(spam, eggs, *, something.cheese) I don't think it makes sense either way, but it isn't because it is a keyword arg. I think it is arbitrarily mixing two distinct things into one convenient but confusing syntax. function(spam=1, eggs=2, something.cheese=3) # won't work -- Steve

On Fri, Apr 28, 2017 at 03:30:29PM +1000, Chris Angelico wrote:

...

Obviously we can define syntax to do anything we like, but what is the logical connection between the syntax and the semantics? What part of "function parameter list" suggests "assign attributes to arbitrary objects"? [...] What part of a 'for' loop suggests that you can do this?

I'm not sure what "this" is supposed to do. You've written some obscure but perfectly legal Python code:

odds = [0]*10; evens = [0]*10 for idx, (odds if idx%2 else evens)[idx//2] in stuff: ...

My guess is that "this" refers to the side-effect that assigning to a list item updates the list item. Um, yeah, it does. What's your point? Of course it does. That's what its supposed to do. Perhaps you think that there's something weird about using an arbitrary assignment target as the for-loop. I don't know why you think that's weird. Here's a simpler example: for obj.attr in seq: ... Yes, its a bit unusual to do that, but its not weird. The assignment target for a loop is just an ordinary assignment target, and the assignment occurs during the execution of code, just like any other assignment that occurs inside the body of the function. What is weird is to have the function *declaration* have global side effects and perform assignments outside of the function. The parameter list is *not* a general assignment statement, it is a declaration of what local variables will be assigned to when you call the function. In Python 3, function paramaters are plain (non-qualified) identifiers, not general assignment targets. Even in Python 2, the most that was supported were tuple-unpacking. Even that can be read as conceptually just a declaration: def func(a, (x,y)): declares that the first argument is a, and the second argument is a pair of values x and y. But this proposal has to be read as a declaration plus a separate assignment: def func(a, spam.x): declares that the second argument is called "x", (but not spam.x), and *in addition* there will be an assignment spam.x = x at some point, presumably before the function body gets entered.

Nothing whatsoever says that this is a good idea, but it's perfectly legal, because the for loop is defined in terms of assignment. If this were to be accepted (which, fwiw, I'm not actually advocating, but IF), it would also be defined in terms of assignment.

Why should it be defined in terms of general assignment? That's the point I'm making. While function sigs are a form of assignment, they're more of a declaration than an executable statement like the other binding statements. There's a superficial connection, but they really are quite different things. (For example: if you allow spam.foo as a parameter, that can call arbitrary Python code in spam.__setattr__, which assigning to foo as a parameter will not do.)

You still shouldn't be assigning to arbitrary objects, especially not randomly rebinding module names, but it's easy to grok the assignment equivalence.

You need to speak to more beginners if you think the connection between spam.x and x is obvious: def func(spam.x): print(x) Where is x declared? It looks like there's a local spam.x which isn't used, and a global x that is. But that's completely wrong. Without the context of somebody telling you "this is syntax for magically assigning to self.attributes in the constructor", I believe this will be unfathomable to the average non-expert.

And yes, it WOULD reinstate the argument unpacking removed by PEP 3113. So for this to go forward, the objections in that PEP would have to be addressed.

Nicely remembered :-) -- Steve

On Fri, Apr 28, 2017 at 4:57 PM, Steven D'Aprano wrote:

On Fri, Apr 28, 2017 at 03:30:29PM +1000, Chris Angelico wrote:

...

...

Obviously we can define syntax to do anything we like, but what is the logical connection between the syntax and the semantics? What part of "function parameter list" suggests "assign attributes to arbitrary objects"? [...] What part of a 'for' loop suggests that you can do this?

I'm not sure what "this" is supposed to do. You've written some obscure but perfectly legal Python code:

...

odds = [0]*10; evens = [0]*10 for idx, (odds if idx%2 else evens)[idx//2] in stuff: ...

My guess is that "this" refers to the side-effect that assigning to a list item updates the list item. Um, yeah, it does. What's your point? Of course it does. That's what its supposed to do.

Perhaps you think that there's something weird about using an arbitrary assignment target as the for-loop. I don't know why you think that's weird. Here's a simpler example:

for obj.attr in seq: ...

Yes, its a bit unusual to do that, but its not weird. The assignment target for a loop is just an ordinary assignment target, and the assignment occurs during the execution of code, just like any other assignment that occurs inside the body of the function.

What is weird is to have the function *declaration* have global side effects and perform assignments outside of the function. The parameter list is *not* a general assignment statement, it is a declaration of what local variables will be assigned to when you call the function.

Waaaaaait a minute. Since when is the *declaration* doing this? No no no. In every proposal, it's been a part of the function's *execution*. The original example was an __init__ function that does the exact same thing as my for loop example: it first sets "self" to the first parameter, and then sets some attributes on self. As you say:

Um, yeah, it does. What's your point? Of course it does. That's what its supposed to do.

There is nothing surprising in it (although my example was deliberately convoluted and a bad example of code). It's assignment, pure and simple. When you call a function, the values you pass to it get assigned to the names provided in the declaration. No assignments happen at declaration other than the function's own name. (I suppose you could say that default argument values are "assigned" at that point, but I prefer to say "collected", since they're basically assembled into a tuple and slapped into an attribute on the function.)

...

Nothing whatsoever says that this is a good idea, but it's perfectly legal, because the for loop is defined in terms of assignment. If this were to be accepted (which, fwiw, I'm not actually advocating, but IF), it would also be defined in terms of assignment.

Why should it be defined in terms of general assignment? That's the point I'm making. While function sigs are a form of assignment, they're more of a declaration than an executable statement like the other binding statements. There's a superficial connection, but they really are quite different things.

There's a lot more similarities than you might think. For example, both of these will create "spam" as a local name, shadowing the global: spam = 1 def func1(spam): print(spam) def func2(): spam = 2 print(spam) As will many other forms of assignment, like "import spam" or "with x as spam:". Some forms are more restricted than others ("import" requires a NAME, not an arbitrary expression), but they all behave the same way with regard to global/nonlocal/local naming - you can "global numpy; import numpy" inside a function to do a delayed import, for instance.

(For example: if you allow spam.foo as a parameter, that can call arbitrary Python code in spam.__setattr__, which assigning to foo as a parameter will not do.)

Sure, but that's a difference between simple name assignment and item/attribute assignment, not a difference between function parameters and other types of variables. Are you next going to point out that you can't "import spam as foo[0]"? Or that importing is somehow special because of this? No. It's still assignment, just one with a restricted syntax.

...

You still shouldn't be assigning to arbitrary objects, especially not randomly rebinding module names, but it's easy to grok the assignment equivalence.

You need to speak to more beginners if you think the connection between spam.x and x is obvious:

def func(spam.x): print(x)

Where is x declared? It looks like there's a local spam.x which isn't used, and a global x that is. But that's completely wrong. Without the context of somebody telling you "this is syntax for magically assigning to self.attributes in the constructor", I believe this will be unfathomable to the average non-expert.

Not sure what you mean. By my reading, that's exactly correct - there IS a global x that is being used here, although "local spam.x" is not accurate. I wouldn't call that "completely wrong". And if you find that confusing, let's look at importing. os = "Linux" path = "/tmp" def func(): import os.path print(path) What's local and what's global? What name is actually bound by "import os.path"? What if you said "import os.path as path"? "import os.path as os"? Does all this confuse people? IMO it's *less* confusing if you can simply say "this is equivalent to <parameter> = <argument>".

...

And yes, it WOULD reinstate the argument unpacking removed by PEP 3113. So for this to go forward, the objections in that PEP would have to be addressed.

Nicely remembered :-)

I didn't remember the PEP number, but the Google is helpful :) ChrisA

Le 26/04/17 à 13:12, Brice PARENT a écrit :

Why not simply do this :

class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

def __init__(self, a, b, c): self._set_multiple(a=a, b=b, c=c)

-> No new syntax, no inspection, simple to read, parse and understand, and explicit.

And you could directly do some simple cleanings or not define a variable, like :

class MyClass: def _set_multiple(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value)

def __init__(self, a, b, c): self._set_multiple(a=a * 2, b=clean_field(b))

- Brice Also, a new syntax that could be useful in many other ways, while being easy to understand to any pythonista, would be : class MyClass: def __init__(self, a, b, c): self.(a, b, c) = a, b, c

You still have to type twice the name of the variable instead of one though, if you don't want to use *args and **kwargs, but you still save the same vertical space with something efficient and way more useful. It is currently an invalid syntax, but that allows to be sure that it doesn't break old source code and doesn't require any deprecation. As a new syntax, it can probably be optimized a lot at the implementation level. It can be used with *args and **kwargs also, ... class MyClass: def __init__(self, *args, **kwargs): self.(a, b, c) = args self.(*kwargs.keys()) = kwargs.values() # or self.(kwargs.keys()) = kwargs.values() ... on instantiated objects (so not only in self), ... background_color.('r', 'g', 'b') = 255, 127, 0 ... update the values to be stored on-the-fly, ... class MyClass: def __init__(self, a, b, c): self.(a, b, c) = a, b * 2.54, c ... make any validation you want, ... class MyClass: def __init__(self, a, b, c): if c > 10: b = 0 elif c < 0: raise ValidationError("c can't be lower than 0") self.(a, b, c) = a, b, c ... update the names of the attributes and insert names that weren't in the signature ... class MyClass: def __init__(self, a, b, c): self.(a, b, _c, uuid) = a, b, c, str(uuid.uuid4()) Morality : This is a completely other thing to what's proposed here, even if it does solve more or less OP's initial problem. It's open to discussion whether it's useful or not, but it allows some kind of unpacking at the classes properties level, not exclusively into active scope. - Brice

On Fri, Apr 28, 2017 at 05:23:59PM +1000, Chris Angelico wrote:

Waaaaaait a minute. Since when is the *declaration* doing this?

That's what the suggested syntax says. You put the attribute assignment you want in the parameter list, which is part of the function/method declaration, not the body. If I recall correctly, the proposal was exactly: def __init__(self, self.attr): That's not in the body of the function, it's in the parameter list, hence part of the declaration. When you call the constructor: instance = MyClass(42) __init__ is called, the argument 42 is bound to the formal parameter "attr", the assignment self.attr = attr is run, and THEN the body of the method is called. (Before you object, see below for justification for why there has to be both a local variable and an attribute.) If there is an exception, what do you think the stack trace will point to? It cannot point to a line of source code that says "self.attr = attr", because there is no such line. At best, it can point to the declaration "def __init__(self, self.attr):" although it might not even do that.

No no no. In every proposal, it's been a part of the function's *execution*.

I did explicitly state that the attribute assignment doesn't occur until the function is called, so I'm aware of this. Nevertheless, the source code being executed at function call time does not reside in the body of the function, but in the function signature. Maybe I'd be less disturbed by this if we had late binding of defaults (defaults are re-evaluated each time they are needed), and a history of abusing that for the side-effects: def function(a, b=print("using b default") or default): But Python function defaults are early binding, and they're only evaluated once, so there's currently no analogy to this proposal. [...]

...

Why should it be defined in terms of general assignment? That's the point I'm making. While function sigs are a form of assignment, they're more of a declaration than an executable statement like the other binding statements. There's a superficial connection, but they really are quite different things.

There's a lot more similarities than you might think. For example, both of these will create "spam" as a local name, shadowing the global:

spam = 1 def func1(spam): print(spam) def func2(): spam = 2 print(spam)

Right. Function parameters are local variables. But you can't write: def func(global spam): to make it assign to a global instead of a local, or nonlocal, and you can't (currently) write: def func(math.spam): to make it assign to an attribute of the math module. It's a big conceptual leap to go from "formal parameters are always bound to local variables of the function" to "formal parameters of the function are bound to anything, anywhere". I wonder whether any other language allows this?

As will many other forms of assignment, like "import spam" or "with x as spam:". Some forms are more restricted than others ("import" requires a NAME, not an arbitrary expression),

Yes, we could restrict the syntax to simple identifiers with a maximum of a single dot: def __init__(self, self.attr, # allowed self[0].foo(1)['key'], # SyntaxError ): which will avoid the worst of the horrors. [...]

...

You need to speak to more beginners if you think the connection between spam.x and x is obvious:

def func(spam.x): print(x)

Where is x declared? It looks like there's a local spam.x which isn't used, and a global x that is. But that's completely wrong. Without the context of somebody telling you "this is syntax for magically assigning to self.attributes in the constructor", I believe this will be unfathomable to the average non-expert.

Not sure what you mean. By my reading, that's exactly correct - there IS a global x that is being used here,

No there isn't. "x" is the parameter name, even though it is written with a "spam." prefix. Let's go back to the original: class MyClass: def __init__(self, self.attr): ... instance = MyClass(42) That binds 42 to the local variable "attr", as well as doing the self.attr=attr assignment. After all, surely we want to be able to refer to the parameter by its local variable, for efficiency (avoiding redundant look-ups of self), or to by-pass any __getattr__ on self. Or to really push the message, think about calling it by keyword: instance = MyClass(self.attr=42) # No. instance = MyClass(attr=42) # Yes. In other words, even though the formal parameter is written as "self.attr", the argument is bound to the local "attr". Quite frankly, I thought this was so self-evident that it didn't even occur to me that anyone would have imagined that no local variable "attr" would be created. As weird as it is to have a parameter declared as "self.attr" but bound to "attr", that's not as weird as having a parameter declared as "self.attr" but not bound to any local at all. (If instance attributes and locals used the same notation, namely a bare identifier, we could gloss over this distinction. But we're not using Java :-) -- Steve

On 28/04/17 10:47, Paul Moore wrote:

On 28 April 2017 at 00:18, Erik wrote:

...

...

The semantics are very different and there's little or no connection between importing a module and setting an attribute on self.

At the technical level of what goes on under the covers, yes. At the higher level of what the words mean in spoken English, it's really not so different a concept.

I disagree. If you were importing into the *class* (instance?) I might begin to see a connection, but importing into self?

I know you already understand the following, but I'll spell it out anyway. Here's a module: ----------------- $ cat foo.py def foo(): global sys import sys current_namespace = set(globals().keys()) print(initial_namespace ^ current_namespace) def bar(): before_import = set(locals().keys()) import os after_import = set(locals().keys()) print(before_import ^ after_import) initial_namespace = set(globals().keys()) ----------------- Now, what happens when I run those functions: $ python3 Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information.

...

...

import foo foo.foo() {'sys', 'initial_namespace'} foo.bar() {'before_import', 'os'}

... so the net effect of "import" is to bind an object into a namespace (a dict somewhere). In the case of 'foo()' it's binding the module object for "sys" into the dict of the module object that represents 'foo.py'. In the case of 'bar()' it's binding the module object for "os" into the dict representing the local namespace of the current instance of the bar() call. Isn't binding an object to a namespace the same operation that assignment performs? So it's a type of assignment, and one that doesn't require the name to be spelled twice in the current syntax (and that's partly why I took offense at a suggestion - not by you - that I was picking "random or arbitrary" keywords. I picked it for that specific reason). I realize that there are other semantic changes (importing a module twice doesn't do anything - and specifically repeated "import * from mod" will not do anything if the module mutates) - and perhaps this is your point.

Also, if you try to make the obvious generalisations (which you'd *have* to be able to make due to the way Python works) things quickly get out of hand:

def __init__(self, a): self import a

self.a = a

OK, but self is just a variable name, so we can reasonably use a different name:

def __init__(foo, a): foo import a

foo.a = a

So the syntax is <variable> import <var-list>

Presumably the following also works, because there's nothing special about parameters?

def __init__(x, a): calc = a**2 x import calc

x.calc = calc

And of course there's nothing special about __init__

def my_method(self, a): self import a

self.a = a

Or indeed about methods

def standalone(a, b): a import b

a.b = b

or statements inside functions:

if __name __ == '__main__: a = 12 b = 13 a import b

a.b = b

Hmm, I'd hope for a type error here. But what types would be allowed for a?

I think you're assuming I'm suggesting some sort of magic around "self" or some such thing. I'm not. I've written above exactly what I would expect the examples to be equivalent to. It's just an assignment which doesn't repeat the name (and in the comma-separated version allows several names to be assigned using compact syntax without spelling them twice, which is where this whole thing spawned from).

See what I mean? Things get out of hand *very* fast.

I don't see how that's getting "out of hand". The proposal is nothing more complicated than a slightly-different spelling of assignment. It could be done today with a text-based preprocessor which converts the proposed form to an existing valid syntax. Therefore, if it's "out of hand" then so is the existing assignment syntax ;) FWIW, I should probably state for the record that I'm not actually pushing for _anything_ right now. I'm replying to questions asked and also to statements made which I think have missed the point of what I was trying to say earlier. So I'm just engaging in the conversation at this point - if it appears confrontational then it's not meant to.

To summarise:

1. There's some serious technical issues with your proposal, which as far as I can see can only be solved by arbitrary restrictions on how it can be used

To be honest, I still don't understand what the serious technical issues are (other than the parser probably doesn't handle this sort of keyword/operator hybrid!). Is it just that I'm seeing the word "import" in this context as a type of assignment and you're seeing any reference to the word "import" as being a completely different type of operation that comes with baggage? Regards, E.

On 28 April 2017 at 23:04, Erik wrote:

...

See what I mean? Things get out of hand *very* fast.

I don't see how that's getting "out of hand". The proposal is nothing more complicated than a slightly-different spelling of assignment. It could be done today with a text-based preprocessor which converts the proposed form to an existing valid syntax. Therefore, if it's "out of hand" then so is the existing assignment syntax ;)

Well with your clarification, it's now clear to me that your proposal is for <obj> import <var1>, <var2> ... to be equivalent to _tmp = <obj> _tmp.var1 = var1 _tmp.var2 = var2 ... del _tmp Please correct me if I'm wrong here - but that's what I get from your comments. Note that the way I've described the proposal allows for an *expression* on the left of import - that's simply because I see no reason not to allow that (the whole "arbitrary restrictions" thing again). So based on the above, you're proposing reusing the import keyword for a series of attribute assignments, on the basis that the current meaning of import is to assign values to a number of attributes of the current namespace. However, that misses the fact that the main point of the current import statement is to do the *import* - the RHS is a list of module names. The assignment is just how we get access to the modules that have been imported. So by "reusing" the import keyword purely by analogy with the assignment part of the current semantics, you're ignoring the fundamental point of an import, which is to load a module. So based on your clarification, I'm now solidly against reusing the "import" keyword, on the basis that your proposed syntax doesn't import any modules. On the other hand, the construct you describe above of repeated attribute assignments is only really common in __init__ functions. It's similar to the sort of "implied target" proposals that have been raised before (based on the Pascal "with" statement and similar constructs): SOME_KEYWORD <obj>: .var1 = var1 .var2 = var2 Your construct is more limited in that it doesn't allow the RHS of the assignments to be anything other than a variable with the same name as the attribute (unless you extend it with "expr as var", which I can't recall if you included in your proposal), nor does it allow for statements other than assignments in the block. And the implied target proposal doesn't really avoid the verbosity that prompted your proposal. So while it's similar in principle, it may not actually help much in your case. So the reason I was saying things got "out of hand" was because the final version I got to had absolutely nothing to do with an import (in my view) - but on reflection, you're right it's no different than the self version. It's just that the self version also has nothing to do with an import! However, in the original context, it's easier to see "name injection into a namespace" as a common factor, and miss "importing a module" as the key point (at least it was easier for me to miss that - you may have seen that and been happy that your proposal was unrelated to modules even though it used the import keyword). I agree with Nick - the place we should be looking for improvements here is in trying to find abstractions for common patterns of class creation. Instead of looking at how to make the low-level mechanisms like __init__ easier to write, we should be concentrating on making it rare for people to *need* to use the low-level forms (while still leaving them present for specialised cases). Paul

On 29 April 2017 at 09:51, Ivan Levkivskyi wrote:

typing.NamedTuple was already mentioned in this discussion, I just would like to add few comments:

1. I think that changing Python syntax to support declarative classes is not a realistic option in nearby future. In contrast, there is an existing syntax change - variable annotations - that can be actively experimented with. Variable annotations are designed to play well with metaclass machinery, for example, they will respect __prepare__ method, if it injects __annotations__ as a custom mapping, etc.

2. Possible strategy for declarative classes could be developing independent *composable* mixins/traits:

@comparable @pickleable class MyClass: x: int y: int

or

class MyClass(Comparable, Pickleable): x: int y: int

The problem with the second approach is that it can lead to metaclass conflicts. A possible solution will be to provide a standard metaclass for mixins in stdlib.

Between __init_subclass__, __set_name__, __annotations__, and guaranteed order preservation for class namespaces, Python 3.6 has provided some pretty powerful tools for folks to experiment with new approaches to declarative class definitions. One point worth considering is that given standard library implementations of the explicit class decorator forms (e.g in the `types` module, or in the modules defining the relevant protocols), it should be relatively straightforward to create mixin classes that use __init_subclass__ to implicitly apply the explicit decorators. The same doesn't hold the other way around - given a mixin, it's tricky to convert that to a class decorator form. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Thu, Apr 27, 2017 at 7:21 PM, Steven D'Aprano wrote:

On Wed, Apr 26, 2017 at 03:54:22PM -0400, Jerry Hill wrote:

...

On Tue, Apr 25, 2017 at 8:05 PM, Ryan Gonzalez wrote:

...

def ___init__(self, self.attr):

I'm not a python developer, I'm just a developer that uses python. That said, I really like this form. It eliminates most of the redundancy, while still being explicit. It's true that you have to repeat the 'self' name, but it feels like the right balance in my mind. It seems like anyone who's familiar with python function definitions would immediately grasp what's going on.

I don't like it, not even a bit. It's not general, "self" is effectively a special case. Consider:

I wasn't thinking that 'self' should be a special case at all.

What happens if you use this syntax in a top-level function rather than a method? (Or a static method?)

def function(x, y, x.attr): ...

(And don't forget that behind the scenes, methods *are* functions.) What would this syntax even mean?

It would mean the same thing as "def function(x, y, z):", which is: take the first three positional arguments, and assign them to the local names listed in the function definition. The same as def function(foo, bar, baz): x = foo y = bar x.attr = baz

Or if you use some other name other than the first parameter?

def method(self, spam, foo.eggs): ...

What's the problem? How is this any different from def method(self, bar, baz): spam = bar foo.eggs = baz I mean, it does imply that 'foo' is some globally writable bit of data, being modified via side effect of calling a method, which is certainly a code smell. Still, we're all consenting adults here, and it doesn't seem any worse than the already-legal variant I mention above.

Conceptually, it is mixing up two distinct tasks:

- declaring the parameter list of the function/method;

- running part of the body of the method.

Is assigning your parameters to their local names really part of 'running the body of the method'? I mean, I almost never write my functions like this: def fun(*args): foo = args[0] bar = args[1] baz = args[2] Do you? If not, aren't you using the function definition to assign parameters to local names? Also, if you do write functions that way, aren't you *also* losing the semantic hints about what parameters are acceptable and what they are used for?

The parameter list of the method is the *interface* to the method: it tells you the public names and default values (and possibly types, if you use type annotations) of the method parameters. But this syntax overloads the parameter list to show part of the *implementation* of the method (namely, that some parameters are assigned directly to attributes of self). Every time the implementation changes, the parameter list will change too.

I guess I don't agree that the function definition only tells you the 'public names' of the parameters being passed. Instead, I think the function definition tells you the names those parameters are going to go by inside the function. That is, their local names. And if you're taking the parameters and assigning them to attributes of self anyway, then you have the exact same issue with your parameter list changing every time the implementation changes anyway, don't you?

it doesn't look so good in larger, more realistic cases, especially with other syntax. Here's a parameter list taken from some real code of mine, with the "self." syntax added:

I won't argue with that, I suppose. I'm not convinced it's worse than the status quo, but yes, if you pack all the possible options into your parameters, you can end up with a messy function signature. I guess my python experience is atypical if most of your methods take 6+ parameters, including some that are keyword-only, most of which have default values, and are annotated with type hints.

class BinnedData(object): def __init__(self, self.number:int, self.start:float=None, self.end:float=None, self.width:float=None, *, self.policy=None, self.mark=False ):

The repetition of "self" is not only tedious and verbose, it adds noise to the parameter list and pushes the reader's attention away from the important part (the name of the parameter, e.g. "width") and to something irrelevant to the interface ("self").

And I am not looking forward to having to explain to beginners to Python why this doesn't work:

data = BinnedData(self.number = 8, self.start = 0, self.end = 20)

For what it's worth, if that construct wouldn't work, then I'm convinced that the idea is a bad one. :) I'm not sure I see why that would have to be forbidden, though. -- Jerry

On 26/04/17 21:50, Chris Angelico wrote:

On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote:

...

The background is that what I find myself doing a lot of for private projects is importing data from databases into a structured collection of objects and then grouping and analyzing the data in different ways before graphing the results.

So yes, I tend to have classes that accept their entire object state as parameters to the __init__ method (from the database values) and then any other methods in the class are generally to do with the subsequent analysis (including dunder methods for iteration, rendering and comparison etc).

You may want to try designing your objects as namedtuples. That gives you a lot of what you're looking for.

I did look at this. It looked promising. What I found was that I spent a lot of time working out how to subclass namedtuples properly (I do need to do that to add the extra logic - and sometimes some state - for my analysis) and once I got that working, I was left with a whole different set of boilerplate and special cases and therefore another set of things to remember if I return to this code at some point. So I've reverted to regular classes and multiple assignments in __init__. E.