[issue1341] correction for test_fileinput in py3k on Windows

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +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

[Neal Norwitz]

Neal Norwitz added the comment:

When I run with the attached patch, I see the message: 

*** dtor called in python ...

Is that the behavior you expect?

Added file: http://bugs.python.org/file8626/stdout-close.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Python/pythonrun.c
===
--- Python/pythonrun.c	(revision 58681)
+++ Python/pythonrun.c	(working copy)
@@ -725,7 +725,8 @@
 	}
 	PySys_SetObject("__stdin__", std);
 	PySys_SetObject("stdin", std);
-	Py_DECREF(std);
+	/* Purposefully lose a ref to stdin so it is never closed. */
+	/* Py_DECREF(std); */
 
 	/* Set sys.stdout */
 	if (!(std = PyFile_FromFd(fileno(stdout), "", "w", -1,
@@ -734,7 +735,8 @@
 }
 	PySys_SetObject("__stdout__", std);
 	PySys_SetObject("stdout", std);
-	Py_DECREF(std);
+	/* Purposefully lose a ref to stdout so it is never closed. */
+	/* Py_DECREF(std); */
 
 	/* Set sys.stderr */
 	if (!(std = PyFile_FromFd(fileno(stderr), "", "w", -1,
@@ -743,7 +745,8 @@
 }
 PySys_SetObject("__stderr__", std);
 	PySys_SetObject("stderr", std);
-	Py_DECREF(std);
+	/* Purposefully lose a ref to stderr so it is never closed. */
+	/* Py_DECREF(std); */
 
 if (0) {
   error:
___
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]

Jean Brouwers added the comment:

Attached is an updated dlibtest.c file.  It prints a message in the con-
/destructor functions and if that fails it calls _exit(9).

Compile and run it as before and check the exit status.  If the latter 
is 9 or 011, a printf error occurred indicating e.g. that stdout was 
closed or something similar.

This version can also be used with gdb, either by pre-loading the 
dlibtest.so library within gdb or before invoking gdb.  To preload the 
library within gdb (on Linux) use

   gdb  .../python
   (gdb) set environment LD_PRELOAD ./dlibtest.so
   (gdb) run
   .

or to preload before gdb use

   setenv LD_PRELOAD ./dlibtest.so
   gdb .../python
   (gdb) run
   .

Lastly, my previous observations about this issue were clearly a "trompe 
d'oeil", especially my statement that PyImport_Cleanup never returned.  
The missing print statements *after* the PyImport_Cleanup call are 
simply due to printf errors, and nothing else ;-)

Added file: http://bugs.python.org/file8625/dlibtest.c

__
Tracker <[EMAIL PROTECTED]>

__
#include "stdio.h"
#include "string.h"
#include "unistd.h"

#ifndef __GNUC__
# error requires the GNU compiler
#endif

extern const char* __progname;

/* call printf() only if inside python binary */
static void
_printf (const char* fmt, const char* arg1, const char* arg2)
{
if (!strcmp("python", __progname)) {
if (printf(fmt, arg1, arg2) < 0) {
_exit(9);  /* stdout closed? */
}
}
}


#if 0  /* pick this ... */

static void  __attribute__((constructor))  /* called on main() */
_ctor (void)
{
_printf("*** %s called in %s ...\n", "ctor", __progname);
}

static void __attribute__((destructor))  /* called on exit() */
_dtor (void)
{
_printf("*** %s called in %s ...\n", "dtor", __progname);
}


#else  /* ... or this case */

static void  /* called on Python exit */
_dtor (void)
{
_printf("*** %s called in %s ...\n", "dtor", __progname);
}

/* the weak attribute prevents unresolved symbol errors */
extern int Py_AtExit (void(*func)(void)) __attribute__((weak));

static void  __attribute__((constructor))  /* called on main() */
_ctor (void)
{
_printf("*** %s called in %s ...\n", "ctor", __progname);
if (Py_AtExit) {
   _printf("*** %s %s\n", "Py_AtExit", (Py_AtExit(_dtor) < 0 ? "failed!" : 
"OK"));
}
}

#endif


/* =

Build this file into a shared library, then pre-load
that library with the Python binary as follows.

On Linux, compile as

gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

and then run

env LD_PRELOAD=./dlibtest.so  .../python


On MacOS X, compile as

gcc -o dlibtest.os -c -Wall -Werror -march=i686 -fPIC dlibtest.c
gcc -o dlibtest.dylib -undefined dynamic_lookup -lpthread -dynamiclib 
dlibtest.os

and run

   env DYLD_INSERT_LIBRARIES=./dlibtest.dylib  .../python.exe


To preload the library within gdb (on Linux) use

   gdb  .../python
   (gdb) set environment LD_PRELOAD ./dlibtest.so
   (gdb) run
   .

or use

   setenv LD_PRELOAD ./dlibtest.so
   gdb .../python
   (gdb) run
   .


After Ctrl-D two messages should have been printed, but 3.0a1
prints only the first one.  An exist status is 9 or 011 indicates
that a printf error occurred.



Here is a log from Linux with my 3.0a1 and 2.51 builds and
with 2.3.4 included with the Linux distro:

$ gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
$ gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

$ env LD_PRELOAD=./dlibtest.so ~/Python-3.0a1/python 
*** ctor called ...
Python 3.0a1 (py3k, Oct 26 2007, 09:45:17) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

$ env LD_PRELOAD=./dlibtest.so ~/Python-2.5.1/python
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:19:11) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...

$ env LD_PRELOAD=./dlibtest.so /usr/bin/python
*** ctor called ...
Python 2.3.4 (#1, May  2 2007, 19:26:00) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...


Similarly on MacOS X with Python 2.3.5 distributed by Apple:

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-3.0a1/python.exe
*** ctor called ...
Python 3.0a1 (py3k, Oct 25 2007, 14:55:57) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-2.5.1/python.exe
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:18:08) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "cr

[issue1247] PEP 3137 patch (repr, names, parser)

[Christian Heimes]

Christian Heimes added the comment:

Here is the patch that contains only the harmless parts of the previous
patches. It changes a bunch of doc strings, changes the name of the
types and their repr() and str(). It also adds __builtin__.buffer but it
leaves __builtin__.bytes, __builtin__.str8 and b'' as they are.

Added file: http://bugs.python.org/file8624/py3k-pep3137_harmless.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c	(revision 58683)
+++ Python/bltinmodule.c	(working copy)
@@ -1797,6 +1797,7 @@
 	SETBUILTIN("True",		Py_True);
 	SETBUILTIN("bool",		&PyBool_Type);
 	SETBUILTIN("memoryview",&PyMemoryView_Type);
+	SETBUILTIN("buffer",		&PyBytes_Type);
 	SETBUILTIN("bytes",		&PyBytes_Type);
 	SETBUILTIN("classmethod",	&PyClassMethod_Type);
 #ifndef WITHOUT_COMPLEX
Index: Objects/bytesobject.c
===
--- Objects/bytesobject.c	(revision 58683)
+++ Objects/bytesobject.c	(working copy)
@@ -395,7 +395,7 @@
 if (i < 0)
 i += Py_Size(self);
 if (i < 0 || i >= Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, "bytes index out of range");
+PyErr_SetString(PyExc_IndexError, "buffer index out of range");
 return NULL;
 }
 return PyInt_FromLong((unsigned char)(self->ob_bytes[i]));
@@ -414,7 +414,7 @@
 i += PyBytes_GET_SIZE(self);
 
 if (i < 0 || i >= Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, "bytes index out of range");
+PyErr_SetString(PyExc_IndexError, "buffer index out of range");
 return NULL;
 }
 return PyInt_FromLong((unsigned char)(self->ob_bytes[i]));
@@ -451,7 +451,7 @@
 }
 }
 else {
-PyErr_SetString(PyExc_TypeError, "bytes indices must be integers");
+PyErr_SetString(PyExc_TypeError, "buffer indices must be integers");
 return NULL;
 }
 }
@@ -551,7 +551,7 @@
 i += Py_Size(self);
 
 if (i < 0 || i >= Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, "bytes index out of range");
+PyErr_SetString(PyExc_IndexError, "buffer index out of range");
 return -1;
 }
 
@@ -587,7 +587,7 @@
 i += PyBytes_GET_SIZE(self);
 
 if (i < 0 || i >= Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, "bytes index out of range");
+PyErr_SetString(PyExc_IndexError, "buffer index out of range");
 return -1;
 }
 
@@ -619,7 +619,7 @@
 }
 }
 else {
-PyErr_SetString(PyExc_TypeError, "bytes indices must be integer");
+PyErr_SetString(PyExc_TypeError, "buffer indices must be integer");
 return -1;
 }
 
@@ -889,11 +889,14 @@
 bytes_repr(PyBytesObject *self)
 {
 static const char *hexdigits = "0123456789abcdef";
-size_t newsize = 3 + 4 * Py_Size(self);
+const char *quote_prefix = "buffer(b'";
+const char *quote_postfix = "')";
+/* 9 prefix + 2 postfix */
+size_t newsize = 11 + 4 * Py_Size(self);
 PyObject *v;
-if (newsize > PY_SSIZE_T_MAX || newsize / 4 != Py_Size(self)) {
+if (newsize > PY_SSIZE_T_MAX || (newsize-11) / 4 != Py_Size(self)) {
 PyErr_SetString(PyExc_OverflowError,
-"bytes object is too large to make repr");
+"buffer object is too large to make repr");
 return NULL;
 }
 v = PyUnicode_FromUnicode(NULL, newsize);
@@ -904,17 +907,17 @@
 register Py_ssize_t i;
 register Py_UNICODE c;
 register Py_UNICODE *p;
-int quote = '\'';
 
 p = PyUnicode_AS_UNICODE(v);
-*p++ = 'b';
-*p++ = quote;
+while (*quote_prefix)
+*p++ = *quote_prefix++;
+
 for (i = 0; i < Py_Size(self); i++) {
 /* There's at least enough room for a hex escape
and a closing quote. */
 assert(newsize - (p - PyUnicode_AS_UNICODE(v)) >= 5);
 c = self->ob_bytes[i];
-if (c == quote || c == '\\')
+if (c == '\'' || c == '\\')
 *p++ = '\\', *p++ = c;
 else if (c == '\t')
 *p++ = '\\', *p++ = 't';
@@ -934,7 +937,9 @@
 *p++ = c;
 }
 assert(newsize - (p - PyUnicode_AS_UNICODE(v)) >= 1);
-*p++ = quote;
+while (*quote_postfix) {
+   *p++ = *quote_postfix++;
+}
 *p = '\0';
 if (PyUnicode_Resize(&v, (p - PyUnicode_AS_UNICODE(v {
 Py_DECREF(v);
@@ -947,7 +952,7 @@
 static PyObject *
 bytes_str(PyBytesObject *self)
 {
-return PyString_FromStringAndSize(self->ob_bytes, Py_Size(self));
+return bytes_repr(self);
 }
 
 static PyObject *
@@ -2028,7 +2033,7 @@
 PyDoc_STRVAR(replace__doc__,
 "B.replace (old, n

[issue1042] test_glob fails with UnicodeDecodeError

[Christian Heimes]

Christian Heimes added the comment:

I think the problem is solved now. I haven't seen glob crashing for a while.

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue1342] Crash on Windows if Python runs from a directory with umlauts

[Christian Heimes]

New submission from Christian Heimes:

Python 3.0 doesn't run from a directory with umlauts and possible other
non ASCII chars.

I renamed my development folder from C:\dev\ to c:\test äöüß name\.
Python crashes after a few moments before it can reach its shell.

python30.dll!PyErr_SetObject(_object * exception=0x1e1b9888, _object *
value=0x00a0b8a0)  Zeile 56 + 0xb Bytes C
python30.dll!PyErr_SetString(_object * exception=0x1e1b9888, const
char * string=0x1e18c358)  Zeile 77 + 0xd Bytes C
python30.dll!find_module(char * fullname=0x0021fcc0, char *
subname=0x, _object * path=0x, char * buf=0x0021fb70,
unsigned int buflen=257, _iobuf * * p_fp=0x0021fb64, _object * *
p_loader=0x0021fb68)  Zeile 1228 + 0x10 Bytes   C
python30.dll!import_submodule(_object * mod=0x1e1c6a88, char *
subname=0x0021fcc0, char * fullname=0x)  Zeile 2313 + 0x27 Bytes
C
python30.dll!load_next(_object * mod=0x1e1c6a88, _object *
altmod=0x1e1c6a88, char * * p_name=0x, char * buf=0x0021fcc0,
int * p_buflen=0x0021fcbc)  Zeile 2127 + 0x15 Bytes C
python30.dll!import_module_level(char * name=0x, _object *
globals=0x, _object * locals=0x1e069ec3, _object *
fromlist=0x, int level=0)  Zeile 1908 + 0x1a Bytes  C
python30.dll!PyImport_ImportModuleLevel(char * name=0x1e184b04,
_object * globals=0x, _object * locals=0x, _object *
fromlist=0x, int level=0)  Zeile 1979 + 0x18 Bytes  C
python30.dll!_PyCodecRegistry_Init()  Zeile 841 + 0x12 BytesC
python30.dll!PyCodec_LookupError(const char * name=0x)  Zeile
436 + 0xc Bytes C
python30.dll!unicode_decode_call_errorhandler(const char *
errors=0x, _object * * errorHandler=0x0009, const char *
encoding=0x1e1979ec, const char * reason=0x, const char * *
input=0x0021fe80, const char * * inend=0x0021fe84, int *
startinpos=0x0021fe6c, int * endinpos=0x0021fe68, _object * *
exceptionObject=0x, const char * * inptr=0x0021fe90, _object * *
output=0x0021fe70, int * outpos=0x0021fe88, unsigned short * *
outptr=0x0021fe74)  Zeile 1384 + 0xa Bytes  C
python30.dll!PyUnicodeUCS2_DecodeUTF8Stateful(const char *
s=0x1e1dd010, int size=48, const char * errors=0x, int *
consumed=0x)  Zeile 1967 + 0x47 Bytes   C
python30.dll!PyUnicodeUCS2_FromStringAndSize(const char *
u=0x1e1dd008, int size=48)  Zeile 464 + 0xb Bytes   C
python30.dll!PyUnicodeUCS2_FromString(const char * u=0x1e1dd008) 
Zeile 482 + 0x7 Bytes   C
python30.dll!_PySys_Init()  Zeile 1084 + 0xb Bytes  C
python30.dll!Py_InitializeEx(int install_sigs=1)  Zeile 220 C
python30.dll!Py_Initialize()  Zeile 292 + 0x7 Bytes C
python30.dll!Py_Main(int argc=2, char * * argv=0x0001)  Zeile 432   
C
>   python.exe!mainCRTStartup()  Zeile 398 + 0xe Bytes  C
kernel32.dll!7c816fd7()

--
components: Interpreter Core
messages: 56841
nosy: tiran
severity: normal
status: open
title: Crash on Windows if Python runs from a directory with umlauts
type: crash
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

[issue1329] Different 3.0a1 exit behavior

[Jean Brouwers]

Jean Brouwers added the comment:

It looks like the problem may indeed just be that I/O is being shut down 
somewhere inside PyImport_Cleanup.  I am modifying the test case to 
demonstrate that and will submit that version as soon as it runs.

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

Warren DeLano added the comment:

I wouldn't know how take the lead, but with customers breathing down 
my neck for x64 support, my own threading.Rlock-dependent software 
product cannot support x64 until an official Python release supports 
it.  

So I guess that automatically puts me in the **highly-
motivated/willing-to-help** camp, if there's anything useful I can 
actually do towards 2.5.2.

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

Jean Brouwers added the comment:

The 3.0a1 build --with-pydebug behaves the same as before (on Linux).  The 
problem does occur without gdb but not with gdb.

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

> However, considering the severity of this problem
> (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think
> about issuing a 2.5.2 maintenance release?

Neal Norwitz and Anthony Baxter have been planning to release 2.5.2
for a while now; unfortunately both seem too busy to make much
progress. Any volunteers?

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

Warren DeLano added the comment:

No need -- turns out the problem was fixed on April 21st a mere three 
days after Python 2.5.1 was released.  Please close this issue -- my 
rookie mistake not working with SVN source from the start! (gee, I 
should have known better...)  Sorry for wasting your time and mine.

However, considering the severity of this problem 
(threading.Lock.acquire(0) broken on 64-bit Windows), what do you think 
about issuing a 2.5.2 maintenance release?

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

Jean Brouwers added the comment:

OK, I try that.

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

I suggest you configure --with-pydebug.  That will disable
optimization, enable debugging symbols and will make it easier to
develop.  Note that a debug version runs much slower due to asserts()
and other internal changes.  Otherwise, it should work the same.

On Oct 26, 2007 4:55 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote:
>
> Jean Brouwers added the comment:
>
> This is quite bizarre and difficult to reproduce.  With gdb, 3.0a1 does
> get to the very end of Py_Finalize, but without gdb it doesn't.
>
> Also, the call to static function  call_all_exitfuncs is inlined, its
> while loop is shown inside Py_Finalize on MacOS X.  On Linux that is not
> visible, probably due to differences in gcc/gdb, 4.0.1 or MacOS X and
> 3.4.6 on Linux.
>
>
> __
> 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

[issue1341] correction for test_fileinput in py3k on Windows

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc:


--
components: +Windows
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

[issue1341] correction for test_fileinput in py3k on Windows

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc:

This patch corrects test_fileinput on Windows: when redirecting stdout,
os.open should be given O_BINARY, because the file descriptor is then
wrapped in a text-mode file; os.fdopen(fd, "w").

--
files: fileinput.diff
messages: 56833
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_fileinput in py3k on Windows
Added file: http://bugs.python.org/file8623/fileinput.diff

__
Tracker <[EMAIL PROTECTED]>

__

fileinput.diff
Description: Binary data
___
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]

Jean Brouwers added the comment:

This is quite bizarre and difficult to reproduce.  With gdb, 3.0a1 does 
get to the very end of Py_Finalize, but without gdb it doesn't.

Also, the call to static function  call_all_exitfuncs is inlined, its 
while loop is shown inside Py_Finalize on MacOS X.  On Linux that is not 
visible, probably due to differences in gcc/gdb, 4.0.1 or MacOS X and 
3.4.6 on Linux.

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

Maybe that's because site and io get cleaned up and then there is some
fatal error that can't be printed?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1340] correction for test_tempfile in py3k on Windows

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc:

This tiny patch correct a failure in test_tempfile on Windows: in
SpooledTemporaryFile, avoid translating the newlines twice.
Otherwise, in "universal" text mode, \n gets transformed to \r\n, then
to \r\r\n, which is read as \n\n.
Passing the encoding is OK, since the round-trip gives the same result,
and it allow encoding errors to occur at the right place.

Index: Lib/tempfile.py
===
--- Lib/tempfile.py (revision 58680)
+++ Lib/tempfile.py (working copy)
@@ -495,7 +495,7 @@
 if 'b' in mode:
 self._file = _io.BytesIO()
 else:
-self._file = _io.StringIO(encoding=encoding, newline=newline)
+self._file = _io.StringIO(encoding=encoding)
 self._max_size = max_size
 self._rolled = False
 self._TemporaryFileArgs = {'mode': mode, 'buffering': buffering,

--
components: Windows
messages: 56830
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_tempfile in py3k on Windows
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

[issue1339] smtplib starttls() should ehlo() if it needs to

[Bill Fenner]

New submission from Bill Fenner:

smtplib's "complex" methods, login and sendmail, try to EHLO or HELO if 
it hasn't been done yet.  login also checks to see if the EHLO response 
included the ability to do authorization.

starttls seems to me to be similar in nature: why should it not try to 
EHLO or HELO, and check that self.has_extn("starttls")?

--
components: Library (Lib)
messages: 56829
nosy: fenner
severity: normal
status: open
title: smtplib starttls() should ehlo() if it needs to
type: rfe
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue829951] Fixes smtplib starttls HELO errors

[Bill Fenner]

Bill Fenner added the comment:

Yes, the state that should be reset includes helo_resp, ehlo_resp, 
esmtp_features, and does_esmtp.

The workaround commonly proposed is to always call ehlo() after starttls() 
.  While this works (most of the time?), it seems arbitrary to require an 
explicit ehlo() call in this case but not other cases.

--
nosy: +fenner
versions: +Python 2.4


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]

Jean Brouwers added the comment:

I put a bunch of printf's in the Py_Finalize function of 2.5.1 and 
3.0a1.

All those show up when 2.5.1 exists including the call to 
call_ll_exitfuncs.

But in 3.0a1 only a few show up and the last one is just before the call 
to PyImport_Cleanup near line 393.  It looks like that call never 
returns.  That call never returns, it seems.

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

Jean Brouwers added the comment:

One more thing.  Stepping with the debugger thru Py_Finalize looks exactly 
the same for 2.5.1 and 3.0a1 in the last part of that function.

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

Jean Brouwers added the comment:

The Py_AtExit function is in Python/pythonrun.c.  The calls to all 
installed C functions are made in  call_ll_exitfuncs, also in 
pythonrun.c.  The call to  call_ll_exitfuncs is at the very end of 
Py_Finalize also in pythonrun.c.

I am just getting down there now and Py_Finalize is called and reaches 
the call to PyGrammar_RemoveAccelerators a few lines higher.  But 
call_ll_exitfuncs is not called, as far as I can tell.

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

OK, confirmed. But no insignt in what happened yet... Do you know where
the atexit stuff happens in 2.5?

__
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

[Guido van Rossum]

Changes by Guido van Rossum:


Removed file: http://bugs.python.org/file8620/dlibtest.c

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

Jean Brouwers added the comment:

My fault, sorry.  The command line to run should be

  env  LD_PRELOAD=./dlibtest.so  ...

i.e. with '=' sign and no spaces.  And the library file may have to be 
an absolute path.

__
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

[Christian Heimes]

Christian Heimes added the comment:

The patch doesn't apply (r58677 of release25-maint). Can you please
create an unified diff against the latest subversion checkout with svn
diff or TortoiseSVN?

$ patch -p1 < thread_nt_fix.patch
missing header for context diff at line 3 of patch
patching file Python/thread_nt.h
Hunk #2 FAILED at 14.
Hunk #3 FAILED at 40.
2 out of 3 hunks FAILED -- saving rejects to file Python/thread_nt.h.rej

--
nosy: +nnorwitz, tiran

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

> Here is the same file with an #if to use to Py_AtExit or destructor case.
> Please us this one instead of the earlier one.
>
> Added file: http://bugs.python.org/file8622/dlibtest.c

I can build it just fine on Ubuntu dapper, but I can't run it.  The
command given in the comment fails immediately:

$ env LD_PRELOAD  dlibtest.so  ~/p3/python
env: LD_PRELOAD: No such file or directory
$

When I modify it slightly I get another error:

$ env LD_PRELOAD=dlibtest.so  ~/p3/python
ERROR: ld.so: object 'dlibtest.so' from LD_PRELOAD cannot be preloaded: ignored.
Python 3.0a1+ (py3k, Oct 26 2007, 12:30:11)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
$

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

Jean Brouwers added the comment:

Here is the same file with an #if to use to Py_AtExit or destructor case.   
Please us this one instead of the earlier one.

Added file: http://bugs.python.org/file8622/dlibtest.c

__
Tracker <[EMAIL PROTECTED]>

__
#include "stdio.h"


#ifndef __GNUC__
# error require GNU compiler
#endif


#if 0  /* pick this ... */

static void  __attribute__((constructor))  /* called on main() */
_ctor (void)
{
printf("*** %s called ...\n", "ctor");
}

static void __attribute__((destructor))  /* called on exit() */
_dtor (void)
{
printf("*** %s called ...\n", "dtor");
}


#else  /* ... or this case */

static void  /* called on Python exit */
_dtor (void)
{
printf("*** %s called ...\n", "dtor");
}

extern int Py_AtExit (void(*func)(void));

static void  __attribute__((constructor))  /* called on main() */
_ctor (void)
{
printf("*** %s called ...\n", "ctor");
if (Py_AtExit(_dtor) < 0) {
printf("%s failed ...\n", "Py_AtExit");
}
}

#endif


/* =

Build this file into a shared library, then pre-load
that library with the Python binary as follows.

On Linux, compile as

gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

and then run

env LD_PRELOAD  dlibtest.so  .../python


On MacOS X, compile as

gcc -o dlibtest.os -c -Wall -Werror -march=i686 -fPIC dlibtest.c
gcc -o dlibtest.dylib -undefined dynamic_lookup -lpthread -dynamiclib 
dlibtest.os

and run

   env DYLD_INSERT_LIBRARIES=./dlibtest.dylib  .../python.exe


After Ctrl-D two messages should have been printed, but 3.0a1
prints only the first one.


Here is a log from Linux with my 3.0a1 and 2.51 builds and
with 2.3.4 included with the Linux distro:

$ gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
$ gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

$ env LD_PRELOAD=./dlibtest.so ~/Python-3.0a1/python 
*** ctor called ...
Python 3.0a1 (py3k, Oct 26 2007, 09:45:17) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

$ env LD_PRELOAD=./dlibtest.so ~/Python-2.5.1/python
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:19:11) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...

$ env LD_PRELOAD=./dlibtest.so /usr/bin/python
*** ctor called ...
Python 2.3.4 (#1, May  2 2007, 19:26:00) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...


Similarly on MacOS X with Python 2.3.5 distributed by Apple:

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-3.0a1/python.exe
*** ctor called ...
Python 3.0a1 (py3k, Oct 25 2007, 14:55:57) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-2.5.1/python.exe
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:18:08) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
*** dtor called ...

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib /usr/bin/python
*** ctor called ...
Python 2.3.5 (#1, Jan 13 2006, 20:13:11) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
*** dtor called ...


/Jean Brouwers  <[EMAIL PROTECTED]>


PS) For more details on the con/destructor attributes, see the GNU
gcc documentation at



See also Apple's documentation DynamicLibrary.pdf which
contains some excellent examples plus special MacOS X
features.  E.g. c/dtor must be ZPRIVATE and a static
ctor can have main-like argc, argv and envp arguments!

 = */

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

Warren DeLano added the comment:

Patch attached.  Do note that this patch will break threading on Win95 
in order to achieve 64-bit compatibility.  Win98 and up should be 
fine -- however, that assertion has not yet been confirmed.

Added file: http://bugs.python.org/file8621/thread_nt_fix.patch

__
Tracker <[EMAIL PROTECTED]>

__*** thread_nt.h Fri Oct 26 21:03:09 2007
--- Python-2.5.1/Python/thread_nt.h Fri Oct 26 21:03:34 2007
***
*** 1,9 
--- 1,10 
  
  /* This code implemented by [EMAIL PROTECTED] */
  /* Fast NonRecursiveMutex support by Yakov Markovitch, [EMAIL PROTECTED] */
  /* Eliminated some memory leaks, [EMAIL PROTECTED] */
+ /* Nixed InterlockedCompareExchange emulation (x86_64:1, Win95:0), [EMAIL 
PROTECTED] */
  
  #include 
  #include 
  #ifdef HAVE_PROCESS_H
  #include 
***
*** 13,88 
LONG   owned ;
DWORD  thread_id ;
HANDLE hevent ;
  } NRMUTEX, *PNRMUTEX ;
  
- typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID *dest, PVOID exc, PVOID 
comperand) ;
- 
- /* Sorry mate, but we haven't got InterlockedCompareExchange in Win95! */
- static PVOID WINAPI
- interlocked_cmp_xchg(PVOID *dest, PVOID exc, PVOID comperand)
- {
-   static LONG spinlock = 0 ;
-   PVOID result ;
-   DWORD dwSleep = 0;
- 
-   /* Acqire spinlock (yielding control to other threads if cant aquire 
for the moment) */
-   while(InterlockedExchange(&spinlock, 1))
-   {
-   // Using Sleep(0) can cause a priority inversion.
-   // Sleep(0) only yields the processor if there's
-   // another thread of the same priority that's
-   // ready to run.  If a high-priority thread is
-   // trying to acquire the lock, which is held by
-   // a low-priority thread, then the low-priority
-   // thread may never get scheduled and hence never
-   // free the lock.  NT attempts to avoid priority
-   // inversions by temporarily boosting the priority
-   // of low-priority runnable threads, but the problem
-   // can still occur if there's a medium-priority
-   // thread that's always runnable.  If Sleep(1) is used,
-   // then the thread unconditionally yields the CPU.  We
-   // only do this for the second and subsequent even
-   // iterations, since a millisecond is a long time to wait
-   // if the thread can be scheduled in again sooner
-   // (~100,000 instructions).
-   // Avoid priority inversion: 0, 1, 0, 1,...
-   Sleep(dwSleep);
-   dwSleep = !dwSleep;
-   }
-   result = *dest ;
-   if (result == comperand)
-   *dest = exc ;
-   /* Release spinlock */
-   spinlock = 0 ;
-   return result ;
- } ;
- 
- static interlocked_cmp_xchg_t *ixchg;
- 
  BOOL
  InitializeNonRecursiveMutex(PNRMUTEX mutex)
  {
-   if (!ixchg)
-   {
-   /* Sorely, Win95 has no InterlockedCompareExchange API (Win98 
has), so we have to use emulation */
-   HANDLE kernel = GetModuleHandle("kernel32.dll") ;
-   if (!kernel || (ixchg = (interlocked_cmp_xchg_t 
*)GetProcAddress(kernel, "InterlockedCompareExchange")) == NULL)
-   ixchg = interlocked_cmp_xchg ;
-   }
- 
mutex->owned = -1 ;  /* No threads have entered NonRecursiveMutex */
mutex->thread_id = 0 ;
mutex->hevent = CreateEvent(NULL, FALSE, FALSE, NULL) ;
return mutex->hevent != NULL ;  /* TRUE if the mutex is created */
  }
  
- #ifdef InterlockedCompareExchange
- #undef InterlockedCompareExchange
- #endif
- #define InterlockedCompareExchange(dest,exchange,comperand) (ixchg((dest), 
(exchange), (comperand)))
- 
  VOID
  DeleteNonRecursiveMutex(PNRMUTEX mutex)
  {
/* No in-use check */
CloseHandle(mutex->hevent) ;
--- 14,32 
***
*** 96,106 
DWORD ret ;
  
/* InterlockedIncrement(&mutex->owned) == 0 means that no thread 
currently owns the mutex */
if (!wait)
{
!   if (InterlockedCompareExchange((PVOID *)&mutex->owned, 
(PVOID)0, (PVOID)-1) != (PVOID)-1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(&mutex->owned) ?
--- 40,50 
DWORD ret ;
  
/* InterlockedIncrement(&mutex->owned) == 0 means that no thread 
currently owns the mutex */
if (!wait)
{
!   if (InterlockedCompareExchange(&mutex->owned, 0, -1) != -1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(&mutex->owned) ?
___
Python-bugs

[issue1329] Different 3.0a1 exit behavior

[Jean Brouwers]

Jean Brouwers added the comment:

Attached is a simple test case which demonstrates the problem on Linux 
and MacOS X.  It is not an xxmodule example, though and hope this is OK.

See the comments for build steps and example output with 3 different 
Python builds on both platforms.

If you need another test case which uses Py_AtExit, let me know.

Added file: http://bugs.python.org/file8620/dlibtest.c

__
Tracker <[EMAIL PROTECTED]>

__
#include "stdio.h"


#ifndef __GNUC__
# error require GNU compiler
#endif


static void  __attribute__((constructor))  /* called on main() */
_ctor (void)
{
printf("*** %s called ...\n", "ctor");
}


static void  __attribute__((destructor))  /* called on exit() */
_dtor (void)
{
printf("*** %s called ...\n", "dtor");
}


/* =

Build this file into a shared library, then pre-load
that library with the Python binary as follows.

On Linux, compile as

gcc -o dlibtest.os -c -m32 -Wall -Werror dlibtest.c
gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

and then run

env LD_PRELOAD  dlibtest.so  .../python


On MacOS X, compile as

gcc -o dlibtest.os -c -Wall -Werror -march=i686 -fPIC dlibtest.c
gcc -o dlibtest.dylib -undefined dynamic_lookup -lpthread -dynamiclib 
dlibtest.os

and run

   env DYLD_INSERT_LIBRARIES=./dlibtest.dylib  .../python.exe


After Ctrl-D two messages should have been printed, but 3.0a1
prints only the first one.


Here is a log from Linux with my 3.0a1 and 2.51 builds and
with 2.3.4 included with the Linux distro:

$ gcc -o dlibtest.os -c -m32 -Wall -Werror dlibtest.c
$ gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os

$ env LD_PRELOAD=./dlibtest.so ~/Python-3.0a1/python 
*** ctor called ...
Python 3.0a1 (py3k, Oct 26 2007, 09:45:17) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

$ env LD_PRELOAD=./dlibtest.so ~/Python-2.5.1/python
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:19:11) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...

$ env LD_PRELOAD=./dlibtest.so /usr/bin/python
*** ctor called ...
Python 2.3.4 (#1, May  2 2007, 19:26:00) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
*** dtor called ...


Similarly on MacOS X with Python 2.3.5 distributed by Apple:

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-3.0a1/python.exe
*** ctor called ...
Python 3.0a1 (py3k, Oct 25 2007, 14:55:57) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-2.5.1/python.exe
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:18:08) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
*** dtor called ...

% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib /usr/bin/python
*** ctor called ...
Python 2.3.5 (#1, Jan 13 2006, 20:13:11) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
*** dtor called ...


/Jean Brouwers  <[EMAIL PROTECTED]>


PS) For more details on the con/destructor attributes, see the GNU
gcc documentation at



See also Apple's documentation DynamicLibrary.pdf which
contains some excellent examples plus special MacOS X
features.  E.g. c/dtor must be ZPRIVATE and a static
ctor can have main-like argc, argv and envp arguments!

 = */

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

OK, I will work on it. I have just downloaded trunk and will see what 
I can do. Might be a week or two.

..jim

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

> Disabling Python's emulated InterlockedCompareExchange (for Win95
> compatibility) cures the problem, so the underlying question is why the
> existence of InterlockedCompareExchange is not being autodetected on 64
> bit systems -- and that is apparently because GetProcAddress
> (kernel,"InterlockedCompareExchange") returns NULL -- which makes sense
> since InterlockedCompareExchange appears to be implemented using macros
> instead of being served up through kernel32.dll.
>
> So is Win95 still a supported platform?

Heavens no!

> If not, then perhaps InterlockedCompareExchange emulation can simply be
> deleted.

Patch please?

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

Warren DeLano added the comment:

Disabling Python's emulated InterlockedCompareExchange (for Win95 
compatibility) cures the problem, so the underlying question is why the 
existence of InterlockedCompareExchange is not being autodetected on 64 
bit systems -- and that is apparently because GetProcAddress
(kernel,"InterlockedCompareExchange") returns NULL -- which makes sense 
since InterlockedCompareExchange appears to be implemented using macros 
instead of being served up through kernel32.dll.

So is Win95 still a supported platform?  

If not, then perhaps InterlockedCompareExchange emulation can simply be 
deleted.  

If so, then either some other approach needs to be adopted to activate 
emulation, or the emulated code needs to be fixed to behave like the 
native windows functions (which appear to only operate on the lowest 32 
bits).

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

If you can, please submit a patch that fixes all those issues, with
unit tests and doc changes if at all possible. That will make it much
easier to evaluate the ramifications of your proposal(s).

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

re: msg56782

Yes, of course I can explicitly write the BOM. I did realize that after 
my first post ( my-'duh' :-[ ).

But after playing some more, I do think this issue has become a 
worthwhile one. My second post msg56780 asks that utf_8 be tolerant 
of the 3-byte sig BOM, and uf_16_[be]e be tolerant of their BOMs, 
which I argue is consistent with "be liberal on what you accept".

A second half of that message suggests that it might be worth 
considering something like a write_bom parameter with utf_16 
defaulting to True, and utf_16_[bl]e defaulting to False.

My  third post (m56782) may actually represent a bug. I have a 
unittest for this and would be glad to provide (although I need 
to reduuce a larger test to a simple case). I will look at this 
again, and re-pester you as required.

Regards (and thanks for the reply),
..jim

__
Tracker <[EMAIL PROTECTED]>

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

[issue1338] pickling bytes?

[Georg Brandl]

Georg Brandl added the comment:

Having explicit support for sets at least would be consistent with all
other types for which there is a display form.

(Or else, {1,2,3} could be a different thing after unpickling if the set
builtin is overwritten.)

--
nosy: +georg.brandl

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

Warren DeLano added the comment:

Hmm.  Well, for one thing, we're falling back on Python's 
interlocked_cmp_xchg instead of using Windows' 
InterlockedCompareExchange (or should it InterlockCompareExchange64?).  
Python's implementation is clearly assuming 64 bit counters, but the 
other native Windows Interlocked* functions may indeed be operating on 
32 bit counters, hence the mismatch.

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

Jean Brouwers added the comment:

Yes, I will make a small library.  But first, here is another piece of 
evidence.

As I mentioned, using std atexit does not work on 3.0a1.  But 
surprisingly, the destructor function is not called either when 
installed with Py_AtExit on 3.0a1.  On 2.5.1 it is.

There must something in Py_Terminate or Py_Finalize which is different 
in 3.0a1.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1338] pickling bytes?

[Guido van Rossum]

New submission from Guido van Rossum:

Alexandre Vassalotti suggested the following:

A simple way to add specific pickling support for bytes/buffer objects
would be to define two new constants:

 BYTES  = b'\x8c'  # push a bytes object
 BUFFER = b'\x8d'  # push a buffer object

And add the following pickling and unpickling procedures:

 def save_bytes(self, obj, pack=struct.pack):
 n = len(obj)
 self.write(BYTES + pack("

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

Warren DeLano added the comment:

Yes.  Here's what I think the problem is:  InterlockedCompareExchange 
called from EnterNonRecursiveMutex in thread_nt.h:101 seems to returns 
(-1) as 0x instead of 0x.  Still working 
out why though...

__
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

[Georg Brandl]

Georg Brandl added the comment:

You're right, fixed that in r58675.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1247] PEP 3137 patch (repr, names, parser)

[Guido van Rossum]

Guido van Rossum added the comment:

Setting to 'high' everything related to PEP 3137.

--
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue1336] subprocess.Popen hangs when child writes to stderr

[Guido van Rossum]

Guido van Rossum added the comment:

I don't think we can prevent GC from occurring between fork and exec --
it's legal to just call os.fork() and execute Python code in the
subprocess forever.  I think the right solution might be to ignore
errors in file_close().  Can you try to whip up a patch for that and
test it?

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1333] merge urllib and urlparse functionality

[Guido van Rossum]

Guido van Rossum added the comment:

You missed urllib2 I think. :-)

I agree it's a mess.  I'm sure it all started out with backwards
compatibility in mind.  I find myself often importing cgi only to use
the tiny function escape() that is defined there...

I wonder if web-sig wouldn't be a good place to get some kindred spirits
together to redesign these APIs for Py3k?

--
nosy: +gvanrossum

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

Can you step through it with a C/C++ debugger to see where it goes wrong?

--
nosy: +gvanrossum

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

Can you provide a very small shared library that demonstrates this
problem? (E.g. you could start by modifying Modules/xxmodule.c, adding a
'destructor' function.)

--
nosy: +gvanrossum

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

Can't you force a BOM by simply writing \ufffe at the start of the file?

--
nosy: +gvanrossum

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

Please submit a patch for docs and a  unittest...

--
nosy: +gvanrossum

__
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

[Guido van Rossum]

Guido van Rossum added the comment:

If you submit a patch that adds docs and a unit test, your wish will be
fulfilled.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1335] bytesiterator patch

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58674.
I added a change to _abcoll.py to remove the registration of bytes as a
subclass of Iterable.

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

[issue1330] Fix truncate on Windows, this time for real

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58673.

I made one change, hopefully I didn't screw it up: skip the positional
restore if the truncation itself failed.  Otherwise the positional
restore might overwrite the error from the truncation.  After an error
from this function they shouldn't make any assumptions about the
position anyway!

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

[issue1329] Different 3.0a1 exit behavior

[Jean Brouwers]

Jean Brouwers added the comment:

Using atexit() to install the destructor function does not help.  The 
function in not called when 3.0a1 exits, but with 2.5.1 it is.  Same 
behavior on Linux and MacOS X.

Btw, that would mean that any C extension which uses atexit() directly 
may be affected by this issue.

Running python with the debugger shows that 3.0a1 and 2.5.1 both exit 
thru exit() and not _exit().  A breakpoint at _exit is hit, but the call 
originates from exit and not anywhere in the python binary.

There is a new atexitmodule.c in 3.0a1 which did not exits in 2.5.1.  
But that is handling the atexit functionality at the Python level and 
not C.

This man page  mentions that all 
registered atexit functions are removed after a fork+exec.  But 
breakpoints set at fork, fork1, forkpty and vfork are never hit by 
3.0a1.

That is as far as I got.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1311] os.path.exists(os.devnull) regression on windows

[Facundo Batista]

Facundo Batista added the comment:

>>> import os.path
>>> os.path.exists("con")
False
>>> os.path.exists("nul")
False
>>> os.path.exists("prn")
False

This is in Windows 2000 (5.00.2195) sp4, using *both* Python 2.3.5 and
2.5.1, no cygwin.

Personally, I'm +1 with Mark Hammond about this:

I agree it is unfortunate that the behaviour has changed, 
but these special names are broken enough on Windows that 
rely on the kernel32 function and behaves like it says 
seems the sanest thing to do.

Taking in consideration that *now* it behaves equally in different
windows systems, but not before, I think this issue should be closed as
"invalid" (it's not a bug).

I'll wait some days to get more behaviour responses, though.

Regards,

__
Tracker <[EMAIL PROTECTED]>

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

[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

[Eric Sammons]

Eric Sammons added the comment:

I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the
exact same issue.  I have also compared ceval.c from 2.3, the last known
working copy and ceval.c from 2.4+ and found that ceval.c has undergone
some pretty significant changes.

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

Jean Brouwers added the comment:

Sorry, premature submit.  I will try using atexit() and report what 
happens there.

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

Jean Brouwers added the comment:

Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to 
terminate.  With _exit() any functions installed with atexit() or 
on_exit() are *not* called.

That would explain the difference but only if destructor functions are 
installed with atexit() or on_exit().  I do not know whether that.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1337] Tools/msi/msi.py does not work with PCBuild8

[Kevin Watters]

New submission from Kevin Watters:

The msi.py script for creating an Windows MSI installer from a Python
source tree has hardcoded values for "PCBuild." The newer MSVC 2005
build directory is "PCBuild8" and has a slightly different structure.

msi.py needs to be changed to be able to work with a 2005-built Python
tree as well.

--
components: Build
messages: 56791
nosy: kevinwatters
severity: normal
status: open
title: Tools/msi/msi.py does not work with PCBuild8
type: rfe
versions: Python 2.6, 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

[issue1336] subprocess.Popen hangs when child writes to stderr

[Jonathan Amsterdam]

New submission from Jonathan Amsterdam:

This is under Linux (2.6).

I occasionally see subprocess.Popen() fail to return, and I have
finally figured out roughly what's going on. It involves the GC and
stderr.

1. os.fork()

2. Parent blocks reading from errpipe_read (subprocess.py:982)

3. In child, a GC occurs before the exec.

4. The GC attempts to free a file descriptor, calling file_dealloc.

5. That function gets an error closing the descriptor ("close failed:
[Errno 9] Bad file descriptor\n," is the string I extracted via gdb).

6. It attempts to write the error to stderr and blocks. Since it never
execs or writes to errpipe_write, both child and parent are hung.

Here is the pstack output on the child:

#0  0x006587a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0072f11b in __write_nocancel () from /lib/tls/libc.so.6
#2  0x006d409f in _IO_new_file_write () from /lib/tls/libc.so.6
#3  0x006d42ec in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#4  0x006afce9 in buffered_vfprintf () from /lib/tls/libc.so.6
#5  0x006afe8b in vfprintf () from /lib/tls/libc.so.6
#6  0x080dd4af in mywrite ()
#7  0x080dd505 in PySys_WriteStderr ()
#8  0x08064cd0 in file_dealloc ()
#9  0x08079c88 in dict_dealloc ()
#10 0x0808931d in subtype_dealloc ()
#11 0x08079af3 in PyDict_Clear ()
#12 0x0807bb6a in dict_tp_clear ()
#13 0x080e0ead in collect ()
#14 0x080e1912 in _PyObject_GC_New ()
#15 0x0805e50b in PyInstance_NewRaw ()
#16 0x0805e5d7 in PyInstance_New ()
#17 0x0805bdc0 in PyObject_Call ()
#18 0x080aecef in PyEval_CallObjectWithKeywords ()
#19 0x080ca975 in PyErr_NormalizeException ()
#20 0x080b492c in PyEval_EvalFrame ()
#21 0x080b5eb2 in PyEval_EvalCodeEx ()
#22 0x080b3c83 in PyEval_EvalFrame ()
#23 0x080b5734 in PyEval_EvalFrame ()
#24 0x080b5eb2 in PyEval_EvalCodeEx ()
#25 0x080fce92 in function_call ()
#26 0x0805bdc0 in PyObject_Call ()
#27 0x080641e5 in instancemethod_call ()
#28 0x0805bdc0 in PyObject_Call ()
#29 0x0808ffce in slot_tp_init ()
#30 0x08088b3a in type_call ()
#31 0x0805bdc0 in PyObject_Call ()
#32 0x080b0f05 in PyEval_EvalFrame ()
#33 0x080b5eb2 in PyEval_EvalCodeEx ()
#34 0x080fce92 in function_call ()
#35 0x0805bdc0 in PyObject_Call ()
#36 0x080641e5 in instancemethod_call ()
#37 0x0805bdc0 in PyObject_Call ()
#38 0x0808ffce in slot_tp_init ()
#39 0x08088b3a in type_call ()
#40 0x0805bdc0 in PyObject_Call ()
#41 0x080b0f05 in PyEval_EvalFrame ()
#42 0x080b5734 in PyEval_EvalFrame ()
#43 0x080b5eb2 in PyEval_EvalCodeEx ()
#44 0x080fce92 in function_call ()
#45 0x0805bdc0 in PyObject_Call ()
#46 0x080641e5 in instancemethod_call ()
#47 0x0805bdc0 in PyObject_Call ()
#48 0x0808ffce in slot_tp_init ()
#49 0x08088b3a in type_call ()
#50 0x0805bdc0 in PyObject_Call ()
#51 0x080b0f05 in PyEval_EvalFrame ()
#52 0x080b5eb2 in PyEval_EvalCodeEx ()
#53 0x080fce92 in function_call ()
#54 0x0805bdc0 in PyObject_Call ()
#55 0x080b075f in PyEval_EvalFrame ()
#56 0x080b5734 in PyEval_EvalFrame ()
#57 0x080b5734 in PyEval_EvalFrame ()
#58 0x080b5734 in PyEval_EvalFrame ()
#59 0x080b5eb2 in PyEval_EvalCodeEx ()
#60 0x080b3c83 in PyEval_EvalFrame ()
#61 0x080b5734 in PyEval_EvalFrame ()
#62 0x080b5734 in PyEval_EvalFrame ()
#63 0x080b5eb2 in PyEval_EvalCodeEx ()
#64 0x080b3c83 in PyEval_EvalFrame ()
#65 0x080b5eb2 in PyEval_EvalCodeEx ()
#66 0x080b3c83 in PyEval_EvalFrame ()
#67 0x080b5eb2 in PyEval_EvalCodeEx ()
#68 0x080b3c83 in PyEval_EvalFrame ()
#69 0x080b5734 in PyEval_EvalFrame ()
#70 0x080b5734 in PyEval_EvalFrame ()
#71 0x080b5734 in PyEval_EvalFrame ()
#72 0x080b5734 in PyEval_EvalFrame ()
#73 0x080b5734 in PyEval_EvalFrame ()
#74 0x080b5eb2 in PyEval_EvalCodeEx ()
#75 0x080fce92 in function_call ()
#76 0x0805bdc0 in PyObject_Call ()
#77 0x080b075f in PyEval_EvalFrame ()
#78 0x080b5eb2 in PyEval_EvalCodeEx ()
#79 0x080b3c83 in PyEval_EvalFrame ()
#80 0x080b5eb2 in PyEval_EvalCodeEx ()
#81 0x080b3c83 in PyEval_EvalFrame ()
#82 0x080b5eb2 in PyEval_EvalCodeEx ()
#83 0x080b3c83 in PyEval_EvalFrame ()
#84 0x080b5734 in PyEval_EvalFrame ()
#85 0x080b5734 in PyEval_EvalFrame ()
#86 0x080b5eb2 in PyEval_EvalCodeEx ()
#87 0x080b601a in PyEval_EvalCode ()
#88 0x080d9ff4 in PyRun_FileExFlags ()
#89 0x080da8d6 in PyRun_SimpleFileExFlags ()
#90 0x08055617 in Py_Main ()
#91 0x08054e3f in main ()

--
components: Library (Lib)
messages: 56790
nosy: jba
severity: normal
status: open
title: subprocess.Popen hangs when child writes to stderr
type: crash
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue1335] bytesiterator patch

[Christian Heimes]

New submission from Christian Heimes:

Here is the long promised bytes iterator view. It was much, *much*
easier to write it than I have thought. In fact I spent more time fixing
the indention than to modify the code from striterator.

I haven't written an unit test for it. The other iterators don't have
extra tests, too.

>>> iter(bytes(b"abc"))

>>> for i in iter(bytes(b"abc")): print(i)
...
97
98
99
>>> for i in bytes(b"abc"): print(i)
...
97
98
99

--
components: Interpreter Core
files: py3k_bytesiterator.patch
messages: 56789
nosy: gvanrossum, tiran
severity: normal
status: open
title: bytesiterator patch
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8619/py3k_bytesiterator.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/bytesobject.c
===
--- Objects/bytesobject.c	(revision 58663)
+++ Objects/bytesobject.c	(working copy)
@@ -3023,6 +3023,8 @@
 \n\
 If an argument is given it must be an iterable yielding ints in range(256).");
 
+static PyObject *bytes_iter(PyObject *seq);
+
 PyTypeObject PyBytes_Type = {
 PyVarObject_HEAD_INIT(&PyType_Type, 0)
 "bytes",
@@ -3050,7 +3052,7 @@
 0,  /* tp_clear */
 (richcmpfunc)bytes_richcompare, /* tp_richcompare */
 0,  /* tp_weaklistoffset */
-0,  /* tp_iter */
+bytes_iter, /* tp_iter */
 0,  /* tp_iternext */
 bytes_methods,  /* tp_methods */
 0,  /* tp_members */
@@ -3065,3 +3067,121 @@
 PyType_GenericNew,  /* tp_new */
 PyObject_Del,   /* tp_free */
 };
+
+/*** Bytes Iterator /
+
+typedef struct {
+PyObject_HEAD
+Py_ssize_t it_index;
+PyBytesObject *it_seq; /* Set to NULL when iterator is exhausted */
+} bytesiterobject;
+
+static void
+bytesiter_dealloc(bytesiterobject *it)
+{
+_PyObject_GC_UNTRACK(it);
+Py_XDECREF(it->it_seq);
+PyObject_GC_Del(it);
+}
+
+static int
+bytesiter_traverse(bytesiterobject *it, visitproc visit, void *arg)
+{
+Py_VISIT(it->it_seq);
+return 0;
+}
+
+static PyObject *
+bytesiter_next(bytesiterobject *it)
+{
+PyBytesObject *seq;
+PyObject *item;
+
+assert(it != NULL);
+seq = it->it_seq;
+if (seq == NULL)
+return NULL;
+assert(PyBytes_Check(seq));
+
+if (it->it_index < PyBytes_GET_SIZE(seq)) {
+item = PyInt_FromLong(
+(unsigned char)seq->ob_bytes[it->it_index]);
+if (item != NULL)
+++it->it_index;
+return item;
+}
+
+Py_DECREF(seq);
+it->it_seq = NULL;
+return NULL;
+}
+
+static PyObject *
+bytesiter_len(bytesiterobject *it)
+{
+Py_ssize_t len = 0;
+if (it->it_seq)
+len = PyBytes_GET_SIZE(it->it_seq) - it->it_index;
+return PyInt_FromSsize_t(len);
+}
+
+PyDoc_STRVAR(length_hint_doc,
+"Private method returning an estimate of len(list(it)).");
+
+static PyMethodDef bytesiter_methods[] = {
+{"__length_hint__", (PyCFunction)bytesiter_len, METH_NOARGS,
+ length_hint_doc},
+{NULL, NULL} /* sentinel */
+};
+
+PyTypeObject PyBytesIter_Type = {
+PyVarObject_HEAD_INIT(&PyType_Type, 0)
+"bytesiterator",   /* tp_name */
+sizeof(bytesiterobject),   /* tp_basicsize */
+0, /* tp_itemsize */
+/* methods */
+(destructor)bytesiter_dealloc, /* tp_dealloc */
+0, /* tp_print */
+0, /* tp_getattr */
+0, /* tp_setattr */
+0, /* tp_compare */
+0, /* tp_repr */
+0, /* tp_as_number */
+0, /* tp_as_sequence */
+0, /* tp_as_mapping */
+0, /* tp_hash */
+0, /* tp_call */
+0, /* tp_str */
+PyObject_GenericGetAttr,   /* tp_getattro */
+0, /* tp_setattro */
+0, /* tp_as_buffer */
+Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, /* tp_flags */
+0, /* tp_doc */
+(traverseproc)bytesiter_traverse,  /* tp_traverse */
+0, /* tp_clear */
+0, /* tp_richcompare */
+0, /* tp_weaklistoffset */
+PyObject_SelfIter, /* tp_iter */
+(iternextfunc)bytesiter_next,  /* t

[issue1334] IDLE - Fix several highlighting bugs

[Tal Einat]

New submission from Tal Einat:

This patch fixes the following bugs:

* Configured selection highlighting colors were ignored
* Updating highlighting in the config dialog would cause
  non-Python files to be colored as if they were Python source

Additionally, adding and removing of ColorDelegators to the Percolator
was not being done in an organized fashion, causing multiple colorizers
to be present simultaneously in certain cases. This patch ensures that
there will always be at most one colorizer present in the Percolator.

This patch also reduces code duplication by grouping colorization code
into EditorWindow.ResetColorizer, and having __init__ let ResetColorizer
do its thing.

There is one side effect to this patch - applying a new highlighting
scheme or renaming a file causes the screen to "blink". This can be
avoided without too much work, but IMHO is minor enough to leave as it is.

--
components: IDLE
files: IDLE_highlighting.071026.patch
messages: 56788
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Fix several highlighting bugs
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch

__
Tracker <[EMAIL PROTECTED]>

__

IDLE_highlighting.071026.patch
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1333] merge urllib and urlparse functionality

[anatoly techtonik]

New submission from anatoly techtonik:

The purpose is to encapsulate all URL handling functions in one module.
At the moment there are three modules that dissect URLs for various bits
of information. These are urlparse - to split url into components,
urllib - to decode splitted data and cgi - to parse query component.

To outline the API of the proposed module I'll start with urlparse :
http://docs.python.org/lib/module-urlparse.html

1. There are two identical functions - urlparse and urlsplit that make
the same parsing operation, but vary in format of return arguments. They
could be replaced with one - let's call it urlsplitex - that returns
result in a class with attributes - not a subclass of list, but rather
dictionary subclass, because positional arguments are evil and you
always have to look into reference to find out the correct order if you
read or debug the code.

2. Returned class should not be immutable. It must be possible to modify
the results to unset extra parts (like fragments) or edit required parts
as needed and get the target URL via urlunsplitex or embedded method of
the same class. Thus arguments "default_scheme" and "allow_fragments"
will be useless as well as function urldefrag.

3. urlparsex, a replacement for "parsing" function of the new library
should be high-level functions to dissect url information into tree-like
structure with atomic leafs. This includes decoding url entities and
splitting parameters into child structures. The proposed structure of
url class attributes is:

scheme   string
netloc   class
   username  string
   password  string
   serverstring
   port  integer
path list with objects of class
   part  string
   param list with objects of class
   name string
   valuestring
querylist with objects of class
   name  string
   value string
fragment string


4. urlunparsex will be provided to reassemble class back into URL. This
will deprecate series of functions from urllib like quote, unquote,
urlencode and also functions parse_qs and parse_qsl from cgi module.

References:
http://mail.python.org/pipermail/patches/2005-February/016972.html
http://bugs.python.org/issue1722348
http://bugs.python.org/issue1462525

--
components: Library (Lib)
messages: 56787
nosy: techtonik
severity: normal
status: open
title: merge urllib and urlparse functionality
type: rfe
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

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

[Christian Heimes]

Christian Heimes added the comment:

> Can you also use a global variable instead of "/etc"? Something like
> ETC_DIR = "/etc" for example. It would allow you to ship samples from
> several distribution and run unit tests against each.

I've attached the two relevant files from Ubuntu 7.10 Gutsy.

Added file: http://bugs.python.org/file8616/debian_version
Added file: http://bugs.python.org/file8617/lsb-release

__
Tracker <[EMAIL PROTECTED]>

__lenny/sid
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"
___
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:

> I am writing a patch but I have a few questions:
> 
> 1) There are at most three places where the distribution name can be
> found. What is the priority order to select only one name ?
> The three places are:
>   a) Inside the /etc/lsb-release file
>   b) In the name of the /etc/-release file
>   c) In the content of the /etc/-release file

As far as I remember the specs a /etc/*-release file has a higher
priority than /etc/lsb-release.

> 2) Can I remove supported_dists parameter of platform.dist ?
> There could be a list of supported distributions but why
> as a parameter of this function ?

I agree. A module global list is better than a list as a function argument.

Can you also use a global variable instead of "/etc"? Something like
ETC_DIR = "/etc" for example. It would allow you to ship samples from
several distribution and run unit tests against each.

Christian

__
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 am writing a patch but I have a few questions:

1) There are at most three places where the distribution name can be
found. What is the priority order to select only one name ?
The three places are:
  a) Inside the /etc/lsb-release file
  b) In the name of the /etc/-release file
  c) In the content of the /etc/-release file
For instance, on Mandriva 2007.1 the possible names are:
  a) 'MandrivaLinux'
  b) 'mandriva'
  c) 'Mandriva Linux'
I would suggest to put a) first to be compatible with LSB
but on most systems it would change the value returned by
platform.dist after the patch (is it a problem ?).
I would have liked to use c) as second choice but this space
in the name set by Mandriva could be a problem (It's possible
to suppress spaces in the result though).

2) Can I remove supported_dists parameter of platform.dist ?
There could be a list of supported distributions but why
as a parameter of this function ?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1089358] need siginterrupt() on Linux - impossible to do timeouts

[Ralf Schmitt]

Ralf Schmitt added the comment:

PyOS_setsig in pythonrun.c now calls siginterrupt(sig, 1) (in Python
2.4.4/Python 2.5.1, but not in Python 2.3). So you should be able to
timeout the system calls with a signal.alarm call.

However, having siginterrupt available would still be useful.
I have some patches for the signal module and will clean them up in some
days and attach to this bug.

Here's an implementation using ctypes:

def siginterrupt(signum, flag):
"""change restart behavior when a function is interrupted by the 
specified signal. see man siginterrupt.
"""
import ctypes
import sys

if flag:
flag = 1
else:
flag = 0

if sys.platform=='darwin':
libc = ctypes.CDLL("libc.dylib")
elif sys.platform=='linux2':
libc = ctypes.CDLL("libc.so.6")
else:
libc = ctypes.CDLL("libc.so")

if libc.siginterrupt(signum, flag)!=0:
raise OSError("siginterrupt failed")

--
nosy: +schmir

_
Tracker <[EMAIL PROTECTED]>

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