[Python-Dev] String views (was: Re: Proof of the pudding:str.partition())
Fredrik Lundh
fredrik at pythonware.com
Fri Sep 2 08:36:45 CEST 2005
More information about the Python-Dev mailing list
Fri Sep 2 08:36:45 CEST 2005
- Previous message: [Python-Dev] String views (was: Re: Proof of the pudding:str.partition())
- Next message: [Python-Dev] import exceptions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [Python-Dev] String views (was: Re: Proof of the pudding:str.partition())
- Next message: [Python-Dev] import exceptions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list