[issue1324] r58034 breaks building _ctypes with the upstream libffi.

[Matthias Klose]

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]>

__
___
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]

Changes by Matthias Klose:


--
type:  -> compile error

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

Changes by Matthias Klose:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

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]>

__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

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

[Yitz Gale]

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]>

__
___
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

[Jean-Paul Calderone]

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]>

__
___
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

[Jean-Paul Calderone]

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]>

__
___
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]

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]>

__
___
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

[Jean-Paul Calderone]

Changes by Jean-Paul Calderone:


--
nosy: +fijal

__
Tracker <[EMAIL PROTECTED]>

__
___
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

[Jean-Paul Calderone]

Changes by Jean-Paul Calderone:


--
nosy: +fijal

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

Jean-Paul Calderone added the comment:

The APR comment is indeed correct, so this is probably a Python bug.

--
nosy: +exarkun


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1287] os.environ.pop doesn't work

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

After reading the change, I think one more small change may be required.

Index: Lib/os.py
===
--- Lib/os.py   (revision 58654)
+++ Lib/os.py   (working copy)
@@ -452,7 +452,7 @@
 del self.data[key]
 def pop(self, key, *args):
 unsetenv(key)
-return self.data.pop(key, *args)
+return self.data.pop(key.upper(), *args)
 def has_key(self, key):
 return key.upper() in self.data
 def __contains__(self, key):

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1700463] VC6 build patch for trunk

[Hirokazu Yamamoto]

Hirokazu Yamamoto added the comment:

I updated patch. To avoid conflict  and ,
WIN32_LEAN_AND_MEAN is needed.

Added file: http://bugs.python.org/file8608/vc6-trunk-ver2.patch

_
Tracker <[EMAIL PROTECTED]>

_Index: Modules/errnomodule.c
===
--- Modules/errnomodule.c	(revision 58625)
+++ Modules/errnomodule.c	(working copy)
@@ -5,6 +5,7 @@
 
 /* Windows socket errors (WSA*)  */
 #ifdef MS_WINDOWS
+#define WIN32_LEAN_AND_MEAN
 #include 
 #endif
 
Index: Modules/selectmodule.c
===
--- Modules/selectmodule.c	(revision 58625)
+++ Modules/selectmodule.c	(working copy)
@@ -46,6 +46,7 @@
 #endif
 
 #ifdef MS_WINDOWS
+#  define WIN32_LEAN_AND_MEAN
 #  include 
 #else
 #  define SOCKET int
Index: Modules/socketmodule.h
===
--- Modules/socketmodule.h	(revision 58625)
+++ Modules/socketmodule.h	(working copy)
@@ -22,6 +22,7 @@
 # define HAVE_GETNAMEINFO
 # define ENABLE_IPV6
 #else
+# define WIN32_LEAN_AND_MEAN
 # include 
 #endif
 #endif
Index: PC/VC6/python.dsp
===
--- PC/VC6/python.dsp	(revision 58625)
+++ PC/VC6/python.dsp	(working copy)
@@ -77,6 +77,11 @@
 # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept
 # ADD LINK32 odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /base:"0x1d00" /subsystem:console /debug /machine:I386 /out:"./python_d.exe" /pdbtype:sept
 # SUBTRACT LINK32 /pdb:none
+# Begin Special Build Tool
+SOURCE="$(InputPath)"
+PostBuild_Desc=Changing stack size...
+PostBuild_Cmds=editbin /STACK:0x20 python_d.exe
+# End Special Build Tool
 
 !ENDIF 
 
Index: PC/VC6/pythoncore.dsp
===
--- PC/VC6/pythoncore.dsp	(revision 58625)
+++ PC/VC6/pythoncore.dsp	(working copy)
@@ -253,7 +253,7 @@
 # End Source File
 # Begin Source File
 
-SOURCE=..\..\Modules\collectionsmodule.c
+SOURCE=..\..\Modules\_collectionsmodule.c
 # End Source File
 # Begin Source File
 
