Avoid using global state

[ThiefMaster]

Please consider using standard OOP patterns as it's common for such libraries instead of relying on global state.
Nothing wrong with providing some convenience utils that rely on a global client, but developers who want to nicely encapsulate things should not be required to deal with global state.

A nice API would be something like this:

cconvert = CloudConvertClient(api_key=..., sandbox=...)
cconvert.foo()

I think #13 and #24 are both about issues which are implicitly caused by the current design.

For a commercial product (albeit at very decent pricing, so nothing wrong with that!) I also find the lack of activity on this repo (and issues) a bit worrying TBH. Can we assume that your infrastructure is better maintained than the client libraries? I'd hope so but you never know... ;)

[josiasmontag]

The current design has historic reasons and I agree that a global client is a bad design. However, changing this would be a breaking change which we do want to avoid at this point.

We might change this with next major version but there are no fixed plans yet.

The repo is actively maintained and we are not aware of any current bugs. It supports all available features of the CloudConvert API, including the latest additions (Signed URLs). The last update has been at the end of March of this year. So I do not see your point of a "lack of activity". Our Python SDK is much less used than our other SDKs; most customers do use the PHP or node.js SDK. This is why you might see more "activity" there.

[ThiefMaster]

Thanks for the quick reply. Indeed, the lack of activity comment was mainly about the repo having open issues and not having had any commits for some months.

Regarding breaking changes, I think a major version bump would avoid any issues there; alternatively it'd most likely be possible to just export a new client class with a currently-unused name and leave the existing parts as they are.