[Python-Dev] Re: PEP 318: Decorators last before colon

Robert Brewer fumanchu at amor.org
Mon Apr 5 02:37:39 EDT 2004


Guido van Rossum wrote:
> ...while far from perfect, in
> terms of readability setting function attributes in a decorator is so
> much better than setting them after the function has been defined,
> that I believe we have no choice but to provide it.

The more I read statements like this, the more I think of replacing:

def foo(arg1, arg2):
    pass
foo = classmethod(foo)
foo.attrA = 3

...with code like:

foo = classmethod()
foo.attrA = 3
def foo(arg1, arg2):
    pass

...the meaning of "def" changes from "make a function" to "bind this
suite to foo". OBVIOUSLY, this would be a huge change as I've written
it. But perhaps, having seen this ideal, a middle ground might become
more visible.

> I also note that accepting decorator-before-colon now would make it
> harder to come up with a decent syntax for declaring the return type,
> which I still want to do in some future version of Python with
> optional (!) static typing.  But not impossible -- there's enough
> punctuation available besides '[' and ':'.

Why would such additional features not be standard attributes of
function objects?

foo = function()
foo.returns(int)
def foo(arg1):
    return int(arg1)

All in all, I'd prefer that function decorators and attributes use
simple, known techniques like assignment and callables (as shown above),
than become monolithic, crystallized all-in-one statements like:

def foo(arg1 as str, arg2 as int) returns str [classmethod] {attrA: 3}:

I understand the desire to keep all those bits near each other on the
page, but stronger is my desire to make them independent statements. If
we could bind a "blank" function object and supply its actual codeblock
in a later statement, the rest falls magically into place, IMO.


Just some thoughts.

Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org



More information about the Python-Dev mailing list