Made dumps and loads pass any optional arguments to the underlying implementation

#4 Declined
Deleted repository
default (0ed3b2ae462a)
  1. Dariusz Suchojad

Hi Rune,

can you please have a look at this pull request? This is to fix #6

As it turns out, jsonlib2 also accepts additional arguments so that one is able to specify custom serializers.

Passing args and *kwargs does the trick in that and any other similar case.


  • Issues #6: add object_hook support new

Comments (3)

  1. Rune Halvorsen repo owner

    Hey, sorry your PR got neglected.

    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?

  2. theatilla

    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.

  3. Dariusz Suchojad author

    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.