[issue18879] tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable
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: +Zdeněk.Pavlas ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19215] StringIO.StringIO('foo').readline(0) == 'foo'
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: Library (Lib)
files: stringio.patch
keywords: patch
messages: 199376
nosy: Zdeněk.Pavlas
priority: normal
severity: normal
status: open
title: StringIO.StringIO('foo').readline(0) == 'foo'
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32029/stringio.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19215
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17544] regex code re-raises exceptions on success
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 case of PyErr_Clear() mentioned. -- assignee: - docs@python components: +Documentation -Regular Expressions nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17544] regex code re-raises exceptions on success
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 if they are supposed to return a pointer, or -1 if they return an integer. /documentation AIUI, the last error global variable should be ignored, unless function fails. This is not the case. To reproduce: 1. call a C function that sets TypeError, but does not return NULL. 2. run a lot of python code, do some I/O.. everything runs fine. 3. run a regexp match, or import the re module. TypeError is raised. -- components: Regular Expressions messages: 185205 nosy: Zdeněk.Pavlas, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: regex code re-raises exceptions on success versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17544] regex code re-raises exceptions on success
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
tst.foo(abc)
3
re.search(a, a)
_sre.SRE_Match object at 0xb76d0950
tst.foo(None)
-1
re.search(a, a)
TypeError: expected a readable buffer object
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17544
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2028] _fmode = O_TEXT is obsolete
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 text files AND CRLF files were used are long over and since Python is NOT C it should reflect that. -- components: Windows messages: 62144 nosy: zde severity: minor status: open title: _fmode = O_TEXT is obsolete type: behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2028 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2028] _fmode = O_TEXT is obsolete
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 and letters quite soon. 64bit words and unicode alphabet finally start to make sense... :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2028 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
