#4 Open
Repository
dsuch dsuch
Branch
default
Repository
runeh runeh
Branch
default

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

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update 
hg pull -r default https://bitbucket.org/dsuch/anyjson
Author
  1. Dariusz Suchojad avatarDariusz Suchojad
Reviewers
Description

Hi Rune,

can you please have a look at this pull request? This is to fix #6 https://bitbucket.org/runeh/anyjson/issue/6/add-object_hook-support

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.

Cheers!

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.

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.