Merge lp:~robru/gwibber/discovery into lp:~barry/gwibber/py3
Status: | Merged |
---|---|
Merged at revision: | 1416 |
Proposed branch: | lp:~robru/gwibber/discovery |
Merge into: | lp:~barry/gwibber/py3 |
Diff against target: |
154 lines (+35/-59) 4 files modified
gwibber/gwibber/protocols/flickr.py (+1/-1) gwibber/gwibber/tests/test_protocols.py (+11/-15) gwibber/gwibber/utils/modules.py (+0/-43) gwibber/gwibber/utils/protocol.py (+23/-0) |
To merge this branch: | bzr merge lp:~robru/gwibber/discovery |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Barry Warsaw | Pending | ||
Review via email: mp+122995@code.launchpad.net |
Description of the change
Ugh, today was a disaster :-/
So what I've done here is merged find_all_protocols and Base protocol class into gwibber.
1. Despite Base class no longer living in protocols directory, inspect.getmembers is still managing to yield it from find_all. My guess would be that this is happening because the flickr plugin imports Base into it's own namespace, so inspect finds it in that namespace and then yields it. So the 'value is not Base' test is still necessary, defeating much of what I set out to do today. The only way I can see around this is to give up on the idea of importing all classes, and just import the class that matches the filename (or just live with it as-is, that's probably not so bad either).
2. My idea that the ProtocolManager would actually instantiate all plugins in it's __init__ method is another utter failure, because the plugins need accounts in order to be instantiated, and the PluginManager doesn't have any access to the accounts in order to actually do that. So the best we're going to get from this is a dict mapping basenames to classes (not instances), which I am about to implement. It's going to break your elegant generator, but unfortunately that is necessary because the other bits of gwibber are going to need to do 'ProtocolManage
Anyway, please review & merge this, and then we can discuss how to proceed with regards to the dispatcher interacting with plugins. I'm thinking that the Account class should contain a reference to the instance of the protocol that it belongs to, but in particular we need to figure out what the lifetime and scope of protocol instances is going be. Eg, can we design it so that the instance that represents each acount is persistent in memory (similar to my @memoize magic), or is it ok to have multiple different instances of the protocol class representing a given account (eg, if two different threads happen to instantiate their own Flickr plugin for the same account, is that ok, or is that going to conflict with each other). I guess what I'm really trying to say is that we need to audit this code for thread safety.
Thanks!
Barry, I can't figure out why the tests aren't passing here, it works successfully when I access it from an interactive python session. Something about the unittest environment is breaking something else that's going on, but I can't figure out what because I haven't changed much from your code that did work, the biggest change is that it's executing the code immediately instead of as a generator.
So sorry for mp'ing broken code, hopefully there's something obvious that I've overlooked because I'm exhausted. Please have a look!