At 10:15 28.03.2004 -0500, Bob Ippolito wrote: >On Mar 28, 2004, at 9:45 AM, Phillip J. Eby wrote: > >>At 12:54 PM 3/28/04 +0100, Paul Moore wrote: >>>Robert Mollitor <mollitor at earthlink.net> writes: >>> >>> > It would be nice if transformer decorations were never allowed >>> > "arguments". It would keep that list as short >>> > and as tidy as possible. >>> >>>That's the sort of restriction I imagined that Guido was tending >>>towards. While it's justifiable in this context, I would prefer to >>>leave the option of using arguments available, in case someone comes >>>up with a use where function attributes are inappropriate. >> >>It's inappropriate to use attributes of a function for attributes that >>logically belong to the decorator. For example >>'synchronized(lockattr="baz")'. The 'lockattr' logically belongs to the >>synchronizing decoration. Declaring it in a separate location makes the >>whole thing harder to read/understand. > >Not to mention the fact that you'll have to start prefixing your function >attributes so that you don't clash between decorators.. because of the >flat namespace. yes, in fact C# and Java use first class objects, namely in their case classes/interfaces to solve the naming problem. A comparable approach in Python would be: author = object() # may be imported from somewhere else def foo(arg): @author: "fooauthor" # === foo.__dict__[author] = "fooauthor" so @ syntax would be "@expr : expr" and not "@name : expr".
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