On 10/15/07, Joel Bender <[EMAIL PROTECTED]> wrote: > Speaking from the protocol encoding/decoding view, and one where a > buffer is very similar to a list of small integers... > > >> Also what about .replace() and .translate()? > > > >> If they are not done in place should they return a new buffer (PyBytes_) > >> object or a bytes (PyString_) object? [i'd say a buffer (PyBytes_)] > > > > They should return the same type as 'self'. > > My preference would be to do the work in place and return None, just > like sorting a list, reversing a list, appending to a list, etc.
Then propose new APIs that don't have the same names as the existing ones, which are amongst the most well-known APIs in all of Python. > >> Alos if not, should we add additional .ireplace() .ilower() etc.. methods > >> to > >> the mutable buffer (PyBytes_)? There are speed advantages to doing many of > >> those in place rather than a data copy. > > > > I'm not sure I see the use case where this matters all that much > > though. Let's say not, if only because it's not in the PEP. ;-) > > I would appreciate it if these functions were list-like and not > tuple-like. In extending buffers to support more structure encoding and > decoding functions, it would be nice to carry the expectation that these > extensions mutate the buffer and I can leverage the built-in > functionality to do that. The existing mutable PyBytes type (which will be known as 'buffer' in 3.0a2 and beyond) *does* have a number of list-like methods: .append(), .insert(), .extend(). Also += will work in place. And of course slice assignment works. For structure encoding/decoding, please have a look at the existing APIs in the struct module and let us know what's missing. > I am but a small voice in the chorus. There is no rule that PEPs need to be written by senior developers! All you need to be able to do in order to *write* a good PEP is to *listen* well. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
