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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4