[Python-3000] PEP 3137 plan of attack

[Guido van Rossum]

It's all fine to debate new names, but for 3.0a2, the existing C-level
names will be used. Period. I am not going to review a change that
touches every other line of code to do such a big rename.

FWIW, I think the new names should be different from any existing
names, otherwise merges from the trunk will be too much of a pain (and
ditto for ports of 3rd party code).

--Guido

On 10/10/07, Brett Cannon <brett at python.org> wrote:
> On 10/10/07, Christian Heimes <lists at cheimes.de> wrote:
> > Georg Brandl wrote:
> > > I agree that this is quite confusing. The PyBytes functions can be changed
> > > without a thought since they aren't 2.x heritage. Since PyBuffer_* is already
> > > taken, what about a PyByteBuffer_ prefix? PyString_ could then be renamed
> > > to PyByteString_. PyUnicode might be allowed to stay...
> >
> > I like your idea!
> >
> > IMHO PyUnicode_ can stay. It reflects the intention and aim of the type
> > and it's easy to remember. str() contains unicode data and it's C name
> > is PyUnicode. That works for me. *g*
> >
> > For the other two names I find PyBytes_ for bytes() and PyBytesBuffer_
> > for buffer() easier to remember and more consistent.
>
> +1 from me.  No need to have PyBytes_ be PyBytesString_ as the string
> tie-in will become historical.  Plus PyBytes_ is shorter without
> losing any detail of what the functions work with.
>
> -Brett
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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