Code review comment for lp:~jkakar/launchpadlib/fake-launchpad

Revision history for this message
Martin Pool (mbp) wrote :

.. you've probably thought about this much more than me, but it seems to me you'd want

1- interfaces that can potentially be used against either a real launchpad or a fake one, assuming the code calling them makes no assumptions about the existence or nonexistence of particular data - for instance making a person and setting some attributes on them should be in that class

2- interfaces that simulate behaviour or state we could assume would already be present on the other end of a remote launchpad, like the existence of 'me' or searchTasks

3- interfaces that populate sample data more quickly/efficiently than talking to Launchpad

Why do I think I want this?

+ self.launchpad.me = dict(getBranches=lambda statuses: branches)
+ branches = self.launchpad.me.getBranches([])

This seems oddly nonpythonic. I can guess there is a getattr hack there, and that's fine for simulating the behaviour on 'me.getBranches', but it seems odd to also load things into it by assigning to a dict.

Secondly, I feel that if just assigning to things works, there is a risk people will have code that accidentally passes, when assigning to lplib proxy objects won't behave the same way. Maybe this isn't a real problem, and we just need to write some actual tests using this to see what happens.

« Back to merge proposal