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. 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.)
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.) On Tue, Dec 2, 2008 at 10:34 PM, Alek Storm <[EMAIL PROTECTED]> wrote: > On Tue, Dec 2, 2008 at 10:04 PM, Petar Petrov <[EMAIL PROTECTED]>wrote: > >> How useful is a remove method on a repeated composite field? None has >> asked about such. Do you have any use cases which require it? What are they? >> >> If you want to remove a value from a repeated composite field, you >> basically have to create the same composite value and pass it to .remove(). >> When can this be useful? >> >> I think removal of composite values doesn't make much sense. Maybe even >> slicing ( __getslice__ could be usefull, but __setslice__ very unlikely). >> > > Just as useful as the remove() method for lists of objects in Python. I > think repeated scalar and composite fields should act exactly like lists, > because that's intuitively what they are. There's no technical downside to > including the remove() method, and it brings repeated composites more in > line with repeated scalars. > > Also, you don't have to recreate the composite in order to pass it to > .remove() - you could easily have another reference to the object stored > somewhere. And I don't know why nobody would want to assign to lists of > objects - this kind of thing is very common. > > In fact, this whole patch was pretty easy. There must be some reason it >>> hasn't been done before. >> >> >> The problem is not in adding slicing support. The problem is that if there >> is a Python/C API at some point, it will be very hard to translate the >> slicing support to the C++ API. However repeated scalar slicing is >> translatable (using RepeatedField's Set/RemoveLast/Add methods) but I don't >> think slicing of repeated composite fields is possible with the C++ API. >> >> I think we should only keep the repeated scalar slicing and maybe only >> __getslice__ and __delslice__ for repeated composites. >> > > Why should it matter if there's no slicing in the C++ API? Each > implementation of Protocol Buffers should feel natural for each language; it > shouldn't be held back just because some other language doesn't support the > same features. The builder pattern is completely normal in Java, but the > C++ version uses an entirely different strategy. Slicing is completely > normal in Python. > > The repeated scalar and composite interfaces should be exactly the same. > Everything is Python is polymorphic - it feels wrong if you can't do > something with a list simply based on the types it contains. This is why I > included a comment in the add() method saying it should be deprecated - the > functionaly is superseded by append(), and there's no corresponding method > in the repeated scalar class. > > 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 -~----------~----~----~----~------~----~------~--~---
