On Sat, Apr 2, 2016 at 4:53 AM, Matthias welp boekewurm@gmail.com wrote:

...

But, I think the benefit for @decorator on functions is mainly because a function body is big, and this way we can read the decorator next to the function signature while on a variable, this just add another way to call a function on a variable.

Yes, it is, but I proposed it to give a visual indicator that it does not change the value that is assigned to the identifier, but rather changes the behaviour of the identifier, just like what most function decorators do.

Wait, what?

Function decorators are simply higher-order functions: they take a function as an argument, and return a function [1]. They can't change the behaviour of the name, only the value it's bound to.

ChrisA

[1] Usually. Nothing's stopping them from returning non-callables, except that it'd confuse the living daylights out of people.

On 04/01/2016 11:08 AM, Matthias welp wrote:

Even earlier, Ethan Furman wrote:

...

So instead of

a = Char(length=10, value='empty')

you want

@Char(length=10) a = 'empty'

?

If possible, yes. So that there is a standardized way to access changing variables, or to put limits on the content of the variable, similar to the @accepts and @produces decorators that are seen here (https://wiki.python.org/moin/PythonDecoratorLibrary#Type_Enforcement_.28acce...)

I don't see it happening. Making that change would be a lot of work, and the advantages (if any) of the second method over the first do not warrant it.

-- ~Ethan~

On Fri, Apr 01, 2016 at 08:08:54PM +0200, Matthias welp wrote:

...

So instead of

a = Char(length=10, value='empty')

you want

@Char(length=10) a = 'empty'

?

If possible, yes. So that there is a standardized way to access changing variables, or to put limits on the content of the variable,

But decoratoring a *name binding* isn't going to do that. All it will do is limit the *initial value*, exactly as the function call does.

After calling

a = Char(length=10, value='empty')

the name "a" is bound to the result of Char(...), whatever that happens to call. But that doesn't change the behaviour of the *name* "a", it only sets the value it is bound to. Nothing stops anyone from saying:

a = 42

and re-binding the name to another value which is no longer a Char.

Python has no default support for running custom code when binding arbitrary names to a value. To get this sort of thing to work, you are limited to attributes, using the descriptor protocol. I'm not going to explain descriptors now, you can google them, but property is a descriptor.

So let's imagine that Python allows the @ syntax as you request, and go through the cases to see what that would imply.

For local variables inside functions, or global top-level module variables, it doesn't give you any interesting power at all. All you have is an alternative syntax:

@spam @eggs @cheese x = 999

is exactly the same as

x = spam(eggs(cheese(999)))

right now. You don't even save any characters: 28 (including newlines) for both. But this doesn't give us anything new and exciting, since x is now just a regular variable that can be replaced with some other value.

So in this scenario, this sounds boring -- it gives you nothing you don't already have.

Inside a class, we have the power of descriptors available to us, so we can use them for computed attributes. (That's how property works, among many others.) So suppose we have:

class MyClass(object): @decorate x = 999

instance = MyClass()

Now instance.x can be a descriptor, which means that it can enforce type and value validation rules, or logging, or whatever amazing functionality you want to add. This is good.

But you can already do this. You just have to write:

class MyClass(object): x = decorate(999)

instead. If decorate() returns a descriptor, it returns a descriptor whatever syntax you use.

What benefit do you gain? Well, in the function and class decorator case, you gain the benefit that the decoration is close to the class or function header, and you don't have to write the name three times:

class MyClass(object): def method(self): [... many, many, many lines of code ...] method = decorate(method)

But this isn't an advantage in the case of the variable:

class MyClass(object): x = decorate(value)

You only have to write the name once, and the decoration is not going to be far away. So just like the global variable case, there's no advantage to @decorate syntax, regardless of whether you are in a class or not.

But that doesn't change the behaviour of the *name* "a", it only sets the value it is bound to. Nothing stops anyone from saying:

a = 42

and re-binding the name to another value which is no longer a Char.

Python has no default support for running custom code when binding arbitrary names to a value. To get this sort of thing to work, you are limited to attributes, using the descriptor protocol.

This is exactly my point. When they implemented descriptors (2.2) they did that to add to the new-style class system. I think they did a great job, but namespaces were overlooked in my opinion. Why should we be limited to class attributes when using descriptors? Any namespace which contains a '.__dict__' content mapping should be able to hold descriptors in my opinion. If this has been discussed before, then please link me to the relevant discussion, I'd love to read the points made.

But this isn't an advantage in the case of the variable

Assigning variables from function results is fairly common. When chaining function calls to get the desired behaviour of the variable, it will get confusing which part is the 'value' part, and which part is the 'behaviour' part, apart from namings:

var = logging( require(int)( factorize( 4 ))))

would get more clear if you wrote it this way:

@logging @require(int) var = factorize(4)

Something I just thought about: currently you can use the property() call to make an attribute have descriptor properties. This may be somewhat controversial, but maybe limit this to decorators only? While keeping the '.__dict__' override method open, the way things work currently won't change that much, but it will make the assignment of attributes or variables with descriptor properties a lot more intuitive, as you do not set a *name* to a variable and then can undo that just a while later:

var = property(setter, getter, deleter, docs) var = 20

currently changes behaviour depending on what kind of scope it is located in (class description, any other scope), while decorators (for functions at least) work in every scope I can think of. I think that is strange, and that it should just be the same everywhere. Using decorators here could be a very nice and interesting choice.

...

var = property(setter, getter, deleter, docs) var = 20

Can you explain - or, preferably, demonstrate - the difference you're talking about here?

Sorry, that was untested code. My expectations of class definitions was wrong, as it does not actually change behaviour inside it's own scope. I thought that when you are defining a class, that when you assign a property value to an attribute, that the attribute 'name value' will directly change it's behaviour to include the descriptor properties of the property object assigned. My mistake.

On 3 April 2016 at 08:32, Chris Angelico rosuav@gmail.com wrote:

On Sun, Apr 3, 2016 at 4:05 PM, Matthias welp boekewurm@gmail.com wrote:

...

While keeping the '.__dict__' override method open, the way things work currently won't change that much, but it will make the assignment of attributes or variables with descriptor properties a lot more intuitive,

as

...

you do not set a *name* to a variable and then can undo that just a while later:

var = property(setter, getter, deleter, docs) var = 20

currently changes behaviour depending on what kind of scope it is

located in

...

(class description, any other scope), while decorators (for functions at least) work in every scope I can think of. I think that is strange, and

that

...

it should just be the same everywhere.

Can you explain - or, preferably, demonstrate - the difference you're talking about here?

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

So is there anything left of the assignment-decorator proposal, or is it completely withdrawn?

I think this sums the current open ends up:

- Namespace variables decoration was dismissed by one of Steven's posts, but is actually something that might be wanted (via being able to put descriptors into namespaces that have a __dict__ accessor (e.g. modules)) - Variable decoration can be more clear about descriptor/value difference at assignment - Giving property objects access to their variable's name (e.g. via __name__) like functions have would open up quite a bit of possibilities, and would mean decorators would get quite a bit more power than what they have.

Something that I had said earlier, but what went on a sidepath - Decorators may directly *deep* set the behaviour of the variable, and with it set the further behaviour of the variable (in the same scope). Such that

@decorator var = 20

var = 40

will not reset var to 40, but the var = 40 goes through the descriptor (if applied).

On Sun, Apr 03, 2016 at 10:02:55AM +0200, Matthias welp wrote:

...

So is there anything left of the assignment-decorator proposal, or is it completely withdrawn?

I think this sums the current open ends up:

• Namespace variables decoration was dismissed by one of Steven's posts,

but is actually something that might be wanted (via being able to put descriptors into namespaces that have a __dict__ accessor (e.g. modules))

It's not that I dismissed the idea, but that such a thing is not possible today.

Maybe you could hack up something tricky by replacing the module __dict__ with a subclass, or replacing the entire module object with some custom class instance, but that's messy and fragile, and I'm not sure that it would work for (say) globals inside functions.

I think the idea of "namespace descriptors" is promising. But it probably needs a PEP and a significant amount of work to determine what actually is possible now and what needs support from the compiler.

• Variable decoration can be more clear about descriptor/value difference

at assignment

I'm not sure what you mean by that.

• Giving property objects access to their variable's name (e.g. via

__name__) like functions have would open up quite a bit of possibilities,

