Writing a module to abstract a REST api

[Sven R. Kunze]

Hi Joseph,

the basic wiring instances together is done via the assignment operator: 
"=". Like: queue._api = foo. Now, the "queue" knows about its API instance.

Question now is, when do you do "="?

On 18.09.2015 23:43, Joseph L. Casale wrote:
> This is where I am going, but how do you perform dependency injection
> in Python?

I am uncertain how large the application you want to build is supposed 
to be. I would definitely would start with less code (tighter coupled) 
which is easier to maintain in the first run.

But if you are interesting the DI in Python in general, I think you 
would love to read those two resources:

http://www.aleax.it/yt_pydi.pdf
http://code.activestate.com/recipes/413268/

I am not saying you shouldn't do DI, but it's easier to tight-couple 
things and make them more flexible in the aftermath *when finally you 
know where you application is going*. Otherwise, it might turn out to be 
a waste of resources.

>> It's perfectly fine to add a "secret" API instance to the object. It's
>> called aspect-oriented programming. You remove the aspect of how to
>> correctly manage an API instance and put that knowledge into a separate
>> piece of code. *thumbs up*
> Yea, I am glad you agree:) Its a model I certainly subscribe to. I just don't
> know how to make the disparate case "know" of the foo instance when
> foo didn't instantiate it (which gives the injection opportunity).

As usual, somebody *needs**to know*. So, if the first version is only 
working hard-coupled because foo instantiated the queues, the second 
version then would, for example, assign the APIWrapper class instead of 
an APIWrapper instance to the _api attribute of all queue instances. The 
class could then work as a lookup/factory method*.***

If that is still not flexible enough and you find Queue and APIWrapper 
is still too much coupled, you can then refactor that out into a third 
module which is responsible only for wiring the instances together (or 
use the recipe).

But remember, you increase the complexity more and more and you better 
decide whether it's worth it, taking maintenance and future development 
into account.

I might reiterate here: I don't know of the scale of your application 
but if it is from scratch, you better start with tighter coupling and 
remove it bit by bit later, when you know where the journey goes AND if 
the tight coupling causes issues. It does not make sense to solve 
non-issues (at least economically).

> That foo instance also serves of a starting point to make the GET type queries.
>
> How would you go about making disparate case lookup a handle, especially
> when I insist on placing all the objects in their files.

Why do you want to store the objects in files? Caching?

> I know, tough to do in
> Python, but its what I am used to.

That's alright. Your thinking will change the longer you use Python. You 
are going to strive for the simples (non-complex), shortest, direct and 
most comprehensive solution. It's a development; don't forget what 
you've learned but be open for the Python style. :)


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150919/1e4c1ba8/attachment.html>