Wow, thanks! Does this noticeably affect performance? I think it's okay if it does, but would be nice to note.

I didn't really measure it, but it should not have much impact: the test to recognize the various formats is very light and the actual parse happens only on positive checks. It is surely much much faster than any alternative way, where the check and the conversion is done at the Python level.

I added a specific benchmark:

tests/test_benchmark.py::test_datetime_performance
Datetimes:
rapidjson (string) serialize: 0.467 deserialize: 0.872 total: 1.338
rapidjson (native) serialize: 1.179 deserialize: 0.931 total: 2.111

To fit my needs, I also implemented an equivalent support for UUIDs. Lemme know if you'd appreciate a PR for that too!

These are the results of another benchmark, that measures the overhead of the datetime_mode
parameter: the first is the default, the second is with datetime_mode=None (to give an idea
of the impact of the partial() wrapper), the third with the datetime machinery activated,
all of them operating on data not containing any datetime object.

I think I'm done for now, but I'm of course willing to do whatever tweak or further test you
may desire.

tests/test_benchmark.py::test_json_medium_complex_objects[rapidjson-serialize3-deserialize3] 
256 Medium Complex objects:
rapidjson   serialize: 2.134  deserialize: 4.015  total: 6.149
PASSED
tests/test_benchmark.py::test_json_medium_complex_objects[rapidjson (dtm=None)-serialize5-deserialize5] 
256 Medium Complex objects:
rapidjson (dtm=None) serialize: 2.195  deserialize: 4.106  total: 6.301
PASSED
tests/test_benchmark.py::test_json_medium_complex_objects[rapidjson (dtm=ISO8601)-serialize6-deserialize6] 
256 Medium Complex objects:
rapidjson (dtm=ISO8601) serialize: 2.192  deserialize: 4.132  total: 6.324
PASSED

@lelit not a maintainer here (or even a contributor), but if these folks want to accept UUIDs PR, I'd appreciate it! :)

Yup, me too!

@kenrobbins, any chance for you to make it clear if/when this could be accepted?

@kenrobbins Ping!

@lelit I think my only complaint about this PR is the lack of documentation. Could you update the README to discuss these changes?

Yes, I can easily do that. But, given that the READMEdoes not currently cover any of these details, shouldn't it be better to write something usable also for #22? What's the state of that?

sorry for the delay. i have returned. thanks very much. uuids are fine with me if you want to submit that pr.

Great, thank you!

I'll probably rebase that branch on top of your current master and propose a PR.