(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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
