[Python-3000] PEP 3137 plan of attack

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