Add json.ExtendedEncoder to the standard library for common types (datetime, UUID, Decimal, set)

[xitop]

Converting many standard values (date, time, bytes, complex numbers, UUIDs, etc.) to text and back from text is quite easy.

Creating a format serializable by JSON is quite easy too (just add a data type info to each converted value - example: "date:2026-06-03", BTW "int:42" solves the JSON key type limitation). What’s quite disappointing and surprising (at least for me) is that there is no real standard for that.

Given the history of TOML, there is a chance that a well thought out solution that suits not 80%, but 99+% becomes a wide-spread standard.

[elis.byberi]

@0xProgress

json module is a vital tool, but it currently lacks native support for several foundational types within Python’s own standard library

Note that JSON is not the only data format; serialization issues exist across all data formats. This means serialization is not specific to JSON. Each format has its own data types and constraints.

When data falls outside those constraints, it often indicates a mismatch between the data format and the use case, which can result in using the wrong format or misusing an existing one rather than a limitation unique to JSON. In such cases, the issue is typically not with the format itself, but with choosing an inappropriate representation for the data.

For example, using JSON to transmit binary data does not make much sense.

[AndersMunch]

@0xProgress

        if isinstance(obj, Decimal):
            # Serialized as string to prevent IEEE 754 float precision loss
            return str(obj)

JSON numbers are quite literally decimal numbers. Representing them as strings because of “IEEE 754” is suspect.

If only json encoder unable to handle decimal · Issue #60739 · python/cpython · GitHub would be completed, then in conjunction with the parse_float argument to json.load, Decimal would be perfectly taken care of.

[Lucas_Malor]

@jb2170

But then it wouldn’t be JSON, it would be, err PythON, or Pythonon, or PYON lol

Why isn’t it JSON? The OP is proposing an opinionated way to serialize some Python object to standard JSON, not to create JSON5++.
Anyway, PYON is cool. It remembers me Starcraft. We can build our own JSON, with blackjack and… lemonade.

@jb2170

base64 also exists (information rate of 6/8) if you’ve agreed on what the extra two symbols are going to be (RFC 4648 or its websafe suggestion

I don’t get the point. I always used JSON in the body of an endpoint, never as URL param or path.

@elis.byberi

For example, using JSON to transmit binary data does not make much sense.

Notice that the OP didn’t added bytes to the proposal. On the contrary, he also explained why he didn’t add it.

[elis.byberi]

@Lucas_Malor

Notice that the OP didn’t added bytes to the proposal. On the contrary, he also explained why he didn’t add it.

My reasoning differs from that of the original poster and applies to any Python object that cannot be represented as text. JSON is not an appropriate format for transmitting data types that it does not support. Serialization is not an issue with the JSON format itself. The JSON library is already complete. This means that the concern of a JSON library is to support JSON data types in Python, not Python-specific data types or objects within JSON.