RetroSearch Browse

Thu Jun 24 13:26:20 EDT 2004 · https://mail.python.org/pipermail/python-dev/2004-June/045561.html

Anthony Baxter <anthony at interlink.com.au> writes:

> So, let the floodgates open. Remember, we _can_ change this any
> time up until 2.4b1, if there's a decision that the chosen form
> sucks. :-)

Here's thinking in a different direction altogether:

   No special syntax

   Instead, expose enough functionality in standard library functions
   that an appropriately-written pure-python "decorate" function can
   do it.

   decorate(staticmethod, my_decorator)
   def f(x):
       whatever()

   Since function definitions are executable statements, it should in
   principle be possible to arrange something that allows one to hook
   the execution of that statement.  Perhaps it's already doable with
   the debugger hook?

If you really want special syntax, this would at least be a way to
gain experience with decorators before introducing syntax changes, and
there's no reason you couldn't keep the decorate function alive
ongoingly.  It could also allow more flexible semantics (e.g. decorate
everything in the current scope with blah until I say otherwise).

You can go on introduce various syntactic abominations using the
special operator methods without actually changing the language
syntax, too.  I happen to like things like this, but I can understand
that some won't.  For example:

   decorated[staticmethod, my_decorator]
   def f(x):
       whatever()

   decorators <= staticmethod, my_decorator
   def f(x):
       whatever()

etc...

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-June/045561.html below:

[Python-Dev] Re: decorators and 2.4