IMHO the ones using interfaces usually immediatly implement them for some
cases - so you actually get the interface for you authentication
framework, and also implement an OpenID plugin for it. And this forms
one package. Then you can add new packages that implement other things.
So if I want to implement another authentication mechanism but doesn't
use any of the auth-frameworks code you mentioned you still would depend
on it.
This depends on your definition of depending... (pun intended).
Sure, the code floats around. But it isn't *used* by your application.
Why do you bother so much?
I didn't say nobody does it, I just said it isn't needed to get a
working plugin system. If you don't want to have a separate package
*and* don't want to pull in any unused code, this is pretty much your
only option.
Do you know somebody/some project/system/... who does it?
Pulling unused code I definitely want to avoid so I probably will stay
with this way.
Well, it's simply duck-typing, so you find it all over the place. Out of
my head I only know about e.g. TurboMail, that allows you to specify
plugins via pkg_resources entry points & simply uses them.
Its "the plugin system", connecting "service providers" (plugins) and
"service users". In my example the "users" also are providers at the
same time, the service "auth", provides the service "wiki".
So it's hypothetical?
To summarize my point again: if you want explicit type-checking or
zope-style interface implementation, but don't want any code that
implements this (at least not imported) - you need an explicit package.
If you don't want this, use duck-typing.
PS I removed you (diez) from the TO list as that bounced. Probably
related to the (not existing?) domain nospam.web.de
I post through NNTP, and the email is obfuscated for the obvious reasons.
--
http://mail.python.org/mailman/listinfo/python-list
