[PATCH] RE: J2 decorator grammar

Michael Sparks zathras at thwackety.com
Mon Aug 23 15:37:49 EDT 2004


Arien Malec wrote:

> Michael Sparks <zathras at thwackety.com> wrote in
> news:412889c8$0$81159$ed2619ec at ptn-nntp-reader02.plus.net:
> 
>> So some other keyword is definitely preferable. Currently I'm swayed
>> heavily by arguments in favour of "using" [...]
> 
> "using" doesn't make the semantics clear. The naming for "decorators"
> should be influenced not only by the basic use cases (in which the
> function is annotated with metadata), but also the more edge-pushing use
> cases, like classmethod, in which the semantics of the function are
> changed.
> 
> Me, I like: "transform:"...
> 
> Arien

For the patch I'm using SpanishInquisition since it'll make changing the
keyword simpler. (Does mean I've got some odd code on my machine at the
moment though :)

I'm not going to impose anything (hence using SpanishInquisition for easy
search and replace), however personally I'm swayed by "using" right now the
most. (Ideally something like "decorate using" in a single clear word would
be good, but in all likelihood not realistic)

I agree that generally decorators transform the function, but I also note
that many suggested decorators are declarative in nature so both "declare"
and "transform" are incomplete, and potentially misleading.

There's also the argument of namespace clashes. I haven't explicitly
searched for projects with "transform" in use methods, packages, classes or 
variables, but I would be extremely surprised if I didn't find one. 

Similarly "declare" has problems since I did do a quick search and was able
to find several projects including the excellent Pyrex project that uses
that as a method. (Similarly for a bare "decorate" has a clash with
mailman)

Whilst it's acceptable to say "all new code should avoid keywords", picking
a commonly used words which clash with widely deployed code strikes me as a
bad thing *if* it can be avoided (very hard, but worth considering). The
reason I say this is given the widespread deployment and use of mailman,
breaking people's mailing list software (for example) simply because they
upgraded python is an admin overhead worth avoiding *if* possible. 

When I did some checking for "using" I was rather suprised that out of
a couple of dozen or so projects the only one I could find using it was
python itself in one method (webbrowser.get) as a single named parameter,
and I couldn't find a project using it. (I haven't checked Zope or twisted
because I didn't have those to hand, it might be useful for someone to
check these...)

I agree as a result that whilst "using" doesn't make the semantics as
clear as I'd (it offloads the semantics to the transforms/declarations
associated), it is clear that it can't stand alone, and is less potentially
misleading:

transform:
   author("Joe Bloggs")

Regarding another post I've seen by yourself I would argue that "using"
falls into the "semantically neutral" camp, which I personally view as
the best option here beyond using something much more verbose like
"decorators". That itself doesn't really work very well with a single
decorator (common case) since it just looks wrong due to being a plural.

If you can find a word that captures the relative opposites of "declare"
and "transform" in a single (short?) word I'd REALLY be interested.
(especially if it doesn't clash with lots of existing code... :-/ )

Mind you if we all decided to call decorators "sheep" this plural vs
non-plural issue would be resolved, and we'd all have something clear
to search for:

sheep:
   author("Joe Bloggs")
   Component(inboxes=["inbox","control"], outboxes=["outbox","signal"])
def myGenerator(self, max=10):
   "Hypothetical generator decorated with named ports for IPC"
   foo =0
   while foo <max:
      self.send("outbox",foo)
      foo +=1
      yield 1
   self.send("signal", ProducerFinished())
   yield 0

and

sheep: staticmethod
def rhubarb(custard):
   print "Jelly", custard

<not-entirely-serious-but-hopefully-you-see-what-I-mean>

;-)

Michael.




More information about the Python-list mailing list