Zdeněk Pavlas added the comment:
Hit this issue too, but with the read method. I think that providing a
custom read() and write() methods in the wrapper class that override
__getattr__ is a sufficient solution. These are the attributes most likely to
be used as the tail.
--
nosy
New submission from Zdeněk Pavlas:
The behavior contradicts documentation and is inconsistent with both cStringIO
and File objects. Patch attached.
StringIO.StringIO('foo').readline(0)
'foo'
cStringIO.StringIO('foo').readline(0)
''
open('/etc/passwd').readline(0)
''
--
components
Zdeněk Pavlas added the comment:
Yes, found that *certain* IO operations re-raise the error, too. However, if
the Python runtime expects extension writers to keep tstate-curexc_type clear,
it should be documented in
http://docs.python.org/2/c-api/exceptions.html
There's not a single use
New submission from Zdeněk Pavlas:
documentation
There is a global indicator (per thread) of the last error that occurred. Most
functions do not clear this on success, but will set it to indicate the cause
of the error on failure. Most functions also return an error indicator, usually
NULL
Zdeněk Pavlas added the comment:
static PyObject*
foo(PyObject *, PyObject *arg)
{
void *buf;
Py_ssize_t size;
if (PyObject_AsReadBuffer(arg, buf, size))
size = -1;
return PyInt_FromLong(size);
}
import tst, re
re.search(a, a)
_sre.SRE_Match object at 0xb76d0950
New submission from Zdeněk Pavlas:
Please consider setting the default file mode to O_BINARY. O_TEXT
breaks many unix programs and Windows has stopped to use CRLF files for
anything of use since the introduction of Win95's registry anyway.
Days when majority of C codebase actually DID process
Zdeněk Pavlas added the comment:
if they want binary data, they will have to open files in binary mode.
There were binary files. *THEN* dos and mac came with text files. To
keep the *ORIGINAL* semantics we have to add *NEW* flags to open/fopen.
Looks we'll run out of O_ bitfields
