At 07:55 PM 3/28/05 -0500, Jack Diederich wrote:
>For compelling, I think the code smell put off by the "no conflict" metaclass
>generator recipe (which also appeared in Alex Martelli's PyCon talk) is fairly
>compelling from a duck typing point of view.
>
># would you rather
>class K:
> __metaclass__ = no_conflict(MetaA, MetaB)
># or
>@decoA
>@decoB
>class K: pass
Actually, it's possible today with:
class K:
decoB()
decoA()
As long as decoA() and decoB() use the "class advisor" mechanism I built
for Zope and PyProtocols.
That mechanism basically sticks a custom __metaclass__ into the enclosing
class, and implements a simple protocol for chaining subsequently-defined
class advisors. See 'protocols.advice' in PyProtocols or
'zope.interface.advice' in Zope or Twisted for details.
Anyway, I'm not certain that moving these functions up to decorator status
will really do anything useful; you can already put them near the top of
the class definition, such that they're relatively prominent.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4