Python Forum

In a future release of Python, decorators could be generalized to handle more types inputs.

The following is "currently" (Python v3.6.1) correct syntax :

    @give_extra_functionality
    def foo(v):
        print(v)
        return

That is, as long as we define "foo" in-line, we can pass the function created by def as an input into the decorator. However, if we define foo somewhere earlier, not in-line, then we are not allowed to pass foo as input to the decorator function.

The following is not currently valid code:

def foo(v):
    print(v)
    return 

@give_extra_functionality
    foo

Note that the use of "foo" in the later example has no parentheses, and is not a function call. We are just giving the label "foo" immediately after a decorator.

A suggestion is that decorators be extended to make the earlier example valid syntax.
That is, the following two pieces of code would produce the same behavior.

 @ give_extra_functionality
foo
####################################
foo = give_extra_functionality (foo)

This would be backwards compatible. The example above is consistent with the way decorators currently work. In the current paradigm, in place of "foo," we simply have an in-line definition of foo.

Although the text above describes the whole idea, it might not be clear what I mean by "as long as we define foo in-line, we can pass the function created by def." If so, the following is some additional explanation:

Suppose we were implementing python in one of the C-derived languages.

The following python....

def foo(v):
        print(v)
        return

In the C-derived language, it might look something like this:

foo  = def("(v): print(v); return;" )

The specific run-time string-processing nature of the above example is not important this analogy. It is critical to view def as a function, which defines a new function and returns a reference, or pointer, to it.

Suppose in this C-dervied language the assignment operator either returned a const reference or a copy of the value assigned.

Then, the following python code....

    @give_extra_functionality
    def foo(v):
        print(v)
        return

Might look something like the following in the C-like language:

foo = give_extra_functionality (  foo = def("(v): print(v); return;" )  );

It would be very weird for the above to be correct syntax, but the following not to be:

foo = def("(v): print(v); return;" );
foo = give_extra_functionality (foo);

In summary, it would be sensible for the following two pieces of code to be equivalent, in some sense, regardless of whether foo is a def statement, or just a label for a function already defined earlier.

@ give_extra_functionality
foo
########################
foo = give_extra_functionality (foo)

I don't think there will ever be a change of syntax in python for the sole benefit of writing one foo in

foo = give_extra_functionality(foo)

The current syntax is very explicit and flexible. Further, one seldom uses decorators without the @

(Feb-14-2018, 03:01 AM)GalacticStarfish Wrote: [ -> ]A suggestion is that decorators be extended to make the earlier example valid syntax.
That is, the following two pieces of code would produce the same behavior.

@give_extra_functionality
foo
####################################
foo = give_extra_functionality (foo)

Good lord, I hope not. That looks like a do-nothing statement, not a late-bound decorator. A decorator fundamentally changes what a function is, having that separated from the function definition doesn't seem to make practical sense.

If the function needs a change under some conditions later in the code, foo = decorator(foo) is simple and readable enough for anyone to understand it. Changing the language syntax just for

@decorator
foo

doesn't sound reasonable to me.