[EMAIL PROTECTED] 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>
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
