python-rapidjson 0.4.0

Python wrapper around rapidjson

RapidJSON is an extremely fast C++ JSON parser and serialization library: this module wraps it into a Python 3 extension, exposing its serialization/deserialization (to/from either bytes, str or file-like instances) and JSON Schema validation capabilities.

Latest version documentation is automatically rendered by Read the Docs.

Getting Started

First install python-rapidjson:

$ pip install python-rapidjson

or, if you prefer Conda:

$ conda install -c conda-forge python-rapidjson

Basic usage looks like this:

>>> import rapidjson
>>> data = {'foo': 100, 'bar': 'baz'}
>>> rapidjson.dumps(data)
'{"bar":"baz","foo":100}'
>>> rapidjson.loads('{"bar":"baz","foo":100}')
{'bar': 'baz', 'foo': 100}
>>>
>>> class Stream:
...   def write(self, data):
...      print("Chunk:", data)
...
>>> rapidjson.dump(data, Stream(), chunk_size=5)
Chunk: b'{"foo'
Chunk: b'":100'
Chunk: b',"bar'
Chunk: b'":"ba'
Chunk: b'z"}'

Development

If you want to install the development version (maybe to contribute fixes or enhancements) you may clone the repository:

$ git clone --recursive https://github.com/python-rapidjson/python-rapidjson.git

Note

The --recursive option is needed because we use a submodule to include RapidJSON sources. Alternatively you can do a plain clone immediately followed by a git submodule update --init.

Alternatively, if you already have (a compatible version of) RapidJSON includes around, you can compile the module specifying their location with the option --rj-include-dir, for example:

$ python3 setup.py build --rj-include-dir=/usr/include/rapidjson

A set of makefiles implement most common operations, such as build, check and release; see make help output for a list of available targets.

Performance

python-rapidjson tries to be as performant as possible while staying compatible with the json module.

The following tables show a comparison between this module and other libraries with different data sets. Last row (“overall”) is the total time taken by all the benchmarks.

Each number show the factor between the time taken by each contender and python-rapidjson (in other words, they are normalized against a value of 1.0 for python-rapidjson): the lower the number, the speedier the contender.

In bold the winner.

Serialization

serialize	dumps()[1]	Encoder()[2]	dumps(n)[3]	Encoder(n)[4]	ujson[5]	simplejson[6]	stdlib[7]	yajl[8]
100 arrays dict	1.00	0.99	0.63	0.63	0.88	3.97	2.24	1.39
100 dicts array	1.00	1.04	0.73	0.70	0.87	5.79	2.31	1.36
256 Trues array	1.00	1.08	1.23	1.09	1.35	3.55	2.31	1.32
256 ascii array	1.00	1.01	1.04	1.03	0.51	1.17	1.04	1.12
256 doubles array	1.00	1.02	1.06	1.02	7.45	8.18	7.69	4.34
256 unicode array	1.00	0.88	0.88	0.88	0.55	0.74	0.67	0.51
complex object	1.00	1.02	0.81	0.79	1.13	3.98	2.84	2.21
composite object	1.00	1.00	0.69	0.65	0.98	3.12	1.99	2.00
overall	1.00	0.99	0.63	0.63	0.88	3.97	2.24	1.39

Deserialization

deserialize	loads()[9]	Decoder()[10]	loads(n)[11]	Decoder(n)[12]	ujson	simplejson	stdlib	yajl
100 arrays dict	1.00	1.00	0.90	0.90	0.96	1.40	1.12	1.15
100 dicts array	1.00	1.04	0.87	0.88	0.94	1.95	1.61	1.25
256 Trues array	1.00	1.24	1.17	1.25	1.16	2.09	1.87	1.86
256 ascii array	1.00	1.03	1.04	1.05	1.41	1.31	1.24	1.49
256 doubles array	1.00	1.01	0.19	0.19	0.44	0.91	0.85	0.56
256 unicode array	1.00	1.01	1.01	1.01	1.27	5.46	6.17	3.04
complex object	1.00	1.02	0.78	0.79	0.99	1.60	1.19	1.22
composite object	1.00	1.01	0.80	0.81	0.76	2.06	1.38	1.29
overall	1.00	1.00	0.90	0.90	0.96	1.41	1.13	1.15

[1]

rapidjson.dumps()

[2]

rapidjson.Encoder()

[3]

rapidjson.dumps(number_mode=NM_NATIVE)

[4]

rapidjson.Encoder(number_mode=NM_NATIVE)

[5]

ujson 1.35

[6]

simplejson 3.13.2

[7]

Python 3.6.4 standard library json

[8]

yajl 0.3.5

[9]

rapidjson.loads()

[10]

rapidjson.Decoder()

[11]

rapidjson.loads(number_mode=NM_NATIVE)

[12]

rapidjson.Decoder(number_mode=NM_NATIVE)

DIY

To run these tests yourself, clone the repo and run:

$ make benchmarks

