If you're in the process of reviewing accelerated Python support for
PB2, were you thinking about something the following approach?
1. Add another output format to protoc (say --pylib_out) which
generates both the existing C++ code plus whatever additional C++
necessary to create a compiled Python module from the specified .proto
The kind of thing mentioned here: http://docs.python.org/extending/extending.html#a-simple-example
2. Ideally, it would even be possible to automatically generate the
Python distutils configuration (http://docs.python.org/extending/
building.html#building) so that
$> python setup.py install
would compile and install the generated C module automatically.
I appreciate this probably means a lot of work, but it will give the
highest possible performance from within Python and may even surpass
Thrift's Python performance.
If you were able to maintain both the --python_out and the --pylib_out
options then users who need pure Python PB support (say for the App
Engine etc) can use one and performance critical applications can use
Would it also be a good time to look at what would need to be changed
to support Python 3.0?
> Yeah, we've dropped the ball on this. Unfortunately the people in charge of
> the Python protocol buffers implementation also have other, apparently very
> demanding projects, and thus Python protobuf hasn't gotten the attention it
> deserves. Sadly even Google doesn't have infinite engineering resources.
> I'm trying to find a solution to this -- it's a management issue, though,
> not a technical one.