On Fri, Apr 28, 2017 at 2:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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 <steve@pearwood.info> 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.
What part of a 'for' loop suggests that you can do this? odds = [0]*10; evens = [0]*10 for idx, (odds if idx%2 else evens)[idx//2] in stuff: ... 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. You still shouldn't be assigning to arbitrary objects, especially not randomly rebinding module names, but it's easy to grok the assignment equivalence. 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. ChrisA