I actually encountered this for the first time yesterday and didn't realise
that the decorator syntax was limited in this way (I was mentally preparing
a blog entry when these emails arrived).
What I needed to do was turn a Python function into a .NET event handler in
IronPython. The simple case is this:
from System import EventHandler
@EventHandler
def on_event(sender, event):
# do stuff...
This works fine of course, but then I needed to use the 'typed' form which
is like this:
@EventHandler[HtmlEventArgs]
def on_event(sender, event):
# do stuff...
I didn't realise this was invalid syntax - nor the neat trick with the
identity function to bypass the limitation.
Michael
2009/9/2 Carl Johnson <cmjohnson.mailingl...@gmail.com>
> Crossposting to Python-ideas,
>
> I asked for the same change to the grammar a couple months back on
> python-ideas.
>
> See
> http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787
>
> I'm all for it, but you'll have to convince Guido that this won't
> result in confusing to read code. My own examples, unfortunately did
> not advance your cause, as Guido explained, "My brain hurts trying to
> understand all this. I don't think this bodes well as a use case for a
> proposed feature." :-D The trouble is that I was using lambdas upon
> lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come
> up with some simple, clear use cases though, and I think he might
> still be persuadable to make a simple change to the grammar.
>
>
> — Carl Johnson
>
> Rob Cliffe <rob.cli...@btinternet.com> wrote:
>
> > Hi All,
> > This is my first post to python-dev so I will briefly introduce myself:
> My
> > name is Rob Cliffe and I am a commercial programmer living in London,
> UK. I
> > have some 30 years of programming experience but have only been using
> Python
> > for a couple of years.
> > First I want to say what a fantastic language Python is. It is THE best
> > language for development in my opinion, and a joy to use.
> >
> > My specific issue:
> > I eventually got my head round decorator syntax and realised that what
> came
> > after the '@' was (basically) a function that took a function as argument
> > and returned a function as result.
> > However it seems to me unPythonesque (i.e. an exception to Python's
> normal
> > consistency) that the syntax of what follows the '@' should be restricted
> to
> > either a single (function) identifier or a single (function) identifier
> with
> > an argument list.
> > The example I tried, which seems not an unreasonable sort of thing to do,
> > was along the lines of:
> >
> > def deco1(func):
> > <deco1-suite>
> > def deco2(func):
> > <deco2-suite>
> >
> > DecoList = [deco1, deco2]
> >
> > @DecoList[0] # NO - CAUSES SYNTAX ERROR
> > def foo():
> > pass
> >
> > I am sure other guys have their own examples.
> >
> > I am of course not the first person to raise this issue, and I see that
> > Guido has a "gut feeling" against allowing a general expression after the
> > '@'.
> >
> > BUT - a general expression can be "smuggled in" very easily as a function
> > argument:
> >
> > def Identity(x): return x
> >
> > @Identity(DecoList[0]) # THIS WORKS
> > def foo():
> > pass
> >
> > So - the syntax restriction seems not only inconsistent, but pointless;
> it
> > doesn't forbid anything, but merely means we have to do it in a slightly
> > convoluted (unPythonesque) way. So please, Guido, will you reconsider?
> >
> > Best wishes
> > Rob Cliffe
> _______________________________________________
> Python-ideas mailing list
> python-id...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
--
http://www.ironpythoninaction.com/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
