At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote:
On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I created a "universal metaclass" in
> DecoratorTools whose sole function is to delegate metaclass __new__,
> __init__, and __call__ to class-level methods (e.g. __class_new__,
> __class_call__, etc.), thereby eliminating the need to have custom
> metaclasses for most use cases in the first place. Now, wherever possible,
> I use that single metaclass in my frameworks, so that there's no
need to mix
> them.
easy_installed DecoratorTools and found it: classy_class.
>From the point of view of the code, this is a beautiful and elegant
snippet. However, suppose that from tomorrow everybody starts
using it. Since metaclasses would become so easy to use, possibly a
lot of people would take advantage of them.
That was sort of the idea. ;-)
Then we would have
potentially complex (multiple) inheritance hierarchies with
chains of methods (_class__new__/_class__init__) calling
themselves cooperatively in the MRO. Would the resulting
code be readable?
Readability's orthogonal. Some of them might be readable, some
not. Depends on who's writing them. :)
How easy would be for an average framework user
to understand what is happening to his class?
You're right, let's abolish inheritance, too, because then you might
have to read more than one class to see what's happening.
I think class decorators would be a much better solution than
classy_class for most use cases
Obviously, I disagree. :) You'll notice that DecoratorTools
supports class decorators for Python 2.3 and up (actually, I think
that particular bit worked in 2.2 as well). So, it's not the absence
of class decorators that motivated the 'classy' mixin.
Generally speaking I like
more solutions bases on functional composition (as in WSGI
that you know very well) than on method cooperation. Rather than
improve the support for inheritance, I would like (in an ideal
world) to reduce it, to make easier the choice for people between
inheritance and alternatives (object composition, delegation, functional
composition). In the real world, I am content in documenting the
pitfalls of super, warn people about the dangers of complex
design involving multiple inheritance and cooperation, and suggest
alternatives.
Naturally, if you can design a system to use delegates instead of
class hierarchy to represent a chain of responsibility, it might well
be an improvement. But there are tradeoffs, and no matter what you
are going to end up coding chains of responsibility. Co-operative
inheritance is a nice solution for chains of responsibility that can
be expressed in a class hierarchy, and are no more "dangerous" than
any other sort of chain of responsibility. In fact, they are in some
ways less so since the patterns are likely to be better documented
than anything you come up with on your own.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
