[issue1324] r58034 breaks building _ctypes with the upstream libffi.
New submission from Matthias Klose: This breaks building _ctypes with the upstream libffi. r58034 | thomas.heller | 2007-09-07 08:32:17 +0200 (Fr, 07 Sep 2007) | 1 line Add a 'c_longdouble' type to the ctypes module. gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I/usr/include -I. -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/./Include -I./Include -IInclude -I. -I/usr/local/include -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Include -I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build -c /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c -o build/temp.linux-armv5tel-2.6/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.o /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1756: error: redefinition of 'ffi_type_double' /home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1755: error: previous definition of 'ffi_type_double' was here ffi.h has: #if 0 extern ffi_type ffi_type_longdouble; #else #define ffi_type_longdouble ffi_type_double #endif -- assignee: theller components: Extension Modules messages: 56736 nosy: doko, theller severity: normal status: open title: r58034 breaks building _ctypes with the upstream libffi. versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1324 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1324] r58034 breaks building _ctypes with the upstream libffi.
Changes by Matthias Klose: -- type: - compile error __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1324 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1324] r58034 breaks building _ctypes with the upstream libffi.
Matthias Klose added the comment:
Index: Modules/_ctypes/cfield.c
===
--- Modules/_ctypes/cfield.c(revision 58651)
+++ Modules/_ctypes/cfield.c(working copy)
@@ -1753,6 +1753,9 @@
ffi_type ffi_type_float = { sizeof(float), FLOAT_ALIGN, FFI_TYPE_FLOAT };
ffi_type ffi_type_double = { sizeof(double), DOUBLE_ALIGN,
FFI_TYPE_DOUBLE };
+#ifdef ffi_type_longdouble
+#undef ffi_type_longdouble
+#endif
ffi_type ffi_type_longdouble = { sizeof(long double), LONGDOUBLE_ALIGN,
FFI_TYPE_LONGDOUBLE };
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1324
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1324] r58034 breaks building _ctypes with the upstream libffi.
Changes by Matthias Klose: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1324 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam() [patch]
Christian Heimes added the comment: os.tmpfile() is the only method that has no duplicate in tempfile. I chose to keep it for this very reason. But you made good point, too. What do you think about renaming tmpfile to _tmpfile and make it available from the tempfile module as tempfile.tmpfile()? I totally agree with your opinion on tmpnam and tempnam. As far as I know it's impossible to prevent a child process from doing something harmful. The child must be mature enough to do the right think and open a file with the correct flags. The promise of tempfile.mkstemp is also bogus for every OS except Windows. IIRC only Windows supports O_NOINHERIT. Let me rephrase the rational for my patch: I want to remove duplicate code to have just but one implementation to create a temporary file (name). I want the one implementation be under our control and not depend on some possible broken or stupid C library like Windows where tmpnam may create the temporary files in C:\. I want an unified way to get the TEMP dir independent of the API. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Christian Heimes added the comment:
Why should I use (sizeof(lower)-1)? Do you mean
PyMem_Malloc(strlen(encoding) + 1)?
Changes since last patch:
* added #include bytes_methods.h in unicodeobject.c
* fix all is* to use the macros from bytes_methods.h
* use malloc/free the lower version instead of using a fixed buffer
* replace '_' with '-' in encoding
I still think that a fixed buffer of 12 chars (strlen(iso-8859-1) + 1 +
\0) is sufficient and faster.
* also check for iso-8859-1
Added file: http://bugs.python.org/file8607/py3k_profile_fix3.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1302
__Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 58654)
+++ Objects/unicodeobject.c (working copy)
@@ -41,6 +41,7 @@
#define PY_SSIZE_T_CLEAN
#include Python.h
+#include bytes_methods.h
#include unicodeobject.h
#include ucnhash.h
@@ -592,9 +593,9 @@
if (*f == '%') {
const char* p = f;
width = 0;
- while (isdigit(Py_CHARMASK(*f)))
+ while (ISDIGIT(*f))
width = (width*10) + *f++ - '0';
- while (*++f *f != '%' !isalpha(Py_CHARMASK(*f)))
+ while (*++f *f != '%' !ISALPHA(*f))
;
/* skip the 'l' or 'z' in {%ld, %zd, %lu, %zu} since
@@ -755,12 +756,12 @@
zeropad = (*f == '0');
/* parse the width.precision part */
width = 0;
- while (isdigit(Py_CHARMASK(*f)))
+ while (ISDIGIT(*f))
width = (width*10) + *f++ - '0';
precision = 0;
if (*f == '.') {
f++;
-while (isdigit(Py_CHARMASK(*f)))
+while (ISDIGIT(*f))
precision = (precision*10) + *f++ - '0';
}
/* handle the long flag, but only for %ld and %lu.
@@ -1056,22 +1057,51 @@
{
PyObject *buffer = NULL, *unicode;
Py_buffer info;
+char *lower;
+char *l, *e;
if (encoding == NULL)
- encoding = PyUnicode_GetDefaultEncoding();
+encoding = PyUnicode_GetDefaultEncoding();
+lower = PyMem_Malloc(strlen(encoding) + 1);
+
+/* Convert encoding to lower case and replace '_' with '-' in order to
+ catch e.g. UTF_8 */
+e = (char*)encoding;
+l = lower;
+while (*e) {
+if (ISUPPER(*e)) {
+*l++ = TOLOWER(*e++);
+}
+else if (*e == '_') {
+*l++ = '-';
+e++;
+}
+else {
+*l++ = *e++;
+}
+}
+*l = '\0';
+
/* Shortcuts for common default encodings */
-if (strcmp(encoding, utf-8) == 0)
+if (strcmp(lower, utf-8) == 0)
return PyUnicode_DecodeUTF8(s, size, errors);
-else if (strcmp(encoding, latin-1) == 0)
+else if ((strcmp(lower, latin-1) == 0) ||
+ (strcmp(lower, iso-8859-1) == 0))
return PyUnicode_DecodeLatin1(s, size, errors);
#if defined(MS_WINDOWS) defined(HAVE_USABLE_WCHAR_T)
-else if (strcmp(encoding, mbcs) == 0)
+else if (strcmp(lower, mbcs) == 0)
return PyUnicode_DecodeMBCS(s, size, errors);
#endif
-else if (strcmp(encoding, ascii) == 0)
+else if (strcmp(lower, ascii) == 0)
return PyUnicode_DecodeASCII(s, size, errors);
+else if (strcmp(lower, utf-16) == 0)
+return PyUnicode_DecodeUTF16(s, size, errors, 0);
+else if (strcmp(lower, utf-32) == 0)
+return PyUnicode_DecodeUTF32(s, size, errors, 0);
+PyMem_Free(lower);
+
/* Decode via the codec registry */
buffer = NULL;
if (PyBuffer_FillInfo(info, (void *)s, size, 1, PyBUF_SIMPLE) 0)
@@ -1470,7 +1500,7 @@
#define B64(n) \
(ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/[(n) 0x3f])
#define B64CHAR(c) \
-(isalnum(c) || (c) == '+' || (c) == '/')
+(ISALNUM(c) || (c) == '+' || (c) == '/')
#define UB64(c) \
((c) == '+' ? 62 : (c) == '/' ? 63 : (c) = 'a' ? \
(c) - 71 : (c) = 'A' ? (c) - 65 : (c) + 4 )
@@ -2703,7 +2733,7 @@
}
for (i = 0; i digits; ++i) {
c = (unsigned char) s[i];
-if (!isxdigit(c)) {
+if (!ISXDIGIT(c)) {
endinpos = (s+i+1)-starts;
if (unicode_decode_call_errorhandler(
errors, errorHandler,
@@ -3077,7 +3107,7 @@
outpos = p-PyUnicode_AS_UNICODE(v);
for (x = 0, i = 0; i count; ++i, ++s) {
c = (unsigned char)*s;
- if (!isxdigit(c)) {
+ if (!ISXDIGIT(c)) {
endinpos = s-starts;
if (unicode_decode_call_errorhandler(
errors, errorHandler,
Index: Lib/test/regrtest.py
===
--- Lib/test/regrtest.py (revision 58654)
+++ Lib/test/regrtest.py (working copy)
@@ -1119,6 +1119,15 @@
if not os.path.supports_unicode_filenames:
self.expected.add('test_pep277')
+# doctest, profile and cProfile tests fail when the codec for the fs
+# encoding isn't
[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol
Yitz Gale added the comment: I was actually bitten badly by this issue with StringIO. I added fileinput only as an afterthought. In an xml.sax app, I needed seek() support for a codec-wrapped file handle, so I over-wrapped it with StringIO. The result was that I had to refactor code all over the place to handle StringIO as a special case. What a mess! Why is this getting over-excited? It's a very lightweight change. You can't beat the cost/benefit ratio. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1286 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1325] zipimport.zipimporter.archive undocumented and untested
New submission from Jean-Paul Calderone: zipimporter instances have a read-only archive attribute, but there is no documentation referring to it, nor any test coverage for its existence. It's quite useful to know what a zipimporter is pointed at (for debugging and other introspection). It'd be nice to know that this is a real feature and isn't going to disappear. -- components: Documentation, Library (Lib) messages: 56741 nosy: exarkun severity: normal status: open title: zipimport.zipimporter.archive undocumented and untested type: rfe __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1325 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326] internal zipimport.zipimporter feature untested
New submission from Jean-Paul Calderone: It's possible to construct a zipimporter with a path which points first to a zip file and then continues to refer to a file within that zip file. For example, /foo/bar.zip/baz where /foo/bar.zip is not a directory, but a zip file, and baz is a file or directory in the contents of the zip file. There is no test coverage for this functionality, though. -- components: Library (Lib) messages: 56742 nosy: exarkun severity: normal status: open title: internal zipimport.zipimporter feature untested type: rfe __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1326 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1301] Bad assertion in _tkinter.c
Facundo Batista added the comment: Really do not understand that assert. It says: assert(size size * sizeof(Tcl_UniChar)); For that to be true, considering size to be positive, the result of sizeof needs to be greater than 0. If you modify it, and also accepts it to be 0, and considering that the result of sizeof won't be negative, what is the point of keeping the assert? -- nosy: +facundobatista __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1301 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1325] zipimport.zipimporter.archive undocumented and untested
Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1325 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326] internal zipimport.zipimporter feature untested
Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1326 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue805194] Inappropriate error received using socket timeout
Jean-Paul Calderone added the comment: The APR comment is indeed correct, so this is probably a Python bug. -- nosy: +exarkun Tracker [EMAIL PROTECTED] http://bugs.python.org/issue805194 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Raghuram Devarakonda added the comment: I think it is safe to ignore lsb-release. In fact, there seems to be a command lsb_release that gives information about distribution. On my SuSE box, this is what I get: marvin:~# lsb_release -i Distributor ID: SUSE LINUX marvin:~# lsb_release -d Description:SUSE LINUX 10.1 (i586) marvin:~# lsb_release -r Release:10.1 sapetnioc, can you check if this command exists on your system and if so, it's output? platform.dist() can check for this command's existence and if present, can perhaps use it to glean distro information. Please let me know if you want to write the patch. I will do it otherwise. -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Yann Cointepas added the comment: I can easily do the patch to ignore symlinks and /etc/lsb-release but I am not sure of the appropriate way to look for lsb_update command, is distutils.spawn.find_executable( 'lsb_release' ) ok ? If you need the patch earlier than begining of next week, you should do it. Otherwise I can make it. On Mandriva 2007.1, the command exists if the package lsb-release is installed. I do not know if it is always installed (I selected a checkbox LSB during install, this checkbox is unchecked by default). The output is: [EMAIL PROTECTED] ~]$ lsb_release -a LSB Version: lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: MandrivaLinux Description:Mandriva Linux Release:2007.1 Codename: Official [EMAIL PROTECTED] ~]$ lsb_release -i Distributor ID: MandrivaLinux [EMAIL PROTECTED] ~]$ lsb_release -d Description:Mandriva Linux [EMAIL PROTECTED] ~]$ lsb_release -r Release:2007.1 On Fedora 4 (rather old) , the command is in the package redhat-lsb. yc176684:src$ lsb_release -a LSB Version:1.3 Distributor ID: FedoraCore Description:Fedora Core release 4 (Stentz) Release:4 Codename: Stentz yc176684:src$ lsb_release -i Distributor ID: FedoraCore yc176684:src$ lsb_release -d Description:Fedora Core release 4 (Stentz) yc176684:src$ lsb_release -r Release:4 On Fedora 7, the command is in the package redhat-lsb and seem to be installed by default. gargamel:riviere% lsb_release -a LSB Version::core-3.1-ia32:core-3.1-noarch: graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: Fedora Description:Fedora release 7 (Moonshine) Release:7 Codename: Moonshine gargamel:riviere% lsb_release -i Distributor ID: Fedora gargamel:riviere% lsb_release -d Description:Fedora release 7 (Moonshine) gargamel:riviere% lsb_release -r Release:7 On 10/25/07, Raghuram Devarakonda [EMAIL PROTECTED] wrote: Raghuram Devarakonda added the comment: I think it is safe to ignore lsb-release. In fact, there seems to be a command lsb_release that gives information about distribution. On my SuSE box, this is what I get: marvin:~# lsb_release -i Distributor ID: SUSE LINUX marvin:~# lsb_release -d Description:SUSE LINUX 10.1 (i586) marvin:~# lsb_release -r Release:10.1 sapetnioc, can you check if this command exists on your system and if so, it's output? platform.dist() can check for this command's existence and if present, can perhaps use it to glean distro information. Please let me know if you want to write the patch. I will do it otherwise. -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ Added file: http://bugs.python.org/file8609/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __I can easily do the patch to ignore symlinks and /etc/lsb-release but I am not sure of the appropriate way to look for lsb_update command, is distutils.spawn.find_executable( #39;lsb_release#39; ) ok ?brIf you need the patch earlier than begining of next week, you should do it. Otherwise I can make it. brbrOn Mandriva 2007.1, the command exists if the package quot;lsb-releasequot; is installed. I do not know if it is always installed (I selected a checkbox quot;LSBquot; during install, this checkbox is unchecked by default). brThe output is:brbr[EMAIL PROTECTED] ~]$ lsb_release -abrLSB Version:nbsp;nbsp;nbsp; lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch brDistributor ID: MandrivaLinuxbrDescription:nbsp;nbsp;nbsp; Mandriva LinuxbrRelease:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 2007.1brCodename:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; Officialbrbr[EMAIL PROTECTED] ~]$ lsb_release -ibrDistributor ID: MandrivaLinuxbrbr[EMAIL PROTECTED] ~]$ lsb_release -d brDescription:nbsp;nbsp;nbsp; Mandriva Linuxbrbr[EMAIL PROTECTED] ~]$ lsb_release -rbrRelease:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 2007.1brbrbrOn Fedora 4 (rather old) , the command is in the package quot;redhat-lsbquot;.brbryc176684:src$ lsb_release -a br LSB Version:nbsp;nbsp;nbsp; 1.3br Distributor ID: FedoraCorebr Description:nbsp;nbsp;nbsp; Fedora Core release 4 (Stentz)br Release:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 4br Codename:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; Stentzbrbryc176684:src$ lsb_release -ibr Distributor ID: FedoraCorebrbryc176684:src$ lsb_release -dbr Description:nbsp;nbsp;nbsp; Fedora Core release 4 (Stentz)brbryc176684:src$ lsb_release -rbr Release:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 4br brbrOn Fedora 7,
[issue1322] platform.dist() has unpredictable result under Linux
Raghuram Devarakonda added the comment: On 10/25/07, Yann Cointepas [EMAIL PROTECTED] wrote: I can easily do the patch to ignore symlinks and /etc/lsb-release but I am not sure of the appropriate way to look for lsb_update command, is distutils.spawn.find_executable( 'lsb_release' ) ok ? You can just execute the command and if there is any error, default to the current code. There is no need to explicitly check for the binary's existence. If you need the patch earlier than begining of next week, you should do it. Otherwise I can make it. I don't need the patch :-). If you can't get to it some time next week, I will try to come up with the patch. On Mandriva 2007.1, the command exists if the package lsb-release is installed. I do not know if it is always installed (I selected a checkbox LSB during install, this checkbox is unchecked by default). The output is: [EMAIL PROTECTED] ~]$ lsb_release -a LSB Version: lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch Distributor ID: MandrivaLinux Description:Mandriva Linux Release:2007.1 Codename: Official [EMAIL PROTECTED] ~]$ lsb_release -i Distributor ID: MandrivaLinux [EMAIL PROTECTED] ~]$ lsb_release -d Description:Mandriva Linux [EMAIL PROTECTED] ~]$ lsb_release -r Release:2007.1 On Fedora 4 (rather old) , the command is in the package redhat-lsb. yc176684:src$ lsb_release -a LSB Version:1.3 Distributor ID: FedoraCore Description:Fedora Core release 4 (Stentz) Release:4 Codename: Stentz yc176684:src$ lsb_release -i Distributor ID: FedoraCore yc176684:src$ lsb_release -d Description:Fedora Core release 4 (Stentz) yc176684:src$ lsb_release -r Release:4 On Fedora 7, the command is in the package redhat-lsb and seem to be installed by default. gargamel:riviere% lsb_release -a LSB Version::core-3.1-ia32:core-3.1-noarch: graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: Fedora Description:Fedora release 7 (Moonshine) Release:7 Codename: Moonshine gargamel:riviere% lsb_release -i Distributor ID: Fedora gargamel:riviere% lsb_release -d Description:Fedora release 7 (Moonshine) gargamel:riviere% lsb_release -r Release:7 On 10/25/07, Raghuram Devarakonda [EMAIL PROTECTED] wrote: Raghuram Devarakonda added the comment: I think it is safe to ignore lsb-release. In fact, there seems to be a command lsb_release that gives information about distribution. On my SuSE box, this is what I get: marvin:~# lsb_release -i Distributor ID: SUSE LINUX marvin:~# lsb_release -d Description:SUSE LINUX 10.1 (i586) marvin:~# lsb_release -r Release:10.1 sapetnioc, can you check if this command exists on your system and if so, it's output? platform.dist() can check for this command's existence and if present, can perhaps use it to glean distro information. Please let me know if you want to write the patch. I will do it otherwise. -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ Added file: http://bugs.python.org/file8609/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Martin v. Löwis added the comment: os.tmpfile() is the only method that has no duplicate in tempfile. Why do you say that? tempfile.mkstemp() does essentially the same as os.tmpfile(). The promise of tempfile.mkstemp is also bogus for every OS except Windows. IIRC only Windows supports O_NOINHERIT. Please read the code. It tries to set the CLOEXEC flag on Unix, which should work on most systems. Let me rephrase the rational for my patch: I want to remove duplicate code to have just but one implementation to create a temporary file (name). I want the one implementation be under our control and not depend on some possible broken or stupid C library like Windows where tmpnam may create the temporary files in C:\. I want an unified way to get the TEMP dir independent of the API. As I said, I agree with most of this rationale, except that I'm uncertain whether it is good to trade a stupid C library for a stupid Python implementation. With this rationale, again, I think tmpfile should be removed as well. Regards, Martin -- title: Remove os.tmpnam() and os.tempnam() [patch] - Remove os.tmpnam() and os.tempnam() __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1252] IDLE - patch Delegator to support callables
Tal Einat added the comment: I understand your argument, but am not convinced. I'll try to explain how I see this and how I came to this view. I wished to wrap a specific method (or function) instead of wrapping the father object with a Delegator and implementing a single method. But I needed more than simple function wrapping - I wanted a chain of functions where each wraps the next, and the ability to change the order of links in this chain. So what I really wanted was a Percolator, but instead of having it wrap an object and delegate methods, I wanted it to delegate direct calls. My first idea was to implement a FunctionDelegator class. But I realized I would have to implement a FunctionPercolator class, which would be indentical to the existing Percolator class except that it would inherit from FunctionDelegator instead of Delegator. From there I had three choices: 1) create a second pair of delegator/percolator classes which are nearly identical (much code ducplication) 2) make a Percolator generator function, which accepts a Delegator class, and returns a Percolator class/object which uses it (possibly inheriting from it) 3) make Delegator able to delegate direct calls The third option is obviously the simplest to implement, requiring the least code without any code duplication. After some thought, I came to the point-of-view described below, and realized that the third option is actually what I would expect if I were thinking about delegators and percolators as transparent proxies. Delegates are not intended to be callable. Why not? IMO, the nice thing about the Delegator class is that you can use an instance just as if it were the underlying object, transparently. The major exception from this behavior was that calling a Delegator never works, even if the underlying object is callable. From this point of view, my patch makes the Delegator concept complete, while before it was broken. I think this patch increases the complexity and obscurity of the Delegator/Percolator/WidgetRedirector code, rather than improving it. Apparently you want to sometimes call a chain of methods (as in current usage) and sometimes call a chain of functions. The semantic overload, which was bad enough already, is too great. You describe method calls and direct calls as though they were fundamentally different. Therefore you find that delegating both is too much semantic overloading. However, if one views direct calling of an object as a special case of calling a method (since functions are also objects) -- the __call__ method -- then delegating both method calls and direct calls is The Right Thing. Also, this __call__ method, if actually used, propagates to the end of the Delegator chain and calls the function at the end, (assuming it is a function). Or it will skip non-callable Delegators and stop at the first callable one. True, since this is precisely what Delegators do for any method call -- this is the expected behavior. If Squeezer and ShellLogger require this change, then I'd suggest changing them to match current Percolator usage, instead. Currently I don't see a Delegator being used in Squeezer. Could you be more specific about why the change is needed for those two extensions? Squeezer currently replaces PyShell's write method with a method of its own. ShellLogger also needs to hook onto the write method, but ShellLogger's function must be called before Squeezer's method, since Squeezer can insert a button without calling the underlying write method. But extensions must replace the write method in their constructor, and the order of their construction is random. In other words, a rudimentary form of constraint enforcement is required, which can be achieved using a Percolator. Without the suggested change to Delegator, this can be accomplished by wrapping EditorWindow with a Percolator, and having extensions insert Delegators (filters) as appropriate. However, this is a much larger change to the code -- for example, this breaks type checks, e.g. assert isinstance(editwin, EditorWindow)). This would also add overhead to every method call done on EditorWindow, with this overhead growing linearly with the number of Delegators inserted. I find wrapping specific methods to be more straightforward and therefore simpler, but this can be argued. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1252 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1324] r58034 breaks building _ctypes with the upstream libffi.
Thomas Heller added the comment: Maybe I should give up the idea to define the ffi_type_... types myself. Committed as rev 58655. Thanks. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1324 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1292] libffi needs an update to support mips64, arm and armeabi on linux
Thomas Heller added the comment: I'm unsure how to proceed with this. Replacing the copy of libffi in the ctypes sources - I'm very afraid to do that. It has it's own configure system, written by someone else. Then it has several changes from various people for Python, which would be overwritten. All these on systems that I do not have direct access to, and we do not have buildbots for all of them. So, it looks like --with-system-ffi should be made the default (on systems that have libffi installed?) There are also test failures since I committed the c_longdouble patch (on alpha debian, and S390 Debian, for example). Maybe newer libffi versions have a fix for that... Last comment: Experimental changes COULD be tested out in a branch, we would only have to manually trigger the build from the buildbot web pages. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1292 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1159051] Handle corrupted gzip files with unexpected EOF
Wummel added the comment:
Here is a new test script that works with simple strings and no file
objects. It reproduces the error by cutting off the last two bytes of
the GZIP data.
The resulting struct error is due to the read() methods missing a check
that the requested amount of data is actually returned. In this case
read(4) returned 2 bytes instead of 4, and the struct raises an error.
I think the easiest way to handle this is to introduce a
read_save(fileobj, size) method that checks that the read() data is of
the requested size, else raise an error (perhaps an IOError?).
btw: you can remove the t.{gz,py} files, the test_gzip_error.py replaces
them.
Added file: http://bugs.python.org/file8610/test_gzip_error.py
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1159051
_# test corrupted GZIP data
import gzip
import StringIO
uncompressed = This is a test
fileobj = StringIO.StringIO()
gzipobj = gzip.GzipFile(test.gz, 'wb', 9, fileobj)
gzipobj.write(uncompressed)
gzipobj.close()
# corrupt the .gz data: remove the last 2 bytes
compressed = fileobj.getvalue()[:-2]
# now uncompress again
fileobj = StringIO.StringIO(compressed)
print gzip.GzipFile('', 'rb', 9, fileobj).read()
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol
Guido van Rossum added the comment: 2007/10/25, Yitz Gale [EMAIL PROTECTED]: I was actually bitten badly by this issue with StringIO. I added fileinput only as an afterthought. In an xml.sax app, I needed seek() support for a codec-wrapped file handle, so I over-wrapped it with StringIO. The result was that I had to refactor code all over the place to handle StringIO as a special case. What a mess! I don't understand. What did your code look like after the refactoring? I find that typically a useful idiom is to have one piece of code handle opening/closing of streams and let the rest of the code just deal with streams without ever closing them. E.g. f = open(filename) try: process(f) finally: f.close() or, if you want: with open(filename) as f: process(f) As I don't understand how you are working the StringIO() call into this I'm still not sure what the issue is. Why is this getting over-excited? It's a very lightweight change. You can't beat the cost/benefit ratio. Until you submit a patch it's more work for me. :-) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1286 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Christian Heimes added the comment: Guido van Rossum wrote: Christian can you revise your patch to also remove os.tmpfile per Martin's request? Make sure unit tests and docs are fixed too. I can do that for you. But I still believe that os.tmpfile() works different than tempfile.mkstemp(). The former returns a file descriptor of a file w/o directory entry and the later a file in tempfile.tempdir. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Guido van Rossum added the comment: Christian can you revise your patch to also remove os.tmpfile per Martin's request? Make sure unit tests and docs are fixed too. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
New submission from James G. sack (jim): The behavior of codecs utf_16_[bl]e is to omit the BOM. In a testing environment (and perhaps elsewhere), a forced BOM is useful. I'm requesting an optional argument something like force_BOM=False I guess it would require such an option in multiple function calls, sorry I don't know enough to itemize them. If this is implemented, it might be desirable to think about the aliases like unicode*unmarked. Regards, ..jim -- components: Unicode messages: 56759 nosy: jgsack severity: minor status: open title: feature request: force BOM option type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Guido van Rossum added the comment: 2007/10/25, Christian Heimes [EMAIL PROTECTED]: I can do that for you. But I still believe that os.tmpfile() works different than tempfile.mkstemp(). The former returns a file descriptor of a file w/o directory entry and the later a file in tempfile.tempdir. True. But tempfile.TemporaryFile() returns a temp file without a name. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Changes by Christian Heimes: Added file: http://bugs.python.org/file8612/py3k_remove_os_tmp.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1329] Different 3.0a1 exit behavior
New submission from Jean Brouwers: Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python 2.4 and 2.5. With previous Python binaries the destructor** function of any pre- loaded shared library is called prior to exit. With Python 3.0a1 it is not, neither when exiting Python from the command line with Ctrl-D nor when using exit(). A workaround is to install a SIGABRT signal handler from the library and exit Python with os.abort(). Python 3.0a1 was built from source using the standard build sequence without any ./configure options except --prefix. --- **) defined with GNU __attribute__((destructor)). The shared library is loaded through environment variable LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on MacOS X. -- components: Interpreter Core messages: 56761 nosy: MrJean1 severity: normal status: open title: Different 3.0a1 exit behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1329 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1318] Remove os.tmpnam() and os.tempnam()
Guido van Rossum added the comment: Committed revision 58657. Thanks! -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1318 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1323] py3k: file.truncate() changes the file position
Guido van Rossum added the comment: Looks fine to me. Committed revision 58658. -- nosy: +gvanrossum resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1323 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Guido van Rossum added the comment: Committed revision 58659. I'm sorry I confused you; I was fine with the version that has char lower[N] but I wanted you to not repeat N-1 later in the code. See what I checked in. :-) -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Christian Heimes added the comment: Guido van Rossum wrote: Guido van Rossum added the comment: Committed revision 58659. I'm sorry I confused you; I was fine with the version that has char lower[N] but I wanted you to not repeat N-1 later in the code. See what I checked in. :-) I still don't understand why you are using (sizeof lower) - 2 and what lower[(sizeof lower) - 2] returns. Is it the memory address of lower[17]? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Alexandre Vassalotti added the comment: I still don't understand why you are using (sizeof lower) - 2 It is simply to avoid duplicating the constant (a.k.a. the Don't Repeat Yourself (DRY) rule). and what lower[(sizeof lower) - 2] returns. Is it the memory address of lower[17]? It the address of lower[18] to be exact. (l lower[(sizeof lower) - 2]) is simply tricky notation to check the bound of the array. Personally, I used like to subtract pointer, ((lower - l + 1) (sizeof lower)) to get the bound. But now, I find Guido's trick more cute (and less error-prone). :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Alexandre Vassalotti added the comment: Personally, I used like to subtract pointer, ((lower - l + 1) (sizeof lower)) to get the bound. Doh. I got it backward. It's (l - lower + 1), not (lower - l + 1). But now, I find Guido's trick more cute (and less error-prone). At least, I got that right. :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1302] Fixes for profile/cprofile
Christian Heimes added the comment: Alexandre Vassalotti wrote: It the address of lower[18] to be exact. (l lower[(sizeof lower) - 2]) is simply tricky notation to check the bound of the array. Personally, I used like to subtract pointer, ((lower - l + 1) (sizeof lower)) to get the bound. But now, I find Guido's trick more cute (and less error-prone). :) Wow, that's a cool trick. The old wizard has still some astonishing tricks in the sleeves of his robe. :] __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1302 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330] Fix truncate on Windows, this time for real
New submission from Christian Heimes:
The patch fixes for real what Patch # 1323 by Amaury Forgeot d'Arc
claims to have fixed. I reverted his patch to io.py and implemented the
fix in the Windows specific part of truncate in _fileio.c. It fixes two
tests for raw io on Windows.
--
components: Library (Lib)
files: py3k_win_io.patch
messages: 56769
nosy: tiran
severity: normal
status: open
title: Fix truncate on Windows, this time for real
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8613/py3k_win_io.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1330
__Index: Lib/io.py
===
--- Lib/io.py (revision 58660)
+++ Lib/io.py (working copy)
@@ -597,25 +597,10 @@
return self.raw.tell()
def truncate(self, pos=None):
-# On Windows, the truncate operation changes the current position
-# to the end of the file, which may leave us with desynchronized
-# buffers.
-# Since we promise that truncate() won't change the current position,
-# the easiest thing is to capture current pos now and seek back to
-# it at the end.
-
-initialpos = self.tell()
if pos is None:
-pos = initialpos
+pos = self.tell()
+return self.raw.truncate(pos)
-# Flush the stream. We're mixing buffered I/O with lower-level I/O,
-# and a flush may be necessary to synch both views of the current
-# file state.
-self.flush()
-newpos = self.raw.truncate(pos)
-self.seek(initialpos)
-return newpos
-
### Flush and close ###
def flush(self):
Index: Modules/_fileio.c
===
--- Modules/_fileio.c (revision 58660)
+++ Modules/_fileio.c (working copy)
@@ -628,14 +628,22 @@
so don't even try using it. */
{
HANDLE hFile;
- PyObject *pos2;
+ PyObject *pos2, *oldposobj;
+ /* store the current position */
+ oldposobj = portable_lseek(self-fd, NULL, 1);
+ if (oldposobj == NULL) {
+ Py_DECREF(posobj);
+ return NULL;
+ }
+
/* Have to move current pos to desired endpoint on Windows. */
errno = 0;
pos2 = portable_lseek(fd, posobj, SEEK_SET);
if (pos2 == NULL)
{
Py_DECREF(posobj);
+ Py_DECREF(oldposobj);
return NULL;
}
Py_DECREF(pos2);
@@ -651,6 +659,16 @@
errno = EACCES;
}
Py_END_ALLOW_THREADS
+
+ /* Move to the previous position in the file */
+ pos2 = portable_lseek(fd, oldposobj, SEEK_SET);
+ if (pos2 == NULL) {
+ Py_DECREF(posobj);
+ Py_DECREF(oldposobj);
+ return NULL;
+ }
+ Py_DECREF(pos2);
+ Py_DECREF(oldposobj);
}
#else
Py_BEGIN_ALLOW_THREADS
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330] Fix truncate on Windows, this time for real
Changes by Christian Heimes: -- nosy: +gvanrossum, nnorwitz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1330 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1331] More fixes for Windows
New submission from Christian Heimes:
The patch fixes some of the problems on Windows. It doesn't introduce
addition problems on Linux.
--
components: Library (Lib)
files: py3k_misc_win.patch
messages: 56770
nosy: gvanrossum, nnorwitz, tiran
severity: normal
status: open
title: More fixes for Windows
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8614/py3k_misc_win.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1331
__Index: Lib/netrc.py
===
--- Lib/netrc.py (revision 58660)
+++ Lib/netrc.py (working copy)
@@ -26,9 +26,12 @@
file = os.path.join(os.environ['HOME'], .netrc)
except KeyError:
raise IOError(Could not find .netrc: $HOME is not set)
-fp = open(file)
self.hosts = {}
self.macros = {}
+with open(file) as fp:
+self._parse(file, fp)
+
+def _parse(self, file, fp):
lexer = shlex.shlex(fp)
lexer.wordchars += r!#$%'()*+,-./:;=[EMAIL PROTECTED]|}~
while 1:
Index: Lib/subprocess.py
===
--- Lib/subprocess.py (revision 58660)
+++ Lib/subprocess.py (working copy)
@@ -809,6 +809,8 @@
if self.stdin:
if input is not None:
+if isinstance(input, str):
+input = input.encode()
self.stdin.write(input)
self.stdin.close()
Index: Lib/test/regrtest.py
===
--- Lib/test/regrtest.py (revision 58660)
+++ Lib/test/regrtest.py (working copy)
@@ -885,6 +885,7 @@
test_pwd
test_resource
test_signal
+test_syslog
test_threadsignals
test_wait3
test_wait4
Index: Lib/test/test_mailbox.py
===
--- Lib/test/test_mailbox.py (revision 58660)
+++ Lib/test/test_mailbox.py (working copy)
@@ -58,6 +58,7 @@
self._box = self._factory(self._path)
def tearDown(self):
+self._box.close()
self._delete_recursively(self._path)
def test_add(self):
@@ -390,12 +391,14 @@
self._box.add(contents[0])
self._box.add(contents[1])
self._box.add(contents[2])
+oldbox = self._box
method()
self._box = self._factory(self._path)
keys = self._box.keys()
self.assertEqual(len(keys), 3)
for key in keys:
self.assert_(self._box.get_string(key) in contents)
+oldbox.close()
def test_dump_message(self):
# Write message representations to disk
@@ -403,7 +406,7 @@
_sample_message, io.StringIO(_sample_message)):
output = io.StringIO()
self._box._dump_message(input, output)
-self.assert_(output.getvalue() ==
+self.assertEqual(output.getvalue(),
_sample_message.replace('\n', os.linesep))
output = io.StringIO()
self.assertRaises(TypeError,
@@ -694,6 +697,7 @@
class _TestMboxMMDF(TestMailbox):
def tearDown(self):
+self._box.close()
self._delete_recursively(self._path)
for lock_remnant in glob.glob(self._path + '.*'):
test_support.unlink(lock_remnant)
@@ -916,6 +920,7 @@
_factory = lambda self, path, factory=None: mailbox.Babyl(path, factory)
def tearDown(self):
+self._box.close()
self._delete_recursively(self._path)
for lock_remnant in glob.glob(self._path + '.*'):
test_support.unlink(lock_remnant)
Index: Lib/test/test_netrc.py
===
--- Lib/test/test_netrc.py (revision 58660)
+++ Lib/test/test_netrc.py (working copy)
@@ -21,25 +21,24 @@
class NetrcTestCase(unittest.TestCase):
-def setUp (self):
+def setUp(self):
mode = 'w'
if sys.platform not in ['cygwin']:
mode += 't'
fp = open(temp_filename, mode)
fp.write(TEST_NETRC)
fp.close()
-self.netrc = netrc.netrc(temp_filename)
-def tearDown (self):
-del self.netrc
+def tearDown(self):
os.unlink(temp_filename)
def test_case_1(self):
-self.assert_(self.netrc.macros == {'macro1':['line1\n', 'line2\n'],
+nrc = netrc.netrc(temp_filename)
+self.assert_(nrc.macros == {'macro1':['line1\n', 'line2\n'],
'macro2':['line3\n', 'line4\n']}
)
-self.assert_(self.netrc.hosts['foo'] == ('log1', 'acct1', 'pass1'))
-self.assert_(self.netrc.hosts['default'] == ('log2', None, 'pass2'))
+self.assert_(nrc.hosts['foo'] ==
[issue1255] Strange Python hangup
Facundo Batista added the comment: The deadlock happens because strptime has an import inside it, and recursive imports are not allowed in different threads. As a general rule and good coding style, don't run your code when the module is imported, but put it in a function like main in the second file,import it and call it from the first one. This will solve your problem. Note that this happens to you with strptime, but could happen with a lot, *a lot*, of functions that do this internal import of something else. So, you'll never be sure. You can follow the python-dev thread titled Deadlock by a second import in a thread for more info. -- nosy: +facundobatista resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1255 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Changes by Warren DeLano: -- components: Windows nosy: delwarl severity: normal status: open title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
New submission from Warren DeLano: import threading rlock = threading.RLock() rlock.acquire(0) # always returns False with python-2.5.1.amd64.msi # even though rlock.acquire() # returns True as expected. # All attempts to acquire locks without blocking are foiled! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Christian Heimes added the comment: Ony my Ubuntu box lsb_release is just a small Python script that parses /etc/lsb-release. I suggest that your read the LSB standards about the file and use the information to parse it instead of invoking a program. -- nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330] Fix truncate on Windows, this time for real
Changes by Guido van Rossum: -- assignee: - gvanrossum keywords: +patch, py3k __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1330 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Christian Heimes added the comment: [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -a LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:desktop-3.1-noarch:desktop-3.1-ia32 Distributor ID: Ubuntu Description:Ubuntu 7.10 Release:7.10 Codename: gutsy [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -i Distributor ID: Ubuntu [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -d Description:Ubuntu 7.10 [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -c Codename: gutsy [EMAIL PROTECTED]:~$ /usr/bin/lsb_release -r Release:7.10 Please read http://linux.die.net/man/1/lsb_release. It explains the content of /etc/*-release in detail. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330] Fix truncate on Windows, this time for real
Guido van Rossum added the comment: While I like fixing the position restore in _fileio.c, I also liked Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that part (while losing the position restore)? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1330 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1330] Fix truncate on Windows, this time for real
Christian Heimes added the comment:
While I like fixing the position restore in _fileio.c, I also liked
Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that
part (while losing the position restore)?
Good point. We have to call flush() in _BufferedIOMixin as you said. I
checked if I could add a flush call to _fileio but it makes no sense. We
are working on file descriptors which means we don't have to use
fflush() and FileIO's flush() is a NOOP.
Added file: http://bugs.python.org/file8615/py3k_win_io2.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1330
__Index: Lib/io.py
===
--- Lib/io.py (revision 58662)
+++ Lib/io.py (working copy)
@@ -597,25 +597,15 @@
return self.raw.tell()
def truncate(self, pos=None):
-# On Windows, the truncate operation changes the current position
-# to the end of the file, which may leave us with desynchronized
-# buffers.
-# Since we promise that truncate() won't change the current position,
-# the easiest thing is to capture current pos now and seek back to
-# it at the end.
-
-initialpos = self.tell()
-if pos is None:
-pos = initialpos
-
# Flush the stream. We're mixing buffered I/O with lower-level I/O,
# and a flush may be necessary to synch both views of the current
# file state.
self.flush()
-newpos = self.raw.truncate(pos)
-self.seek(initialpos)
-return newpos
+if pos is None:
+pos = self.tell()
+return self.raw.truncate(pos)
+
### Flush and close ###
def flush(self):
Index: Modules/_fileio.c
===
--- Modules/_fileio.c (revision 58662)
+++ Modules/_fileio.c (working copy)
@@ -628,14 +628,22 @@
so don't even try using it. */
{
HANDLE hFile;
- PyObject *pos2;
+ PyObject *pos2, *oldposobj;
+ /* store the current position */
+ oldposobj = portable_lseek(self-fd, NULL, 1);
+ if (oldposobj == NULL) {
+ Py_DECREF(posobj);
+ return NULL;
+ }
+
/* Have to move current pos to desired endpoint on Windows. */
errno = 0;
pos2 = portable_lseek(fd, posobj, SEEK_SET);
if (pos2 == NULL)
{
Py_DECREF(posobj);
+ Py_DECREF(oldposobj);
return NULL;
}
Py_DECREF(pos2);
@@ -651,6 +659,16 @@
errno = EACCES;
}
Py_END_ALLOW_THREADS
+
+ /* Move to the previous position in the file */
+ pos2 = portable_lseek(fd, oldposobj, SEEK_SET);
+ if (pos2 == NULL) {
+ Py_DECREF(posobj);
+ Py_DECREF(oldposobj);
+ return NULL;
+ }
+ Py_DECREF(pos2);
+ Py_DECREF(oldposobj);
}
#else
Py_BEGIN_ALLOW_THREADS
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1331] More fixes for Windows
Guido van Rossum added the comment: Tested on OSX as well. Thanks!! Committed revision 58662. -- assignee: - gvanrossum keywords: +patch, py3k resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1331 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
