[Python-3000] The grand renaming

[Guido van Rossum]

On Jan 1, 2008 11:32 AM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > I don't like renaming PyString to PyBytes right now -- in 2.6 this
> > sounds wrong since it is publicly known as the str[ing] type. Renaming
> > only in 3.0 would make merges from the trunk harder. (Unless you have
> > evidence to the contrary?)
> >
> > I'm okay with renaming PyBytes -> PyByteArray, PyBuffer ->
> > PyMemoryView, and the corresponding file renames (make sure to update
> > all the project files, even for obsolete or minority compilers or
> > platforms).
> >
> > There's also a bunch of potential renames in the area of method and
> > function objects, but I don't have the time to dig up the details.
>
> I was thinking about a backport of the bytes type to Python 2.6. The new
> bytes type is going to cause the largest head ache for developers. The
> name "bytes" and the b"" literal don't conflict with any 2.5 feature.

Are you thinking of adding bytes as an alias of str, or as a whole new
type? I see problems for both, unfortunately. Making it an alias for
str has very different semantics than in 3.0 (where it is incompatible
with the new str, PyUnicode); making it a new type causes problems
because anything that *returns* str in 2.5 will have to return str in
2.6 as well. So only the backported io.py could really use it.

> A rename of the file would make it harder to merge changes from 2.6's
> Objects/stringobject.c to 3.0's Object/byteobject.c but the renaming of
> the function names doesn't make it much harder to merge. It's going to
> cause some conflicts but they are easy to resolve.

That depends. If a call to PyString_WhatEver() is added to 2.6, the
most likely translation in 3.0 is also PyString_WhatEver(). If it has
to be changed into PyBytes_WhatEver() that is just asking for merge
problems.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)