I'm not convinced there is a good use case for that code though. To pass in args/kwargs that make sense, you have to know what implementation is being used. If you require a particular implementation, it makes more sense to import it directly, doesn't it?
I might be misunderstanding though. Do you have an example, when it makes sense to pass in extra args?
There are actually a bunch of kwargs that are passed in to loads() and dumps(), as well as load() and dump(). I've had increasing need to use them lately and not every implementation seems to support them all. In order for this to make sense, one would have to cross-reference the args of all supported implementations and check which parameters could be supported.
Well, in 90% of cases I just like to use anyjson instead of thinking of what the current implementation is.
However, there are situations when I know exactly which one it is because I've got it configured through buildout, i.e. I know it will be such and such thing and nothing else. This is where it's convenient and safe to use these args and kwargs.
As far as cross-referencing the arguments, I guess this would be quite a burden to maintain not to mention that with time there would be some conflicts, the name would be the same but functionality across different impls would differ.
I'm honestly happy with anything you guys decide - I still think args and kwargs are OK because they let the user control and decide what they prefer to use instead of anyjson's deciding what is better - but if you're not fine with it /in most cases/ I can just patch the library myself. Not always doable but I can live with it.