RetroSearch Browse

Fri Mar 26 14:10:02 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-March/043550.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-March/043550.html below:

[Python-Dev] method decorators (PEP 318)