@@ -329,6 +329,10 @@
 # End Source File
 # Begin Source File
 
+SOURCE=..\..\Parser\firstsets.c
+# End Source File
+# Begin Source File
+
 SOURCE=..\..\Objects\floatobject.c
 # End Source File
 # Begin Source File
@@ -398,10 +402,18 @@
 # End Source File
 # Begin Source File
 
+SOURCE=..\..\Parser\grammar.c
+# End Source File
+# Begin Source File
+
 SOURCE=..\..\Parser\grammar1.c
 # End Source File
 # Begin Source File
 
+SOURCE=..\..\Modules\zlib\gzio.c
+# End Source File
+# Begin Source File
+
 SOURCE=..\..\Modules\imageop.c
 # End Source File
 # Begin Source File
@@ -419,6 +431,10 @@
 # End Source File
 # Begin Source File
 
+SOURCE=..\..\Modules\zlib\infback.c
+# End Source File
+# Begin Source File
+
 SOURCE=..\..\Modules\zlib\inffast.c
 # End Source File
 # Begin Source File
@@ -583,10 +599,6 @@
 # End Source File
 # Begin Source File
 
-SOURCE=..\..\Modules\rgbimgmodule.c
-# End Source File
-# Begin Source File
-
 SOURCE=..\..\Modules\rotatingtree.c
 # End Source File
 # Begin Source File
@@ -675,6 +687,10 @@
 # End Source File
 # Begin Source File
 
+SOURCE=..\..\Modules\zlib\uncompr.c
+# End Source File
+# Begin Source File
+
 SOURCE=..\..\Objects\unicodectype.c
 # End Source File
 # Begin Source File
Index: PC/VC6/readme.txt
===
--- PC/VC6/readme.txt	(revision 58625)
+++ PC/VC6/readme.txt	(working copy)
@@ -203,8 +203,6 @@
 the build.  This Python script locates and builds your OpenSSL
 installation, then invokes a simple makefile to build the final .pyd.
 
-Win9x users:  see "Win9x note" below.
-
 build_ssl.py attempts to catch the most common errors (such as not
 being able to find OpenSSL sources, or not being able to find a Perl
 that works with OpenSSL) and give a reasonable error message.
@@ -216,31 +214,7 @@
 build_ssl.py/MSVC isn't clever enough to clean OpenSSL - you must do
 this by hand.
 
-Win9x note:  If, near the start of the build process, you see
-something like
 
-C:\Code\openssl-0.9.6g>set OPTS=no-asm
-Out of environment space
-
-then you're in trouble, and will probably also see these errors near
-the end of the process:
-
-NMAKE : fatal error U1073: don't know how to make
-'crypto\md5\asm\m5_win32.asm'
-Stop.
-NMAKE : fatal error U1073: don't know how to make
-'C:\Code\openssl-0.9.6g/out32/libeay32.lib'
-Stop.
-
-You need more environment space.  

[issue1322] platform.dist() has unpredictable result under Linux

[Raghuram Devarakonda]

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]>

__
___
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]

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] >
> 
> __
>

Added file: http://bugs.python.org/file8609/unnamed

__
Tracker <[EMAIL PROTECTED]>

__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 -aLSB 
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: MandrivaLinuxDescription:    Mandriva 
LinuxRelease:    
2007.1Codename:   Official[EMAIL 
PROTECTED] ~]$ lsb_release -iDistributor ID: MandrivaLinux[EMAIL 
PROTECTED] ~]$ lsb_release -d
Description:    Mandriva Linux[EMAIL PROTECTED] ~]$ 
lsb_release -rRelease:    
2007.1On 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:   Stentzyc176684:src$ 
lsb_release -i
Distributor ID: FedoraCoreyc176684: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 
-aLSBVersion:    :core-3.1-ia32:core-3.1-noarch
:graphics-3.1-ia32:graphics-3.1-noarchDistributor ID: 
FedoraDescription:    Fedora release 7 (Moonshine)Release: 
       7Codename:       
Mo

