> I don’t know what black magic Google uses for the Python implementation, but the classes it generates are totally opaque and impossible to inspect.
replyTFA seems to say that they’re just thin proxies over the underlying C++ APIs, which would more than do it, and does not surprise me (the re2 Python bindings are similar, not as bad since they don’t generate Python code but they’re really c++-y — in Google’s flavour too — and uncomfortable).
I did not know this before... Google protobuf is not one thing, it is three! Same import, but:
reply* old C++ extension
* upb
* pure Python
upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?
This one helped me to dig deeper - https://vectree.io/c/how-python-protobuf-runtimes-work-pure-...
> upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?
replyThat is pretty unlikely. TFA's version is in Rust and just barely edges out upb.
When I was a novice in protobuf I felt tempted to inspect the generated code, but soon I learned that the documentation is good enough that I don’t need to read the generated code.
reply