Decorator keyword options - brainstorming

Michael Sparks michaels at rd.bbc.co.uk
Fri Aug 20 11:23:13 EDT 2004


Paul McGuire wrote:
...
> 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:
... [ short list ] ...
> 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? 

Since they're a list of functions that will be applied to the
function/method that follows, I personally think it's important.

Whilst many decorators can be alluded to as a keyword, I don't think all
decorators would be. Consider how you would describe the actions of
this list, or how you would describe this list of actions: (taken from
various sources)

      staticmethod
      generator
      grammarrule('statement : expression')
      versioninfo("Added in 2.4")
      deprecated
      typeinfo(None)
      author("joe bloggs")
      funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
               status="experimental", author="BDFL")

> 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.   

Personally I'd prefer a full word, but neither def or elif are full
words, so I doubt it _has_ to be, but I'd prefer something relevant to
what is happening behind the scenes rather than something ambiguous :)

> Or if "lambda" is used, why not some other Greek letter, such as "mu"
> or "sigma".

Because they're not really meaningful beyond a small number of people?

> This clearly represents some "thinking out loud". 

Ditto.

One other thing that jumped out at me is that different syntaxes
probably work better using different keywords. (Partly why I've snipped
decorator syntaxes)


Michael.
-- 
Michael.Sparks at rd.bbc.co.uk    
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.





More information about the Python-list mailing list