(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
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at