Simply put, augmented assignment of the form
x op= expr
invites pythonistas to a particular intuition of the DRY principle which feels denied whenever the need is encountered to write code of the form
x = f(x,y)
or even, more simply
x = f(x)
on another hand, Python already admits an implied x = f(x) with decorators, since by definition of decorators
@f def x(...) : suite
means the same as
def x(...) : suite x=f(x)
the embryonic proposal is to extend decorator syntax to arbitrary assignment targets, to permit use of it to formulate x=f(x) DRY-ly, e.g.
@f x
together with a further syntax extension allowing to write the above on a single line, by postfixing the assignment target with the decorator, e.g.
x @f
or perhaps
x @= f
to be more in line with other augmented assignment operators, by analogy, say, with how
x *= 2
can replace
x = 2*x
while removing the need to repeat x
ok, this is clearly an completely embryonic idea shown (and motivated) only by (and through) how it would apply to the simplest imaginable use case. The displaying of it is intended to stimulate community discussion on whether and how it might extend to a more useful wider and consistent extension of the python language, and not to invite approval ratings over its current, well, egg.
IOW, does anybody feel like me there is a challenge to see better whether/how these two disjoint python corners, e.g. decorators on the one hand, and augmented assignment on the other hand, may surprisingly reveal they can fit a unifying extension of both ?
Cheers, BB
Boris Borcic schrieb:
[...]
Note that it is *not* required to prefix each thread on this list with "Wild idea".
Georg
Boris Borcic wrote:
@f x
I was thinking about something like this myself recently. I have some custom property classes that I use extensively in a couple of projects, declared like this:
foo = fancy_property('foo', 'The fancy foo property')
It would be nice to be able to write this as something like
@fancy_property foo = 'The fancy foo property'
or perhaps
@fancy_property('The fancy foo property') foo = default_foo_value
x @= f
I think that would be going a bit too far.
On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
I was thinking about something like this myself recently. I have some custom property classes that I use extensively in a couple of projects, declared like this:
foo = fancy_property('foo', 'The fancy foo property')
It would be nice to be able to write this as something like
@fancy_property foo = 'The fancy foo property'
How did one occurrence of 'foo' suddenly turn into foo (without quotes)? That's not how decorators behave elsewhere.
or perhaps
@fancy_property('The fancy foo property') foo = default_foo_value
I think the interpretation for decorators on things other than classes and functions should be derived by carefully reinterpreting what a decorator does for a function or class.
We already have the rule that
@fancy def foo......... # or class foo..........
is equivalent to
def foo.......... # or class foo.......... foo = fancy(foo)
Now in addition we know that
def foo........ # or class foo...........
means
foo = <create something>
so we have
@fancy def foo........ # or class foo.........
as a shorthand for
foo = fancy(<create something>)
From this we can conclude that
@fancy foo = <expression>
just means
foo = fancy(<expression>)
which is (IMO) an utterly unattractive violation of TOOWTDI.
If you were going to object "but def foo and class foo also pass the string 'foo' into <create something>", my counter-objection is that those semantics are implied by the def/class keywords and not by the @decorator syntax.
Ergo, -1.
Guido van Rossum wrote:
On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
@fancy_property foo = 'The fancy foo property'
How did one occurrence of 'foo' suddenly turn into foo (without quotes)? That's not how decorators behave elsewhere.
Decorators on assignments would have to be defined slightly differently, since as you point out, they wouldn't gain you anything otherwise.
If you would prefer to use some syntax other than @ for this, that would be fine with me. All I'm asking for is *some* way to write things like this without having to repeat the name of the thing being defined. There doesn't seem to be any way to do that at the moment without abusing some other construct, such as using a 'def' when you aren't really defining a function.
On Thu, Sep 24, 2009 at 7:20 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
Guido van Rossum wrote:
On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
@fancy_property foo = 'The fancy foo property'
How did one occurrence of 'foo' suddenly turn into foo (without quotes)? That's not how decorators behave elsewhere.
Decorators on assignments would have to be defined slightly differently, since as you point out, they wouldn't gain you anything otherwise.
If you would prefer to use some syntax other than @ for this, that would be fine with me. All I'm asking for is *some* way to write things like this without having to repeat the name of the thing being defined. There doesn't seem to be any way to do that at the moment without abusing some other construct, such as using a 'def' when you aren't really defining a function.
So, you don't care abut the repetition of x in "x = f(x)" but you'd like to have a way to implicitly pass an argument giving the string name of the target variable, like "x = f('x')" ? (Or "x = f('x', x)"; it's the same thing really.) That certainly has nothing to do with decorators. I'm not sure that it's common enough to warrant special syntax; certainly "x = f(x)" must be a lot more common without also needing to pass in the string 'x'.
Guido van Rossum wrote:
So, you don't care abut the repetition of x in "x = f(x)" but you'd like to have a way to implicitly pass an argument giving the string name of the target variable, like "x = f('x')" ?
Yes. I'm defining a property, and the descriptor happens to need to know the name of the property being defined, but that's an implementation detail. The user shouldn't be required, or even allowed, to specify it as an independent parameter.
I'm not sure that it's common enough to warrant special syntax;
Probably not very common in general, but I find myself doing this very intensively in some of my projects. I have two GUI libraries in which nearly every externally visible attribute is one of these properties.
On Fri, Sep 25, 2009 at 2:57 AM, Greg Ewing greg.ewing@canterbury.ac.nz wrote:
Guido van Rossum wrote:
So, you don't care abut the repetition of x in "x = f(x)" but you'd like to have a way to implicitly pass an argument giving the string name of the target variable, like "x = f('x')" ?
Yes. I'm defining a property, and the descriptor happens to need to know the name of the property being defined, but that's an implementation detail. The user shouldn't be required, or even allowed, to specify it as an independent parameter.
I'm not sure that it's common enough to warrant special
syntax;
Probably not very common in general, but I find myself doing this very intensively in some of my projects. I have two GUI libraries in which nearly every externally visible attribute is one of these properties.
A common pattern for this is to have a metaclass that walks over all the properties in the class (which are easily recognized using isinstance() or some other check) and calls them with an initialization function that passed in their name.
participants (4)
-
Boris Borcic -
Georg Brandl -
Greg Ewing -
Guido van Rossum