[Python-3000] PEP 3137 plan of attack (original) (raw)

Guido van Rossum guido at python.org
Mon Oct 15 18:28:12 CEST 2007


On 10/15/07, Joel Bender <jjb5 at cornell.edu> 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/)



More information about the Python-3000 mailing list