[Python-Dev] Re: PEP 318: Decorators last before colon
Holger Krekel
pyth at devel.trillke.net
Wed Mar 31 15:37:01 EST 2004
Hi Bob,
Bob Ippolito wrote:
> On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote:
> >Please don't add any decorator syntax to Python, at least not yet. All
> >of the proposals I have seen so far are, to be blunt, and in my opinion
> >of course, ugly and are getting uglier as the discussion ensues.
> >
> >I see nothing wrong, at least for the present, with the status quo
> >decorators that follow a function or class definition. They are
> >explicit, functionally equivalent, use the existing and completely
> >understandable syntax, and are so rarely used by only the *most*
> >experienced and advanced programmers that violating the beauty of the
> >language is unjustified.
>
> I've been pretty quiet about this lately because the discussions have
> gone into space, largely by people who don't even have a need or desire
> for decorators, but uninformed comments like this just irk me.
I don't see anything particularly more uninformed here than in many
other postings.
I agree to Michel in that we may be trying to fix a slighly inconvenient
but currently nevertheless explicit and easily understandable syntax with
something special cased.
But is the special case of decorated functions/methods really worth adding a
special case to current syntax rules?
> Decorators *are not rare* and are *used by regular programmers* in some
> problem domains. Yes, it takes an advanced programmer to write such a
> framework, but that doesn't mean that the syntax is useless to
> non-advanced programmers.
I have and had lots of use cases where i "decorated" functions --- but i
didn't use the syntax discussed in the decorator threads for it.
Instead i did something like:
cls = transform_methods(cls)
after the definition of a class. Which functions are selected to be
transformed by 'transform_methods' is up to you. I used special names as
well as inspecting the first argument name (e.g. 'cls') and other
applicable ideas. Specifically, in PyPy we use something like
def add_List_List(self, w_list1, w_list2):
...
def add_Int_Int(self, w_list1, w_list2):
...
and later on just one:
register_all(vars(), W_ListType)
(which will register the methods to some multimethod dispatcher). It's
a matter of taste i guess if using decorators - whatever syntax - at each
function definition would be more readable.
> It's particularly applicable to applications
> using PyObjC or ctypes where the function simply will not work unless
> it's decorated with the correct type signature. It can also
> potentially make pure python frameworks such as Twisted, ZopeX3, or
> PEAK easier to use, by moving boilerplate wrapping stuff into
> decorators. Decorators solve a *huge* problem with the current syntax:
>
> def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(takes,
> some, args, here):
> pass
> someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ =
> objc.selector(someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonge
> r_, signature='some type signature')
I am not sure the only "good" solution here is to add special decorator
syntax like ...
> [objc.selector(signature='some type signature')]
> def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(self,
> some, args, here):
> pass
for example you could try to use the first line of the docstring
for it - maybe building on the typical way to document C-defined python
functions. e.g.:
"(some_type_signature) -> (some_return_type)"
I am not saying straight away this is better but i doubt that the
only good solution to the above problem is to add new syntax.
> It has nothing to do with being an
> experienced or advanced programmer, some problem domains simply REQUIRE
> decorated functions in order to work at all.
But do these problem domains REQUIRE special syntax? I doubt it.
> If decorators do not make
> Python 2.4, that is another major release cycle that extensions such as
> PyObjC and ctypes will be hampered by lack of syntax... to the point
> where I'd be inclined to just fork Python (or Stackless, more likely)
> in order to get the syntax.
Nah, just work with us on PyPy to allow it to add decorator syntax
at runtime :-)
cheers,
holger
More information about the Python-Dev
mailing list