PEP318: radical notion

[Christophe Cavalaria]

Arien Malec wrote:

> Apologies for feeding the fire, when we are rallying around a consensus,
> but I've been concerned about the clash between syntax and semantics, and
> I've finally reached a mini-epiphany:
> 
> The problem with PEP318 is that it is too powerful, and tries to do too
> much. It is a sledgehammer for attacking three problems:
> 
> 1) Metadata, a la Java and C#
> 2) class & static method defs
> 3) Arbitrary post-definitional transformations of functions.
> 
> (where 2 is a special frequent use case that's part of 3).
> 
> We have ueber-powerful semantics (implementing 3), trying to solve
> problems with very different semantics (e.g., 1).
> 
> OK, that's what I know. Here's a proprosal, that may or may not work,
> because my knowledge of metaclass programming is only sketchy:
> 
> 1) Make PEP318 *only* implement problem (1). That is, create sematics for
> defining and retrieving function/method/class metadata
> 2) Create a new default metaclass that uses metadata for class/static
> method definitions to perform the necessary class/staticmethod
> transformations. Perhaps use this metaclass as default in 2.4 only via a
> "from __future__ import foo".
> 3) Leave any arbitrary transformations to be implemented via custom
> metaclasses -- these metaclasses will have access to the custom metadata
> to trigger method def transformations.
> 
> Arien

Unfortunately for you, you can use decorators on normal functions and not
only on member functions. It rules out any metaclass based implementation.