(Okay, back on track)

On Tue, Dec 2, 2008 at 11:17 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 2, 2008 at 11:08 PM, Alek Storm <[EMAIL PROTECTED]> wrote:
>> I would think encoding and decoding would be the main bottlenecks, so
>> can't those be wrappers around C++, while let object handling (reflection.py
>> and friends) be pure-python?  It seems like the best of both worlds.
> Well, the generated serializing and parsing code in C++ is an order of
> magnitude faster than the dynamic (reflection-based) code.  But to use
> generated code you need to be using C++ object handling.

Not if you decouple them.  Abstractly, the C++ parser receives a serialized
message and descriptor and returns a tree of the form [(tag_num, value)]
where tag_num is an integer and value is either a scalar or a subtree (for
submessages).  The Python reflection code takes the tree and fills the
message object with its values.  It's simple, fast, and the C++ parser can
be easily swapped out for a pure-Python one on systems that don't support
the C++ version.

Run this backwards when serializing, and you get another advantage: you can
easily swap out the function that converts the tree into serialized protobuf
for one that outputs XML, JSON, etc.

> You're right.  If it's a waste of time for them, most people won't use it.
>> But if there's no point to it, why do normal Python lists have it?  It's
>> useful enough to be included there.  And since repeated fields act just like
>> lists, it should be included here too.
> I think Python object lists are probably used in a much wider variety of
> ways than protocol buffer repeated fields generally are.

Let's include it - it gives us a more complete list interface, there's no
downside, and the users can decide whether they want to use it.  We can't
predict all possible use cases.

 In fact, it doesn't even have to be useful for repeated composites.  The
>> fact that repeated scalars have it means it's automatically included for
>> repeated composites, because they should have the exact same interface.
>> Polymorphism is what we want here.
> But they already can't have the same interface because append() doesn't
> work.  :)

We don't have confirmation on that yet ;).  Having the same interface is
what we should be shooting for.

Alek Storm

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to