[Python-Dev] method decorators (PEP 318) (original) (raw)
Phillip J. Eby pje at telecommunity.com
Fri Mar 26 14:10:02 EST 2004
- Previous message: [Python-Dev] method decorators (PEP 318)
- Next message: [Python-Dev] method decorators (PEP 318)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 10:37 AM 3/26/04 -0800, Guido van Rossum wrote:
> It's apparent Guido doesn't agree; I just wish I knew what was > bothering him about the PEP, so I could either provide a convincing > counterargument, or understand better why I'm wrong. <0.5 wink> At > the moment, I'm worried that something in my actual use cases will > scare him into rejecting the PEP altogether. <0.01 wink>
Let me try to explain what bothers me. If we were going to use this mostly for decorators spelled with a single work, like classmethod, I would favor a syntax where the decorator(s) are put as early as reasonable in the function definition, in particular, before the argument list. After seeing all the examples, I still worry that this: def foobar(cls, blooh, blah) [classmethod]: hides a more important fact for understanding it (classmethod) behind some less important facts (the argument list). I would much rather see this: def foobar [classmethod] (cls, blooh, blah):
Either way is still a huge improvement over what we have now, but I certainly see your point.
I agree that if this will be used for decorators with long argument lists, putting it in front of the arguments is worse than putting it after, but I find that in that case the current PEP favorite is also ugly:
def foobar (self, blooh, blah) [ metadata(author="GvR", version="1.0", copyright="PSF", ...), deprecated, ]: for bl, oh in blooh: print oh(blah(bl)) I don't see a way to address both separate concerns (hiding the most important fact after the signature, and the ugliness of long complex lists of decorators) with a single syntactic alternative. The two concern are in conflict with each other. That's why I'm trying to pull the proposal apart into two directions: put small decorators in front, put large function attribute sets in the body. (For those worried that the function attribute sets appear to belong to the body, I point to the precedent of the docstring. IMO the start of the function body is a perfectly fine place for metadata about a function.)
Okay, then how about:
def foobar(cls,blooh, blah):
[classmethod]
"""This is a class method"""
# body
and def foobar(self,bloo,blah): [metadata(author="GvR",version=1.0,copyright="PSF"), deprecated] """This is deprecated""" # body
Okay, you're right, they're both ugly. :) In fact, they seem uglier than:
def foobar(self,bloo,blah) [
metadata(author="GvR",version=1.0,copyright="PSF"),
deprecated
]:
"""This is deprecated"""
# body
or:
def foobar(self,bloo,blah) [
deprecated, metadata(
author="GvR",version=1.0,copyright="PSF"
)
]:
"""This is deprecated"""
# body
but I think this is largely a function of whitespace and other optional formatting choices.
- Previous message: [Python-Dev] method decorators (PEP 318)
- Next message: [Python-Dev] method decorators (PEP 318)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]