[Python-Dev] PEP 318: Suggest we drop it

Roman Suzi rnd at onego.ru
Thu Aug 19 06:27:16 CEST 2004


On Wed, 18 Aug 2004, Kevin J. Butler wrote:

>- decorators will incosistently retain or drop docstrings (this may even
>be the most appropriate thing to do)

Well, so does any function working on functions. Probably special
Decorator class could help make decorators friendly when needed.

>- a "decorated" function may have an arbitrarily distant relationship
>with the function as implemented in the def statement (this is a killer)

Is is the case in the DecoratorLibrary on the wiki? No.

>- if you want to decorate a single function two separate ways, you're

- any use cases for this?

>back to 2.3 syntax - say, one that logs, checks parameters, etc., and
>the "internal" optimal version. None of the decorator syntaxes
>facilitate this.
>
>Because of all these issues, I think we should drop PEP 318.

Still these issues do not outweight the usefulness of decorators
and their support for "write once" concept, while in old syntax one need
to write a function name 4 times to merely get it decorated and with __doc__
string.

>The 2.3 form seems more reasonable all the time:
>
>def __func( self ):
>    pass
>spanishInquisition = mydecorator( __func )
>spanishInquisition.__doc__= """Something unexpected"""
>
>parrot = otherdecorator( __func )
>parrot.__doc__ = """And now for something completely different"""
>
>Are any of the syntaxes enough better to justify the irritation or
>divisiveness of including it?

Theoretically it is an argument, but in practice I do not think
the above construct will appear frequently enough. If you have
the case, try class instead of function+decorator.


Sincerely yours, Roman Suzi
-- 
rnd at onego.ru =\= My AI powered by GNU/Linux RedHat 7.3


More information about the Python-Dev mailing list