.. 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
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.
.. 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(getBranche s=lambda statuses: branches) me.getBranches( [])
+ branches = self.launchpad.
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.