NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #489 most downloaded on PyPI
Iterative JSON parser with standard Python iterator interfaces
Last release 3 months ago
06 Jul 2026
Release timing varies
gaps range from 9 days to 1.8 years
Most releases are documented
notes for 26 of 41 stable releases
Nothing withdrawn
no release was ever pulled
16 years old
44 releases · first in 2010
The internal ijson.common.ObjectBuilder no longer creates internal reference cycles, so discarded builders are freed by reference counting instead of
ijson.common.ObjectBuilder no longer creates internal reference
cycles, so discarded builders are freed by reference counting instead
of waiting for a cyclic garbage collection pass. This lowers peak
memory usage for code that builds and discards one large object at a
time. As a side effect, builder.value is now None before any
event is processed (previously accessing it raised AttributeError),
and the undocumented containers attribute holds the in-progress
containers rather than setter closures.This project publishes no release notes. Between v3.5.0 and v3.5.1 there were 17 commits, 11 of them substantive:
One column per quarter.
Added input iterator support via the new ijson.from_iter adapter. It allows users to easily consume iterators and async iterators, with common example
ijson.from_iter adapter.
It allows users to easily consume iterators and async iterators,
with common examples being HTTP stream responses
as modelled by the requests and httpx libraries.tox for common task execution.This project publishes no release notes. Between v3.4.0.post0 and v3.5.0 there were 13 commits, 5 of them substantive:
Release ijson 3.4.0.post0
Release ijson 3.4.0.post0
This project publishes no release notes. Between v3.4.0 and v3.4.0.post0 there were 15 commits, 8 of them substantive:
Added support for PEP 489 multi-phase initialisation and per-module state for our C extension, allowing us to support sub-interpreters with per-interp
ijson.ALL_BACKENDS constant
listing all supported backends
(which might or not be available at runtime).capabilities constant to each backend
describing which capabilities it supports.<backend>.backend_name,
and default backend's name under ijson.backend_name.
This is similar to the already existing name constant,
only slightly better named to hopefully avoid confusion.src/,
and the ijson.backends._yajl2 extension under src/ijson/backends/ext/_yajl2.
This allows C backend tests to actually run on cibuildwheel.parse routine in C backend by ~4%.yajl2_c backend,
which didn't work correctly with user-provided event names.yajl and yajl2 backends
where crashes could occur at interpreter shutdown.pyproject.toml.This project publishes no release notes. Between v3.3.0 and v3.4.0 there were 106 commits, 96 of them substantive:
…and 76 more.
Removed support for Python 2.7 and 3.4, 3.5+ is still supported.
benchmark.py script
as ijson.benchmark.
The module is an improved version of the script,
supporting #iterations for a given function invocation,
multiple input files,
and more.This project publishes no release notes. Between v3.2.3 and v3.3.0 there were 26 commits, 26 of them substantive:
…and 6 more.
Fixed several issues in the yajl2_c backend and its async generators that were only made apparent when running it with PyPy and/or a CPython debug bui
yajl2_c backend
and its async generators
that were only made apparent
when running it with PyPy
and/or a CPython debug build (#101).
As part of that,
an issue was found and fixed in PyPy itself
affecting all versions up to 7.3.12,
so users will need to wait until the next version is released
to be able to use async generators
(https://foss.heptapod.net/pypy/pypy/-/issues/3956).yajl2_c async generators
to work against PyPy shortcomings
(https://foss.heptapod.net/pypy/pypy/-/issues/3965).This project publishes no release notes. Between v3.2.2 and v3.2.3 there were 6 commits, 6 of them substantive:
Fixed compilation and async support of the yajl2_c backend in pyhthon 3.12 (#98).
async support
of the yajl2_c backend in pyhthon 3.12 (#98).IJSON_BUILD_YAJL2C environment variable
when building ijson
to force/skip building the yajl2_c backend (#102).This project publishes no release notes. Between v3.2.1 and v3.2.2 there were 10 commits, 10 of them substantive:
Fixed a memory leak in the yajl2_c backend triggered only when the underlying yajl functions reported a failure (#97).
yajl2_c backend
triggered only when the underlying yajl functions
reported a failure (#97).This project publishes no release notes. Between v3.2.0.post0 and v3.2.1 there were 6 commits, 6 of them substantive:
Fixed minor README rendering issues that prevented upload of 3.2.0 distributions to PyPI.
This project publishes no release notes. Between v3.1.4 and v3.2.0.post0 there were 22 commits, 22 of them substantive:
…and 2 more.
Fixed bug in yajl2_c backend introduced in 3.1.0 where ijson.items didn't work correctly against member names containing . (#41).
yajl2_c backend introduced in 3.1.0
where ijson.items didn't work correctly
against member names containing . (#41).Python backed correctly raises errors when JSON numbers with leading zeros are found in the stream (#40).
read coroutines
(i.e., a read generator decorated with @types.coroutine)
for the purpose of automatically routing user calls
done through the main entry points.
For example, when using aiofiles objects
users could invoke async for item in ijson.parse_async(f)
but not async for item in ijson.parse(f),
while the latter has been possible since 3.1
for native coroutines.Moved binary wheel generation from GitHub Actions to Travis. This gained us binary ARM wheels, which are becoming increasingly popular
Fixed minor memory leaks in the initialization methods of the generators of the yajl2_c backend. All generators (i.e., basic_parse, parse, kvitems and
yajl2_c backend.
All generators
(i.e., basic_parse, parse, kvitems and items)
in both their sync and async versions,
were affected.Fixed two problems in the yajl2_c backend related to asyncio support, which prevented some objects like those from aiofiles from working properly (#32
yajl2_c backend
related to asyncio support,
which prevented some objects
like those from aiofiles
from working properly (#32).use_float=True
and its side-effect on integer number parsing.Removed test package from binary distributions.
test package from binary distributions.ijson.common routines parse, items and kvitems are marked as deprecated. Users should use the ijson.* routines instead, which now accept event iterabl…
use_float option has been added to all backends
to control whether float values should be returned
for non-integer numbers instead of Decimal objects.
Using this option trades loss of precision
(which most applications probably don't care)
for performance (which most application do care about).
Historically ijson has returned Decimal objects,
and therefore the option defaults to False
for backwards compatibility,
but in later releases this default could change to True.items and kvitems methods
of the yajl2_c backend
(by internally avoiding unnecessary string concatenations).
Local tests show a performance improvement of up to ~15%,
but mileage might vary depending on your use case and system.basic_parse, parse, items and kvitems
can now be used with different types of inputs.
In particular they accept not only file-like objects,
but also asynchronous file-like objects,
behaving like their *_async counterparts.
They also accept bytes and str objects directly
(and unicode objects in python 2.7).
Finally, they also accept iterables,
in which case they behave like the ijson.common.* functions,
allowing users to tap into the event pipeline.ijson.common routines parse, items and kvitems
are marked as deprecated.
Users should use the ijson.* routines instead,
which now accept event iterables.ijson.get_backend function
for users to import a backend programmatically
(without having to manually use importlib).IJSON_BACKEND environment variable
can be used to choose the default backend to be exposed by ijson.ijson.common.number is marked as deprecated,
and will be removed on some later release.Fixed errors triggered by JSON documents where the top-level value is an object containing an empty-named member (e.g., {"": 1}). Although such docume
{"": 1}).
Although such documents are valid JSON,
they broke basic assumptions made
by the kvitems and items functions
(and all their variants)
in all backends,
producing different types of unexpected failures,
including segmentation faults, raising unexpected exceptions,
and producing wrong results.Fixed segmentation fault in yajl2_c backend's parse caused by the previous fix introduced in 3.0.2 (#29).
yajl2_c backend's parse
caused by the previous fix introduced in 3.0.2 (#29).Fixed memory leak in yajl2_c backend's parse functionality (#28).
yajl2_c backend's parse functionality (#28).Adding back the parse, kvitems and items functions under the ijson.common module (#27). These functions take an events iterable instead of a file and
parse, kvitems and items functions
under the ijson.common module (#27).
These functions take an events iterable instead of a file
and are backend-independent (which is not great for performance).
They were accidentally removed in the redesign of ijson 3.0,
which is why they are coming back.
In the future they will slowly transition into being
backend-specific rather than independent.Exposing backend's name under .backend, and default backend's name under ijson.backend.
<backend>.backend,
and default backend's name under ijson.backend.ijson.sendable_list to users in case it comes in handy.Implemented all asynchronous iterables (i.e., *_async functions) in C for the yajl2_c backend for increased performance.
*_async functions)
in C for the yajl2_c backend for increased performance.Fixed known problem with 3.0rc1, namely checking that asynchronous files are opened in the correct mode (i.e., binary).
.close() on the coroutine.benchmark.py.Full re-design of ijson: instead of working with generators on a "pull" model, it now uses coroutines on a "push" model. The current set of generators
basic_parse, parse, kvitems and items)
are implemented on top of these coroutines,
and are fully backward compatible.
Some text comparing the old a new designs
can be found here.asyncio in python 3.5+
in the for of async for-enabled asynchronous iterators.
These are named *_async, and take a file-like object
whose read() method can be awaited on.*_coro,
and take a coroutine-like object
(i.e., implementing a send method)
instead of file-like objects.
In this scheme, users are in charge
of sending chunks of data into the coroutines
using coro.send(chunk).readinto when possible)
and by avoiding tuple packing/unpacking in certain situations.Fixed a deprecation warning in the C backend present in python 3.8 when parsing Decimal values.
New kvitems method in all backends. Like items, it takes a prefix, and iterates over the key/value pairs of matching objects (instead of iterating ove
kvitems method in all backends.
Like items, it takes a prefix,
and iterates over the key/value pairs of matching objects
(instead of iterating over objects themselves, like in items).
This is useful for iterating over big objects
that would otherwise consume too much memory.map_key values as unicode objects, not str
(until now only the Python backend did so).
This is what the json built-in module does,
and allows for correctly handling non-ascii key names.
Comparison between unicode and str objects is possible,
so most client code should be unaffected.Fixing backwards compatibility, allowing string readers in all backends (#12, #13).
Default backend changed (#5). Instead of using the python backend, now the fastest available backend is selected by default.
map_type option (#7).multiple_values support in C backend (#8).multiple_values flag in python backend (#9).**kwargs from ijson.items to ijson.parse and
ijson.basic_parse (#10).common.number implementation.New ijson.backends.yajl2_c backend written in C and based on the yajl2 library. It performs ~10x faster than cffi backend.
ijson.backends.yajl2_c backend written in C
and based on the yajl2 library.
It performs ~10x faster than cffi backend.ijson.itemsNothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →