[Python-Dev] Re: def ... decorate
gareth.mccaughan at pobox.com
Sat Aug 14 03:18:36 CEST 2004
Josiah Carlson wrote, in reply to me:
> You seem to have missed the point of function decorations entirely. We
> already have what you offer in current Python syntax. The point was to
> move decorations to near/next to the function signature.
No, that was only part of the point. That it's part of the point
is why I still prefer the list-before-colon syntax, which
seems to me to go furthest towards keeping all information
about the interface of a function together. And yes, I know
that Guido finds that syntax unacceptable.
> Read the PEP:
I have read the PEP, thanks. Heck, I'm even named in it.
(I think I was the first person to propose a generalized
decoration facility for Python, rather than just special
syntax for a few special cases such as static methods.
And, for what it's worth, the list-before-colon syntax was
my proposal. Not that it matters much who thought of
what, but I do think it's a bit off to tell me that I've
"completely missed the point" of something I *invented*.)
>> I actually quite like this. It seems more Pythonic
>> than the @foo proposal. Its obvious problem is that
>> it involves something that looks at first glance like
>> an ordinary suite of statements or expressions, but
>> whose interpretation is substantially different. At
>> least the @foo proposal avoids that.
> What you like is what has existed with Python since the beginning.
No, it is not. What has existed with Python since the beginning
f = decorate_somehow(f)
requires three instances of the name of f. If you have N decorators
it requires 2N+1 instances of the name of f. Not a big deal when
the name is "f", but not so good if it's "build_interface_subgraph"
or something. Not even great when the name is "f": what if you
decide to rename it "g"? *And* it's ugly. These are reasons to want
something else, even without the issue of putting all the "interface"
More information about the Python-Dev