Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com:
We've been handling some constructive criticisms from repoze.bfg
developers
with respect to verbosity resulting from use of unnamed utility
registrations
in a component architecture registry.
These criticisms, and our
Charlie Clark wrote:
Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com:
We've been handling some constructive criticisms from repoze.bfg
developers
with respect to verbosity resulting from use of unnamed utility
registrations
in a component architecture registry.
Hi,
On 11/25/2009 02:35 AM, Chris McDonough wrote:
Chris McDonough wrote:
I think it makes sense. If we can relax the utility name must be a string
restriction it would be the best solution I think.
I'll see what I can do.
I've decided to keep the components subclass which inherits from
On 2009-11-24 05:57, Martin Aspeli wrote:
I whole-heartedly agree, and I think it's important that we use the
momentum behind BFG (and other consumers of the ZTK) to drive the ZTK
forward. Anything else would be stupid.
I don't think BFG can be considered to be a 'consumer of the ZTK'. It
On Tue, Nov 24, 2009 at 5:53 AM, Matthew Wilkes
matt...@matthewwilkes.co.uk wrote:
But, here is where the ZCA eyes come back into play, I wouldn't add
this to the ZCA itself. One reason being that Hanno's been working on
a more useful persistent component root for Zope that brings in bits
of
Hanno Schlichting wrote:
I'm not sure how this affects Chris proposal. But we already have a
commonly used subclass of the component registry that uses the dict
API in a somewhat different way here.
Thanks for the explanation Hanno, fair enough. five.localsitemanager peed in
this API pool
Chris McDonough wrote:
Except at this point we've lost all the other ZCA stuff. You can't
override with a local utility, for example.
I see. I didn't understand that this was a use case, because I don't use any
persistent registries. If you say this is a use case, I believe it.
Note
Martin Aspeli wrote:
I *do* actually like the named IAnonymousUtility thing as a
convenience, because it retains some consistency. Maybe it's slower,
which would be a negative. But it also allows all the other ZCA stuff
(overriding, introspection, global/local variants, etc) and API: we're
Martin Aspeli wrote:
Chris McDonough wrote:
Except at this point we've lost all the other ZCA stuff. You can't
override with a local utility, for example.
I see. I didn't understand that this was a use case, because I don't use
any
persistent registries. If you say this is a use case,
On Tue, Nov 24, 2009 at 6:22 AM, Chris McDonough chr...@plope.com wrote:
I think we have to divorce the requirement from the ZCA.
The requirement:
- an attribute of an instance of the class
zope.component.registry.Components which is dictionarylike
(accepts any key type, any value
On Tuesday 24 November 2009, Chris McDonough wrote:
Off the top of my head, another way to think of this might be to say
that the 'dict access' is basically looking up a named utility
providing a very generic marker interface, e.g.
zope.component.interfaces.IUtility or even just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Martin Aspeli wrote:
I *do* actually like the named IAnonymousUtility thing as a
convenience, because it retains some consistency. Maybe it's slower,
which would be a negative. But it also allows all the other ZCA stuff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
On 2009-11-24 05:57, Martin Aspeli wrote:
I whole-heartedly agree, and I think it's important that we use the
momentum behind BFG (and other consumers of the ZTK) to drive the ZTK
forward. Anything else would be stupid.
On 2009-11-24 17:26, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
On 2009-11-24 05:57, Martin Aspeli wrote:
I whole-heartedly agree, and I think it's important that we use the
momentum behind BFG (and other consumers of the ZTK) to drive the ZTK
Stephan Richter wrote:
On Tuesday 24 November 2009, Chris McDonough wrote:
Off the top of my head, another way to think of this might be to say
that the 'dict access' is basically looking up a named utility
providing a very generic marker interface, e.g.
zope.component.interfaces.IUtility or
Chris McDonough wrote:
I think it makes sense. If we can relax the utility name must be a string
restriction it would be the best solution I think.
I'll see what I can do.
I've decided to keep the components subclass which inherits from dict.
- C
Chris McDonough wrote:
I think we have to divorce the requirement from the ZCA.
The requirement:
- an attribute of an instance of the class
zope.component.registry.Components which is dictionarylike
(accepts any key type, any value type).
If I can get that, I'd be happy,
Martin Aspeli wrote:
Chris McDonough wrote:
I think we have to divorce the requirement from the ZCA.
The requirement:
- an attribute of an instance of the class
zope.component.registry.Components which is dictionarylike
(accepts any key type, any value type).
If I can get that,
Chris McDonough wrote:
I fear it was for naught, sorry.
Adding an attribute is unsightly and turning this into a component problem
doesn't have enough immediate gain. The BFG registry will just continue to
be
a dict subclass.
If Zope folks later want to use libraries that come from
Martin Aspeli wrote:
Chris McDonough wrote:
I fear it was for naught, sorry.
Adding an attribute is unsightly and turning this into a component problem
doesn't have enough immediate gain. The BFG registry will just continue to
be
a dict subclass.
If Zope folks later want to use
We've been handling some constructive criticisms from repoze.bfg developers
with respect to verbosity resulting from use of unnamed utility registrations
in a component architecture registry.
These criticisms, and our ameliorations are detailed here:
Hi Chris,
On 2009-11-24, at 0324, Chris McDonough wrote:
In repoze.bfg, we've actually decided to use a subclass of the
component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility =
Matthew Wilkes wrote:
Hi Chris,
On 2009-11-24, at 0324, Chris McDonough wrote:
In repoze.bfg, we've actually decided to use a subclass of the component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility
You may have Zope Component Developer's Eyes, a common disease in
these parts. ;-)
The goggles, they do nothing.
Under the hood, the system does something like this when a root
factory needs to be registered:
from repoze.bfg.interfaces import IRootFactory
from zope.component import
Hi Chris,
In repoze.bfg, we've actually decided to use a subclass of the component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility = SomeUtilityImplementation()
registry['someutility'] = utility
I
Matthew Wilkes wrote:
Right, but I think mixing the two is just going to be confusing. Your
alternative spelling may well be useful, but only if it works within
the confines of the ZCA itself, otherwise you're just hijacking the
component root for your own (nefarious) purposes.
The
Matthew Wilkes wrote:
In a system like this, there are no interfaces; the string
'root_factory' performs the same job as the IRootFactory interface for
registration and lookup. I'd like to make the ZCA registry operate
like this. There's really no reason for there to be an interface
Chris McDonough wrote:
A lookup keyed entirely on strings and not interfaces is perfectly
possible using the ZCA, just register your utility to provide
z.i.Interface and name it. Your semantics are the same as the simple
dictionary use-case, but it doesn't force people to choose one means
Martin Aspeli wrote:
We need to make sure that we're not inventing a different way to achieve
something which is already possible. This will lead to confusion,
because people will have to know which way is applicable in a given
situation, and the distinction will seem arbitrary.
I fear we
Chris McDonough wrote:
Off the top of my head, another way to think of this *might* be to say
that the 'dict access' is basically looking up a *named* utility
providing a very generic marker interface, e.g.
zope.component.interfaces.IUtility or even just
zope.interface.Interface. That
Hi Chris,
Chris McDonough wrote:
Martin Aspeli wrote:
We need to make sure that we're not inventing a different way to achieve
something which is already possible. This will lead to confusion,
because people will have to know which way is applicable in a given
situation, and the
Chris McDonough wrote:
Chris McDonough wrote:
Off the top of my head, another way to think of this *might* be to say
that the 'dict access' is basically looking up a *named* utility
providing a very generic marker interface, e.g.
zope.component.interfaces.IUtility or even just
Martin Aspeli wrote:
Hi Chris,
Chris McDonough wrote:
Martin Aspeli wrote:
We need to make sure that we're not inventing a different way to achieve
something which is already possible. This will lead to confusion,
because people will have to know which way is applicable in a given
Matthew Wilkes wrote:
On 2009-11-24, at 0521, Chris McDonough wrote:
I don't think I understand. Could you provide an example?
Sure!
I think this is the same thing that Martin suggested, but here's some
code which should make it clearer.
First, we create an object that we want to
Martin Aspeli wrote:
Meh, I just remembered that I tried this. The current implementation
requires
that the name value be a literal string object (or at least something
convertable to Unicode). I think we could relax this requirement; it really
only needs to be hashable. I wouldn't
Chris McDonough wrote:
Thanks. Yup. I would be +1 on this if the registry itself implemented
IDictInterface.
If that was untenable, if all the above code lived in the zope.component
package itself, and you had an API that manifested an IDictInterface object
when you asked for a
Chris McDonough wrote:
OK after rereading this, I think we may be massively overthinking this. The
above is getting kinda silly. I can't think of a use case where being able
to
alternate between:
reg.utils['root_factory']
and
reg.getUtility(IAnonymousUtility,
Martin Aspeli wrote:
Could maybe we instead just do:
class Components(object):
def __init__(self, name='', bases=()):
self.utils = {}
This would be faster, simpler to document, and would require exactly one
line
of code.
Except at this point we've lost all the
38 matches
Mail list logo
