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 <[EMAIL PROTECTED]> wrote: > On 10/10/07, Christian Heimes <[EMAIL PROTECTED]> 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 > [email protected] > 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/) _______________________________________________ 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
