Description
Hello,
The API currently returns a dict from many calls where it seems, perhaps naively, an object would be more useful. I'm aiming to add some OO notions to the API exposed by docker-py, but not before consulting people here.
For example, Client.create_container returns a dict, and usage looks like:
client = Client()
cont = client.create_container(**info)
if 'Id' in cont:
client.start(cont['Id'])
with needing both client and cont for the 'start' call. Whereas if create_container returned a hypothetical Container object, the container run code then look like:
client = Client()
cont = client.create_container(**info)
cont.start()
There's a branch called 'objects' that looks like the very beginnings of such an approach, but it hasn't been touched in 3 years, and current master shows no sign of incorporating any OO notions for the API, outside of docker.Client.
Why that approach was dropped? I'd like to look at adding some objects to the API, but not if there were unforeseen issues with that. If there are issues, it would be preferable to have them written down and documented here. (There are various ways to approach supporting legacy code, but if an OO api is fundamentally incisompatible, for whatever reason, then discussing support of legacy code seems premature.)
I was unable to find any docs or issues relating to this particular architectural decision, though I did come across #417 and #538, which aren't this specific question.