[Python-Dev] C-API status of Python 3?

[Guido van Rossum]

On Sun, Mar 2, 2008 at 3:26 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-03-02 23:11, Greg Ewing wrote:
>  > M.-A. Lemburg wrote:
>  >> Why not also make unicode() the default type constructor and only
>  >> keep str() as alias to simplify porting (perhaps with a warning) ?
>  >
>  > -1 on making us type 7 characters instead of
>  > 3 all over the place.
>
>  Oh well... how about "text()" ?

Sorry, this was discussed and decided long ago. I'm not going to
change this now. The type is called string or some variation thereof
in most other popular languages.

>  >> The term "string" is just too overloaded with all kinds of
>  >> misinterpretations. The term "string" just refers to a string of
>  >> bytes - a variable length array so to speak.
>  >
>  > I disagree -- "string" has come to mean "string of
>  > characters" unless otherwise qualified. Using one
>  > to hold non-characters is just an aberration that
>  > was necessary in Python 2 because there wasn't much
>  > alternative.

Historically that's incorrect. In 1990, when Unicode hadn't even been
invented, 'str' was very intentionally designed to hold text and data
equally well.

>  Buffer objects have been around for years and for exactly
>  this purpose.

No, buffer objects were not invented to *hold* binary data. The buffer
API was invented to *reference* bytes that were owned by 3rd party C
libraries. Its descendant in Py3k, 'memoryview' (see PEP 3118) has the
same purpose without having the same bugs. For *holding* bytes in Py3k
we'll use bytes (immutable) or bytearray (mutable).

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