Decorator keyword options - brainstorming

Paul McGuire ptmcg at austin.rr._bogus_.com
Fri Aug 20 10:56:39 EDT 2004


One impression I've gotten from this whole endeavor (even going back to
Kevin Smith's python-dev e-mail thread titled "PEP 318: Can't we all just
get along?") is that what started out as a desire to simplify the
designation of some methods as "class-level" or "static" or "special" in
some way, has gotten muddied with the implementation as it got represented
with the classmethod and staticmethod decorators, and then mutating to
accommodate all types of modifier/decorator/mutators, for resource locking,
debugging, logging, memoizing, etc.

Similarly, I feel our fixation on the "decorator" concept is confounded by
our own understanding that the entries in a list of decorators such as:

keyword:
    memoize
    synchronize
    staticmethod
def foo:
    pass

will translate to:
foo = staticmethod(synchronize(memoize(foo)))

in the current vernacular.

But should we consider this implementation detail when coming up with this
name?  I'd prefer to think of the associations that exist between the
concepts of 'memoize' et al. with 'foo', and use a keyword that describes
those relationships.  And try to do this independent of implementation, or
coincidence with a GoF archetype.

So I have been looking at some alternatives, such as
helper:
amend:
modify:
qualify: (or perhaps qual:)
property: (or perhaps prop:)

On an alternative path, does this have to be a real word?  I confess that
"qual" strikes me in an interesting way, in that it could be thought to
represent either "qualifier" or "quality", and yet is neither.  Or if
"lambda" is used, why not some other Greek letter, such as "mu" or "sigma".

Still, I would like to avoid arbitrary words, as they are little better than
'@' - I'd say that something like "gerbil" should be right out! :)

This clearly represents some "thinking out loud".  Throw rocks or
suggestions at will.

-- Paul





More information about the Python-list mailing list