RFE concerning 'Extension' class

[Stefan Seefeld]

hi there,

I'd like to suggest some enhancements to the Extension class which (IMO) 
makes its use a bit cleaner.

Right now each Extension class derivative has to declare its arguments
within the class variable 'arguments', being a list of 'Fields'. These
Fields are self-documenting, as they contain their name, description,
and default value.

In the Extension constructor this list is mapped to actual instance 
variables for convenient use, and the values are (possibly) overridden
by arguments passed to the constructor.

I'd suggest to create a metaclass for the 'Extension' type that handles
this mapping in its '__init__' method.

However, instead of scanning the content of the 'arguments' variable,
it could scan the whole dictionary (of class variables) for variables
of type 'Field'. That would avoid the potential naming collisions
between class variables and fields, as fields *are* class variables.

It would also be more natural to write

class MyExtension(Extension):

   my_arg = TextField('hello', 'world')

instead of

class MyExtension(Extension):

   arguments = [TextField('my_arg', 'hello', 'world')]

Depending on the constraints on the design, such a change could be
implemented to be backward compatible to various degrees.
What do you think ?

Regards,
		Stefan

PS: the current implementation of the 'get_class_arguments' function
     contains a little bug: The given class' '__mro__' list is scanned
     for an 'arguments' variable which is interpreted as a list of
     Fields.
     However, as __mro__ may contain mixin classes not deriving from
     'Extension', there is a potential for a conflict where the class
     has such a variable but with a totally unrelated type / meaning.