or

$ make benchmarks-other

The former will focus only on RapidJSON and is particularly handy coupled with the compare past runs functionality of pytest-benchmark:

$ make benchmarks PYTEST_OPTIONS=--benchmark-autosave
# hack, hack, hack!
$ make benchmarks PYTEST_OPTIONS=--benchmark-compare=0001

----------------------- benchmark 'deserialize': 18 tests ------------------------
Name (time in us)                                                            Min…
----------------------------------------------------------------------------------
test_loads[rapidjson-256 Trues array] (NOW)                         5.2320 (1.0)…
test_loads[rapidjson-256 Trues array] (0001)                        5.4180 (1.04)…
…

To reproduce the tables above run make benchmarks-tables

Incompatibility

Here are things in the standard json library supports that we have decided not to support:

separators argument

This is mostly used for pretty printing and not supported by RapidJSON so it isn’t a high priority. We do support indent kwarg that would get you nice looking JSON anyways.

Coercing keys when dumping

json will stringify a True dictionary key as "true" if you dump it out but when you load it back in it’ll still be a string. We want the dump and load to return the exact same objects so we have decided not to do this coercion.

Changes

0.4.0 (2018-01-05)

• Implemented the streaming interface, see load() and dump() (issue #80)

  Backward incompatibility: now the flags arguments on all the functions are keyword only, to mimic stdlib’s json style

0.3.2 (2017-12-21)

• Reduce compiler warnings (issue #87)

0.3.1 (2017-12-20)

• Fix Travis CI recipe to accomodate MacOS

0.3.0 (2017-12-20)

• Fix compilation on MacOS (issue #78)

• Handle generic iterables (PR #89)

  Backward incompatibility: the dumps() function and the Encoder() constructor used to accept a max_recursion_depth argument, to control the maximum allowed nesting of Python structures; since the underlying function is now effectively recursive, it has been replaced by the generic sys.setrecursionlimit() mechanism

0.2.7 (2017-12-08)

• Restore compatibility with Python < 3.6

0.2.6 (2017-12-08)

• Fix memory leaks when using object_hook/start_object/end_object

0.2.5 (2017-09-30)

• Fix bug where error handling code could raise an exception causing a confusing exception to be returned (PR #82)

• Fix bug where loads’s object_hook and dumps’s default arguments could not be passed None explicitly (PR #83)

• Fix crash when dealing with surrogate pairs (issue #81)

0.2.4 (2017-09-17)

• Fix compatibility with MacOS/clang

0.2.3 (2017-08-24)

• Limit the precision of DM_UNIX_TIME timestamps to six decimal digits

0.2.2 (2017-08-24)

• Nothing new, attempt to fix production of Python 3.6 binary wheels

0.2.1 (2017-08-24)

• Nothing new, attempt to fix production of Python 3.6 binary wheels

0.2.0 (2017-08-24)

• New parse_mode option, implementing relaxed JSON syntax (issue #73)

• New Encoder and Decoder, implementing a class-based interface

• New Validator, exposing the underlying JSON schema validation (issue #71)

0.1.0 (2017-08-16)

• Remove beta status

0.1.0b4 (2017-08-14)

• Make execution of the test suite on Appveyor actually happen

0.1.0b3 (2017-08-12)

• Exclude CI configurations from the source distribution

0.1.0b2 (2017-08-12)

• Fix Powershell wheel upload script in appveyor configuration

0.1.0b1 (2017-08-12)

• Compilable with somewhat old g++ (issue #69)

• Backward incompatibilities:

  • all DATETIME_MODE_XXX constants have been shortened to DM_XXX DATETIME_MODE_ISO8601_UTC has been renamed to DM_SHIFT_TO_UTC

  • all UUID_MODE_XXX constants have been shortened to UM_XXX

• New option DM_UNIX_TIME to serialize date, datetime and time values as UNIX timestamps targeting issue #61

• New option DM_NAIVE_IS_UTC to treat naïve datetime and time values as if they were in the UTC timezone (also for issue #61)

• New keyword argument number_mode to use underlying C library numbers

• Binary wheels for GNU/Linux and Windows on PyPI (one would hope: this is the reason for the beta1 release)

0.0.11 (2017-03-05)

• Fix a couple of refcount handling glitches, hopefully targeting issue #48.

0.0.10 (2017-03-02)

• Fix source distribution to contain all required stuff (PR #64)

0.0.9 (2017-03-02)

• CI testing on GitHub

• Allow using locally installed RapidJSON library (issue #60)

• Bug fixes (issue #37, issue #51, issue #57)

0.0.8 (2016-12-09)

• Use unpatched RapidJSON 1.1 (PR #46)

• Handle serialization and deserialization of datetime, date and time instances (PR #35) and of UUID instances (PR #40)

• Sphinx based documentation (PR #44)

• Refresh benchmarks (PR #45)

• Bug fixes (issue #25, issue #38, PR #43)