[Zope-dev] make zope.component.registry.Components inherit from dict?

[Chris McDonough]

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 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.

> In fact, this is not a ZCA 
> "utility" at all, it's just a key-value pair in a threadlocal. It 
> doesn't have any consistency with named utilities or adapters or any 
> other aspect of the ZCA.
> 
> I'm not saying having "just" a thread-local dictionary is a bad idea, 
> but maybe it's not a ZCA responsibility at all. Why would you really 
> expect it on getSiteManager().utils or whatever?

Sure, I could have another dictionary laying around as a thread local.  I 
already effectively do that now; the particular thread local dictionary I use 
just happens to *be* the registry.  Libraries written that make use of that 
feature in BFG are not usable within Zope, however, which is suboptimal.

The types of data contained by both the dictionary I want and the ZCA are the 
same types of things (statements about application configuration, expressed 
conceptually as "utilities").  We only need one thread local to hold 
application configuration; having N of them is an anti-use-case, and having 
multiple of them implies balkanization.

So if you say that you must be able to override registrations made via 
"reg['foo']" or "reg.utils['foo']" with a local utility via 
"localreg.registerUtility(someoverride, IAnonymousUtility, name='foo')", and 
that the local utility registry can't handle "localreg['foo']" sensibly by 
falling back to "globalreg['foo']", I'd believe you, even though I don't 
understand why not.  It's not that important, really.

> Maybe it's better to 
> look into the stacked variables that Pylons uses for some of its 
> configuration stuff?

Hell no.  That particular implementation is a holy mess.

- C