PEP318: radical notion

[Arien Malec]

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