decorator J4 - any objections?

[Larry Bates]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.

def func(arg1, arg2):
    {'version': 'Added in 2.4',
     'returns': None,
     'docstring': 'Docstring could be here, or in decorator part above'}
     """Docstring could be here, or in decorator part above"""

or perhaps:


def func(arg1, arg2):
    #
    # Similiar to class __dict__
    #
    __decorators__=__{'version': 'Added in 2.4',
                      'returns': None,
                      'docstring': 'Docstring could be here, or in decorator
part above'}
    """Docstring could be here, or in decorator part above"""


I'm sure there is a reason, but it would seem to make
"Python"-sense to me.  It would then be very extensible
for the meta-data that everyone seems to also want decorators
to support.



"Jim Jewett" <JimJJewett at yahoo.com> wrote in message
news:cab22418.0408201006.16f163b2 at posting.google.com...
> Guido has said that he is open to considering *one* alternative
> decorator syntax.  At the moment, (Phillip Eby's suggestion) J4
>
> <URL: http://www.python.org/moin/PythonDecorators > (section 5.21 J4)
>
> looks very good to me -- and it is the only alternative without negatives.
>
>    def func(arg1, arg2)
>        @version("Added in 2.4")
>        @returns(None)
>    as:
>        """Docstring could be here, or in decorator part above"""
>        # body goes here
>
> (Note the lack of colon on the func line; adding it would be more
> consistent and not hurt readability.)
>
>    def func(arg1, arg2):
>        @version("Added in 2.4")
>        @returns(None)
>    as:
>        """Docstring could be here, or in decorator part above"""
>        # body goes here
>
> While I think this is the best solution so far, I realize that others
> have often disagreed with me on this issue -- so I would appreciate
> some feedback, particularly from those who don't like the J4 syntax.
>
> Disclosure:  I like decorators on their own, but they are enough of
> a special case that I worry about cluttering up the language as a
> whole.  J4 seems the best compromise to me, but I could also make
> peace with Guido's current @proposal.
>
> -jJ