(I accidentally only replied to Kenton, so here's the original message) On Tue, Dec 2, 2008 at 10:49 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> C++ compatibility matters because eventually we want to be able to generate > Python code which just wraps C++ code for efficiency. C++ isn't garbage > collected, so append() can't easily be implemented in this case without > having ownership problems. Slice assignment has the same problem. > 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. 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? 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. 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. Cheers, 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 http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
