[Python-Dev] Re: Dropping decorator syntax for 2.4?

Thomas Heller theller at python.net
Fri Jun 4 09:06:09 EDT 2004


Jeremy Hylton <jhylton at gmail.com> writes:

> On Fri, 04 Jun 2004 11:59:46 +0200, Thomas Heller <theller at python.net> wrote:
>> 
>> Couldn't Guido's syntax be implemented as a combination of an import
>> hook together with a byte code hack, without direct support in the core?
>> 
>> Code like this
>> 
>>   [decorator1, decorator2]
>>   def func(args):
>>       pass
>
> How about this?
>
> [decorator1, decorator2]
> if 0:
>     print "Obscure corner case?"
> def func(args):
>     pass
>  
>> seems to be compiled into these byte codes
>>              ....
>>            6 BUILD_LIST
>>            9 POP_TOP
>>           10 LOAD_CONST               0 (<code object test at 0091FD20, ...)
>>           13 MAKE_FUNCTION            0
>>           16 STORE_NAME               2 (test)
>> 
>> It seems BUILD_LIST / POP_TOP / LOAD_CONST / MAKE_FUNCTION is the
>> sequence which should trigger the magic.
>
> I don't recall Guido's patch.  Did he modify the grammar or can it all
> be done inside the compiler?  Not that it's practical for 2.4, but I
> think it wouldn't be hard to post-process the existing AST to
> recognize decorators written like this.

He does it inside the compiler.  The patch is here:
http://python.org/sf/926860

> You'd like for adjacent statements of the form:
>     Expr(List())
>     FunctionDef()
> and replace them with a single
>     FunctionDef()
>
> Or do we need to catch Expr(ListComp()) too?  PEP 318 doesn't mention
> semantics anywhere, so it doesn't say what is allowed inside the
> square brackets.

IIUC, inside the square brackets only a list of simple expressions is
allowed.

Two more remarks:

1. Guido's patch contains one flaw, as I see it: it doesn't work for top
level functions. That is probably good for interactive use, but bad for
modules.  I don't know if this was intended or not.

2. Implementing my proposal above doesn't seem trivial.  Default
arguments to functions can contain arbitrarily complex expressions, so
at least a simple pattern matching on byte codes does not work.

3. My interest in this is because it would be nice to get a
backwards compatible way to use this in Python 2.3.

Thomas




More information about the Python-Dev mailing list