[issue1322] platform.dist() has unpredictable result under Linux

[Raghuram Devarakonda]

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] >
> > 
> > __
> >
>
> Added file: http://bugs.python.org/file8609/unnamed
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

_# 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

[Guido van Rossum]

Changes by Guido van Rossum:


--
nosy:  -gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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

[James G. sack (jim)]

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]>

__
___
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]

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]>

__
___
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]

Changes by Christian Heimes:


Added file: http://bugs.python.org/file8612/py3k_remove_os_tmp.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
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

[Jean Brouwers]

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]>

__
___
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]

Guido van Rossum added the comment:

Committed revision 58657.

Thanks!

--
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

Guido van Rossum added the comment:

Looks fine to me.
Committed revision 58658.

--
nosy: +gvanrossum
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__
___
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]

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]>

__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

[Christian Heimes]

Changes by Christian Heimes:


--
nosy: +gvanrossum, nnorwitz

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1331] More fixes for Windows

[Christian Heimes]

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]>

__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

[issue1255] Strange Python hangup

[Facundo Batista]

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]>

__
___
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

[Warren DeLano]

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]>

__
___
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

[Warren DeLano]

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]>

__
___
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]

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]>

__
___
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]

Changes by Guido van Rossum:


--
assignee:  -> gvanrossum
keywords: +patch, py3k

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

Raghuram Devarakonda 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.

Can you please check if it supports all the options mentioned
previously in the bug report? I agree that reading from a file is
preferable to running a command, if issues OP mentioned can be
addressed.

__
Tracker <[EMAIL PROTECTED]>

__
___
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]

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]>

__
___
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]

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]>

__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]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1255] Strange Python hangup

[Jiri Krivanek]

Jiri Krivanek added the comment:

In the mena time, by intuition, I have resolved my troube exactly the
way you recommend.

Thanks to you, currently I also know what is he core of the problem.

So the issue can be closed...

__
Tracker <[EMAIL PROTECTED]>

__
___
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

[Neal Norwitz]

Neal Norwitz added the comment:

Thanks for testing 3.0.  

Do you have any idea why they are no longer called?  I don't recall any
changes related to this area.  Can you try to debug further?

--
nosy: +nnorwitz

__
Tracker <[EMAIL PROTECTED]>

__
___
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

[James G. sack (jim)]

James G. sack (jim) added the comment:

Feature Request REVISION

Upon reflection and more playing around with some test cases, I wish to 
revise my feature request.

I think the utf8 codecs should accept input with or without the "sig".
On output, only the utf_8_sig should write the 3-byte "sig". This behavior 
change would not seem disruptive to current applications. 

For utf16, (arguably) a missing BOM should merely assume machian endianess.
For utf_16_le, utf_16_be input, both should accept & discard a BOM.
On output, I'm not sure; maybe all should write a BOM unless passed a flag 
signifying no bom? 
Or to preserve backward compat, could have a parm write_bom defaulting to 
True for utf16 and False for utf_16_le and utf_16_be. This is a 
modification of the originial request (for a force_bom flag).  

Unless I have confused myself with my test cases, the current codecs are 
slightly inconsistent for the utf8 codecs:

utf8 treats "sig" as real data, if present, but..
utf_8_sig works right even without the "sig" (so this one I like as is!)

The 16'ers seem to match the (inferred) specs, but for completeness here:
utf_16 refuses to proceed w/o BOM (even with correct endian input data)
utf_16_le treats BOM as data
utf_16_be treats BOM as data

Regards,
..jim

__
Tracker <[EMAIL PROTECTED]>

__
___
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

[James G. sack (jim)]

James G. sack (jim) added the comment:

Later note: kind of weird!

On my LE machine, utf16 reads my BE-formatted test data (no BOM) 
apparently assumng some kind of surrogate format, until it finds 
an "illegal UTF-16 surrogate".

That I fail to understand, especially since it quits upon seeing 
a BOM with valid LE data.

Test data and test code available on request.

Regards,
..jim

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com