On Mon, Mar 21, 2011 at 15:28, Jim Fulton <j...@zope.com> wrote:
> This might be OK for @implements and maybe @adapts, which describe
> behavior, but start feeling wonky to me for something like: @utility.
Well, the wonkyness comes from @utility *not* being inherited, while
@implements would be. That could be confusing.
It wold be possible to let @utility be inherited if it's done by
scanning, though. But under what name in that case? I think that
possibly would be even *more* confusing.
It may be that decorators isn't the right answer for registration. In
that case scanning is an option, unless we simply go for straight
def __init__(self, foot, face)
self.foot = foot
self.face = face
It's easy and clear, but has the drawback of encouraging that
registration is done on import time, while scanning separates the
registration from the definition. I'm not sure how important that is.
On Mon, Mar 21, 2011 at 15:36, Martijn Faassen <faas...@startifact.com> wrote:
> Do we really care about "the Python world in general"? Is that relevant
> to the discussion? Can't we just talk about what we care about? The
> Python world in general uses metaclasses for this kind of stuff, which
> relies on base classes too, by the way.
Yeah, but that's to a large extent because class decorators still are
relatively new. You can't use them if you need to support Python 2.5.
> You'll still need a module importing process, as I sketched out
> elsewhere if you use class decorators, to have the class decorators
> kick in at all for modules you don't need to import otherwise.
Is that a problem? In the end, no matter what you do, the module needs
to be imported. :-) That a utility doesn't get registered unless you
import a specific module somewhere in the app doesn't seem like a
problem to me.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -