dep-protobuf/python
Tony Liao 9d98477ca9 Optimize pure Python parse path for custom JSON enum names.
This implementation is similar to our Java idea in cl/949670944,
basically the idea is that we will have a local map (dictionary) that
will be populated the very first time we try to parse into an enum
field. The lifetime of this dictionary will be tied to the Parser
instance, similar to the Java implementation.

BENCHMARKS (baseline stats are recorded at cl/952170250):

Python:
```
[BENCHMARK] ParseJsonDefault:                med 10.06 us/op | p99 11.22 us/op | mean 10.10 ± 0.20 us/op
[BENCHMARK] ParseJsonCustom:                 med 20.33 us/op | p99 22.23 us/op | mean 20.40 ± 0.34 us/op
[BENCHMARK] ParseJsonUnknownIgnored:         med 24.21 us/op | p99 26.25 us/op | mean 24.31 ± 0.44 us/op
[BENCHMARK] ParseRepeatedJsonDefault:        med 1.94 us/item | p99 2.05 us/item | mean 1.95 ± 0.03 us/item
[BENCHMARK] ParseRepeatedJsonCustom:         med 2.26 us/item | p99 2.45 us/item | mean 2.27 ± 0.03 us/item
[BENCHMARK] ParseRepeatedJsonUnknownIgnored: med 5.31 us/item | p99 5.52 us/item | mean 5.32 ± 0.05 us/item
```

Cpp:
```
[BENCHMARK] ParseJsonDefault:                med 8.66 us/op | p99 9.21 us/op | mean 8.70 ± 0.13 us/op
[BENCHMARK] ParseJsonCustom:                 med 26.33 us/op | p99 29.71 us/op | mean 26.44 ± 0.69 us/op
[BENCHMARK] ParseJsonUnknownIgnored:         med 28.46 us/op | p99 31.80 us/op | mean 28.59 ± 0.67 us/op
[BENCHMARK] ParseRepeatedJsonDefault:        med 1.72 us/item | p99 2.19 us/item | mean 1.74 ± 0.06 us/item
[BENCHMARK] ParseRepeatedJsonCustom:         med 2.12 us/item | p99 2.38 us/item | mean 2.13 ± 0.04 us/item
[BENCHMARK] ParseRepeatedJsonUnknownIgnored: med 4.61 us/item | p99 4.92 us/item | mean 4.62 ± 0.07 us/item
```

UPB:
```
[BENCHMARK] ParseJsonDefault:                med 11.22 us/op | p99 12.29 us/op | mean 11.27 ± 0.21 us/op
[BENCHMARK] ParseJsonCustom:                 med 37.54 us/op | p99 39.25 us/op | mean 37.65 ± 0.46 us/op
[BENCHMARK] ParseJsonUnknownIgnored:         med 41.18 us/op | p99 48.45 us/op | mean 41.30 ± 0.89 us/op
[BENCHMARK] ParseRepeatedJsonDefault:        med 2.10 us/item | p99 2.19 us/item | mean 2.10 ± 0.02 us/item
[BENCHMARK] ParseRepeatedJsonCustom:         med 2.58 us/item | p99 2.73 us/item | mean 2.59 ± 0.03 us/item
[BENCHMARK] ParseRepeatedJsonUnknownIgnored: med 5.70 us/item | p99 5.90 us/item | mean 5.71 ± 0.04 us/item
```

Seeing these benchmarks, we can see a very noticeable improvement in
`ParseRepeatedJsonCustom` and `ParseRepeatedJsonUnknownIgnored` cases --
which correspond to the pathological cases that we are worried about.
Singular fields are taking longer to parse in our microbenchmark because
the cache that we've added is tied to each Parser instance and must be
re-instantiated across every `Parse` call.

PiperOrigin-RevId: 970528683
2026-08-25 07:09:41 -07:00
..
dist Add json_options.proto and json_enumvalue_options.proto and/or gencode derived from them to release artifacts 2026-07-31 16:20:59 -07:00
docs py generate_docs: simplify copyright header 2026-03-12 11:53:27 -07:00
google Optimize pure Python parse path for custom JSON enum names. 2026-08-25 07:09:41 -07:00
protobuf_distutils Drop Python 3.9 support 2026-01-09 14:20:23 -08:00
.repo-metadata.json Sync from Piper @457757259 2022-06-28 17:01:18 +00:00
buffer_convert.c Internal change. 2026-07-14 11:25:48 -07:00
buffer_convert.h Internal change. 2026-07-14 11:25:48 -07:00
BUILD.bazel Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
build_targets.bzl Migrate Protobuf Python C extensions to rules_python toolchain targets. 2026-08-17 21:03:55 -07:00
convert.c Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
convert.h upb: add 'options' arg to upb_Message_IsEqual() 2024-03-11 10:16:13 -07:00
descriptor.c Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
descriptor.h bazel 9 tests for csharp, hpb, objc, php, python, rust and upb 2026-05-19 19:58:47 -07:00
descriptor_containers.c Emit deprecation warning when comparing descriptor containers with unrecognized types in OSS 2026-07-10 12:16:37 -07:00
descriptor_containers.h bazel 9 tests for csharp, hpb, objc, php, python, rust and upb 2026-05-19 19:58:47 -07:00
descriptor_pool.c Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
descriptor_pool.h bazel 9 tests for csharp, hpb, objc, php, python, rust and upb 2026-05-19 19:58:47 -07:00
extension_dict.c Emit future warning when mutating GetOptions() in OSS 2026-07-12 13:41:24 -07:00
extension_dict.h bazel 9 tests for csharp, hpb, objc, php, python, rust and upb 2026-05-19 19:58:47 -07:00
internal.bzl avoid using deprecated @bazel_tools//src/conditions:host_windows (#23119) 2025-08-12 09:42:22 -07:00
MANIFEST.in Add LICENSE to released python packages (#8913) 2021-08-27 15:41:58 -07:00
map.c Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
map.h [py/upb] Make GetOptions() return immutable options for scalar type. UPB will raise a TypeError when options returned GetOptions() by is mutated. 2026-05-20 11:33:26 -07:00
message.c fix missed oom handling in unset required 2026-07-30 10:42:17 -07:00
message.h [py/upb] Make GetOptions() return immutable options for scalar type. UPB will raise a TypeError when options returned GetOptions() by is mutated. 2026-05-20 11:33:26 -07:00
minimal_test.py Auto-format Py Proto python files. 2026-04-29 13:40:58 -07:00
protobuf.c Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
protobuf.h Check return values and handle alloc failures in python 2026-07-27 22:11:16 -07:00
py_extension.bzl internal change 2026-07-22 14:45:08 -07:00
python_api.h Update remainder of upb to new short license style. 2023-11-20 13:43:32 -08:00
python_version_test.py Remove --noenable_bzlmod from .bazelrc 2025-01-31 16:45:18 -08:00
README.md Breaking Change: Removed obsolete/duplicate setup.py from Python. 2024-01-31 14:40:41 -08:00
repeated.c Introduce overflow checking functions for add and multiply in upb to replace error-prone manual checks 2026-08-17 17:17:05 -07:00
repeated.h [py/upb] Make GetOptions() return immutable options for scalar type. UPB will raise a TypeError when options returned GetOptions() by is mutated. 2026-05-20 11:33:26 -07:00
requirements.txt Add Python 3.14 test coverage 2025-11-06 19:21:19 -08:00
unknown_fields.c Handle refcount issues on allocation failure in python 2026-08-21 15:34:04 -07:00
unknown_fields.h bazel 9 tests for csharp, hpb, objc, php, python, rust and upb 2026-05-19 19:58:47 -07:00
version_script.lds Reorganize upb file structure 2023-09-26 14:38:35 -07:00

Protocol Buffers Python

This directory contains the Protobuf library for Python.

For user documentation about how to use Protobuf Python, see https://protobuf.dev/getting-started/pythontutorial/

Installation

In most cases you should install the library using pip or another package manager:

$ pip install protobuf

The packages released on https://pypi.org/project/protobuf/#files include both a source distribution and binary wheels.

Building packages from this repo

If for some reason you wish to build the packages directly from this repo, you can use the following Bazel commands:

$ bazel build //python/dist:source_wheel
$ bazel build //python/dist:binary_wheel

The binary wheel will build against whatever version of Python is installed on your system. The source package is always the same and does not depend on a local version of Python.

Building from setup.py

We support building from setup.py, but only from a Python source package. You cannot build from setup.py using the GitHub repo or the GitHub source tarball.

To build a source package from this repo, see the instructions in the previous section.

Implementation backends

There are three separate implementations of Python Protobuf. All of them offer the same API and are thus functionally the same, though they have very different performance characteristics.

The runtime library contains a switching layer that can choose between these backends at runtime. Normally it will choose between them automatically, using priority-ordered list, and skipping any backends that are not available. However you can request a specific backend by setting the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION environment variable to one of the following values:

  1. upb: Built on the upb C library, this is a new extension module released in 4.21.0. It offers better performance than any of the previous backends, and it is now the default. It is distributed in our PyPI packages, and requires no special installation. The code for this module lives in this directory.
  2. cpp: This extension module wraps the C++ protobuf library. It is deprecated and is no longer released in our PyPI packages, however it is still used in some legacy cases where apps want to perform zero-copy message sharing between Python and C++. It must be installed separately before it can be used. The code for this module lives in google/protobuf/pyext.
  3. python: The pure-Python backend, this does not require any extension module to be present on the system. The code for the pure-Python backend lives in google/protobuf/internal

The order given above is the general priority order, with upb being preferred the most and the python backend preferred the least. However this ordering can be overridden by the presence of a google.protobuf.internal._api_implementation module. See the logic in api_implementation.py for details.

You can check which backend you are using with the following snippet:

$ python
Python 3.10.9 (main, Dec  7 2022, 13:47:07) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from google.protobuf.internal import api_implementation
>>> print(api_implementation.Type())
upb

This is not an officially-supported or stable API, but it is useful for ad hoc diagnostics.

More information about sharing messages between Python and C++ is available here: https://protobuf.dev/reference/python/python-generated/#sharing-messages

Code generator

The code for the Protobuf Python code generator lives in //src/google/protobuf/compiler/python. The code generator can output two different files for each proto foo.proto:

  • foo_pb2.py: The module you import to actually use the protos.
  • foo_pb2.pyi: A stub file that describes the interface of the protos.

The foo_pb2.pyi file is useful for IDEs or for users who want to read the output file. The foo_pb2.py file is optimized for fast loading and is not readable at all.

Note that the pyi file is only generated if you pass the pyi_out option to protoc:

$ protoc --python_out=pyi_out:output_dir