Such as what?

and would mean decorators would get quite a bit more power than what they have.

What extra power are you thinking of?

Something that I had said earlier, but what went on a sidepath

• Decorators may directly *deep* set the behaviour of the variable, and

with it set the further behaviour of the variable (in the same scope). Such that

@decorator
var = 20

var = 40

will not reset var to 40, but the var = 40 goes through the descriptor

(if applied).

This functionality has nothing to do with decorators. If it were possible, if namespaces (other than classes) supported descriptors, then the decorator syntax doesn't add anything to this. You could write:

var = magic(20)

I'm not calling it "decorator" because the whole @ decorator syntax is irrelevant to this.

With respect Matthias, I think you are conflating and mixing up the power of descriptors as applied to classes, and the separate and distinct powers of decorators. You don't need one to have the other.

On 04/01/2016 10:53 AM, Matthias welp wrote:

...

But, I think the benefit for @decorator on functions is mainly because a function body is big, and this way we can read the decorator next to the function signature while on a variable, this just add another way to call a function on a variable.

Yes, it is, but I proposed it to give a visual indicator that it does not change the value that is assigned to the identifier, but rather changes the behaviour of the identifier, just like what most function decorators do.

So instead of

a = Char(length=10, value='empty')

you want

@Char(length=10) a = 'empty'

?

-- ~Ethan~

Steven D'Aprano writes:

...

and this way we can read the decorator next to the function signature while on a variable, this just add another way to call a function on a variable.

I'm afraid I don't understand what you mean by this. What does "while on a variable" mean here?

Missing punctuation (see substring in square brackets):

and this way we can read the decorator next to the function signature[. W]hile on a variable, this just add another way to call a function on a variable.

So, it appears that he's proposing pure syntactic sugar with no semantic change at all. The syntactic effects are that decorator syntax separates function calls from the values they act on (-1 on that), and makes it appear that in Python a function can change the value of its formal argument (-1 on that, too).

The latter characteristic may need some expansion. Of course Python has mutable objects which can be changed "inside" a function and that effect propagates to "outside" the function. But in the containing scope, while the object has mutated, the variable (more precisely, the name-object binding) has not.

It seems to me that everything he's asked for can be accomplished by defining a descriptor class and assigning an instance of that class. I don't yet understand why that isn't good enough, unless it's just a matter of taste about the sweetness of syntax.