[merge] LazyFactory

John Arbash Meinel john at arbash-meinel.com
Tue Aug 15 05:05:48 BST 2006


Adeodato Simó wrote:
> * John Arbash Meinel [Mon, 14 Aug 2006 11:34:32 -0500]:
> 
>>> +    def register(self, key, object):
>>> +        """Register a new object to a name.
>>> +
>>> +        :param key: This is the key to use to request the object later.
>>> +        :param object: The object to register.
>>> +        """
>>> +        if self._first_is_default and not self._dict:
>>> +            self._default_key = key
>>> +        self._dict[key] = object
> 
>> If you are going to have an explicit _default_key object, then this
>> should be:
> 
>> if self._first_is_default and self._default_key is None:
>>   self._default_key = key
> 
> Well, while I see your point, I think bool(self._dict) reads closer to
> "is this the first registered entry?", than checking _default_key. But
> if you're strong on having it with "_default_key is None", I don't
> object at all to changing it.

I'm fine with using bool(self._dict).

...

> On perspective, the name of the parameter should probably be "fallback_key"
> instead of "default_key". I've changed that in my branch.
> 
> The intent is to supply the functionality of default_value, but assuming
> such value would always come from the registry itself, so that instead
> of e.g.:
> 
>   foo = registry.get(user_supplied, registry.get(another_one))
> 
> you could do:
> 
>   foo = registry.get(user_supplied, another_one)

What is your specific use case for this? When would it be better to fall
back, rather than give a warning that the value requested didn't exist?

...

> Nice. So to clear things up, this should be ready to enter after you
> tell me your preference about this two issues:
> 
>   - the register() bit mentioned at the beginning of this mail
> 
>   - whether to drop fallback_key in get(), and whether to replace it
>     with default_value=None (in which way, as a side-effect, the method
>     would never raise a KeyError exception, but return None instead).

You can convince me if you have an actual use case for fallback_key.
We need a way to specify what the real default is (just having it set at
to the first key doesn't let something later on update it to a new key).

> 
> I hope this can make it into 0.10, maybe even with making log.py use it.
> BTW, would this addition need a NEWS entry under "INTERNALS"?
> 
> Thanks,
> 

Probably would be good to add something to INTERNALS. Either that or we
could actually wake up NEWS.developers and put it there.

I'm not sure what will use it. I wanted to get my 'version_info' stuff
in, and have it be used there. And it opens up the door for a few more
things to use it. (I envision even having Branch and Repository using
something like this so we don't have to load all compatibility code for
every operation. And even doing something similar for Command classes.
But that needs a new lazy class, so that you can get aliases and such
out). I don't see a lot of the other stuff happening for 0.10, but
getting this in would be nice.

It just needs to be accepted before Monday, though.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060814/17c8c6a9/attachment.pgp 


More information about the bazaar mailing list