Using metaclasses to play with decorators.

[Michele Simionato]

Michael Sparks <zathras at thwackety.com> wrote in message news:<mailman.13.1087333033.21521.python-list at python.org>...
> By doing so I came to the viewpoint of why have __doc__ ? Why not have
> access to whatever the first object is - as far as this is practical? If
> it's a dict, so be it, if it's a string, so be it, but provide a uniform
> way of accessing. (eg func.__meta__ perhaps)

Uhm, that's interesting bu I had a different idea. I think I will post 
about that later.

> I also came to the opinion that having access to that object is orthoganal
> though complementary to decorators. Without metaclasses I simply would not
> have played around with the ideas, and that's the only area I feel
> comfortable with metaclasses at present - playing with ideas.

IMO, you really need metaclasses only if you are building a framework such
as Zope or Twisted, or you are a core Python developer. Mere mortals can have 
only few reasonable usages for metaclasses: to play with them (which is good as 
far as you don't put your experiment in production code), to use them for
debugging, and to use them as a quick hack to fix code written by others
or such that you want to change the source code as little as possible.
 
> However, your point:
> 
> > Decorators MUST be in the core language. Waiting will only favor the
> > abuse of metaclasses.
> 
> Is something I hadn't considered, and perhaps alot of the people prepared
> to wait beyond 2.4 for a "better" syntax hadn't considered because they
> hadn't realised something like it could be done using metaclasses.
> 
> Indeed, if I hadn't seen Theo de Ridder's excellent talk I certainly
> wouldn't've considered the idea. I'm not sure I would want to use python
> that why myself, but it was impressive.

Even more impressive is the black magic trick to implement lazy evaluation
and the ternary operator ... or implementing a prototype based object
system in few lines ... metaclasses ARE fearful. 
 
> Based on playing with metaclasses for different aspects, I might've voted
> for Guido's preferred syntax instead if that possible aspect had been
> raised rather than voting to wait.

I don't think lot of people will play with metaclasses, and I hope people
using them will be wise enough to avoid abusing them. So the risk is 
(maybe) small. The reason why I want decorators now is that I have
started using Zope recently and Zope is in *desperate* need for 
decorators. There will certainly be a delay before decorators will 
enter in Zope after they entered in Python; if they enter in Python
after 2.4 they will enter in Zope when I will be near retirement ...  :-(

> > ...
> > *without* the ability to specify multiple decorators (i.e. let compose
> > the multiple generators explicitely by hand, with a functional.compose
> > function or something like that).
> 
> What if the decorators are things like author, grammar rules, type hints
> (maybe) for external language bindings etc?
 
Two options: or you collect the additional attributes in a single decorator

  def txt2html(self, txt) is writtenby(
      author = "M.S",
      email = "M.S at myaddress,com",
      version = "1.0"):
      ...

or you compose the decorators explicitely

   def txt2html(self, txt) is with_attributes(author, email, version):
      ...

where with_attributes is a function composing the decorators author, email, 
version, that you have to write by hand. So you are explicit, you
avoid confusion about the order of the multiple decorators, and you save square
brackets :)
 
     Michele Simionato