(And I accidentally replied only to Alek...)

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.

> Also note that even pure-python protocol buffers have a sort of "ownership"
>> issue:  Sub-messages all contain pointers back to their parents, so that
>> when a sub-message is modified, the parent's cached size can be marked
>> dirty.  (Also, singular sub-messages have to inform their parents when the
>> first field within them is set, but that doesn't apply here.)
> I thought that might be a problem, which is why I was kind of nervous
> before :).  Are you saying append() is a problem, even in pure python?

I assume it would be, yes.  I don't know the exact details of the Python
implementation (Petar does).

> As for remove(), it seems awkward because you have to identify the message
>> to be removed rather than the index to be removed.  If you know what message
>> you want removed, you probably already know what its index is.  Therefore,
>> removing by identity rather than index is a waste of time, because you're
>> forcing a linear scan through the list to find the element to be removed.
>>  (Though removing by index is may also be linear-time depending on how lists
>> are implemented in Python; I don't really know.)
> 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.

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.  :)

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