RetroSearch Browse

Fri Sep 2 08:36:45 CEST 2005 · http://mail.python.org/pipermail/python-dev/2005-September/056026.html

skip at pobox.com wrote:

>    Fredrik> Python strings are character buffers with a known length, not
>    Fredrik> null-terminated C strings.  the CPython implementation
>    Fredrik> guarantees that the character buffer has a trailing NULL
>    Fredrik> character, but that's mostly to make it easy to pass Python
>    Fredrik> strings directly to traditional C API:s.
>
> I'm obviously missing something that's been there all along.  Since Python
> strings can contain NULs, why do we bother to NUL-terminate them?  Clearly,
> any tradition C API that expects to operate on NUL-terminated strings would
> break with a string containing an embedded NUL.

sure, but that doesn't mean that such an API would break on a string that
*doesn't* contain an embedded NUL.

in practice, this is the difference between the "s" and "s#" argument specifiers;
the former requires a NUL-free string, the latter can handle any byte string:

    >>> f = open("myfile\0")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: file() argument 1 must be (encoded string without NULL bytes), not str
    >>> f = open("myfile")
    >>> f
    <open file 'myfile', mode 'r' at 0x0091E9A0>

</F> 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-September/056026.html below:

Re: Proof of the pudding:str.partition())