From report at bugs.python.org  Tue Jul  1 00:09:46 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Jun 2008 22:09:46 +0000
Subject: [issue3245] Memory leak on OS X
In-Reply-To: <1214853896.85.0.513571586109.issue3245@psf.upfronthosting.co.za>
Message-ID: <1214863786.49.0.961567988805.issue3245@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I can reproduce this with the Apple-supplied Python, but I'm having 
trouble reproducing it with anything from python.org.  I tried checking 
out revision 54863 and doing

./configure --enable-framework MACOSX_DEPLOYMENT_TARGET=10.3 && make
sudo make altinstall

Then I get:

$ /usr/local/bin/python2.5 -S
Python 2.5.1 (release25-maint:54863, Jun 30 2008, 22:59:07) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

$ leaks Python
Process 84169: 534 nodes malloced for 1029 KB
Process 84169: 0 leaks for 0 total leaked bytes.

So maybe the leak is the result of something that Apple did?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3245>
_______________________________________

From report at bugs.python.org  Tue Jul  1 00:17:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Jun 2008 22:17:54 +0000
Subject: [issue3191] round docstring is inaccurate
In-Reply-To: <1214319817.88.0.0731467937099.issue3191@psf.upfronthosting.co.za>
Message-ID: <1214864274.3.0.86421261282.issue3191@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: georg.brandl -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3191>
_______________________________________

From report at bugs.python.org  Tue Jul  1 00:25:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Jun 2008 22:25:01 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1214864701.12.0.0425241690813.issue3008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm looking forward to your C implementation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul  1 00:39:33 2008
From: report at bugs.python.org (kai zhu)
Date: Mon, 30 Jun 2008 22:39:33 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1214865572.96.0.639860025423.issue3238@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

ideally that may be true.

but its quite frustrating testing/developing new py3k software when many
modules/extensions we take for granted in 2.x isn't available.  in the
meantime, this patch serves as a very convenient stopgap for developers
(even w/ its bugs), for writing py3k migration code in 2.x (& access to
all its extensions)

for example, its a difficult task to port a big project like numpy to
py3k all @ once.  but this patch could allow u to piece-wise transform
it, one script @ a time, to py3k language syntax compliance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Tue Jul  1 00:47:24 2008
From: report at bugs.python.org (Edward Langley)
Date: Mon, 30 Jun 2008 22:47:24 +0000
Subject: [issue3245] Memory leak on OS X
In-Reply-To: <1214853896.85.0.513571586109.issue3245@psf.upfronthosting.co.za>
Message-ID: <1214866044.02.0.300100292038.issue3245@psf.upfronthosting.co.za>


Edward Langley <fiddler.wo.a.roof+python at gmail.com> added the comment:

I think it may be a result of the framework build, I don't have the
problem with either 2.5.2 (debug build) or 2.6b1, both non-framework 
builds.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3245>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:06:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 30 Jun 2008 23:06:54 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1214867214.27.0.183860191075.issue3088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed my changes to threading.local as r64601.

I think we could enable the "Manager" tests again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:11:45 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 30 Jun 2008 23:11:45 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1214867214.27.0.183860191075.issue3088@psf.upfronthosting.co.za>
Message-ID: <66D0DAAE-8346-43BF-9D7A-2667D07333C6@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Alright - I'll do that asap

On Jun 30, 2008, at 7:06 PM, Amaury Forgeot d'Arc <report at bugs.python.org 
 > wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Committed my changes to threading.local as r64601.
>
> I think we could enable the "Manager" tests again.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3088>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:23:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Jun 2008 23:23:18 +0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1214861857.95.0.566473532158.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20806301623g44e7e376l45e20d22aeb7886b@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

That's fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:24:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 30 Jun 2008 23:24:20 +0000
Subject: [issue3245] Memory leak on OS X
In-Reply-To: <1214853896.85.0.513571586109.issue3245@psf.upfronthosting.co.za>
Message-ID: <1214868259.98.0.516419690442.issue3245@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I assume it was fixed then.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed
type: performance -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3245>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:41:36 2008
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 30 Jun 2008 23:41:36 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214869296.96.0.555839076279.issue3242@psf.upfronthosting.co.za>


Brodie Rao <junk at dackz.net> added the comment:

Actually, I've tested this script on another Debian x86 machine and two 
Ubuntu x86 machines, all which exhibit the exact same crash with their 
Python 2.4 distributions. I don't think it's a hardware issue, I think 
there's a legitimate issue here. The crash always originates from 
PyFile_SoftSpace in PyEval_EvalFrameEx.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 01:59:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 30 Jun 2008 23:59:43 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214870383.7.0.418211955864.issue3242@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can you try on later versions of Python. 2.4 is no longer supported.

----------
nosy: +benjamin.peterson
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:10:51 2008
From: report at bugs.python.org (vizcayno)
Date: Tue, 01 Jul 2008 00:10:51 +0000
Subject: [issue3247] dir of an "_sre.SRE_Match" object not working
In-Reply-To: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>
Message-ID: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>


New submission from vizcayno <vizcaynot at gmail.com>:

For Windows XP SP3:

v = 'add 1 to 4.56'
import re
r=re.search("([0-9]+)\D+(\d+\.\d+)","add 1 to 4.56")
r
<_sre.SRE_Match object at 0x00BED920>
r.groups()
('1', '4.56')
dir(r)
[]

in pyhton 2.5 it shows:
['__copy__', '__deepcopy__', 'end', 'expand', 'group', 'groupdict', 'gro
ups', 'span', 'start']

----------
components: Regular Expressions
messages: 69031
nosy: vizcayno
severity: normal
status: open
title: dir of an "_sre.SRE_Match" object not working
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3247>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:26:00 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 01 Jul 2008 00:26:00 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1214871960.42.0.808869719404.issue1754483@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

The patch does not fix the underlying problem which is not limited to
files named '__init__.py'.

----------
nosy: +ndim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:28:22 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 01 Jul 2008 00:28:22 +0000
Subject: [issue1068477] linecache.py::updatecache strips directory info from
	files
Message-ID: <1214872102.02.0.883996401526.issue1068477@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

The following issues appear to be the same bug to me:

   http://bugs.python.org/issue1068477
   http://bugs.python.org/issue1309567
   http://bugs.python.org/issue1754483

and are, as of 2008-06-30, unfixed in both rel25-maint and trunk.

----------
nosy: +ndim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068477>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:28:24 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 01 Jul 2008 00:28:24 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1214872104.92.0.177028929534.issue1309567@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

The following issues appear to be the same bug to me:

   http://bugs.python.org/issue1068477
   http://bugs.python.org/issue1309567
   http://bugs.python.org/issue1754483

and are, as of 2008-06-30, unfixed in both rel25-maint and trunk.

----------
nosy: +ndim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:28:28 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 01 Jul 2008 00:28:28 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1214872108.4.0.837013656295.issue1754483@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

The following issues appear to be the same bug to me:

   http://bugs.python.org/issue1068477
   http://bugs.python.org/issue1309567
   http://bugs.python.org/issue1754483

and are, as of 2008-06-30, unfixed in both rel25-maint and trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:30:07 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 01 Jul 2008 00:30:07 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1214872207.89.0.306558415404.issue1309567@psf.upfronthosting.co.za>


Changes by Hans Ulrich Niedermann <hun at n-dimensional.de>:


----------
components: +Library (Lib) -None
versions: +Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:41:18 2008
From: report at bugs.python.org (Brodie Rao)
Date: Tue, 01 Jul 2008 00:41:18 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214872878.53.0.326105429004.issue3242@psf.upfronthosting.co.za>


Brodie Rao <junk at dackz.net> added the comment:

Using Python 2.5.2 from python.org on Mac OS X 10.5, I get the same 
error:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000ad40
0x0052ed30 in ?? ()
(gdb) bt
#0  0x0052ed30 in ?? ()
#1  0x0002ad41 in frame_dealloc (f=0x61cca0) at 
Objects/frameobject.c:416
#2  0x0002adf2 in frame_dealloc (f=0x61ea10) at 
Objects/frameobject.c:424
#3  0x0002adf2 in frame_dealloc (f=0x61eb70) at 
Objects/frameobject.c:424
#4  0x0004574b in _PyTrash_destroy_chain () at Objects/object.c:2136
#5  0x000aebc2 in PyErr_Clear () at Python/errors.c:231
#6  0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at 
Objects/fileobject.c:2127
#7  0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at 
Python/ceval.c:1608
#8  0x0009f29a in PyEval_EvalCodeEx (co=0x595410, globals=0x52ed20, 
locals=0x52ed20, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#9  0x0009f3a7 in PyEval_EvalCode (co=0x595410, globals=0x52ed20, 
locals=0x52ed20) at Python/ceval.c:494
#10 0x000c31d7 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xbffff0cc, 
start=257, globals=0x52ed20, locals=0x52ed20, closeit=1, 
flags=0xbfffef3c) at Python/pythonrun.c:1273
#11 0x000c3583 in PyRun_SimpleFileExFlags (fp=0xa0125de0, 
filename=0xbffff0cc, closeit=1, flags=0xbfffef3c) at 
Python/pythonrun.c:879
#12 0x000d1d27 in Py_Main (argc=1, argv=0xbfffefb8) at 
Modules/main.c:523
#13 0x00001bcc in _start ()
#14 0x00001af9 in start ()
(gdb) info locals
No symbol table info available.
(gdb) up
#1  0x0002ad41 in frame_dealloc (f=0x61cca0) at 
Objects/frameobject.c:416
416	                Py_CLEAR(*p);
(gdb) info locals
p = (PyObject **) 0x61cdd8
valuestack = (PyObject **) 0x61cde0
co = (PyCodeObject *) 0x61cdd8
f = (PyFrameObject *) 0x61cca0

[...]

(gdb) up
#6  0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at 
Objects/fileobject.c:2127
2127				PyErr_Clear();
(gdb) info locals
v = (PyObject *) 0x0
oldflag = 0
f = (PyObject *) 0x700cb0
(gdb) up
#7  0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at 
Python/ceval.c:1608
1608						PyFile_SoftSpace(w, 0);
(gdb) info locals
stack_pointer = (PyObject **) 0x0
next_instr = (unsigned char *) 0x61e5e0 "?(\r"
opcode = 0
oparg = 7343280
why = 7343280
err = 0
x = (PyObject *) 0x0
v = (PyObject *) 0x700cb0
w = (PyObject *) 0xffffffff
u = (PyObject *) 0x700cb0
t = (PyObject *) 0x0
stream = (PyObject *) 0x0
fastlocals = (PyObject **) 0x61b978
freevars = (PyObject **) 0x61b978
retval = (PyObject *) 0x0
tstate = (PyThreadState *) 0x600170
co = (PyCodeObject *) 0x595410
instr_ub = -1
instr_lb = 0
instr_prev = -1
first_instr = (unsigned char *) 0x704034 "d"
names = (PyObject *) 0x58a4b0
consts = (PyObject *) 0x597ab0

>From what I see on python.org, the advertised policy is to fix bugs 
affecting the stability of the interpreter. I don't know if it's 
relevant to the 2.5 crash, but using Python 2.4.5 from python.org on 
Debian x86 I'm able to get a more detailed backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210747200 (LWP 11771)]
PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, 
args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2571
2571				Py_INCREF(x);
(gdb) bt
#0  PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, 
args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:2571
#1  0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfd9ac, 
kw=0x0) at Objects/funcobject.c:548
#2  0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#3  0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7cfdc60) at Objects/typeobject.c:4607
#4  0x080b69b2 in PyEval_EvalFrame (f=0x81a5b6c) at Python/ceval.c:1957

[with the same stack trace as above continuing...]

#155 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, 
locals=0x0, args=0xb7cfde58, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#156 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfde4c, 
kw=0x0) at Objects/funcobject.c:548
#157 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#158 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7cfdc60) at Objects/typeobject.c:4607
#159 0x080b69b2 in PyEval_EvalFrame (f=0x81a9084) at Python/ceval.c:1957
#160 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, 
locals=0x0, args=0xb7cfde98, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#161 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfde8c, 
kw=0x0) at Objects/funcobject.c:548
#162 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, 
format=0x8115c8b "OO") at Objects/abstract.c:1795
#163 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, 
name=0xb7ce8c78) at Objects/typeobject.c:4607
#164 0x0807e6a9 in PyObject_GetAttrString (v=0xb7cfd9ac, name=0x810748e 
"softspace") at Objects/object.c:1031
#165 0x08064fb1 in PyFile_SoftSpace (f=0xb7cfd9ac, newflag=0) at 
Objects/fileobject.c:1994
#166 0x080b540e in PyEval_EvalFrame (f=0x81a2ac4) at Python/ceval.c:1584
#167 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ce0, globals=0xb7d30824, 
locals=0xb7d30824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2741
#168 0x080b97e9 in PyEval_EvalCode (co=0xb7cf7ce0, globals=0xb7d30824, 
locals=0xb7d30824) at Python/ceval.c:484
#169 0x080dc097 in PyRun_FileExFlags (fp=0x8145008, filename=0xbf9239e3 
"[...]/crash5.py", start=257, globals=0xb7d30824, locals=0xb7d30824, 
closeit=1, flags=0xbf9228f4) at Python/pythonrun.c:1287
#170 0x080dc294 in PyRun_SimpleFileExFlags (fp=0x8145008, 
filename=0xbf9239e3 "[...]/crash5.py", closeit=1, flags=0xbf9228f4) at 
Python/pythonrun.c:871
#171 0x08055bc8 in Py_Main (argc=1, argv=0xbf9229b4) at 
Modules/main.c:493
#172 0x08055052 in main (argc=Cannot access memory at address 0x2
) at Modules/python.c:23

Locals:

(gdb) info locals
i = 0
n = 2
kwdict = (PyObject *) 0x0
f = (PyFrameObject *) 0x81a5ce4
retval = <value optimized out>
fastlocals = (PyObject **) 0x81a5e30
freevars = (PyObject **) 0x81a5e38
tstate = (PyThreadState *) 0x81451b0
x = (PyObject *) 0x0
u = <value optimized out>

I can't reproduce the crash on Linux with Python 2.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 02:46:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 01 Jul 2008 00:46:14 +0000
Subject: [issue3248] ScrolledText can't be placed in a PanedWindow
In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>
Message-ID: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Right now ScrolledText can't be added to a Tkinter.PanedWindow, also
can't be added to a ttk.Notebook (which is not part of the stdlib),
because it is a lacking a proper __str__ method.

Run the following sample code to check how it fails:
import Tkinter
import ScrolledText

paned = Tkinter.PanedWindow()
stext = ScrolledText.ScrolledText(paned)
paned.add(stext)

----------
components: Tkinter
files: scrolledtext_masterstr.diff
keywords: patch
messages: 69037
nosy: gpolo
severity: normal
status: open
title: ScrolledText can't be placed in a PanedWindow
versions: Python 2.6
Added file: http://bugs.python.org/file10787/scrolledtext_masterstr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3248>
_______________________________________

From report at bugs.python.org  Tue Jul  1 03:04:37 2008
From: report at bugs.python.org (Brodie Rao)
Date: Tue, 01 Jul 2008 01:04:37 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214874277.47.0.0686853387415.issue3242@psf.upfronthosting.co.za>


Brodie Rao <junk at dackz.net> added the comment:

Running with Python 2.5.2 with guard malloc on OS X 10.5 produces a 
similar crash to that of Python 2.4 on Linux:

(gdb) set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib
(gdb) run ~/Documents/Code/py-crash/crash5.py
Starting program: /Users/brodie/Downloads/Python-2.5.2/python.exe 
~/Documents/Code/py-crash/crash5.py
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18
Reading symbols for shared libraries +. done
Reading symbols for shared libraries .. done
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or 
Altivec) should work.
GuardMalloc: GuardMalloc version 18

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xb2f79e88
0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at 
Objects/object.c:1126
1126		if (tp->tp_getattro != NULL)
(gdb) info locals
tp = (PyTypeObject *) 0xb2f79e40
v = (PyObject *) 0xb2de7c50
name = (PyObject *) 0xb2de79c0
(gdb) print tp->tp_getattro
Cannot access memory at address 0xb2f79e88
(gdb) bt
#0  0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at 
Objects/object.c:1126
#1  0x00099409 in PyEval_EvalFrameEx (f=0xb31fdeb0, throwflag=0) at 
Python/ceval.c:1990
#2  0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8fc, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#3  0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8f0, 
kw=0x0) at Objects/funcobject.c:517
#4  0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#5  0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#6  0x00099409 in PyEval_EvalFrameEx (f=0xb31fbeb0, throwflag=0) at 
Python/ceval.c:1990
#7  0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8d4, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#8  0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8c8, 
kw=0x0) at Objects/funcobject.c:517
#9  0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#10 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#11 0x00099409 in PyEval_EvalFrameEx (f=0xb31f9eb0, throwflag=0) at 
Python/ceval.c:1990
#12 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee8ac, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#13 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8a0, 
kw=0x0) at Objects/funcobject.c:517
#14 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#15 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#16 0x00099409 in PyEval_EvalFrameEx (f=0xb31f7eb0, throwflag=0) at 
Python/ceval.c:1990
#17 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, 
locals=0x0, args=0xb2dee884, argcount=2, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2836
#18 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee878, 
kw=0x0) at Objects/funcobject.c:517
#19 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at 
Objects/abstract.c:1861
#20 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775

[...]

#1554 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) 
at Objects/abstract.c:1861
#1555 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb2de79c0) at Objects/typeobject.c:4775
#1556 0x00099409 in PyEval_EvalFrameEx (f=0xb2f8beb0, throwflag=0) at 
Python/ceval.c:1990
#1557 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, 
globals=0xb002fd20, locals=0x0, args=0xb2de967c, argcount=2, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836
#1558 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2de9670, 
kw=0x0) at Objects/funcobject.c:517
#1559 0x00008b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) 
at Objects/abstract.c:1861
#1560 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, 
name=0xb060d5c0) at Objects/typeobject.c:4775
#1561 0x00044a66 in PyObject_GetAttrString (v=0xb2de7c50, name=0xed255) 
at Objects/object.c:1069
#1562 0x00023455 in PyFile_SoftSpace (f=0xb2de7c50, newflag=0) at 
Objects/fileobject.c:2125
#1563 0x0009b819 in PyEval_EvalFrameEx (f=0xb2f51ea0, throwflag=0) at 
Python/ceval.c:1608
#1564 0x0009f29a in PyEval_EvalCodeEx (co=0xb0621410, 
globals=0xb002fd20, locals=0xb002fd20, args=0x0, argcount=0, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836
#1565 0x0009f3a7 in PyEval_EvalCode (co=0xb0621410, globals=0xb002fd20, 
locals=0xb002fd20) at Python/ceval.c:494
#1566 0x000c31d7 in PyRun_FileExFlags (fp=0xa0125de0, 
filename=0xbffff06c, start=257, globals=0xb002fd20, locals=0xb002fd20, 
closeit=1, flags=0xbfffeecc) at Python/pythonrun.c:1273
#1567 0x000c3583 in PyRun_SimpleFileExFlags (fp=0xa0125de0, 
filename=0xbffff06c, closeit=1, flags=0xbfffeecc) at 
Python/pythonrun.c:879
#1568 0x000d1d27 in Py_Main (argc=1, argv=0xbfffef54) at 
Modules/main.c:523
#1569 0x00001bcc in _start ()
#1570 0x00001af9 in start ()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 09:55:09 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 01 Jul 2008 07:55:09 +0000
Subject: [issue3099] On windows, "import nul" always succeed
In-Reply-To: <1213319928.58.0.193615390811.issue3099@psf.upfronthosting.co.za>
Message-ID: <1214898908.71.0.0574133612066.issue3099@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

GetFileAttributes() succeeds for "nul", but GetFileAttributesEx() fails.
Maybe is it good idea to use GetFileAttributesEx()?

# test code

import ctypes
import ctypes.wintypes as type

dll = ctypes.windll.kernel32

print dll.GetFileAttributesA("nul") # 32

class WIN32_FILE_ATTRIBUTE_DATA(ctypes.Structure):
	_fields_ = [("dwFileAttributes", type.DWORD),
	            ("ftCreationTime", type.FILETIME),
	            ("ftLastAccessTime", type.FILETIME),
	            ("ftLastWriteTime", type.FILETIME),
	            ("nFileSizeHigh", type.DWORD),
	            ("nFileSizeLow", type.DWORD)]

GetFileExInfoStandard = 0

wfad = WIN32_FILE_ATTRIBUTE_DATA()

print dll.GetFileAttributesExA("nul", GetFileExInfoStandard,
ctypes.byref(wfad)) # 0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3099>
_______________________________________

From report at bugs.python.org  Tue Jul  1 10:59:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Jul 2008 08:59:24 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214902764.84.0.018522379314.issue3242@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduced the problem on windows, and it is indeed a problem with the
"print" statement, when the write() method reassigns sys.stdout: the
code calls PyFile_WriteString(), then PyFile_SoftSpace on the same
object, which has been freed in your case.
A pair of INCREF/DECREF did the trick. See attached patch.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file10788/print.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 11:19:14 2008
From: report at bugs.python.org (Chris Withers)
Date: Tue, 01 Jul 2008 09:19:14 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

The following demonstrates the problem:

>>> from datetime import datetime,timedelta
>>> datetime.now().date()+timedelta(hours=1)
datetime.date(2008, 7, 1)

I'd expect the above to either result in a TypeError or (preferably)
datetime.datetime(2008, 7, 1, 1, 0)

----------
components: Library (Lib)
messages: 69041
nosy: cjw296
severity: normal
status: open
title: bug adding datetime.timedelta to datetime.date
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Tue Jul  1 11:49:00 2008
From: report at bugs.python.org (Chris Withers)
Date: Tue, 01 Jul 2008 09:49:00 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

>>> from datetime import time
>>> time(9,0)-time(8,0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -: 'datetime.time' and
'datetime.time'

I'd expect a datetime.timedelta(0,3600)

----------
components: Library (Lib)
messages: 69042
nosy: cjw296
severity: normal
status: open
title: datetime.time does not support arithmetic
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Tue Jul  1 15:07:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 13:07:14 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1214917634.97.0.403328082352.issue3250@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
type:  -> feature request
versions: +Python 2.7 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Tue Jul  1 15:30:46 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jul 2008 13:30:46 +0000
Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface
Message-ID: <1214919046.04.0.856571887828.issue1613573@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

* use newer 2.0 public interface of httplib for connection handling

Attached patch is for trunk/
Tested for Python 2.5
issue1767370 is a separate issue that can be fixed later

----------
keywords: +patch
nosy: +techtonik
versions: +Python 2.6
Added file: http://bugs.python.org/file10789/issue1613573_xmlrpc_uses_deprecated_api.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613573>
_______________________________________

From report at bugs.python.org  Tue Jul  1 15:41:19 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jul 2008 13:41:19 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1214919679.1.0.370303066042.issue648658@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I will be second to emphasize the importance of using XML-RPC through a
proxy. bzr behind a proxy can't be used with launchpad because of this bug.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Tue Jul  1 15:55:15 2008
From: report at bugs.python.org (Wolfgang Langner)
Date: Tue, 01 Jul 2008 13:55:15 +0000
Subject: [issue3251] references are case insensitive
In-Reply-To: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za>
Message-ID: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za>


New submission from Wolfgang Langner <tds333 at gmail.com>:

References can be added case sensitive as .. _myRef:
but only used case insensitive with :ref:`myref`
usage of :ref:`myRef` doesn't generate a working reference.

Make this behavior consistent please, always case insensitive or always
case sensitive.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 69045
nosy: georg.brandl, tds333
severity: normal
status: open
title: references are case insensitive

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3251>
_______________________________________

From report at bugs.python.org  Tue Jul  1 17:26:15 2008
From: report at bugs.python.org (Tim Peters)
Date: Tue, 01 Jul 2008 15:26:15 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1214925975.77.0.594527466074.issue3249@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

This isn't "a bug", since it's functioning as documented and designed.
Read note 1 in the "date Objects" section of the reference manual,
explaining the meaning of "date2 = date1 + timedelta":

"""
date2 is moved forward in time if timedelta.days > 0, or backward if
timedelta.days < 0. Afterward date2 - date1 == timedelta.days.
timedelta.seconds and timedelta.microseconds are ignored. OverflowError
is raised if date2.year would be smaller than MINYEAR or larger than
MAXYEAR.
"""
).

You could call this a feature request instead, but an incompatible
change to documented always-worked-this-way behavior is unlikely to be
accepted.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Tue Jul  1 17:31:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 15:31:00 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1214926260.99.0.166118346618.issue3249@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Tue Jul  1 17:39:12 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 01 Jul 2008 15:39:12 +0000
Subject: [issue3252] str.tobytes() and bytes/bytearray.tostr()
In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
Message-ID: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

I know it is almost certainly too late, but I think a lot of people will
be confused by str.decode() and bytes.encode() (or was that the other
way around)?

Calling the methods str.tobytes() and bytes.tostr() (or nicer,
str.to_bytes() and bytes.to_str()) would be hard to confuse and IMO will
lead to fewer bug reports and complaints once Python 3.0 final comes out.

And there is a kind of precedent in that threading.isDaemon() became
threading.is_daemon() between 30a5 and 30b1.

----------
components: Interpreter Core
messages: 69047
nosy: mark
severity: normal
status: open
title: str.tobytes() and bytes/bytearray.tostr()
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3252>
_______________________________________

From report at bugs.python.org  Tue Jul  1 17:52:24 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 01 Jul 2008 15:52:24 +0000
Subject: [issue3000] 2to3 doesn't handle print(whatever);
	print nor string.* functions
In-Reply-To: <1212070891.46.0.168640128737.issue3000@psf.upfronthosting.co.za>
Message-ID: <1214927544.73.0.735170780972.issue3000@psf.upfronthosting.co.za>


Changes by Mark Summerfield <mark at qtrac.eu>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3000>
_______________________________________

From report at bugs.python.org  Tue Jul  1 17:54:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 15:54:15 +0000
Subject: [issue3252] str.tobytes() and bytes/bytearray.tostr()
In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
Message-ID: <1214927655.64.0.303479769402.issue3252@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

-1
encoding and decoding is generally accepted terminology. Besides then we
would be binding ourselves to returning bytes or a str; that's not
necessarily guaranteed.

Anyway, I think this hardly has a chance in the place we are (between
betas).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3252>
_______________________________________

From report at bugs.python.org  Tue Jul  1 18:04:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Jul 2008 16:04:04 +0000
Subject: [issue3252] str.tobytes() and bytes/bytearray.tostr()
In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
Message-ID: <1214928244.38.0.427136943491.issue3252@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> encoding and decoding is generally accepted terminology

Yes, but I personally always pause a couple of seconds each time I have
to write "encode" or "decode".
Following Mark's idea, I think I will mentally use "en-bytes" and
"de-bytes" as a mnemonic...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3252>
_______________________________________

From report at bugs.python.org  Tue Jul  1 18:11:33 2008
From: report at bugs.python.org (Brodie Rao)
Date: Tue, 01 Jul 2008 16:11:33 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214928693.05.0.459373533163.issue3242@psf.upfronthosting.co.za>


Brodie Rao <junk at dackz.net> added the comment:

Thanks. The patch fixes the crash for me on Python 2.5.2 and 2.6b1 on OS X 
and Python 2.4.5 on Debian and Ubuntu.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 19:16:01 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 01 Jul 2008 17:16:01 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1214932561.05.0.439601786586.issue3218@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

The change to pytree.py doesn't add much speed benefit over the
fix_imports.py change, and causes a test to fail.

The fix_imports.py change, on the other hand, takes the test suite run
time from 8m31s down to 1m45s -- this needs to go in!

That said, I don't think the change is correct: you remove the portion
of the pattern that matches "from foo import bar, baz, x, y as z", as
well as the portion that matches "foo.bar" in the body of the code,
where foo is a module to be renamed. These should be added back, but
with support for member matching removed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Tue Jul  1 19:17:53 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 01 Jul 2008 17:17:53 +0000
Subject: [issue3252] str.tobytes() and bytes/bytearray.tostr()
In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za>
Message-ID: <1214932673.04.0.0895623396031.issue3252@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

There's nothing new to .encode() and .decode(). They have existed since
Python 1.6.

----------
nosy: +lemburg
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3252>
_______________________________________

From report at bugs.python.org  Tue Jul  1 19:35:09 2008
From: report at bugs.python.org (grissiom)
Date: Tue, 01 Jul 2008 17:35:09 +0000
Subject: [issue3253] shutil.move bahave unexpected in fat32
In-Reply-To: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za>
Message-ID: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za>


New submission from grissiom <chaos.proton at gmail.com>:

Build the environment in a fat32 file system:
$echo test > test_move
$mkdir testmove

If I shutil.move('test_move', 'testmove'), it will raise: 
Traceback (most recent call last):
  File "testmove.py", line 5, in <module>
    shutil.move('test_move', 'test_python')
  File "/usr/lib/python2.5/shutil.py", line 199, in move
    copy2(src,dst)
  File "/usr/lib/python2.5/shutil.py", line 92, in copy2
    copystat(src, dst)
  File "/usr/lib/python2.5/shutil.py", line 69, in copystat
    os.chmod(dst, mode)
OSError: [Errno 1] Operation not permitted: 'test_python/test_move'

If I shutil.move('test_move', 'testmove/testmove'), it will succeed
quietly. This problem doesn't happen in an ext3 file system.

----------
components: Library (Lib)
messages: 69053
nosy: grissiom
severity: normal
status: open
title: shutil.move bahave unexpected in fat32
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3253>
_______________________________________

From report at bugs.python.org  Tue Jul  1 19:47:12 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Tue, 01 Jul 2008 17:47:12 +0000
Subject: [issue3239] curses/textpad.py incorrectly and redundantly imports
	ascii
In-Reply-To: <1214774912.88.0.531536472348.issue3239@psf.upfronthosting.co.za>
Message-ID: <1214934432.84.0.128206887909.issue3239@psf.upfronthosting.co.za>


Georgij Kondratjev <smpuj at bk.ru> added the comment:

>>> import curses.ascii as curses_ascii

If you like curses_ascii you would probably like curses.ascii :) so here
is the patch. I tested it with module built-in testing facility (if
__name__ == '__main__') but didn't run other tests.

Patch with "patch -i curses-textpad-ascii.patch
src/python/Lib/curses/textpad.py"

----------
keywords: +patch
Added file: http://bugs.python.org/file10790/curses-textpad-ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3239>
_______________________________________

From report at bugs.python.org  Tue Jul  1 19:54:28 2008
From: report at bugs.python.org (Nick Edds)
Date: Tue, 01 Jul 2008 17:54:28 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1214934868.33.0.828914413016.issue3218@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Here is a diff for the both the fix_imports changes which I corrected,
and the pytree changes. The pytree changes were a lot more significant
before the fix_imports change, but I think they are still a decent
improvement. I think I have now restored the functionality you wanted
without the members, although I'm not quite sure I made the patterns
exactly right. I tested the from a import b as c, as well as in text
foo.bar references, and they seemed to be corrected properly.

----------
keywords: +patch
Added file: http://bugs.python.org/file10791/fix_imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Tue Jul  1 20:24:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 18:24:24 +0000
Subject: [issue3174] 3.0b1 doesn't seem to install on macs
In-Reply-To: <1214207562.58.0.0463418278377.issue3174@psf.upfronthosting.co.za>
Message-ID: <1214936663.55.0.231628291867.issue3174@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I tried to get it working in r64618.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3174>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:11:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 19:11:01 +0000
Subject: [issue2683] subprocess.Popen.communicate takes bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1214939461.95.0.274001152101.issue2683@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed docs in r64619.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2683>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:18:11 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Tue, 01 Jul 2008 19:18:11 +0000
Subject: [issue2683] subprocess.Popen.communicate takes bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1214939891.01.0.650442764976.issue2683@psf.upfronthosting.co.za>


Rafael Zanella <rafael.zanella at yahoo.com.br> added the comment:

_communicate still encodes the string under the hood

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2683>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:35:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 19:35:30 +0000
Subject: [issue3219] repeated keyword arguments
In-Reply-To: <1214594266.45.0.948323179256.issue3219@psf.upfronthosting.co.za>
Message-ID: <1214940930.71.0.389840405776.issue3219@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Done for 2.6 in r64622. (Georg reviewed.)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3219>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:49:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 19:49:26 +0000
Subject: [issue3174] 3.0b1 doesn't seem to install on macs
In-Reply-To: <1214207562.58.0.0463418278377.issue3174@psf.upfronthosting.co.za>
Message-ID: <1214941766.94.0.140761724813.issue3174@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3174>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:50:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 19:50:19 +0000
Subject: [issue2683] subprocess.Popen.communicate takes bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1214941819.45.0.405443030881.issue2683@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You're right, I fixed that too in r64621.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2683>
_______________________________________

From report at bugs.python.org  Tue Jul  1 21:56:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 19:56:45 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1214942205.05.0.907936774053.issue2775@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r64624.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:00:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:00:23 +0000
Subject: [issue3235] Improve subprocess module usage
In-Reply-To: <1214731574.46.0.694544049658.issue3235@psf.upfronthosting.co.za>
Message-ID: <1214942422.98.0.427015015363.issue3235@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a link to PEP 324 in r64625. The other issues were explained by
Martin; it will be easier to read the subprocess docs in 2.6 where
they're all on one page.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3235>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:06:57 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 01 Jul 2008 20:06:57 +0000
Subject: [issue3240] IDLE environment corrupts string.letters
In-Reply-To: <1214784620.79.0.803163811318.issue3240@psf.upfronthosting.co.za>
Message-ID: <1214942817.95.0.11274740533.issue3240@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

It introduces high characters that cause comparisons to fail under IDLE 
that succeed from the normal python prompt:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>> u'a' in string.letters
True


IDLE 1.2.2      
>>> import string
>>> u'a' in string.letters

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    u'a' in string.letters
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 
52: ordinal not in range(128)

Or am I misunderstanding how the locale works with string comparisons ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3240>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:08:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:08:21 +0000
Subject: [issue3220] Improve Bytes and Byte Array Methods doc
In-Reply-To: <1214596032.47.0.841255812222.issue3220@psf.upfronthosting.co.za>
Message-ID: <1214942901.74.0.13207911303.issue3220@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Lib Ref/Built-in Types/Sequence Types/Bytes and Byte Array Methods
>  
> The following set/frozenset and dict sections repeat (and for dicts,
> expands upon) the constructor interface from the Built-in Functions
> section.  The sequence type sections do not.  There should as least be a
> reference back.  "For the constructor interface, see xxx"

Right -- I need to reorganize that section a bit more, and this is on
the list to do.

> Similarly there is no mention here of the difference between bytes and
> bytearray, as there is below for the difference between set and
> frozenset.  I think there should be here, in this section, even though
> there is back in Built-in Functions.

The difference is mentioned under the "sequence types" heading.

> (Sets/frozenset have the opposite problem in that Built-in Functions
> makes no mention that one is mutable and the other is not.  I also think
> just one word for each should be added there too.)
>  
> "The bytes and bytearray types have an additional class method:
> bytes.fromhex(string) " should be followed by
> "bytearray.fromhex(string)" and
> "This bytes class method returns a bytes object," changed to
> "These class methods return a bytes or bytearray object,"

Agreed.

> I don't think the line 'Example:' is needed.

Yep.

> A thread today on the Py3 lists again brought up the issue that just as
> bytes can be created by either a literal or class call, they could be
> represented on output by either, with possible confusion.
> Guido responded
> > Only if you didn't know that b'' is an alternative to bytes(). The b''
> > notation is so much more compact and so  much more helpful that I
> > really don't want to go back to it. We will somehow have to deal with
> > this through education and documentation.
>  
> I suggest adding at the end:
> "Just as a bytes objects can be constructed either with a literal or a
> class constructor call, they could be represented on output either by a
> literal or class constructor call.  The literal was chosen as being
> shorter, generally more useful, and consistent with how other classes
> are displayed.  Similarly, the display of bytearrays uses the
> corresponding bytes literal.  If you want to see the bytes of either
> class as integers, use tuple.
>  
> >>> a, b = b'abc', bytes((1,2,3))
> >>> a,b
> (b'abc', b'\x01\x02\x03')
> >>> tuple(a), tuple(b)
> ((97, 98, 99), (1, 2, 3))
> >>> c = bytearray(a)
> >>> c, tuple(c)
> (bytearray(b'abc'), (97, 98, 99))
> "

The same section that documents the bytes/bytearray difference also already
mentions this; I've amended it a bit to include the bit about
representation.

Committed changes as r64627.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3220>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:13:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:13:22 +0000
Subject: [issue3217] make text is broken
In-Reply-To: <1214583274.28.0.668624284342.issue3217@psf.upfronthosting.co.za>
Message-ID: <1214943202.82.0.946888951244.issue3217@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed with r64629.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3217>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:15:26 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:15:26 +0000
Subject: [issue3240] IDLE environment corrupts string.letters
In-Reply-To: <1214784620.79.0.803163811318.issue3240@psf.upfronthosting.co.za>
Message-ID: <1214943326.26.0.514976703316.issue3240@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, that wouldn't be different if you had set the locale in your
prompt. In short, ``u'a' in string.letters`` can never work with any
string.letters except the default, English-only one, and therefore is wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3240>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:19:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:19:07 +0000
Subject: [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1214943547.62.0.548240398458.issue3216@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed the Execute parameter in r64630. add_data was already fixed.

Assigning to Martin; if someone is to write usage info, it's got to be him.

----------
assignee: georg.brandl -> loewis
nosy: +loewis
resolution:  -> fixed
title: errors in msilib documentation -> Scarce msilib documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3216>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:34:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:34:40 +0000
Subject: [issue3203] sphinx - table of contents doesn't render correctly (html)
In-Reply-To: <1214426188.21.0.172463487619.issue3203@psf.upfronthosting.co.za>
Message-ID: <1214944480.19.0.37933888907.issue3203@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already on my to-do list. Thanks for raising it as an issue
though, I won't forget it so easily this way :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3203>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:35:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Jul 2008 20:35:23 +0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1214944523.13.0.244067314.issue1682@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, I can't find anything more to fuss about here. :-)

Reclosing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:35:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:35:49 +0000
Subject: [issue3214] Suggest change to glossary explanation:  "Duck Typing"
In-Reply-To: <1214543459.76.0.157400708153.issue3214@psf.upfronthosting.co.za>
Message-ID: <1214944549.52.0.855339021772.issue3214@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Paddy: IMO hasattr() is the "if it quacks like a duck" part of
duck-typing. It e.g. allows testing "hasattr(x, 'write')" to see if it's
a writable file-like object, and doing something else otherwise.

Benjamin: ABCs are not duck-typing since they involve isinstance() anyway.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3214>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:37:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 01 Jul 2008 20:37:44 +0000
Subject: [issue3240] IDLE environment corrupts string.letters
In-Reply-To: <1214784620.79.0.803163811318.issue3240@psf.upfronthosting.co.za>
Message-ID: <1214944664.59.0.830985952725.issue3240@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As Georg says: you shouldn't be mixing Unicode objects and string
objects. It's perfectly valid for string.letters to contain non-ASCII
bytes, and it's no surprise that this fails for you. string.letters
indeed *does* contain only letters.

In any case, testing for letter-ness by using "in string.letters" is not
a good idea, as it involves a linear search. I recommend to use

u"a".isalpha() 

instead

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3240>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:38:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Jul 2008 20:38:28 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1214944708.31.0.641719361345.issue3112@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Potential reviewers, let's make life easier for you:
http://codereview.appspot.com/2448

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:40:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:40:12 +0000
Subject: [issue3191] round docstring is inaccurate
In-Reply-To: <1214319817.88.0.0731467937099.issue3191@psf.upfronthosting.co.za>
Message-ID: <1214944812.69.0.448567279397.issue3191@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r64634.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3191>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:45:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:45:18 +0000
Subject: [issue1523853] 2.4.2 file.read caches EOF state
Message-ID: <1214945118.56.0.462059563265.issue1523853@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added note in r64635.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1523853>
_______________________________________

From report at bugs.python.org  Tue Jul  1 22:50:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 20:50:16 +0000
Subject: [issue1410739] Add notes to the manual about `is` and methods
Message-ID: <1214945416.26.0.41050722839.issue1410739@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reworded a bit and applied as r64638.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1410739>
_______________________________________

From report at bugs.python.org  Tue Jul  1 23:02:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Jul 2008 21:02:23 +0000
Subject: [issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with
	sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214946143.86.0.249141399539.issue3242@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Corrected as r64633 (trunk) and r64639 (release25-maint). version 3.0 is
not affected, and there won't be any more 2.4 release.

Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3242>
_______________________________________

From report at bugs.python.org  Tue Jul  1 23:02:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 21:02:57 +0000
Subject: [issue3251] references are case insensitive
In-Reply-To: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za>
Message-ID: <1214946177.0.0.626926918672.issue3251@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r64642.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3251>
_______________________________________

From report at bugs.python.org  Tue Jul  1 23:09:56 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Jul 2008 21:09:56 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1214946596.83.0.408495948217.issue2351@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Tue Jul  1 23:36:19 2008
From: report at bugs.python.org (cvp)
Date: Tue, 01 Jul 2008 21:36:19 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
Message-ID: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>


New submission from cvp <cperepelitsa at gmail.com>:

After defining my own __eq__ method for a class that judged equality
based on a 'name' variable, imagine my surprise to see this:

In [20]: my_graph.edges[-1].end == my_graph.vertices[-1]
Out [20]: True

In [21]: my_graph.edges[-1].end != my_graph.vertices[-1]
Out [21]: True

...all because I forgot to modify __ne__ as well.

I think __ne__ should be changed to 'not __eq__' for the sake of
consistency.

----------
messages: 69078
nosy: cvp
severity: normal
status: open
title: Suggestion: change default behavior of __ne__
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________

From report at bugs.python.org  Wed Jul  2 00:57:28 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Jul 2008 22:57:28 +0000
Subject: [issue2885] Create the urllib package
In-Reply-To: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
Message-ID: <1214953048.43.0.192093365109.issue2885@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And it looks like the 2.6 docs need to be updated as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2885>
_______________________________________

From report at bugs.python.org  Wed Jul  2 01:11:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 23:11:00 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
Message-ID: <1214953860.88.0.164452470459.issue3254@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, this is documented [1], and it unlikely to ever be changed. 

[1] http://docs.python.org/ref/customization.html

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________

From report at bugs.python.org  Wed Jul  2 01:20:10 2008
From: report at bugs.python.org (cvp)
Date: Tue, 01 Jul 2008 23:20:10 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1214953860.88.0.164452470459.issue3254@psf.upfronthosting.co.za>
Message-ID: <905ab9d60807011620n2454e166j81f64f096b827606@mail.gmail.com>


cvp <cperepelitsa at gmail.com> added the comment:

But why not? Laziness or something? Or "just cuz?"

-Constantine

On Tue, Jul 1, 2008 at 4:11 PM, Benjamin Peterson <report at bugs.python.org>
wrote:

>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Sorry, this is documented [1], and it unlikely to ever be changed.
>
> [1] http://docs.python.org/ref/customization.html
>
> ----------
> nosy: +benjamin.peterson
> resolution:  -> rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3254>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080701/b0934a9f/attachment.txt>

From report at bugs.python.org  Wed Jul  2 01:20:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Jul 2008 23:20:58 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <905ab9d60807011620n2454e166j81f64f096b827606@mail.gmail.com>
Message-ID: <1afaf6160807011620n32e81b56qd4160b9a316c5505@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

1) It's much more flexible.
2) It would break compatibility.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________

From report at bugs.python.org  Wed Jul  2 02:33:56 2008
From: report at bugs.python.org (cvp)
Date: Wed, 02 Jul 2008 00:33:56 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1afaf6160807011620n32e81b56qd4160b9a316c5505@mail.gmail.com>
Message-ID: <905ab9d60807011733n6d7444a9n9809fd3fa21b6ec2@mail.gmail.com>


cvp <cperepelitsa at gmail.com> added the comment:

1) I didn't say that the option to edit __ne__ should be removed, only that
it'd be both more consistent and convenient to change the meaning to
something relative by default.

2) So long as the old code defines __ne__, which I'm guessing is the code
that you're telling me will break, I still don't see how this will cause any
issues whatsoever. I mean, I guess it could mess up some people who were
using '!=' to be *intentionally* synonymous with 'is not', but that's
awfully contrived for a language that's supposed to be well-known for being
straight-forward and easily readable.

-Constantine

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080702/1500bfbe/attachment.txt>

From report at bugs.python.org  Wed Jul  2 02:34:54 2008
From: report at bugs.python.org (cvp)
Date: Wed, 02 Jul 2008 00:34:54 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
Message-ID: <1214958894.0.0.768160246066.issue3254@psf.upfronthosting.co.za>


Changes by cvp <cperepelitsa at gmail.com>:


Removed file: http://bugs.python.org/file10792/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________

From report at bugs.python.org  Wed Jul  2 02:34:58 2008
From: report at bugs.python.org (cvp)
Date: Wed, 02 Jul 2008 00:34:58 +0000
Subject: [issue3254] Suggestion: change default behavior of __ne__
In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za>
Message-ID: <1214958898.08.0.0771997246947.issue3254@psf.upfronthosting.co.za>


Changes by cvp <cperepelitsa at gmail.com>:


Removed file: http://bugs.python.org/file10793/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3254>
_______________________________________

From report at bugs.python.org  Wed Jul  2 03:50:51 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 02 Jul 2008 01:50:51 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1214963451.74.0.28329155565.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file9907/issue2275.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  2 03:51:43 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 02 Jul 2008 01:51:43 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1214963503.23.0.632419085464.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Issue applicable to Py2.6 and Py3K. Previous patch attached was wrong.
Removed it.

----------
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  2 07:27:13 2008
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 02 Jul 2008 05:27:13 +0000
Subject: [issue3214] Suggest change to glossary explanation:  "Duck Typing"
In-Reply-To: <1214543459.76.0.157400708153.issue3214@psf.upfronthosting.co.za>
Message-ID: <1214976432.91.0.297441007011.issue3214@psf.upfronthosting.co.za>


Paddy McCarthy <paddy3118 at users.sourceforge.net> added the comment:

Hi Georg,
A bit of relevant background about me: 
  I've been interested in Duck Typing _specifically_ for a couple of
years when I started watching edits to it on Wikipedia. I researched the
history of the use of the term and changed the attribution of first use
to Alex Martelli after digging in Google, and still trawl reading code
and articles on the subject. But I DONT think this makes me an expert -
Duck typing is a 'mould-able' term and the things we write about it help
to define it.

On your comment about hasattr:
  I think more and more that Duck-Typing is what allows us, (as in
Python), to substitute one class for another in a method previously
designed with only the other in mind - you know, as in the canonical
example of file-like objects such as StringIO substituting in methods
defined originally for files. In this case hasattr checks don't add
anything, and EAFP is all important.

I tried to get wider context on this by posting it originally to
comp.lang.python but no one was interested. I don't normally frequent
the developers forumbut maybe we should open the issue to that audience?

- Paddy.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3214>
_______________________________________

From report at bugs.python.org  Wed Jul  2 08:51:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jul 2008 06:51:31 +0000
Subject: [issue3214] Suggest change to glossary explanation:  "Duck Typing"
In-Reply-To: <1214543459.76.0.157400708153.issue3214@psf.upfronthosting.co.za>
Message-ID: <1214981491.82.0.0372127312917.issue3214@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

While we are at it, should we keep this one as is?

? Python3000
    A mythical python release, not required to be backward compatible,
with telepathic interface. ?

Not so mythical after all... missing the telepathic interface though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3214>
_______________________________________

From report at bugs.python.org  Wed Jul  2 10:43:13 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 02 Jul 2008 08:43:13 +0000
Subject: [issue3255] [proposal] alternative for re.sub
In-Reply-To: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za>
Message-ID: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

I often do same mistake again and again. Most of re module's method
takes optional argument "flags" like this.

finditer( pattern, string[, flags]) 

But, sub() takes optional argument "count" not "flags".

sub( pattern, repl, string[, count]) 

So, when I write this code, it doesn't behave like what I want.

re.sub("<[^>]+>", "", content, re.S)

I think it would be nice if the method which takes optional argument
"flags" and do same behavior with re.compile(pattern[, flags]).sub(repl,
string). Thank you.

----------
components: Regular Expressions
messages: 69087
nosy: ocean-city
severity: normal
status: open
title: [proposal] alternative for re.sub
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3255>
_______________________________________

From report at bugs.python.org  Wed Jul  2 15:10:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 02 Jul 2008 13:10:22 +0000
Subject: [issue3190] Pydoc should ignore __package__ attributes
In-Reply-To: <1214309924.87.0.972230589947.issue3190@psf.upfronthosting.co.za>
Message-ID: <1215004222.48.0.967805125513.issue3190@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed for 2.6b2 in rev 64656 (will be ported to Py3k as part of the
normal merge process)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3190>
_______________________________________

From report at bugs.python.org  Wed Jul  2 15:26:33 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 02 Jul 2008 13:26:33 +0000
Subject: [issue678464] Docs don't define sequence-ness very well
Message-ID: <1215005192.63.0.907927969528.issue678464@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

(Sorry for the delay responding.  Gmail thought Facundo's response was
spam. :-/)  In defense of my bug report, note that I submitted it in
January 2003!  It's quite possible that the docs have improved in this
regard since then.

If you think the docs are up-to-date in this regard now (I have no time
to do a careful investigation) please close the ticket.

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678464>
_______________________________________

From report at bugs.python.org  Wed Jul  2 15:32:19 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 02 Jul 2008 13:32:19 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

Multiprocessing docs contain examples, that are not valid py3k code,
mostly because of print used as a statement. Example (taken from
multiprocessing.rst):

from multiprocessing import Process

def f(name):
    print 'hello', name

if __name__ == '__main__':
    p = Process(target=f, args=('bob',))
    p.start()
    p.join()

If no one is working on this already, than I'll start fixing this and
will present a patch in 2 or 3 days.

----------
assignee: georg.brandl
components: Documentation
messages: 69090
nosy: georg.brandl, jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing docs are not 3.0-ready
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul  2 15:42:33 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 13:42:33 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215006153.12.0.89098236246.issue3256@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

If you're willing to make the patch - I can review and submit. I 
appreciate it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul  2 15:42:37 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 02 Jul 2008 13:42:37 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1215006157.42.0.14236422487.issue3173@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Good question.  I don't claim that the strftime.c I found is complete
for our needs, only that we can avoid the "rewrite strftime from
scratch" problem Guido indicated.

S

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:10:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jul 2008 14:10:31 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215007831.41.0.541949387492.issue3256@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: georg.brandl -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:29:38 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 02 Jul 2008 14:29:38 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1215008978.92.0.237247186673.issue648658@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:31:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jul 2008 14:31:10 +0000
Subject: [issue678464] Docs don't define sequence-ness very well
Message-ID: <1215009070.81.0.39958778182.issue678464@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think the glossary now has some good definitions of iterable and
sequence, so we can close this. (after 5 years!)

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678464>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:32:37 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Jul 2008 14:32:37 +0000
Subject: [issue2195] urlparse() does not handle URLs with port numbers properly
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1215009157.4.0.956798603405.issue2195@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Duplicate of the #754016 one.

----------
nosy: +facundobatista
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:40:57 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Jul 2008 14:40:57 +0000
Subject: [issue754016] urlparse goes wrong with IP:port without scheme
Message-ID: <1215009657.46.0.910487914323.issue754016@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I think this last patch is ok, but the third case that was raised in the
web-sig should be addressed:

"""
There's even a 3rd case: HTTP's Request-URI. For example, '//path' must
be treated as an abs_path consisting of two path_segments ['', 'path'],
not a net_loc, since the Request_URI must be one of ("*" | absoluteURI |
abs_path | authority).
"""

Please, address this new detail, and I'd commit this. Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue754016>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:42:19 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 02 Jul 2008 14:42:19 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215009739.49.0.790361583328.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Suggestion from GvR (one I like): instead of re-using Py_None, add a new
C function that is stored in the tp_hash slot as a sentinel instead of
the Py_None value used in the posted version of the patch. This will
avoid breaking code that just checks for NULL before calling the tp_hash
slot directly, while still allowing typeobject.c to detect that the
object isn't actually hashable despite the presence of a non-NULL value
in the tp_hash slot.

(I'll keep the None at the Python level though, since that matches the
Py3k behaviour and plays nicely with collections.Hashable)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:42:44 2008
From: report at bugs.python.org (fgoujeon)
Date: Wed, 02 Jul 2008 14:42:44 +0000
Subject: [issue3257] "#define socklen_t int" in pyconfig.h
In-Reply-To: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>
Message-ID: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>


New submission from fgoujeon <flog2 at wanadoo.fr>:

Hello all,

I'm using MinGW 4.2.1 and was unable to compile my code when including
pyconfig.h.

The culpables are these lines (from line 428):

/* Define to `int' if <sys/types.h> doesn't define.  */
#if 1 //_MSC_VER + 0 >= 1300
/* VC.NET typedefs socklen_t in ws2tcpip.h. */
#else
#define socklen_t int
#endif

MinGW (at least the version I use) typedefs socklen_t too, in ws2tcpip.h
(at line 272):
typedef int socklen_t;

When the #define takes effect, code becomes:
typedef socklen_t socklen_t;

...which leads to a compile error (really hard to understand):
C:/MinGW/include/ws2tcpip.h:272: error: multiple types in one declaration


I hope these details will be useful for you. I'm available for another
questions.

Thanks!

----------
components: Library (Lib)
messages: 69097
nosy: fgoujeon
severity: normal
status: open
title: "#define socklen_t int" in pyconfig.h
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3257>
_______________________________________

From report at bugs.python.org  Wed Jul  2 16:46:23 2008
From: report at bugs.python.org (fgoujeon)
Date: Wed, 02 Jul 2008 14:46:23 +0000
Subject: [issue3257] "#define socklen_t int" in pyconfig.h
In-Reply-To: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>
Message-ID: <1215009982.97.0.903095637562.issue3257@psf.upfronthosting.co.za>


fgoujeon <flog2 at wanadoo.fr> added the comment:

Erratum:

The culpables are these lines (from line 428):
/* Define to `int' if <sys/types.h> doesn't define.  */
#if _MSC_VER + 0 >= 1300
/* VC.NET typedefs socklen_t in ws2tcpip.h. */
#else
#define socklen_t int
#endif


Sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3257>
_______________________________________

From report at bugs.python.org  Wed Jul  2 17:00:41 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Jul 2008 15:00:41 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1215010840.76.0.788620148864.issue600362@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Hi Senthil, some details:

- You should not withdraw the parse_qsl from cgi.rst (btw, why didn't
you extracted also the parse_qs one?), but put a Deprecation message,
saying that the user should use it from the urlparse module.

- In cgi.py, in the added message "parse query string functions called
from urlparse", you should say that this is for backward compatibility
reasons.

- You defined an "unquote" function in urlparse.py. Isn't this function
the same that already exists in urllib? Why can't you just use that one?

Thank you!!

----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Wed Jul  2 17:09:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 15:09:35 +0000
Subject: [issue3257] "#define socklen_t int" in pyconfig.h
In-Reply-To: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za>
Message-ID: <1215011375.68.0.607017828415.issue3257@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This block is only to support the older VC6 compiler. Since your
installation was most certainly compiled with VS7, your change is correct.

(or better, something like:
   #if !defined(_MSC_VER) || _MSC_VER + 0 >= 1300
)

The trunk version (future 2.6) was already fixed with r64214: the
"#define socklen_t int" was moved to socketmodule.h, which is not
included in python.h.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3257>
_______________________________________

From report at bugs.python.org  Wed Jul  2 17:15:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 15:15:25 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215011725.28.0.496720023999.issue2235@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't like the changes in listobject.c and dictobject.c: they seem to
imply that all unhashable types must be modified when upgrading to 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:28:05 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 02 Jul 2008 16:28:05 +0000
Subject: [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

The following code raises an Assertion Failure under debug in r64518
running on Windows XP SP2:

<code>
import ctypes

class X (ctypes.Structure): pass

ctypes.POINTER (X)
</code>

Assertion failed: PyErr_Occurred(), file ..\Modules\_ctypes\_ctypes.c,
line 309

----------
assignee: theller
components: ctypes
messages: 69102
nosy: theller, tim.golden
severity: normal
status: open
title: ctypes assertion failure in trunk
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:29:25 2008
From: report at bugs.python.org (Tim Golden)
Date: Wed, 02 Jul 2008 16:29:25 +0000
Subject: [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1215016165.91.0.329820740681.issue3258@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

The comment just before _ctypes.c:309 indicates that when a NULL is
returned at that point, an error condition should already obtain.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:48:52 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 16:48:52 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215017332.21.0.348517849176.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Tests are back on as of r64663 on trunk.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:48:35 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 16:48:35 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1215017315.36.0.789911996581.issue3125@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I closed the wrong bug

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3125>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:53:47 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Jul 2008 16:53:47 +0000
Subject: [issue449227] rlcompleter add "(" to callables feature
Message-ID: <1215017627.37.0.331804233448.issue449227@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Fixed in 64664.

Thank you everybody!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue449227>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:53:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 16:53:51 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215017631.05.0.469882269761.issue3088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Not sure that all problems reported here are resolved.
For example, "test_get (__main__.WithProcessesTestQueue)" does not seem
to use threading.local at all.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 18:46:59 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 16:46:59 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1215017218.95.0.278908340618.issue3125@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Tests are back on as of r64663 on trunk.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3125>
_______________________________________

From report at bugs.python.org  Wed Jul  2 19:31:14 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 02 Jul 2008 17:31:14 +0000
Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__
Message-ID: <1215019874.42.0.734990029091.issue1690840@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690840>
_______________________________________

From report at bugs.python.org  Wed Jul  2 19:54:45 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 02 Jul 2008 17:54:45 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215021284.94.0.904770898727.issue3088@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Still hangs for me on revision 64665

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 20:01:53 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 18:01:53 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215021713.55.0.782115067373.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Miki where does it hang? I've run it in a tight loop for over 500 
iterations without a single hang.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 21:39:23 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Wed, 02 Jul 2008 19:39:23 +0000
Subject: [issue3235] Improve subprocess module usage
In-Reply-To: <1214731574.46.0.694544049658.issue3235@psf.upfronthosting.co.za>
Message-ID: <1215027563.1.0.683071642272.issue3235@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

Georg, but would you please improve the docs explaining what communicate
really does? The syntax is nice but I don't see how can I use poll()
described in the same above to use that. Providing Examples section
would be the best. Of course I don't mind if the examples come from Doug
Hellman or not, as mentioned in msg68956. ;-) Or how about placing a
link to that page
(http://blog.doughellmann.com/2007/07/pymotw-subprocess.html)?

Please reopen unless better docs are available. I don't care about 2.6
either, sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3235>
_______________________________________

From report at bugs.python.org  Wed Jul  2 21:49:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 19:49:43 +0000
Subject: [issue2046] patch to fix_import: UserDict -> collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1215028183.1.0.881297211157.issue2046@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
superseder:  -> Write UserDict fixer for 2to3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
_______________________________________

From report at bugs.python.org  Wed Jul  2 21:50:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 19:50:24 +0000
Subject: [issue2046] patch to fix_import: UserDict -> collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1215028224.69.0.687562794983.issue2046@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
superseder: Write UserDict fixer for 2to3 -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
_______________________________________

From report at bugs.python.org  Wed Jul  2 21:50:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 19:50:45 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1215028245.76.0.0763435683682.issue2876@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

There is a possible patch in issue2046.

----------
superseder:  -> patch to fix_import: UserDict -> collections

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Wed Jul  2 21:54:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 19:54:08 +0000
Subject: [issue3259] fix_imports needs to be using the 'as' keyword
In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
Message-ID: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you run ``echo "import commands" | ./2to3 -f imports -``, you end up
with ``import subprocess``. That's bad as the code in the module works
off of 'commands'. The fix really should be ``import subprocess as
commands``.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69113
nosy: brett.cannon, collinwinter
priority: critical
severity: normal
status: open
title: fix_imports needs to be using the 'as' keyword

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3259>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:02:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 20:02:15 +0000
Subject: [issue3260] fix_imports does not handle intra-package renames
In-Reply-To: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za>
Message-ID: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

``from test import test_support`` should lead to ``from test import
support as test_support``. Also does not work for ``from
test.test_support import Error``.

There is also no good way to handle ``import test.test_support`` since
``import test.test_support as test.support`` is an error. Perhaps
``import test.support; test.test_support = support``?

At the moment test.support is the only rename like this, so it is not
critical that this be fixed immediately as probably few people use the
module outside of the stdlib.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69114
nosy: brett.cannon, collinwinter
priority: high
severity: normal
status: open
title: fix_imports does not handle intra-package renames
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3260>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:06:54 2008
From: report at bugs.python.org (Leonardo Soto)
Date: Wed, 02 Jul 2008 20:06:54 +0000
Subject: [issue3261] Lib/test/test_cookielib declares utf-8 encoding,
	but contains non-valid bytes
In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
Message-ID: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>


New submission from Leonardo Soto <leo.soto at gmail.com>:

http://svn.python.org/projects/python/branches/release25-maint/Lib/test/test_cookielib.py
contains non-utf8 bytes.

Currently, That confuses Jython.

----------
messages: 69115
nosy: leosoto
severity: normal
status: open
title: Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:26:39 2008
From: report at bugs.python.org (Collin Winter)
Date: Wed, 02 Jul 2008 20:26:39 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215030399.8.0.587000225092.issue3238@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I don't know why this is assigned to me.

----------
assignee: collinwinter -> 
components: +None -2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:43:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 20:43:51 +0000
Subject: [issue3247] dir of an "_sre.SRE_Match" object not working
In-Reply-To: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>
Message-ID: <1215031431.35.0.407724613231.issue3247@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The cause is that this object use a custom tp_getattr slot, and use
Py_FindMethod from there. and py3k removed the special "__methods__"
lookup that allowed to lists these items.

Of course, nowadays the way to add methods is not to put them in
tp_getattr, but in a tp_methods slot.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3247>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:43:53 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Wed, 02 Jul 2008 20:43:53 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1215031433.43.0.601447838555.issue3119@psf.upfronthosting.co.za>


Aaron Gallagher <habnabit at gmail.com> added the comment:

Ah, I didn't know that a list would be as fast for appending and popping. 
I knew that lists were optimized for .append() and .pop(), but I didn't 
know that a list would be just as fast as a deque if it was just used as a 
stack.

And I'll be happy to write unit tests if it can be pointed out to me how 
exactly they can be written. Should it just test to make sure pickling a 
deeply nested object hierarchy can be pickled without raising a 
RuntimeError? I tried to make this as transparent as possible of a change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:48:15 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 20:48:15 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215031695.55.0.64657497765.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The g4 buildbot still isn't happy, either.  See:

http://www.python.org/dev/buildbot/trunk.stable/g4%20osx.4%20trunk/builds/
3645/step-test/0

(This was a run of revision 64663, I think.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:51:31 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 20:51:31 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215031891.57.0.987939731494.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

The G4 buildbot is green right now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 22:57:11 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 20:57:11 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215032231.05.0.760911161008.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Looking through the buildbot's history (OSX G4) I can see it hung *prior* 
and after the change to turn the manager tests back on, so it's unrelated 
to those tests. I'll reopen this bug.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:00:30 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 21:00:30 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215032430.13.0.374226876761.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The G4 buildbot is green right now.

Sure.  But it looks like test_multiprocessing hung on build 3645, which 
as far as I can tell included all the recent fixes.

My machine's behaving the same way:  when doing 'make test', sometimes 
test_multiprocessing passes, sometimes (about half the time, maybe a 
little less) it hangs.  Unfortunately, when running test_multiprocessing 
by itself it hardly ever hangs;  and when running it under regrtest.py 
with verbose output it doesn't hang either, so it's a little difficult 
to figure out where things are going wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:02:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 21:02:02 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215032522.15.0.345694212921.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

What platform mark?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:05:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 21:05:29 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215032729.56.0.689839091414.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an interesting snippet from the my most recent attempt to run 
'make test'.  I got a failed assertion:

[...]
test_multibytecodec_support
test_multifile
test_multiprocessing
Assertion failed: (bp != NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 746.
make: *** [test] Abort trap
./python.exe -E -tt ./Lib/test/regrtest.py -l 
test_grammar
test_opcodes
[...]

This is again on OS X 10.5.3;  I built with:

LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include ./configure --
with-pydebug && make

(the /opt/local stuff is there because that's where my readline library 
is...)

Python 2.6b1+ (trunk:64671, Jul  2 2008, 21:51:37) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:07:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 21:07:12 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215032832.44.0.0749299703366.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What platform mark?

OS X 10.5.4/Intel Core 2 Duo.  (It's a 2007 Macbook Pro.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:10:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jul 2008 21:10:04 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1215031433.43.0.601447838555.issue3119@psf.upfronthosting.co.za>
Message-ID: <1215032998.5989.17.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

Le mercredi 02 juillet 2008 ? 20:43 +0000, Aaron Gallagher a ?crit :
> Aaron Gallagher <habnabit at gmail.com> added the comment:
> 
> Ah, I didn't know that a list would be as fast for appending and popping. 
> I knew that lists were optimized for .append() and .pop(), but I didn't 
> know that a list would be just as fast as a deque if it was just used as a 
> stack.

If you have a few minutes to spare, the best would be to measure the
speed of both possibilities, and opt for the fastest. 

> And I'll be happy to write unit tests if it can be pointed out to me how 
> exactly they can be written. Should it just test to make sure pickling a 
> deeply nested object hierarchy can be pickled without raising a 
> RuntimeError?

Yes, exactly. Just create a very deeply nested object (a list should be
sufficient I suppose), pickle it, unpickle it, and check that the result
is equal to the original. No need to do more. Don't bother catching the
eventual RuntimeError, if it is raised the test will be failed anyway.

Since your patch only regards the pickle module (not cPickle) I suppose
the test could go directly into Lib/test/test_pickle.py.

(oh and don't forget to check the test case fails without your
patch :-))

Thanks !

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:11:06 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 21:11:06 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215033066.09.0.0270776422671.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks. I'm a been mystified why it hanging on you - I'm on a 2008 Macbook 
Pro running latest 10.5.4. I'm still trying to get it to hang though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:18:15 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 21:18:15 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215033495.42.0.345128183531.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Mark, can you try commenting out _TestCondition and seeing if you can 
still get it to hang?;

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:43:24 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 02 Jul 2008 21:43:24 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215035004.48.0.298049377685.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unhashable types that implement an "I'm not hashable" __hash__ method
will indeed require modification in 2.6 in order to avoid incorrectly
passing an "isinstance(obj, collections.Hashable)" check (note that
several of the mutable standard library types such as collections.deque
are incorrectly detected as hashable in the current SVN trunk).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:44:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 21:44:09 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215035049.24.0.0836249156916.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Mark, can you try commenting out _TestCondition and seeing if you can 
> still get it to hang?;

I removed the _TestCondition class entirely from test_multiprocessing, 
and did make test again.  It didn't hang! :-)  It crashed instead.  :-(
 
The output's below, in all its gory glory.  I can't make head or tail or 
it, but maybe someone else can.  The last two runs before this gave me a 
Segmentation fault.

test_multiprocessing
Debug memory block at address p=0x2ecd928:
Debug memory block at address p=0x2ecd928:
    49 bytes originally requested
    49 bytes originally requested
    The 4 pad bytes at p-4 are     The 4 pad bytes at p-4 are 
FORBIDDENBYTE, as expected.
FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x2ecd959 are     The 4 pad bytes at 
tail=0x2ecd959 are not all FORBIDDENBYTE (0xfb):
not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x7d        at tail+0: 0x7d *** OUCH *** OUCH

        at tail+1: 0x74        at tail+1: 0x74 *** OUCH *** OUCH

        at tail+2: 0x71        at tail+2: 0x71 *** OUCH *** OUCH

        at tail+3: 0x02        at tail+3: 0x02 *** OUCH *** OUCH

    The block was made by call #782281511 to debug malloc/realloc.
    The block was made by call #782281511 to debug malloc/realloc.
    Data at p:    Data at p: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 ... ... 87 87 71 71 02 02 2e 2e 00 00 1c 1c 02 02 85 85

Fatal Python error: bad trailing pad byte
Fatal Python error: bad trailing pad byte
make: *** [test] Abort trap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:50:14 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 02 Jul 2008 21:50:14 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215035414.45.0.18282967768.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

That output exceeds my knowledge of python internals by several light 
years. :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul  2 23:54:19 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 21:54:19 +0000
Subject: [issue3261] Lib/test/test_cookielib declares utf-8 encoding,
	but contains non-valid bytes
In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
Message-ID: <1215035659.02.0.849269299786.issue3261@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, r64673 was a failed attempt at fixing this by blindly changing the
file over to UTF-8. But r64677 reverted the previous commit and just
changed the encoding specification for the file.

I am not backporting to 2.5 and forward-porting to 3.0.

----------
nosy: +brett.cannon
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:00:45 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 02 Jul 2008 22:00:45 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1215035049.24.0.0836249156916.issue3088@psf.upfronthosting.co.za>
Message-ID: <aac2c7cb0807021500r3e3bee50geca2315440037060@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

On Wed, Jul 2, 2008 at 3:44 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> Mark, can you try commenting out _TestCondition and seeing if you can
>> still get it to hang?;
>
> I removed the _TestCondition class entirely from test_multiprocessing,
> and did make test again.  It didn't hang! :-)  It crashed instead.  :-(

Try running "ulimit -c unlimited" in the shell before running the test
(from the same shell).  After it aborts it should dump a core file,
which you can then inspect using "gdb ./python core", to which "bt"
will give you a stack trace ("backtrace").

On a minor note, I'd suggest running "./python -m test.regrtest"
explicitly, rather than "make test".  The latter runs the test suite
twice, deleting all .pyc files before the first run, to detect
problems in their creation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:07:50 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 02 Jul 2008 22:07:50 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

re.split doesn't split a string when the regex matches a zero characters.

For example:

re.split(r'\b', 'a b') returns ['a b'] instead of ['', 'a', ' ', 'b', ''].

re.split(r'(?<!\w)(?=\w)', 'a b') returns ['a b'] instead of ['', 'a ',
'b'].

----------
components: Regular Expressions
messages: 69134
nosy: mrabarnett
severity: normal
status: open
title: re.split doesn't split with zero-width regex
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:09:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jul 2008 22:09:55 +0000
Subject: [issue3261] Lib/test/test_cookielib declares utf-8 encoding,
	but contains non-valid bytes
In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
Message-ID: <1215036595.2.0.824841482553.issue3261@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Backported to 2.5 in r64680 and blocked/merged in 3.0 (which had no
issues) in r64678 and r64679.

----------
assignee:  -> brett.cannon
status: pending -> closed
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:30:27 2008
From: report at bugs.python.org (Leonardo Soto)
Date: Wed, 02 Jul 2008 22:30:27 +0000
Subject: [issue3261] Lib/test/test_cookielib declares utf-8 encoding,
	but contains non-valid bytes
In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za>
Message-ID: <1215037827.57.0.773875875282.issue3261@psf.upfronthosting.co.za>


Leonardo Soto <leo.soto at gmail.com> added the comment:

Thanks, that was fast!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:32:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 22:32:06 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215037926.23.0.575758156055.issue2235@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't that a serious compatibility issue? 2.5 code should work on 2.6
with minimal effort.


For deque objects, I don't get your point:

Python 2.6b1+ (trunk, Jul  1 2008, 22:35:48) [MSC v.1500 32 bit Intel)]
on win32
>>> from collections import deque
>>> hash(deque())
TypeError: deque objects are unhashable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:33:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 22:33:50 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215038030.8.0.36504542005.issue3088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

And please add the "-v" option at the end, so we can see which function
fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 00:51:52 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 02 Jul 2008 22:51:52 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215039112.47.0.953963778423.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The attached patch appears to work.

----------
keywords: +patch
Added file: http://bugs.python.org/file10794/split_zero_width.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:06:54 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Jul 2008 23:06:54 +0000
Subject: [issue3263] Odd code fragment in ABC definitions
In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
Message-ID: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In the Hashable ABC, there is a peculiar code fragment:

                if "__hash__" in B.__dict__:
                    if B.__dict__["__hash__"]:
                        return True
                    break

When would the innermost if-statement ever be False?  Is there a reason 
to define __hash__ to be something that evaluates to False?

----------
assignee: gvanrossum
messages: 69140
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Odd code fragment in ABC definitions
versions: Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3263>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:07:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 23:07:21 +0000
Subject: [issue3247] dir of an "_sre.SRE_Match" object not working
In-Reply-To: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za>
Message-ID: <1215040041.05.0.3528889087.issue3247@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Done in several changes: r64672 r64674 r64681.

Now the dir() is even more complete than before. I get:
['__class__', '__copy__', '__deepcopy__', '__delattr__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__gt__',
'__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__','__setattr__', '__sizeof__',
'__str__', '__subclasshook__', 'end', 'endpos', 'expand', 'group',
'groupdict', 'groups', 'lastgroup', 'lastindex', 'pos', 're', 'regs',
'span', 'start', 'string']

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3247>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:08:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2008 23:08:25 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215040105.18.0.397811822686.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay.  I just got about 5 perfect runs of the test suite, followed by:

Macintosh-3:trunk dickinsm$ ./python.exe -m test.regrtest
[...]
test_multiprocessing
Assertion failed: (bp != NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 746.
Abort trap (core dumped)

I then did:

gdb -c /cores/core.16235

I've attached the traceback as traceback.txt

Added file: http://bugs.python.org/file10795/traceback.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:10:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 23:10:37 +0000
Subject: [issue3263] Odd code fragment in ABC definitions
In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
Message-ID: <1215040237.3.0.486173594313.issue3263@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is precisely under discussion in issue2235:
if a base class is hashable, a derived class may set __hash__ to None,
and disallow hashing.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3263>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:12:02 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Wed, 02 Jul 2008 23:12:02 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Hi,
  although the issues libraries to be created with -fpic are known I
still do believe ./config could do something here:

building 'crypt' extension
gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypt -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
Text relocation remains                         referenced
    against symbol                  offset      in file
_des_setkey                         0x4         /usr/lib/libcrypt.a(crypt.o)
_des_encrypt                        0x10        /usr/lib/libcrypt.a(crypt.o)
_des_crypt                          0x1c        /usr/lib/libcrypt.a(crypt.o)
<unknown>                           0x4        
/usr/lib/libcrypt.a(des_crypt.o)
<unknown>                           0x8        
/usr/lib/libcrypt.a(des_crypt.o)
...
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
# gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypto -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
#

----------
components: Build
messages: 69144
nosy: mmokrejs
severity: normal
status: open
title: Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:24:05 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Jul 2008 23:24:05 +0000
Subject: [issue3263] Odd code fragment in ABC definitions
In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
Message-ID: <1215041045.27.0.978650699893.issue3263@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't think we should build in explicit support for bad designs that 
violate the Liskov substitution principle. Are there any valid use 
cases for wanting non-hashable subclasses of hashable classes?

If for some reason, this feature survives, it would be better to use 
NotImplemented instead of None.

----------
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3263>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:28:54 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Jul 2008 23:28:54 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215041334.65.0.965831656759.issue3262@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Probably by design. There's probably even a unittest for this behavior.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:32:19 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Jul 2008 23:32:19 +0000
Subject: [issue3263] Odd code fragment in ABC definitions
In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za>
Message-ID: <1215041539.41.0.0440719819109.issue3263@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

There are tons of ways to violate Liskov in Python. Liskov is not always
the right rule.

NotImplemented is not appropriate -- it is only used as a magic return
value from binary functions.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3263>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:47:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jul 2008 23:47:41 +0000
Subject: [issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
In-Reply-To: <1213613487.11.0.64218401652.issue3122@psf.upfronthosting.co.za>
Message-ID: <1215042461.95.0.659348752081.issue3122@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It now works for SRE objects in the py3k branch since r64672, but my
patch is still needed for types that define tp_getattr.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3122>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:55:43 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 02 Jul 2008 23:55:43 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1215040105.18.0.397811822686.issue3088@psf.upfronthosting.co.za>
Message-ID: <aac2c7cb0807021655p310daffl5cad97af39bbe4d0@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

On Wed, Jul 2, 2008 at 5:08 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Okay.  I just got about 5 perfect runs of the test suite, followed by:
>
> Macintosh-3:trunk dickinsm$ ./python.exe -m test.regrtest
> [...]
> test_multiprocessing
> Assertion failed: (bp != NULL), function PyObject_Malloc, file
> Objects/obmalloc.c, line 746.
> Abort trap (core dumped)
>
> I then did:
>
> gdb -c /cores/core.16235
>
> I've attached the traceback as traceback.txt

Are you sure that's right?  That traceback has no mention of
PyObject_Malloc or obmalloc.c.  Try checking the date.  Also, if  you
use "gdb ./python.exe <corefile>" to start gdb it should print a
warning if the program doesn't match the core.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:57:17 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 02 Jul 2008 23:57:17 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215043037.45.0.0530139303743.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've found that this issue has been discussed before: #988761.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 01:58:36 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 02 Jul 2008 23:58:36 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215043116.24.0.643120135544.issue3088@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I just run "make test" and it never moves past test_multiprocessing.

Maybe it's my machine which is dual cpu quad core (total of 8 cores)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:07:47 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 00:07:47 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Hi,
  when building on Solaris 2.6 with gcc I get the following error:

building '_ctypes' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.o
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c: In function
`_CallProc':
/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c:921: warning:
implicit declaration of function `alloca'
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.o
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.6-sun4u-2.5/libffi
-I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include
-I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.o
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c: In function
`more_core':
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
`MAP_ANONYMOUS' undeclared (first use in this function)
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
(Each undeclared identifier is reported only once
/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
for each function it appears in.)
building '_ctypes_test' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
-L/usr/local/lib -o build/lib.solaris-2.6-sun4u-2.5/_ctypes_test.so


Let me add that I see -fPIC in the top-level Makefile but do not know
why -static is not in the same variable as well. Anyway, it is not
a shared library problem I think as I already recompiled my bzip2,
openssl and ncurses libs with "-shared -fpic". ;-)

----------
messages: 69152
nosy: mmokrejs
severity: normal
status: open
title: Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:14:14 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 00:14:14 +0000
Subject: [issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
	undeclared
In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
Message-ID: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Some typo in the sources showing up on Solaris 2.6 only?

building 'mmap' extension
gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c -o
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/mmapmodule.o
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c: In function
`new_mmap_object':
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: warning: implicit
declaration of function `open'
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
undeclared (first use in this function)
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: (Each
undeclared identifier is reported only once
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: for each
function it appears in.)

----------
components: Build
messages: 69153
nosy: mmokrejs
severity: normal
status: open
title: Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3266>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:25:52 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 03 Jul 2008 00:25:52 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215044752.19.0.821411437193.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Doubtful Miki - I do the work on the module on an 8 Core Gentoo, 8 Core 
Mac Pro and Dual Core Macbook Pro - it's not a # of cores issue, unless 
it's simply a >1 issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:30:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jul 2008 00:30:14 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215045014.96.0.41299779528.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Are you sure that's right?

Not at all.  :-)

> That traceback has no mention of
> PyObject_Malloc or obmalloc.c.  Try checking the date.  Also, if  you
> use "gdb ./python.exe <corefile>" to start gdb it should print a
> warning if the program doesn't match the core.

The date and time on the core file look right (Jul 2, 23:52 GMT+1), and 
gdb ./python.exe ... doesn't give any warning.  So I'm not sure what I 
did wrong.  I'll try again and see if I get the same thing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:44:30 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jul 2008 00:44:30 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215045870.46.0.358350028389.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a new traceback (a different error again, this time: a negative 
refcount in Objects/tupleobject.c.)

Added file: http://bugs.python.org/file10796/traceback2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:59:02 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 03 Jul 2008 00:59:02 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215046742.27.0.0996147213936.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

New patch version after studying #988761 and doing more testing.

Added file: http://bugs.python.org/file10797/split_zero_width_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 02:59:38 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 03 Jul 2008 00:59:38 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215046778.05.0.0670929738281.issue3262@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file10794/split_zero_width.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul  3 03:19:43 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 03 Jul 2008 01:19:43 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1215045870.46.0.358350028389.issue3088@psf.upfronthosting.co.za>
Message-ID: <aac2c7cb0807021819k546456fft9f292e0543d2fad9@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

That looks better.  It crashed while deleting an exception, who's args
tuple has a bogus refcount.  Could be a refcount issue of the
exception or the args, or of something that that references them, or a
dangling pointer, or a buffer overrun, etc.

Things to try:
1) Run "pystack" in gdb, from Misc/gdbinit
2) Print the exception type.  Use "up" until you reach
BaseException_clear, then do "print self->ob_type->tp_name".  Also do
"print *self" and make sure the ob_refcnt is at 0 and the other fields
look sane.
3) Compile using --without-pymalloc and throw it at a real memory
debugger.  I'd suggest starting with your libc's own debugging
options, as they tend to be less invasive:
http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html
.  If that doesn't work, look at Electric Fence, Valgrind, or your
tool of choice.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 03:28:58 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 03 Jul 2008 01:28:58 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215048538.22.0.110639551147.issue3088@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Also, make sure you do a "make clean" since you last updated the tree or
touched any file or ran configure.  The automatic dependency checking
isn't 100% reliable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 04:07:50 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 03 Jul 2008 02:07:50 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215050870.53.0.742348023165.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Barring the segfaults Mark is seeing, I went through and removed all of 
the tests, and I have been incrementally adding them back one by one. _TestQueue seems to be the one (at least, the first) which is hanging 
intermittently in a racquire(). If anyone else who is having hangs minds, 
please try removing _TestQueue and see if you can still get it to hang.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 04:37:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 02:37:33 +0000
Subject: [issue3259] fix_imports needs to be using the 'as' keyword
In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
Message-ID: <1215052653.4.0.834554746924.issue3259@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yeah, but then commands will be replaced with subprocess.

$ cat > m
import commands
commands.getoutput()
$ 2to3 m
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- m (original)
+++ m (refactored)
@@ -1,2 +1,2 @@
-import commands
-commands.getoutput()
+import subprocess
+subprocess.getoutput()

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3259>
_______________________________________

From report at bugs.python.org  Thu Jul  3 07:08:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jul 2008 05:08:25 +0000
Subject: [issue3261] Lib/test/test_cookielib declares utf-8 encoding,
	but contains non-valid bytes
In-Reply-To: <1215037827.57.0.773875875282.issue3261@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807022208x3d2b9abga4e8d5475ca04b52@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 2, 2008 at 3:30 PM, Leonardo Soto <report at bugs.python.org> wrote:
>
> Leonardo Soto <leo.soto at gmail.com> added the comment:
>
> Thanks, that was fast!
>

It was simple and came into my inbox at just the right time. =)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3261>
_______________________________________

From report at bugs.python.org  Thu Jul  3 07:12:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jul 2008 05:12:00 +0000
Subject: [issue3259] fix_imports needs to be using the 'as' keyword
In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
Message-ID: <1215061920.63.0.381946312643.issue3259@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Gotcha. Here is to hoping that won't cause issues with someone's
variable name being silly.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3259>
_______________________________________

From report at bugs.python.org  Thu Jul  3 07:13:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jul 2008 05:13:47 +0000
Subject: [issue3259] fix_imports needs to be using the 'as' keyword
In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za>
Message-ID: <1215062027.83.0.847918384365.issue3259@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3259>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:17:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:17:12 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215065832.29.0.572695182917.issue3264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why didn't it link with /usr/lib/libcrypt.so? That has always worked on
Solaris, including Solaris 2.6.

In addition, even if it did decide to use libcrypt.a for some strange
reason, it should still link successfully, since libcrypt.a should
define _des_encrypt. Please do "ar tv /usr/lib/libcrypt.a", and report
the object files contained in the library.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:22:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:22:17 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215066137.64.0.0734041175467.issue3265@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please report from the mmap man page how anonymous mappings can
be achieved on Solaris 2.6?

----------
assignee:  -> theller
nosy: +loewis, theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:24:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:24:44 +0000
Subject: [issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
	undeclared
In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
Message-ID: <1215066284.6.0.875320914456.issue3266@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think there is a typo? O_RDWR is a valid constant that should
be provided on all Unix-like systems.

Can you please find out from the open(2) man page: a) whether Solaris
2.6 supports the O_RDWR constant, b) what header files to include, and
c) whether including these header files solves the problem?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3266>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:25:35 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:25:35 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215066335.47.0.600742990761.issue3264@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

# ar tv /usr/lib/libcrypt.a
rw-rw-r-- 0/1   1296 Jul 16 05:57 1997 crypt.o
rw-rw-r-- 0/1   4996 Jul 16 05:57 1997 cryptio.o
rw-rw-r-- 0/1   1508 Jul 16 05:57 1997 des_encrypt.o
rw-rw-r-- 0/1   5356 Jul 16 05:58 1997 des_crypt.o
# ls -la /usr/lib/libcrypt.so
ls: cannot access /usr/lib/libcrypt.so: No such file or directory
#

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:28:19 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 03 Jul 2008 06:28:19 +0000
Subject: [issue3267] yield in list comprehensions possibly broken in 3.0
In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
Message-ID: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

This may be a known consequence of python 3.0, but I couldn't find any 
reference to it, nor a test case that covers it. Here's a valid use of yield 
in 2.5.1:

>>> def foo():
...   x=[(yield x) for x in 1,2,3]
...   yield 5
...   yield x
>>> x=foo()
>>> x.next()
1
>>> x.send(6)
2
>>> x.send(7)
3
>>> x.send(8)
5
>>> x.send(9)
[6, 7, 8]
>>> x.send(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration


But in python 3.0, this code results in:

>>> def foo():
...   x=[(yield x) for x in (1,2,3)]
...   yield 5
...   yield x
>>> x=foo()
>>> next(x)
5
>>> x.send(6)
<generator object <listcomp> at 0x3678f0>
>>> x.send(7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration


Looking further, it seems that this is a comprehension:

>>> def foo(): [(yield 5)]
>>> type(foo())
<class 'generator'>

Whereas this is not:

>>> def foo(): [(yield 5) for x in range(3)]
>>> type(foo())
<class 'NoneType'>


Is this expected behavior?

----------
components: Interpreter Core
messages: 69168
nosy: erickt
severity: normal
status: open
title: yield in list comprehensions possibly broken in 3.0
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3267>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:31:39 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 03 Jul 2008 06:31:39 +0000
Subject: [issue3268] Cleanup of tp_basicsize inheritance
In-Reply-To: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za>
Message-ID: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

inherit_special contains logic to inherit the base type's tp_basicsize
if the new type doesn't have it set.  The logic was spread over several
lines, but actually does almost nothing (presumably an artifact of
previous versions), so here's a patch to clean it up.

There was also an incorrect comment which I've removed.  A new one
should perhaps be added explaining what the other code there does, but
it's not affected by what I'm changing, and I'm not sure why it's doing
what it's doing anyway, so I'll leave that to someone else.

----------
files: python-inheritsize.diff
keywords: patch
messages: 69169
nosy: Rhamphoryncus, nnorwitz
severity: normal
status: open
title: Cleanup of tp_basicsize inheritance
Added file: http://bugs.python.org/file10798/python-inheritsize.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3268>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:36:19 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:36:19 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215066979.7.0.237123422922.issue3265@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

A Goggle search gives between many others:
http://gcc.gnu.org/ml/gcc/2000-09/msg00054.html
http://www.ravenbrook.com/project/mps/master/design/vmso/
http://developers.sun.com/solaris/articles/read_mmap.html

Added file: http://bugs.python.org/file10799/mmap.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:44:33 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:44:33 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215067473.4.0.000813263675452.issue3265@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-07/0256.html
http://source.winehq.org/source/libs/wine/mmap.c

I will stop posting URLs. ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:47:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:47:17 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215067637.49.0.252123769643.issue3264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Something must be broken with your system installation. des_crypt.o
should define the function _des_crypt (ar x /usr/lib/libcrypt.a;nm -g
des_crypt.o). What linker are you using?

It seems that the shared version of libcrypt was only added in Solaris
7, but the static version should work regardless.

Regards,
Martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:52:44 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:52:44 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215067964.06.0.0666159902903.issue3264@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
#

The installation is actually very fresh, as I re-installed the
machine some year ago but it was turned off since few days. With
whatever last aggregate patches were available on dying Solaris
web pages.

# gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 3.4.2
#

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:55:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:55:47 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215067473.4.0.000813263675452.issue3265@psf.upfronthosting.co.za>
Message-ID: <486C77F1.8080101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I will stop posting URLs. ;-)

Thanks. None of the URLs seem to be helpful, anyway.
Please avoid posting URLs without any indication as to what
specific conclusion you like to see drawn from the page.

It seems that Solaris 2.6 just doesn't have explicit support
anonymous mmap explicitly. As a consequence, ctypes, in its
current form, just can't run on it.

A solution might be to map /dev/zero instead. Contributions
are welcome.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:56:08 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:56:08 +0000
Subject: [issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR'
	undeclared
In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za>
Message-ID: <1215068168.51.0.398125306157.issue3266@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

So adding these two lines helped:

# diff /usr/scratch/Python-2.5.2/Modules/mmapmodule.c.ori
/usr/scratch/Python-2.5.2/Modules/mmapmodule.c
36a37
> #include <sys/types.h>
38a40
> #include <fcntl.h>
#

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3266>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:57:49 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 06:57:49 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1215068269.72.0.768928809075.issue3265@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

Thanks, but I can only help with testing. :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Thu Jul  3 08:59:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 06:59:41 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215068381.55.0.424374000978.issue3264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok. I have no further ideas on what the problem might be, but I'm
confident that linking with a different library is not the right thing
to do. Linking with -lcrypt did always work on Solaris 2.6, so I'm not
going to change that.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:23:39 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 07:23:39 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215069819.91.0.274147093665.issue3264@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

Could it be the name clashing problem between -lcrypt and -lcrypto?

bash-3.00# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
bash-3.00# ar x /usr/local/lib/libcrypto.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
bash-3.00#

There used to be name clashes between -lcrypt from KTH-KRB/HEIMDAL
with those from openssl -lcrypto in the past. I think that was
"fixed" around/in openssl-2.7 and heimdal-1.0. The clashes caused
openssh dying when compiled with kerberos4 support because the
functions of same names expected in some way different data.
I am sure you would Goggle it out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:25:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 07:25:43 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215069943.73.0.523742713478.issue3264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No. We are not linking with libcrypto at all, so there can't be clashes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:31:39 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 07:31:39 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215070299.88.0.425404248816.issue3264@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

You say "did always work"?

http://mail.python.org/pipermail/python-list/2002-December/177479.html

Maybe the reason why in ruby they forced to -shared flag
because it was possible to link only with the shared library?
I do not know from which package to get the shared version. :(
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/33517

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:43:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Jul 2008 07:43:36 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215071016.66.0.809639363194.issue3088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The two tracebacks provided by Mark seem to correspond to the following
python stack (innermost last):

Lib/test/test_multiprocessing.py, line 1005, in _test_map_unordered
    self.assertEqual(sorted(it), map(sqr, range(1000)))
Lib/multiprocessing/pool.py, line 500, in IMapIterator.next()
    self._cond.acquire()
Lib/threading.py, line 123, in _RLock.acquire():
    rc = self.__block.acquire(blocking)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:51:14 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 03 Jul 2008 07:51:14 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215071474.92.0.0563517476497.issue3088@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

The test hanged for me at first try but worked fine on the second test,
weird.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 09:54:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 07:54:27 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215071667.28.0.965774841034.issue3264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, ok. I completely missed the point of the error message (i.e.
"relocations remain"), and misinterpreted it as missing symbols.

So I still recommend doing what I recommended back then: Uncomment the
line in Modules/Setup to build the crypt module on Solaris 2.6. That
should still work as it always did.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 10:10:01 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 03 Jul 2008 08:10:01 +0000
Subject: [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when
	available
In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za>
Message-ID: <1215072601.8.0.341481183605.issue3264@psf.upfronthosting.co.za>


Martin Mokrejs <mmokrejs at users.sourceforge.net> added the comment:

Confirming the enabling line 216 like below helped. Thanks. Maybe change
"Resolution"?

    204 # Socket module helper for SSL support; you must comment out the
other
    205 # socket line above, and possibly edit the SSL variable:
    206 #SSL=/usr/local/ssl
    207 #_ssl _ssl.c \
    208 #       -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
    209 #       -L$(SSL)/lib -lssl -lcrypto
    210 
    211 # The crypt module is now disabled by default because it breaks
builds
    212 # on many systems (where -lcrypt is needed), e.g. Linux (I believe).
    213 #
    214 # First, look at Setup.config; configure may have set this for you.
    215 
    216 crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on
some systems

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3264>
_______________________________________

From report at bugs.python.org  Thu Jul  3 10:14:39 2008
From: report at bugs.python.org (Paul Melis)
Date: Thu, 03 Jul 2008 08:14:39 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215072879.46.0.296280487748.issue3088@psf.upfronthosting.co.za>


Paul Melis <paul at floorball-flamingos.nl> added the comment:

On a Linux system (FC4) with r64686 of the Py3k branch I also still get
occassional hangs (with ./python -E -bb ./Lib/test/regrtest.py -v
test_multiprocessing). Mostly this seems to occur with the very first
test executed, i.e. before any of the "test_... " lines have been generated.

The following may or may not be related. Some time ago I decided to give
valgrind a try to see if it could detect anything strange going on with
the multiprocessing tests, specifically using the 'helgrind'
thread-debugging tool that comes with it. 

Valgrind reports as its first error:

==9719== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore
without prior sem_post
==9719==    at 0x4007FFF: sem_wait_WRK (hg_intercepts.c:1057)
==9719==    by 0x4008094: sem_wait@* (hg_intercepts.c:1073)
==9719==    by 0x46A0087: semlock_acquire (semaphore.c:310)
==9719==    by 0x808C121: PyEval_EvalFrameEx (ceval.c:3371)
==9719==    by 0x808D0FE: PyEval_EvalCodeEx (ceval.c:2808)
==9719==    by 0x808B9D0: PyEval_EvalFrameEx (ceval.c:3469)
==9719==    by 0x808D0FE: PyEval_EvalCodeEx (ceval.c:2808)
==9719==    by 0x80F4B65: function_call (funcobject.c:628)
==9719==    by 0x80D1207: PyObject_Call (abstract.c:2178)
==9719==    by 0x80890EC: PyEval_EvalFrameEx (ceval.c:3672)
==9719==    by 0x808C1A9: PyEval_EvalFrameEx (ceval.c:3459)
==9719==    by 0x808C1A9: PyEval_EvalFrameEx (ceval.c:3459)
==9716== Thread #1 is the program's root thread

I've been hesitant to report this as the claim that libpthread is broken
is pretty bold. I contacted the valgrind devs about this, see [1]. 
More recently, someone on the valgrind list reported problems that do
seem to indicate there are broken libpthreads out there (see [2]), as
this individual reports a semaphore wait not blocking where it should.

Could it be that the multiprocessing tests are exposing one or more bugs
in libpthread?

[1] http://thread.gmane.org/gmane.comp.debugging.valgrind/8345
[2] http://thread.gmane.org/gmane.comp.debugging.valgrind/8384

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 11:43:33 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 03 Jul 2008 09:43:33 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1215078213.37.0.67258210368.issue1322@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Please see the top of platform.py:

#    This module is maintained by Marc-Andre Lemburg <mal at egenix.com>.
#    If you find problems, please submit bug reports/patches via the
#    Python SourceForge Project Page and assign them to "lemburg".
#
#    Note: Please keep this module compatible to Python 1.5.2.

I wonder why the ticket wasn't assigned to me.

Regarding the patch: 

 * the dist() function has been superseded by linux_distribution().

 * the supported_dists argument is a documented feature of
linux_distributions(), so should not be removed

 * the Windows name normalization should not be removed (it fixes a bug
in Vista)

 * the change from using string functions to using string methods breaks
1.5.2 compatibility (*)

 * the _ETC_DIR global just makes things harder to read and there's no
apparent need for it

(*) It's probably time to drop 1.5.2 compatibility and only keep the
module compatible to Python 2.1, so this is not much of an issue.

Overall, I think it's better to define a fixed search order for the
release files than to try to figure out and parse random release files
that happen to match the release file RE.

For that to work, it would help a lot if you could provide the file name
and contents of various platform release files.

----------
assignee: christian.heimes -> lemburg
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Thu Jul  3 11:53:03 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 03 Jul 2008 09:53:03 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1215078783.18.0.245274624164.issue1322@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Also note that linux_distribution() will use the parsed distro name from
the release file per default (full_distribution_name=1), so the problem
described in the original ticket description should no longer be
relevant: all release files point to the same lsb-release file in the end.

I don't have access to Mandriva. Could you please let me know whether
the current SVN version of platform.py still exhibits the mentioned
problem ?

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Thu Jul  3 12:06:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jul 2008 10:06:14 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215079573.91.0.592474333685.issue3088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Are you sure that's right?  That traceback has no mention of
> PyObject_Malloc or obmalloc.c.

So now I think that the traceback was right.  There was no mention of 
PyObject_Malloc or obmalloc.c because the traceback only showed 1 of the 9 
threads, and the failed assert occurred in a different thread.

I've attached another traceback, showing all the threads, and applying 'tb 
full' to the relevant thread.  (This was from a different run, but with 
the same failed assertion at line 746 of Objects/obmalloc.c.)

Added file: http://bugs.python.org/file10800/multithread_traceback.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul  3 12:41:58 2008
From: report at bugs.python.org (Chris Withers)
Date: Thu, 03 Jul 2008 10:41:58 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1215081718.48.0.130444226777.issue3249@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

This may be "as documented" but it's *extremely* counter intuitive and
seems to go against the grain of where python is headed.

(remember that whole struggle to get 3/2 = 1.5 rather 3/2=1? ;-) )

I've changed the "type" to "feature request", what's the best mailing
list to kick off discussion about this?

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Thu Jul  3 12:50:33 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 03 Jul 2008 10:50:33 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215082233.77.0.298772541219.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as deque goes, the following behaviour on the trunk is the
problem I am trying to fix:

Python 2.6b1+ (trunk:64655, Jul  2 2008, 22:48:24)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import deque, Hashable
>>> isinstance(deque(), Hashable)
True

All of the container types that my patch touches were already unhashable
in 2.5 - my patch just ensures that they all correctly return false for
isinstance(obj, collections.Hashable) even after we make object.__hash__
inherited by default again. This is also the reason why simply reverting
the trunk hash implementation to the 2.5 behaviour (which is what I
first tried) is inadequate.

Since collections.Hashable is new in 2.6, I can live with it returning
the wrong answer for types which define __hash__ to always raise an
error (that's a known limitation of the ABC system, even in Py3k).
However, we should at least make sure it returns the correct answer for
all of the types in the standard library.

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Thu Jul  3 13:44:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Jul 2008 11:44:31 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1215085471.84.0.842348859855.issue3249@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To be valid, your analogy between dates and numbers suggests that a date
should be convertible to the datetime with the same date, at midnight.
And both objects compare equal, just like 42==42.0

But today this is not the case: it's hard to convert a date into a
datetime, and types cannot be ordered:
>>> datetime.date.today() < datetime.datetime.now()
TypeError: can't compare datetime.datetime to datetime.date

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Thu Jul  3 13:47:36 2008
From: report at bugs.python.org (=?utf-8?q?Neven_Gor=C5=A1i=C4=87?=)
Date: Thu, 03 Jul 2008 11:47:36 +0000
Subject: [issue3269] strptime() makes an error concerning second in arg
In-Reply-To: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>
Message-ID: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>


New submission from Neven Gor?i? <neven.gorsic at gmail.com>:

strptime() allows 60 and 61 sec, but not 62 sec in arg. string 

>>> s='02/28/2000 12:33:61 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
(2000, 2, 28, 0, 33, 61, 0, 59, -1)

>>> s='02/28/2000 12:33:62 AM'
>>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p')

Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    time.strptime(s,'%m/%d/%Y %I:%M:%S %p')
  File "C:\Python25\lib\_strptime.py", line 330, in strptime
    (data_string, format))
ValueError: time data did not match format:  data=02/28/2000 12:33:62 AM
 fmt=%m/%d/%Y %I:%M:%S %p

----------
components: None
messages: 69192
nosy: nevgor
severity: normal
status: open
title: strptime() makes an error concerning second in arg
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________

From report at bugs.python.org  Thu Jul  3 14:53:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 12:53:34 +0000
Subject: [issue1622] zipfile hangs on certain zip files
In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za>
Message-ID: <1215089614.67.0.677246785315.issue1622@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. This is now committed as r64688

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1622>
_______________________________________

From report at bugs.python.org  Thu Jul  3 14:53:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 12:53:43 +0000
Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000
	files
In-Reply-To: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za>
Message-ID: <1215089623.59.0.165601129283.issue1526@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch for issue1622 was committed as r64688; closing this patch as
outdated.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1526>
_______________________________________

From report at bugs.python.org  Thu Jul  3 14:54:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 12:54:11 +0000
Subject: [issue3267] yield in list comprehensions possibly broken in 3.0
In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
Message-ID: <1215089651.32.0.952085982722.issue3267@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is because list comprehensions are implemented as functions in 3.0
so their scope is not leaked out to the rest of the function.

Here is the bytecode for 2.6:
>>> dis.dis(f)
  2           0 BUILD_LIST               0
              3 DUP_TOP             
              4 STORE_FAST               0 (_[1])
              7 LOAD_CONST               5 ((1, 2, 3))
             10 GET_ITER            
        >>   11 FOR_ITER                14 (to 28)
             14 STORE_FAST               1 (x)
             17 LOAD_FAST                0 (_[1])
             20 LOAD_FAST                1 (x)
             23 YIELD_VALUE         
             24 LIST_APPEND         
             25 JUMP_ABSOLUTE           11
        >>   28 DELETE_FAST              0 (_[1])
             31 STORE_FAST               1 (x)

  3          34 LOAD_CONST               4 (5)
             37 YIELD_VALUE         
             38 POP_TOP             

  4          39 LOAD_FAST                1 (x)
             42 YIELD_VALUE         
             43 POP_TOP             
             44 LOAD_CONST               0 (None)
             47 RETURN_VALUE        

and here it is for 3.0:
>>> dis.dis(f)
  2           0 LOAD_CONST               1 (<code object <listcomp> at
0x740770, file "<stdin>", line 2>) 
              3 MAKE_FUNCTION            0 
              6 LOAD_CONST               6 ((1, 2, 3)) 
              9 GET_ITER             
             10 CALL_FUNCTION            1 
             13 STORE_FAST               0 (x) 

  3          16 LOAD_CONST               5 (5) 
             19 YIELD_VALUE          
             20 POP_TOP              

  4          21 LOAD_FAST                0 (x) 
             24 YIELD_VALUE          
             25 POP_TOP              
             26 LOAD_CONST               0 (None) 
             29 RETURN_VALUE

----------
nosy: +benjamin.peterson
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3267>
_______________________________________

From report at bugs.python.org  Thu Jul  3 14:54:22 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Jul 2008 12:54:22 +0000
Subject: [issue1746] ZIP files with archive comments longer than 4k not
	recognized as valid by zipfile module
In-Reply-To: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za>
Message-ID: <1215089662.23.0.488079228983.issue1746@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch in #1622 was committed as r64688.

----------
nosy: +loewis
resolution: duplicate -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746>
_______________________________________

From report at bugs.python.org  Thu Jul  3 14:58:44 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 03 Jul 2008 12:58:44 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

Per mail thread:
http://mail.python.org/pipermail/python-dev/2008-June/080497.html

Attached is the patch to connection.py to drop the fqdn call.

Final suggestion from Trent:

> This is a common problem.  Binding to '127.0.0.1' will bind to *only*
> that address;

Indeed.

> binding to "" will bind to *all* addresses the machine
> is known by.

Agreed again.  I believe what we're dealing with here though is a lack 
of clarity regarding what role the 'address' attribute exposed by 
multiprocess.connection.Listener should play.  The way 
test_listener_client() is written, it effectively treats 'address' as an 
end-point that can be connected to directly (irrespective of the 
underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)).

I believe the problems we've run into stem from the fact that the API 
doesn't provide any guarantees as to what 'address' represents.  The 
test suite assumes it always reflects a connectable end-point, which I 
think is more than reasonable.  Unfortunately, nothing stops us from 
breaking this invariant by constructing the object as 
Listener(family='AF_INET', address=('0.0.0.0', 0)).

How do I connect to an AF_INET Listener (i.e. SocketListener) instance 
whose 'address' attribute reports '0.0.0.0' as the host?  I can't.

So, for now, I think we should enforce this invariant by raising an 
exception in Listener.__init__() if self._socket.getsockbyname()[0] 
returns '0.0.0.0'.  In effect, tightening up the API such that we can 
guarantee  Listener.address will always represent a connectable end-
point.  We can look at how to service 'listen on all available 
interfaces' semantics at a later date -- that adds far less value IMO 
than being able to depend on the said guarantee.

----------
assignee: jnoller
components: Library (Lib)
files: connection.patch
keywords: patch
messages: 69197
nosy: jnoller, roudkerk
priority: high
severity: normal
status: open
title: test_multiprocessing: test_listener_client flakiness
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10801/connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Thu Jul  3 15:19:44 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 13:19:44 +0000
Subject: [issue3269] strptime() makes an error concerning second in arg
In-Reply-To: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>
Message-ID: <1215091184.0.0.329875586849.issue3269@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the
theoretical calendar because of small differences with real world
rotation... 

Are you aware of any case where a minute with 63 seconds (0..62) should
be used?

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________

From report at bugs.python.org  Thu Jul  3 15:31:49 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 03 Jul 2008 13:31:49 +0000
Subject: [issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
In-Reply-To: <1213613487.11.0.64218401652.issue3122@psf.upfronthosting.co.za>
Message-ID: <1215091909.2.0.533078295728.issue3122@psf.upfronthosting.co.za>


Robert Schuppenies <okkotonushi at googlemail.com> added the comment:

Amaury,
I was testing your patch and it turns out, that it will ignore
any __sizeof__ attribute which may be available through getattr. I
adapted it a bit, so now getsizeof will try to call the method on the
passed object first, and if it fails or the object is a type, the code
proposed by you will be executed. This also deals with old-style class
instances. The match_sizeof function in the patch is just to showcase
the example. What do you think?

Added file: http://bugs.python.org/file10802/sizeof2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3122>
_______________________________________

From report at bugs.python.org  Thu Jul  3 15:32:30 2008
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 03 Jul 2008 13:32:30 +0000
Subject: [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1215091950.49.0.614336678099.issue3258@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________

From report at bugs.python.org  Thu Jul  3 15:33:32 2008
From: report at bugs.python.org (=?utf-8?q?Neven_Gor=C5=A1i=C4=87?=)
Date: Thu, 03 Jul 2008 13:33:32 +0000
Subject: [issue3269] strptime() makes an error concerning second in arg
In-Reply-To: <1215091184.0.0.329875586849.issue3269@psf.upfronthosting.co.za>
Message-ID: <8acd28da0807030633r32a9a050i4a8f08395fde9555@mail.gmail.com>


Neven Gor?i? <neven.gorsic at gmail.com> added the comment:

Thank you for your reply, although is not helpful for me.

I use strptime() for datedate transformation and datatime boundaries
checking
and therefore I am not conserned in Reltivity theory.

When someone in datetime table enter 02:61:38 it is sign for me to
rise a warning and not to supposed that the gay is astrophysicist :)

-------------------------

On Thu, Jul 3, 2008 at 3:19 PM, Facundo Batista <report at bugs.python.org>
wrote:

>
> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
>
> Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the
> theoretical calendar because of small differences with real world
> rotation...
>
> Are you aware of any case where a minute with 63 seconds (0..62) should
> be used?
>
> ----------
> nosy: +facundobatista
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3269>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080703/d45cba6a/attachment.txt>

From report at bugs.python.org  Thu Jul  3 15:49:21 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 13:49:21 +0000
Subject: [issue3269] strptime() makes an error concerning second in arg
In-Reply-To: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za>
Message-ID: <1215092961.52.0.978720618937.issue3269@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Closing as invalid, two reasons:

- Your original issue was that time.strptime() didn't allow 62 seconds,
not that it allowed 60 or 61.

- If you use it to validate input... how do you actually know that
03/25/2012 17:13:61 AM' is an invalid date?

I suggest to bring this issue in the python list if you have further doubts.

Thank you!!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________

From report at bugs.python.org  Thu Jul  3 16:03:57 2008
From: report at bugs.python.org (=?utf-8?q?Neven_Gor=C5=A1i=C4=87?=)
Date: Thu, 03 Jul 2008 14:03:57 +0000
Subject: [issue3269] strptime() makes an error concerning second in arg
In-Reply-To: <1215092961.52.0.978720618937.issue3269@psf.upfronthosting.co.za>
Message-ID: <8acd28da0807030703o17542943rb36968ff646fab2e@mail.gmail.com>


Neven Gor?i? <neven.gorsic at gmail.com> added the comment:

- My original issue was that time.strptime() makes difference between 61 and
62 seconds
- 17h AM, 78 s, 128min everyone can easly transform correctly, I just wanted
to use function for
  boundarie checking: rising error for 62 sec and not for 61 is confusing!
- I just wanted to point out that Python should be consistent: to provide
the same behaviour for 60,61 and 62 sec.

The conclusion is over as far as I am concerned.
I got the picture (you standpoint), and I hope, you too.

Thank you, once again,

Regards

     Neven

----------------------

On Thu, Jul 3, 2008 at 3:49 PM, Facundo Batista <report at bugs.python.org>
wrote:

>
> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
>
> Closing as invalid, two reasons:
>
> - Your original issue was that time.strptime() didn't allow 62 seconds,
> not that it allowed 60 or 61.
>
> - If you use it to validate input... how do you actually know that
> 03/25/2012 17:13:61 AM' is an invalid date?
>
> I suggest to bring this issue in the python list if you have further
> doubts.
>
> Thank you!!
>
> ----------
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3269>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3269>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080703/cf27bb7a/attachment.txt>

From report at bugs.python.org  Thu Jul  3 16:52:11 2008
From: report at bugs.python.org (chris.eveleigh)
Date: Thu, 03 Jul 2008 14:52:11 +0000
Subject: [issue1555570] email parser incorrectly breaks headers with a CRLF at
	8192
Message-ID: <1215096731.12.0.536898316232.issue1555570@psf.upfronthosting.co.za>


Changes by chris.eveleigh <chris.eveleigh at planningportal.gov.uk>:


----------
nosy: +chris.eveleigh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1555570>
_______________________________________

From report at bugs.python.org  Thu Jul  3 17:01:47 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 03 Jul 2008 15:01:47 +0000
Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__
Message-ID: <1215097307.63.0.77118134201.issue1690840@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I think __str__ should also be implemented.
I'm attaching a patch with unittests against current trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file10805/xmlrpc_repr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690840>
_______________________________________

From report at bugs.python.org  Thu Jul  3 17:04:30 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 03 Jul 2008 15:04:30 +0000
Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__
Message-ID: <1215097470.3.0.92386767924.issue1690840@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

this is how it looks:

~/pydev/trunk/ python                                              
ralf at red ok
Python 2.6b1+ (trunk, Jul  3 2008, 12:43:37) 
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import Server
>>> Server("http://localhost:8000").doit
<xmlrpclib._Method doit <bound method ServerProxy.__request of
<ServerProxy for localhost:8000/RPC2>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690840>
_______________________________________

From report at bugs.python.org  Thu Jul  3 17:10:00 2008
From: report at bugs.python.org (vizcayno)
Date: Thu, 03 Jul 2008 15:10:00 +0000
Subject: [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>


New submission from vizcayno <vizcaynot at gmail.com>:

For Win XP SP3 I do next in py30.b1:

a=[9,8,1,2]
it=iter(a)
it.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'list_iterator' object has no attribute 'next'

but doing:
it.__next__()
9
it.__next__()
8

it is ok.

However, manual of Py3.0 indicates iter.next() as valid.

Python 25 does not accept "it.__next__()" but "it.next()"
Regards.

----------
assignee: georg.brandl
components: Documentation
messages: 69205
nosy: georg.brandl, vizcayno
severity: normal
status: open
title: iter.next() or iter.__next__() ?
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________

From report at bugs.python.org  Thu Jul  3 18:44:18 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 16:44:18 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1215103458.34.0.348972015673.issue1641@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Generally speaking, delayed calls, and/or a practical scheduling
algorithm are useful for async servers.  Since 2.6 and 3.0 are on
feature freeze right now, this is going to have to wait for 2.7 and 3.1
.  I'll make sure to get something like this into 2.7 / 3.1 .

----------
assignee: akuchling -> josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Thu Jul  3 18:48:38 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 03 Jul 2008 16:48:38 +0000
Subject: [issue3272] Multiprocessing hangs when multiprocessing.Pool methods
	are called
In-Reply-To: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>
Message-ID: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

`multiprocessing` hangs, when `multiprocessing.Pool` methods `map`,
`imap`, `imap_unordered`, `apply`, `apply_async`, `map_async` are called.
Here is an example:

Python 3.0b1+ (py3k:64686M, Jul  3 2008, 13:06:13)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pool
>>> Pool(processes=4).imap(lambda x: x, range(10))
<multiprocessing.pool.IMapIterator object at 0x83bcc8c>
>>> Pool(processes=4).map(lambda x: x, range(10))
Exception in thread Thread-13:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/threading.py", line 492, in
_bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.0/threading.py", line 447, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 225, in
_handle_tasks
    put(task)
  File "/usr/local/lib/python3.0/pickle.py", line 1319, in dumps
    Pickler(f, protocol).dump(obj)
  File "/usr/local/lib/python3.0/multiprocessing/util.py", line 311, in
_reduce_method
    if m.__self__ is None:
AttributeError: 'function' object has no attribute '__self__'

Process PoolWorker-28:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
    self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
    task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-27:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
    self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
    task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
Process PoolWorker-26:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
Process PoolWorker-25:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232,
in _bootstrap
    self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
    task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337,
in get
    self.run()
  File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88,
in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in
worker
    task = get()
  File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 339,
in get
    return recv()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
Terminated

The same happens on latest trunk of Python 2.6.
Note, `map` and `apply` methods hang Python interpreter completely, so I
have to use `kill` utility to exit Python.

----------
components: Library (Lib)
messages: 69207
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing hangs when multiprocessing.Pool methods are called
type: crash
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3272>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:03:29 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 03 Jul 2008 17:03:29 +0000
Subject: [issue3273] multiprocessing and meaningful errors
In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>
Message-ID: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

multiprocessing uses a lot of `assert` statements all over the code. I
propose to change this way to a more readable and understandable. For
example:
Lib/multiprocessing/managers.py, line 136:
assert isinstance(authkey, bytes)
>From my point of view, raising an AssertionError is not enough in this
case. I propose changing this one to more intuitive:
if not isinstance(authkey, bytes):
   raise TypeError("'authkey' argument should be an instance of 'bytes'")
(Well, maybe message could be more descriptive. :) )

And this goes for all of the multiprocessing code base.
Should I consider writing a patch for this?

----------
components: Library (Lib)
messages: 69208
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: multiprocessing and meaningful errors
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3273>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:27:59 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:27:59 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1215106079.24.0.672913691257.issue1675455@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

What I don't understand here is... if gethostbyname() lacks of IPv6
support, instead of creating a new function why not to add the
functionality to that same function?

Right now gethostbyname() is implemented in C, which would be the
drawback of making it a Python function?

----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:30:04 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:30:04 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1215106204.46.0.858168815851.issue1424152@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:30:57 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:30:57 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1215106257.73.0.284770501533.issue1424152@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


Removed file: http://bugs.python.org/file10632/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:30:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jul 2008 17:30:59 +0000
Subject: [issue3267] yield in list comprehensions possibly broken in 3.0
In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
Message-ID: <1215106259.75.0.0778483549179.issue3267@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yes, this change in semantics is expected. Closing as "won't fix".

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3267>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:33:51 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:33:51 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1215106431.47.0.189977887237.issue1424152@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I see that you're working on a final solution, this is great!

What we would need also to incorporate this to the trunk is a patch for
the test suite. Senthil, could you handle this?

----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:37:13 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:37:13 +0000
Subject: [issue2916] urlgrabber.grabber calls setdefaulttimeout
In-Reply-To: <1211212331.88.0.0515887247336.issue2916@psf.upfronthosting.co.za>
Message-ID: <1215106633.6.0.516119914178.issue2916@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2916>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:39:55 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:39:55 +0000
Subject: [issue2756] urllib2 add_header fails with existing unredirected_header
In-Reply-To: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
Message-ID: <1215106795.71.0.353398162723.issue2756@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

BitTorment, what would increase the possibility of accepting this is a
patch also for the test suite (test_urllib2.py), checking this
behaviour, for us to be sure that does not break again in the future.

Could you please submit also this?

----------
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2756>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:42:25 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 17:42:25 +0000
Subject: [issue2776] urllib2.urlopen() gets confused with path with // in it
In-Reply-To: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
Message-ID: <1215106945.69.0.225416296971.issue2776@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2776>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:54:09 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 03 Jul 2008 17:54:09 +0000
Subject: [issue3274] Py_CLEAR(tmp) seg faults
In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
Message-ID: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

I'm writing a C extension module and discovered that Py_CLEAR() causes a
crash if the programmer happened to name their variable "tmp".  The
Py_CLEAR() macro internally uses the name "tmp" in a new scope, hiding
the callers "tmp", and calling Py_DECREF() on an essentially random bit
of memory.

I suggest changing Py_CLEAR() to use something a little less common than
"tmp".  Perhaps "_py_tmp".

For easy reference, here's how Py_CLEAR() is defined now:

#define Py_CLEAR(op)				\
        do {                            	\
                if (op) {			\
                        PyObject *tmp = (PyObject *)(op);	\
                        (op) = NULL;		\
                        Py_DECREF(tmp);		\
                }				\
        } while (0)

----------
components: Interpreter Core
messages: 69213
nosy: stutzbach
severity: normal
status: open
title: Py_CLEAR(tmp) seg faults
type: crash
versions: Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3274>
_______________________________________

From report at bugs.python.org  Thu Jul  3 19:58:04 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 17:58:04 +0000
Subject: [issue1063924] asyncore should handle ECONNRESET in send
Message-ID: <1215107884.44.0.397218866235.issue1063924@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

We are actually closing the socket before returning in the latest
version of asyncore.  Closing as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1063924>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:00:12 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:00:12 +0000
Subject: [issue760475] asyncore.py and "handle_error"
Message-ID: <1215108012.71.0.377993940067.issue760475@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I forgot to fix this in my most recent commits, but I'll fix it this
weekend for Python 2.6 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue760475>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:01:26 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:01:26 +0000
Subject: [issue1736101] asyncore should handle also ECONNABORTED in recv
Message-ID: <1215108086.17.0.536258821897.issue1736101@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736101>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:03:13 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:03:13 +0000
Subject: [issue889153] asyncore.dispactcher: incorrect connect
Message-ID: <1215108193.59.0.700342457076.issue889153@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue889153>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:04:31 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:04:31 +0000
Subject: [issue1740572] asynchat should call "handle_close"
Message-ID: <1215108271.45.0.665741875143.issue1740572@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740572>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:05:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Jul 2008 18:05:47 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1215108347.21.0.467246888125.issue3232@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Martin, you seem to be the author of that module.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:08:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Jul 2008 18:08:29 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215108509.38.0.844152283996.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Wow...
Isn't this kind of code supposed to ask for a buffer on the bytearray
object, together with an optional lock on it (or something like that)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:11:01 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:11:01 +0000
Subject: [issue909005] asyncore fixes and improvements
Message-ID: <1215108661.58.0.973390063148.issue909005@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I have applied my variant patch to trunk, which will be in 3.0 this weekend.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue909005>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:14:04 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:14:04 +0000
Subject: [issue1025525] asyncore.file_dispatcher should not take fd as argument
Message-ID: <1215108844.24.0.805309946434.issue1025525@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in trunk, will be fixed in 3.0 this weekend.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1025525>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:14:58 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:14:58 +0000
Subject: [issue1736190] asyncore/asynchat patches
Message-ID: <1215108898.25.0.891350660209.issue1736190@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Committed to trunk a bit ago, will be in 3.0 this weekend.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736190>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:16:02 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 18:16:02 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1215108962.84.0.266205348327.issue2464@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:17:38 2008
From: report at bugs.python.org (George Boutsioukis)
Date: Thu, 03 Jul 2008 18:17:38 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1215109058.32.0.654905905829.issue3250@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

I have also come across this in the past. Although I sense that some
obscure reason might prevent time arithmetic from being included, here's
a patch to add time/timedelta addition and subtraction. It closely
follows the datetime arithmetic functions. To handle overflows, I
figured it should wrap around a 24-hour limit. The timezone stuff is
copied verbatim from the datetime functions, some finger-crossing applied.

----------
keywords: +patch
nosy: +gboutsioukis
Added file: http://bugs.python.org/file10806/datetime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:19:40 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 03 Jul 2008 18:19:40 +0000
Subject: [issue2808] asynchat forgets packets when push is called from a thread
In-Reply-To: <1210417225.64.0.883655852515.issue2808@psf.upfronthosting.co.za>
Message-ID: <1215109180.18.0.302014216316.issue2808@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2808>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:20:37 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 18:20:37 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215109237.45.0.790406850489.issue2275@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil: We would need some tests to assure this will keep working ok in
the future

Also as this is (somehow) a new functionality, we'd need to modify the
NEWS file and maybe even the docs (a comment about this case insensitivity?

Could you please send a patch for these? Thank you!

----------
assignee:  -> facundobatista
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Thu Jul  3 20:59:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 18:59:31 +0000
Subject: [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215111571.18.0.334215560136.issue3271@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Where in the 3.0 docs do you see it.next() used? It should be changed.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________

From report at bugs.python.org  Thu Jul  3 21:10:39 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 03 Jul 2008 19:10:39 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1215112239.06.0.909145973256.issue1462525@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil, we should incorporate the tests from RFC 3986 to the test
suite, what do you think?

Coul we integrate the effort from Paul Jimenez and the current urlparse
and achieve a RFC compliant library? Should we handle this compliance in
this bug?

----------
assignee:  -> facundobatista
nosy: +facundobatista, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Thu Jul  3 22:05:33 2008
From: report at bugs.python.org (vizcayno)
Date: Thu, 03 Jul 2008 20:05:33 +0000
Subject: [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215115533.83.0.423168513498.issue3271@psf.upfronthosting.co.za>


vizcayno <vizcaynot at gmail.com> added the comment:

Please, go to python 3.0 -> python manuals and search with word: iter
then select first line of found titles, i.e. Functional Programming 
HOWTO. Into this title you will find some samples.
Regards,

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________

From report at bugs.python.org  Thu Jul  3 22:29:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 20:29:02 +0000
Subject: [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215116942.51.0.865476644712.issue3271@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

fixed in r64696.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________

From report at bugs.python.org  Thu Jul  3 22:29:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 20:29:29 +0000
Subject: [issue3271] iter.next() or iter.__next__() ?
In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za>
Message-ID: <1215116969.2.0.550545078121.issue3271@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3271>
_______________________________________

From report at bugs.python.org  Thu Jul  3 22:43:13 2008
From: report at bugs.python.org (Daniel Colascione)
Date: Thu, 03 Jul 2008 20:43:13 +0000
Subject: [issue3275] Control flow not optimized
In-Reply-To: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>
Message-ID: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>


New submission from Daniel Colascione <dan.colascione at gmail.com>:

Consider:

import dis
def foo():
  if 0 and 1: return "hi"

dis.dis(foo)

What I get is 

  2           0 LOAD_CONST               1 (0)
              3 JUMP_IF_FALSE           15 (to 21)
              6 POP_TOP             
              7 LOAD_CONST               2 (1)
             10 JUMP_IF_FALSE            8 (to 21)
             13 POP_TOP             
             14 LOAD_CONST               3 ('hi')
             17 RETURN_VALUE        
             18 JUMP_FORWARD             1 (to 22)
        >>   21 POP_TOP             
        >>   22 LOAD_CONST               0 (None)
             25 RETURN_VALUE        

What I'd expect to see is:

  1           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE

----------
components: Interpreter Core
messages: 69230
nosy: quotemstr
severity: normal
status: open
title: Control flow not optimized
type: performance
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3275>
_______________________________________

From report at bugs.python.org  Thu Jul  3 22:51:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jul 2008 20:51:30 +0000
Subject: [issue3275] Control flow not optimized
In-Reply-To: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>
Message-ID: <1215118290.34.0.543644240667.issue3275@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

A patch for this was just recently rejected. See #1394.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3275>
_______________________________________

From report at bugs.python.org  Fri Jul  4 01:39:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Jul 2008 23:39:34 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215128374.38.0.701347056925.issue1580@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'd like to reopen this. I'm still in favor of something like to this
algorithm:

def float_repr(x):
  s = "%.16g" % x
  if float(s) != x:
    s = "%.17g" % x
  s1 = s
  if s1.startswith('-'):
    s1 = s[1:]
  if s1.isdigit():
    s += '.0'  # Flag it as a float
  # XXX special case inf and nan, see floatobject.c::format_double
  return s

combined with explicitly using %.17g or the new hex notation (see issue
3008) in places where cross-platform correctness matters, like pickle
and marshal.

This will ensure float(repr(x)) == x on all platforms, but not cross
platforms -- and I don't care.

I'm fine with only doing this in 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul  4 01:41:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Jul 2008 23:41:55 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215128515.2.0.864399183652.issue3008@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Raymond, Mark?  Is a new patch with tests and docs forthcoming?  Have
you decided on the API yet?  I'm willing to approve this for beta 2,
which will be around July 15.

----------
assignee: gvanrossum -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 02:19:29 2008
From: report at bugs.python.org (toxik)
Date: Fri, 04 Jul 2008 00:19:29 +0000
Subject: [issue3276] httplib.HTTPConnection._send_request should not blindly
	assume dicts for headers
In-Reply-To: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>
Message-ID: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>


New submission from toxik <ludvig.ericson at users.sourceforge.net>:

Presently it's impossible to use httplib.HTTPConnection.request and send 
the several headers with the same name. This is because _send_request 
assumes a dict is passed in, or a dict-like interface. Obviously one could 
make a list subclass or some such and give it an iteritems that returns 
itself, but IMHO the solution is to fix httplib.

Attached patch changes the current behavior to using iteritems only if it 
exists, otherwise iterate directly (which would fit with sequences of two-
tuples).

----------
components: Library (Lib)
files: httplib.py.diff
keywords: patch
messages: 69234
nosy: ludvig.ericson
severity: normal
status: open
title: httplib.HTTPConnection._send_request should not blindly assume dicts for headers
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file10807/httplib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3276>
_______________________________________

From report at bugs.python.org  Fri Jul  4 03:02:28 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Jul 2008 01:02:28 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215133348.35.0.867053922521.issue1580@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

If you think using 16 (when possible) will stop complaints, think again
;-)  For example,

>>> for x in 0.07, 0.56:
...     putatively_improved_repr = "%.16g" % x
...     assert float(putatively_improved_repr) == x
...     print putatively_improved_repr
0.07000000000000001
0.5600000000000001

(those aren't the only "2-digit" examples, but I expect those specific
examples work the same under Linux and Windows).

IOW, 16 doesn't eliminate base-conversion surprises, except at the 8
"single-digit surprises" (i/10.0 for i in range(1, 5) + range(6, 10)).

To eliminate "2-digit surprises" (like 0.07 and 0.56 above), and higher,
 in this way, you need to add a loop and keeping trying smaller
conversion widths so long as they convert back to the original input.

Keep it up, and you can make repr(float) so slow it would be faster to
do perfect rounding in Python ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul  4 03:51:20 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 01:51:20 +0000
Subject: [issue3277] socket's OOB data management is broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

I've tried to run the code below on Windows XP and Linux Ubuntu and it
works as expected. Here is the output:

expt -> o
read -> fo

On FreeBSD 7.0 it raises the following exception:

expt -> o
read -> fo 
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "_test2.py", line 13, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')





--- code ---

import socket, select, threading, time, os

def server():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(('', 1024))
    s.listen(1)
    conn, addr = s.accept()
    conn.setblocking(0)
    while 1:
        r, w, e = select.select([conn], [conn], [conn], 0.01)
        if e:
            data = conn.recv(1024, socket.MSG_OOB)
            print "expt -> " + data
        if r:
            data = conn.recv(1024)
            print "read -> " + data


threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('foo', socket.MSG_OOB)

--- /code ---

----------
messages: 69236
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's OOB data management is broken on FreeBSD
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Fri Jul  4 03:56:43 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 01:56:43 +0000
Subject: [issue3277] socket's OOB data management is broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215136603.43.0.852383677875.issue3277@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Fri Jul  4 04:18:01 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 02:18:01 +0000
Subject: [issue3278] socket's SO_REUSEADDR option does not work on FreeBSD
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

When the SO_OOBINLINE option is used against a socket, out-of-band data
should be placed in the normal data input stream as it is received.
In fact this is what happens on Windows and Linux by using the script below.
On FreeBSD this does not happen. select instead of returning a
"readable" file descriptor returns an "exceptional" file descriptor. 
Later, when we try to read some data from the socket, the following
exception is raised:


Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "_test2.py", line 14, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')





--- code ---

import socket, select, threading, time, os

def server():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(('', 1024))
    s.listen(1)
    conn, addr = s.accept()
    conn.setblocking(0)
    conn.setsockopt(socket.SOL_SOCKET, socket.SO_OOBINLINE, 1)
    while 1:
        r, w, e = select.select([conn], [conn], [conn], 0.01)
        if r:
            # the socket is supposed to be in the "readable" list
            data = conn.recv(1024)
            print "read -> " + data
        if e:
            # ...but not in the "exception" list
            data = conn.recv(1024, socket.MSG_OOB)
            print "expt -> " + data


threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('x', socket.MSG_OOB)

--- /code ---

----------
components: Library (Lib)
messages: 69237
nosy: giampaolo.rodola
severity: normal
status: open
title: socket's SO_REUSEADDR option does not work on FreeBSD
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Fri Jul  4 04:19:03 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 02:19:03 +0000
Subject: [issue3278] socket's SO_REUSEADDR option does not work on FreeBSD
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215137943.26.0.84743103065.issue3278@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

This bug should be strictly related with issue 3277:
http://bugs.python.org/issue3277

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Fri Jul  4 04:19:22 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 02:19:22 +0000
Subject: [issue3277] socket's OOB data management is broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215137962.49.0.830248690505.issue3277@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

This bug should be strictly related with issue 3278:
http://bugs.python.org/issue3278

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Fri Jul  4 05:40:27 2008
From: report at bugs.python.org (Roger Upole)
Date: Fri, 04 Jul 2008 03:40:27 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

In pythonrun.c, initstdio injects 'open' into builtins.  However,
initsite is called before initstdio and site.py uses open.
Running with -v, this traceback is printed:

Traceback (most recent call last):
  File "j:\python30\lib\site.py", line 518, in <module>
main()
  File "j:\python30\lib\site.py", line 501, in main
known_paths = addsitepackages(known_paths)
  File "j:\python30\lib\site.py", line 281, in addsitepackages
addsitedir(sitedir, known_paths)
  File "j:\python30\lib\site.py", line 178, in addsitedir
addpackage(sitedir, name, known_paths)
  File "j:\python30\lib\site.py", line 141, in addpackage
f = open(fullname, "rU")
NameError: global name 'open' is not defined

----------
messages: 69240
nosy: rupole
severity: normal
status: open
title: import of site.py fails on startup
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Fri Jul  4 06:30:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 04:30:32 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215145831.9.0.718756205421.issue3008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, I'm tied-up with EuroPython until the 14th.  Do you have time to 
take a crack at this?

----------
assignee: rhettinger -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 06:57:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Jul 2008 04:57:02 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215147422.47.0.577279516342.issue1580@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Here's a rough-and-tumble implementation of that idea, for Py3k.

Added file: http://bugs.python.org/file10808/float.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul  4 06:58:41 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Jul 2008 04:58:41 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215147521.18.0.605508318543.issue1580@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

That is truly maddening! :-(

I guess Noam's proposal to return str(x) if float(str(x)) == x makes
more sense then.  I don't really care as much about 1.234567890123 vs.
1.2345678901229999 as I care about 1.2345 vs. 1.2344999999999999.

(This comment is supposed to *precede* the patch.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul  4 07:48:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 04 Jul 2008 05:48:09 +0000
Subject: [issue3277] socket's OOB data management is broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215150489.0.0.302103457195.issue3277@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in Python, and not in FreeBSD?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Fri Jul  4 08:29:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 06:29:48 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215152987.93.0.712106443226.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Probably, but this affects all PyArg_ParseTuple("s#") calls that release
the GIL afterwards. How many of them are there?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Jul  4 09:13:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Jul 2008 07:13:14 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215155594.91.0.935827241614.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm working on it.  I expect to have something ready by the end of this 
weekend.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 11:02:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 09:02:04 +0000
Subject: [issue3280] %c format does not accept large numbers on ucs-2 builds
In-Reply-To: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za>
Message-ID: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Since python3.0, chr(0x2f81a) works even on narrow Unicode builds, but 
>>> "%c" % 0x2f81a
OverflowError: %c arg not in range(0x10000) (narrow Python build)

Likewise, Py_BuildValue("C") should accept codes outside the BMP.

----------
components: Unicode
messages: 69247
nosy: amaury.forgeotdarc
severity: normal
status: open
title: %c format does not accept large numbers on ucs-2 builds
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3280>
_______________________________________

From report at bugs.python.org  Fri Jul  4 11:05:54 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jul 2008 09:05:54 +0000
Subject: [issue3275] Control flow not optimized
In-Reply-To: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za>
Message-ID: <1215162354.27.0.883037566508.issue3275@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What real-life use case do you have for a condition that is a boolean
operation on two constant values anyway? Things like

while 1:
   ...

are properly optimized since they serve a useful purpose.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3275>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:00:31 2008
From: report at bugs.python.org (LI Daobing)
Date: Fri, 04 Jul 2008 11:00:31 +0000
Subject: [issue3281] support r"\"
In-Reply-To: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za>
Message-ID: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za>


New submission from LI Daobing <lidaobing at gmail.com>:

currently r"\" or r'\' is not a valid string literal and it is already
documented.

but this exception is not simple enough, it make users confused when
they found that r'C:\Program\Python\' does not work as expected.

please consider support this, thanks.

----------
components: None
messages: 69249
nosy: lidaobing
severity: normal
status: open
title: support r"\"
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3281>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:41:29 2008
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Jul 2008 11:41:29 +0000
Subject: [issue3249] bug adding datetime.timedelta to datetime.date
In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za>
Message-ID: <1215171689.39.0.359048994201.issue3249@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Amaury,

Yes, I agree with you, and that sucks too. I'd suggest opening another
bug for that ;-)

For an allegedly nice, shiny, new and perfect module, datetime sure
seems to have an awful lot lacking...

Chris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3249>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:42:43 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Jul 2008 11:42:43 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work on FreeBSD
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215171763.8.0.408541931825.issue3278@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
title: socket's SO_REUSEADDR option does not work on FreeBSD -> socket's SO_OOBINLINE option does not work on FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:44:00 2008
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Jul 2008 11:44:00 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1215171840.06.0.771113095499.issue3250@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Hi George,

I haven't looked at your patch but that fact that there are no unit
tests and you talk about copying and pasting code, I'd suggest this
might not be a good patch.

Refactor so code is only in one place rather than copying and pasting,
and make sure you write extensive unit tests, especially for things like
date/time...

cheers,

Chris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:47:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 11:47:27 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1215172047.95.0.519738559374.issue3279@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This happens if the site-packages directory contains a .pth file.

This was unnoticed because the usual message
   'import site' failed; use -v for traceback
is never printed: sys.stderr is empty before the call to initstdio().

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Fri Jul  4 13:55:29 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 04 Jul 2008 11:55:29 +0000
Subject: [issue3281] support r"\"
In-Reply-To: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za>
Message-ID: <1215172529.13.0.375433788851.issue3281@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

The "r" prefix changes how the escape sequences are interpreted after
the string literal has been parsed, it doesn't change how the literal
itself is actually parsed.

Fixing this will imply too much low level work, and it's easily solved
in other ways, so it's not foreseeable to change.

If you really want to push this, you should propose the change and how
to do it in python-ideas or python-dev.

Thank you!

----------
nosy: +facundobatista
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3281>
_______________________________________

From report at bugs.python.org  Fri Jul  4 15:30:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 13:30:07 +0000
Subject: [issue3282] Undefined unicode characters should be non-printable
In-Reply-To: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za>
Message-ID: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

str.isprintable() returns True for undefined unicode code points:

>>> c = "\ufffe"
>>> unicodedata.category(c)
'Cn'             # (Other, Not Assigned)
>>> c.isprintable()
True

Same for "\u0242", "\ufb12"...

The cause is probably in unicodectype.c: _PyUnicode_IsPrintable():
    return (ctype->flags & NONPRINTABLE_MASK) == 0;
but ctype->flags is 0 for undefined chars.

----------
components: Unicode
messages: 69254
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Undefined unicode characters should be non-printable
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3282>
_______________________________________

From report at bugs.python.org  Fri Jul  4 15:45:11 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 04 Jul 2008 13:45:11 +0000
Subject: [issue3283] multiprocessing.connection doesn't import
	AuthenticationError, while using it
In-Reply-To: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>
Message-ID: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

Lib/multiprocessing/connection.py contains two uses of
AuthenticationError, while it's not imported from multiprocessing
package. This exception is used in deliver_challenge() and
answer_challenge() functions. I've attached a small patch that fixes
possible NameError while calling any of these two functions.

----------
components: Library (Lib)
files: multiprocessing.connection.py.diff
keywords: patch
messages: 69255
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: multiprocessing.connection doesn't import AuthenticationError, while using it
versions: Python 3.0
Added file: http://bugs.python.org/file10809/multiprocessing.connection.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3283>
_______________________________________

From report at bugs.python.org  Fri Jul  4 15:45:13 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Jul 2008 13:45:13 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215179113.31.0.00368370321059.issue3008@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

BTW couldn't you use the %a feature built into C99 to implement this?
(Both input and output?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 16:12:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Jul 2008 14:12:25 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215180745.92.0.93598178833.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sure.  What about non-C99 machines?  I thought Python code was only 
allowed to assume ANSI C.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 16:28:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Jul 2008 14:28:30 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1215180745.92.0.93598178833.issue3008@psf.upfronthosting.co.za>
Message-ID: <ca471dc20807040728k5380ed04ub925ae3a2689dd35@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Fri, Jul 4, 2008 at 7:12 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Sure.  What about non-C99 machines?  I thought Python code was only
> allowed to assume ANSI C.

I'm pretty sure that's a thing of the past. Ask MvL.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 16:34:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jul 2008 14:34:03 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1215182043.92.0.425124663448.issue3279@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Fri Jul  4 16:45:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 14:45:25 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215182725.62.0.689265633166.issue3008@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Microsoft compilers implement %a since VS8.0. 
VS7.1 does not have it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul  4 17:01:04 2008
From: report at bugs.python.org (George Boutsioukis)
Date: Fri, 04 Jul 2008 15:01:04 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za>
Message-ID: <1215183664.65.0.798785112819.issue3250@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

Hi Chris,
 
 I know copy-pasted sounds horrible--perhaps I should have said 'modeled
afterwards'(better marketing;). The thing is, the datetime & time
classes share a lot of common functionality; it is inevitable that some
code looks like it's repeated, because the same process is followed(take
a look at the datetime & date functions already there). 
 I can't see much room for refactoring the arithmetic functions across
classes(seems too messy). Besides, the existing timezone, normalization
and delta functions are used, so no significant logic is repeated.The
patch indeed requires some cleanup, but overall it's good code(and not a
lot of it). 
 I submitted it without tests/doc because I think there should be a
chance for this functionality to be discussed. Also, the datetime module
looks like for some reason these functions were left out(some discussion
I'm missing?).

So before investing any more time on this some feedback would be
appreciated.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Fri Jul  4 17:55:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jul 2008 15:55:29 +0000
Subject: [issue3282] Undefined unicode characters should be non-printable
In-Reply-To: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za>
Message-ID: <1215186929.49.0.255091953484.issue3282@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in r64701...

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3282>
_______________________________________

From report at bugs.python.org  Fri Jul  4 18:51:41 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Jul 2008 16:51:41 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1215190301.26.0.770034823707.issue3279@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Fri Jul  4 20:44:26 2008
From: report at bugs.python.org (Andrew Azarov)
Date: Fri, 04 Jul 2008 18:44:26 +0000
Subject: [issue3277] socket's OOB data management is broken on FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215197066.07.0.651122680609.issue3277@psf.upfronthosting.co.za>


Andrew Azarov <equand at gmail.com> added the comment:

tested:

Python 2.5.2 (r252:60911, Jun 24 2008, 16:40:26) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

FreeBSD tomcat 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52
UTC 2008     root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

expt -> o
read -> fo
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 486, in
__bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.5/threading.py", line 446, in run
    self.__target(*self.__args, **self.__kwargs)
  File "test.py", line 13, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')

and:
Python 2.5 (r25:51908, Jun 25 2007, 16:00:15) 
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5

FreeBSD timcat 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sat Sep  9 03:32:05
MSD 2006     root at timcat:/usr/obj/usr/src/sys/SMP  i386

expt -> o
read -> fo
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "test.py2", line 13, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')

and:

Python 2.4.3 (#1, Jun 23 2006, 10:54:52) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4

FreeBSD comanchee-girl 4.9-RELEASE-CMN-1.1 FreeBSD 4.9-RELEASE-CMN-1.1
#4: Mon Apr 26 02:11:27 MSD 2004    
root at comanchee-girl:/usr/obj/usr/src/sys/CMN  i386

expt -> o
read -> fo
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.4/threading.py", line 422, in run
    self.__target(*self.__args, **self.__kwargs)
  File "test.py", line 13, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')


All versions are stable and working in production. Except 7th version
the servers are loaded (la 0.2 to 3) with http/mysql/mail daemons.
Seems like a bug in python socket usage of freebsd for long time.

----------
nosy: +Ikinoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Fri Jul  4 21:26:09 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jul 2008 19:26:09 +0000
Subject: [issue3284] Delete obsolete 'Unicode' in Py3 str docstrings;
	related fixes
In-Reply-To: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za>
Message-ID: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 3.0b1, several str methods have 'Unicode' in their docstrings
leftover from 2.x when str *was* unicode.

For
  center
  count
  ljust
  rjust
  translate
'Unicode' should be deleted before 'string'.
For 'translate', I presume 'Unicode ordinal' should be left as is as was
done for 'maketrans'.

For
  lstrip
  rstrip
  strip
"If chars is a str, it will be converted to unicode before stripping"
should be deleted.  Bytes (which replace old str) and bytearrays are not
automatically converted.

Other fixes

For
  maketrans
the word 'then' should be removed from 'will then be' in the fourth line
since it only confuses.  The conversion is the first and only thing done
in the one-argument case.

For
  lstrip
  rstrip
  strip
remove ', Unicode' from
"TypeError: <x>strip arg must be None, unicode or str"

For
  ljust
  rjust
"TypeError: The fill character cannot be converted to Unicode"
should be changed to
TypeError: The fill character cannot be implicitly converted to str"
or even, copying from several other method error messages
TypeError: Can't convert 'bytes' object to str implicitly"
or perhaps best would be
"TypeError: For the fill char, can't convert 'bytes' object to str
implicitly"

The other methods taking str args seem to have been updated already.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 69263
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Delete obsolete 'Unicode' in Py3 str docstrings; related fixes
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3284>
_______________________________________

From report at bugs.python.org  Fri Jul  4 21:36:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 19:36:27 +0000
Subject: [issue3285] Fraction.from_any()
In-Reply-To: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za>
Message-ID: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

After exercising the fractions module, I've found it problematic that 
there isn't a unified constructor to handle mixed data input types.  

For example, when updating the accurate summation recipe at 
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393090 to show 
how it could be done with rational arithmetic.  Handling mixed-type 
inputs required writing a factory function:

    def makefrac(x):
        if isinstance(x, Decimal):
            return Fraction.from_decimal(x)
        if isinstance(x, float):
            return Fraction.from_float(x)
        return Fraction(x)

That function supported a clean version of the recipe:

    def frsum(iterable):
        return float(sum(map(makefrac, iterable)))

It would have been much better if that functionality were built into 
the class definition.  See attached patch.

----------
components: Library (Lib)
files: from_any.diff
keywords: patch
messages: 69264
nosy: rhettinger
severity: normal
status: open
title: Fraction.from_any()
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10810/from_any.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3285>
_______________________________________

From report at bugs.python.org  Fri Jul  4 21:45:26 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jul 2008 19:45:26 +0000
Subject: [issue3286] IDLE opens window too low on Windows
In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>
Message-ID: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

On my Windows XP system, IDLE opens windows too low, even the first, so
that the bottom is behind the task bar.  When I move the window up,
close, and reopen, it occasionally remembers the position but usually
forgets.  Always remembering would be nicer.

It also seems to me that the default should at least be centered, but
preferably even higher since new windows are cascaded down.

Or Configure/General could have an initial position for first window
entry just below or above the initial size.

----------
components: IDLE
messages: 69265
nosy: tjreedy
severity: normal
status: open
title: IDLE opens window too low on Windows
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3286>
_______________________________________

From report at bugs.python.org  Fri Jul  4 21:55:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 04 Jul 2008 19:55:55 +0000
Subject: [issue3284] Delete obsolete 'Unicode' in Py3 str docstrings;
	related fixes
In-Reply-To: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za>
Message-ID: <1215201355.44.0.765178419452.issue3284@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Done in r64716.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3284>
_______________________________________

From report at bugs.python.org  Fri Jul  4 21:57:23 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 19:57:23 +0000
Subject: [issue3287] Fraction constructor should raise TypeError instead of
	AttributeError
In-Reply-To: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>
Message-ID: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

>>> from fractions import *
>>> Fraction(3.1)

Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    Fraction(3.1)
  File "C:\Python26\lib\fractions.py", line 100, in __new__
    numerator = numerator.__index__()
AttributeError: 'float' object has no attribute '__index__'

----------
assignee: jyasskin
components: Library (Lib)
messages: 69267
nosy: jyasskin, rhettinger
severity: normal
status: open
title: Fraction constructor should raise TypeError instead of AttributeError
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3287>
_______________________________________

From report at bugs.python.org  Fri Jul  4 22:08:00 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2008 20:08:00 +0000
Subject: [issue3287] Fraction constructor should raise TypeError instead of
	AttributeError
In-Reply-To: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>
Message-ID: <1215202080.06.0.487513667483.issue3287@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file10811/fractype.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3287>
_______________________________________

From report at bugs.python.org  Fri Jul  4 23:31:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Jul 2008 21:31:38 +0000
Subject: [issue3280] %c format does not accept large numbers on ucs-2 builds
In-Reply-To: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za>
Message-ID: <1215207098.88.0.850683166032.issue3280@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r64717.

----------
resolution:  -> fixed
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3280>
_______________________________________

From report at bugs.python.org  Sat Jul  5 01:38:42 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Jul 2008 23:38:42 +0000
Subject: [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1215214722.33.0.322501475797.issue3168@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Below is the reply from SUN.  It was indeed a bug which has been fixed already.

I have not yet applied the patches to my SUN compilers and tried again.

/Jean

Begin forwarded message:

From: Sun Microsystems <IncidentUpdateDaemon at sun.com>
Date: July 1, 2008 3:51:17 PM PDT

Subject: Re: (Incident Review ID: 1284413) Sun C 5.8 optimization bug for 64-bit Opteron

--- Note: you can send us updates about your Incident ---
--- by replying to this mail.  Place new information  ---
--- above these lines.  Do not include attachments.   ---
--- Our system ignores attachments and anything below ---
--- these lines.                                      ---

Hi Jean Brouwers,

We appreciate your feedback.  Using your sample I was able to get the correct results using Sun 
Studio 12.  This may indicate that the issue was also fixed in a backported patch to Studio 11 (Sun 
C 5.8).  Check to be sure that the latest patches have been applied to your installation.  See:

<http://developers.sun.com/sunstudio/downloads/patches/ss11_patches.html>

Regards,
Brad Mayer

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This message, including any attachments, is for the intended
recipient(s) only.  If you are not the intended recipient(s), please
reply to the sender, delete this message, and refrain from disclosing,
copying, or distributing this message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--------------- Previous Messages ----------------


--------------------- Report ---------------------

      category : c
   subcategory : compiler
       release : other
          type : bug
      synopsis : Sun C 5.8 optimization bug for 64-bit Opteron
 customer name : Jean Brouwers
        sdn id : 
      language : en
      hardware : x86
            os : sol2.5.1
        bug id : 0
  date created : Sun Jun 29 11:49:10 MST 2008
date evaluated : Tue Jul 01 15:41:10 MST 2008
   description : 

FULL PRODUCT VERSION :
which cc
/opt/SUNWspro/bin/cc
cc -V
cc: Sun C 5.8 2005/10/13

ADDITIONAL OS VERSION INFORMATION :
uname -a
SunOS unknown 5.10 Generic_118855-14 i86pc i386 i86pc


EXTRA RELEVANT SYSTEM CONFIGURATION :
Solaris 10 on an Ultra20 Opteron machine.


A DESCRIPTION OF THE PROBLEM :
At higher optimization levels, the Sun C compiler does not handle certain function call patterns 
correctly.  Specifically, the values of complex_t  variables q and r in the code snippet below are 
different.

typedef struct {
	double real;
	double imag;
} complex_t;

complex_t c_comp(double real);
complex_t c_quot(complex_t a, complex_t b);
...
	complex_t_t x, y, q, r;

	x = c_comp(4.6051701859880918);
	y = c_comp(0.69314718055994529);

	q = c_quot(x, y);

	r = c_quot(x, c_comp(0.6931471805599452));
...

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See the attached test case.  Instructions are included inside.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -

rm a.out ; cc -xtarget=native64 -xO0 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
6.643856 + j 0.000000

ACTUAL -

rm a.out ; cc -xtarget=native64 -xO3 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
Inf + j 0.000000


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

/* Split this file in 3 separate file, c_main.c, c_quot.h and
   c_quot.c.  Compile with and without optimization using Sun
   C 5.8 compiler on Solaris 10 (Opteron) and run as follows.

rm a.out ; cc -xtarget=native64 -xO0 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
6.643856 + j 0.000000

rm a.out ; cc -xtarget=native64 -xO1 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
6.643856 + j 0.000000

rm a.out ; cc -xtarget=native64 -xO2 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
6.643856 + j 0.000000

rm a.out ; cc -xtarget=native64 -xO3 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
Inf + j 0.000000

rm a.out ; cc -xtarget=native64 -xO4 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
Inf + j 0.000000

rm a.out ; cc -xtarget=native64 -xO5 c_main.c c_quot.c -lm ; ./a.out
c_main.c:
c_quot.c:
6.643856 + j 0.000000
Inf + j 0.000000

*/


------------------ save as c_main.c -----------------
#include <stdio.h>
#include "c_quot.h"

int main(int argc, char* argv[])
{
	complex_t x, y, q, r;

	x = c_comp(4.6051701859880918);
	y = c_comp(0.69314718055994529);
	q = c_quot(x, y);
	/* expect: 6.643856 + j 0.000000 */
	printf("%f + j %f\n", q.real, q.imag);

	x = c_comp(4.6051701859880918);
	y = c_comp(0.69314718055994529);
	r = c_quot(x, c_comp(0.6931471805599452));
	/* expect: 6.643856 + j 0.000000, but ... */
	printf("%f + j %f\n", r.real, r.imag);
}


------------------ save as c_quot.h -----------------
typedef struct {
	double real;
	double imag;
} complex_t;

complex_t c_comp(double real);
complex_t c_quot(complex_t a, complex_t b);


------------------ save as c_quot.c -----------------
#include "c_quot.h"

complex_t
c_comp(double real)
{
	complex_t c;
	c.real = real;
	c.imag = 0.0; /* ignore imag */
	return c;
}

complex_t
c_quot(complex_t a, complex_t b)
{
	complex_t r;
	r.real = a.real / b.real;
	r.imag = 0.0; /* ignore imag */
	return r;
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Compiling with -xO... less than 3 avoids the problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3168>
_______________________________________

From report at bugs.python.org  Sat Jul  5 02:40:37 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 05 Jul 2008 00:40:37 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215218437.23.0.457055948897.issue3221@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, setting an invalid value for __package__ will definitely break
relative imports (see PEP 361), but it probably shouldn't be breaking
absolute imports.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Sat Jul  5 02:54:04 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 05 Jul 2008 00:54:04 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215219244.07.0.295378722997.issue3221@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One idea would be to change the import code to only produce a warning
for a missing __package__ entry instead of a SystemError (reserving the
SystemError for cases where the package name is derived from __name__
rather than being retrieved from the __package__ attribute).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Sat Jul  5 07:58:47 2008
From: report at bugs.python.org (Kevin Goodsell)
Date: Sat, 05 Jul 2008 05:58:47 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1215237527.34.0.280734658782.issue1754483@psf.upfronthosting.co.za>


Kevin Goodsell <sourceforge.20.fusion at neverbox.com> added the comment:

Hans is right, that patch isn't very good. Here's a second pass. This
one avoids joining the file basename to sys.path components, which I'd
say is wrong since it strips (presumably relevant) leading path components.

A second part of this skips out early on absolute file names, which
prevents joining them with sys.path components also. As far as I can
tell this would cause no harm, but it's not useful either.

Added file: http://bugs.python.org/file10812/linecache.py_2008_07_04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Sat Jul  5 08:00:56 2008
From: report at bugs.python.org (Kevin Goodsell)
Date: Sat, 05 Jul 2008 06:00:56 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1215237656.18.0.961954896777.issue1754483@psf.upfronthosting.co.za>


Kevin Goodsell <sourceforge.20.fusion at neverbox.com> added the comment:

Here's a small test script.

Added file: http://bugs.python.org/file10813/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Sat Jul  5 10:58:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 08:58:13 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215248292.8.0.944461678618.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

In the interests of getting early feedback, here's half a patch, 
containing an implementation of from.fromhex and tests.

Still to come:  float.hex and documentation.

I'll ask on python-dev about C99 and %a.

Added file: http://bugs.python.org/file10814/hex_float.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul  5 11:02:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 09:02:59 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215248579.53.0.89195377877.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> containing an implementation of from.fromhex and tests.

That should be 'float.fromhex', not 'from.fromhex'.
I should also have said that this patch is against the trunk;  only minor 
changes should be required for py3k.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul  5 11:49:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Jul 2008 09:49:01 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1215251341.29.0.968037953114.issue1754483@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Sat Jul  5 12:13:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Jul 2008 10:13:53 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1215252833.85.0.914099171699.issue2663@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r64722. Thanks everyone!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
_______________________________________

From report at bugs.python.org  Sat Jul  5 12:41:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 10:41:18 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The float.as_integer_ratio method needs to be documented somewhere other 
than whatsnew/2.6.rst.

----------
assignee: georg.brandl
components: Documentation
messages: 69277
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: float.as_integer_ratio method is not documented
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Sat Jul  5 13:08:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 11:08:58 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215256138.89.0.690769009768.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated patch, complete with both float methods and 
documentation.

Added file: http://bugs.python.org/file10815/hex_float2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul  5 14:37:21 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Sat, 05 Jul 2008 12:37:21 +0000
Subject: [issue1754483] linecache package handling
Message-ID: <1215261441.87.0.591509728069.issue1754483@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

Even with that patch, I'm still getting backtraces similar to this:

Traceback (most recent call last):
  File "/home/user/foo/src/foo", line 83, in <module>
    foomain(sys.argv)
  File "/home/uli/foo/src/foo", line 79, in foomain
    foolib.main.cmdmain(sys.argv)
  File "./foolib/main.py", line 250, in cmdmain
  File "./foolib/main.py", line 199, in main
  File "./foolib/main.py", line 180, in __init__
  File "./foolib/main.py", line 115, in __get__
AttributeError: property--48216a94

Looks like I should write a dozen test cases I can think of on my own. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754483>
_______________________________________

From report at bugs.python.org  Sat Jul  5 14:42:40 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 12:42:40 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215261760.48.0.382588597986.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Add updated patch with expanded documentation.

Added file: http://bugs.python.org/file10816/hex_float2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul  5 14:42:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 12:42:49 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215261769.47.0.531047702661.issue3008@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file10815/hex_float2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul  5 17:23:16 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 15:23:16 +0000
Subject: [issue3188] float('infinity') should be valid
In-Reply-To: <1214304455.81.0.663476079399.issue3188@psf.upfronthosting.co.za>
Message-ID: <1215271396.69.0.449311066884.issue3188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Checked in, r64729.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3188>
_______________________________________

From report at bugs.python.org  Sat Jul  5 17:26:30 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 15:26:30 +0000
Subject: [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1215271590.34.0.421823984145.issue3168@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Jean.  I've checked in your workaround in r64735.

Leaving this open for now as a reminder about finite/is_finite.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3168>
_______________________________________

From report at bugs.python.org  Sat Jul  5 18:13:29 2008
From: report at bugs.python.org (Jon Nelson)
Date: Sat, 05 Jul 2008 16:13:29 +0000
Subject: [issue3289] unnecessary call to time and localtime slows time.mktime
In-Reply-To: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za>
Message-ID: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za>


New submission from Jon Nelson <jnelson+python at jamponi.net>:

Basically, time.mktime calls time and localtime, and then overwrites
those results. Removing these unnecessary calls results in a fairly
noticeable speedup, lower double-digit percentile improvements for
applications that do time parsing, for example.

The patch below is for 2.5, but should apply to more recent versions.

diff --git a/Modules/timemodule.c b/Modules/timemodule.c
index be02ec2..dad235a 100644
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -599,8 +599,6 @@ time_mktime(PyObject *self, PyObject *tup)
 {
        struct tm buf;
        time_t tt;
-       tt = time(&tt);
-       buf = *localtime(&tt);
        if (!gettmarg(tup, &buf))
                return NULL;
        tt = mktime(&buf);

----------
components: Extension Modules
messages: 69283
nosy: nother_jnelson
severity: normal
status: open
title: unnecessary call to time and localtime slows time.mktime
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3289>
_______________________________________

From report at bugs.python.org  Sat Jul  5 18:39:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Jul 2008 16:39:39 +0000
Subject: [issue3235] Improve subprocess module usage
In-Reply-To: <1214731574.46.0.694544049658.issue3235@psf.upfronthosting.co.za>
Message-ID: <1215275979.4.0.530717787969.issue3235@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't understand the comment about poll().

In any case, I plan on referencing Doug's PyMOTW pages for all modules
he does, since they are indeed excellent tutorials.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3235>
_______________________________________

From report at bugs.python.org  Sat Jul  5 20:34:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 18:34:56 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1215282896.03.0.62683257353.issue1023290@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pickle is a solution only if you accept the target format to be opaque,
which is not what you are looking for usually.
Once again I just had to write the cumbersome:

junk_len = 1024
junk =  (("%%0%dX" % junk_len) % random.getrandbits(junk_len *
8)).decode("hex")

... because there is no obvious way to convert longs to bytes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Jul  5 20:35:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 18:35:49 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215282949.16.0.548133345407.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If I try to follow the chain the consequences:
 - all PyArg_ParseTuple("s#") calls that release the GIL afterwards
should be re-written to use another API (which one I don't know exactly,
but hopefully the appropriate functions are already provided by the
buffer API); this applies to third-party extension modules as well
 - consequently, forward compatibility is broken in an important way
(but it would probably be ok for py3k)
 - perhaps the bytearray type should not have been backported to 2.6, or
perhaps it should carry a big warning in the documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Jul  5 20:39:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 18:39:19 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215283159.58.0.225552053347.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, here's a more reliable way to make it crash (on my Linux
machine):


import bz2, threading

bz2c = bz2.BZ2Compressor()
# Span at least a whole arena (256KB long)
junk_len = 512 * 1024
junk = b"a" * junk_len
buf = bytearray()

for x in range(50):
    buf[:] = junk
    t = threading.Thread(target=bz2c.compress, args=[buf])
    t.start()
    buf[:] = b""
    t.join()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Jul  5 20:48:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 18:48:16 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215283696.15.0.292198046158.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now I've just discovered there is the same problem with the
array.array() type (see following code).


import bz2, threading, array

bz2c = bz2.BZ2Compressor()
# Span at least a whole arena (256KB long)
junk_len = 512 * 1024
junk = array.array("c", b"a") * junk_len
empty = array.array("c")
buf = empty[:]

for x in range(50):
    buf[:] = junk
    t = threading.Thread(target=bz2c.compress, args=[buf])
    t.start()
    buf[:] = empty
    t.join()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Jul  5 21:09:07 2008
From: report at bugs.python.org (Sacha Varma)
Date: Sat, 05 Jul 2008 19:09:07 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>


New submission from Sacha Varma <sacha-python at ssl.co.uk>:

As I understand it, python-config --cflags is intended to yield the C
compiler flags needed to compile a program that uses Python headers and
libraries (as opposed to the C flags needed to compile python itself).

However, it seems to include irrelevant options such as -Wall and -O3,
which interfere with the build (for example, by enabling optimisation in
a debug build):

$ python-config --cflags
-I/opt/Python-2.5.1/include/python2.5
-I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes

----------
components: Build
messages: 69289
nosy: sacha
severity: normal
status: open
title: python-config --cflags includes irrelevant flags
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Sat Jul  5 21:36:00 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 05 Jul 2008 19:36:00 +0000
Subject: [issue3289] unnecessary call to time and localtime slows time.mktime
In-Reply-To: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za>
Message-ID: <1215286560.44.0.376475759074.issue3289@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in r64745. Thanks for this patch!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3289>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:10:34 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jul 2008 20:10:34 +0000
Subject: [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1215288634.52.0.627512039296.issue3168@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> There is another, perhaps related issue on Solaris.  The compiler warns 
> that function  finite is implicitly defined.
>
> Commenting out this line in pyconfig.h as
>
> /* #define HAVE_FINITE 1 */
>
> make that warning go away.  If there is no function  finite, why is 
> HAVE_FINITE defined at all?

I don't think this is too serious.  My guess would be that both finite and 
isfinite (which is the C99-recommended way to spell finite) are 
implemented in libm, but that only isfinite is mentioned in math.h (or 
possibly that finite is mentioned is math.h but is ifdef'd out as a result 
of some particular compiler options).

So a code snippet that refers to 'finite' emits a warning, but compiles 
fine.  Hence the corresponding autoconf test passes, and autoconf sets 
HAVE_FINITE to 1.  And the Python build also emits a warning, but compiles 
and runs fine.

Could you take a look in the 'config.log' file after configuring and see 
whether the 'implicit definition of finite' warning is in there as well?

The right fix is probably to rework things to use 'isfinite' in preference 
to 'finite'.  I'm not sure that Windows has isfinite, though.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3168>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:10:51 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Jul 2008 20:10:51 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1215288651.0.0.57858685083.issue3290@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Georg, what do you think?

----------
assignee:  -> georg.brandl
nosy: +georg.brandl, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:29:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 20:29:43 +0000
Subject: [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In the latest py3k versions, rlcompleter doesn't work anymore. Pressing
the tab key (with tab-completion enabled) doesn't produce anything on
screen.

----------
components: Library (Lib)
messages: 69293
nosy: pitrou
severity: normal
status: open
title: rlcompleter doesn't work anymore
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:32:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Jul 2008 20:32:26 +0000
Subject: [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215289946.29.0.26580115869.issue3291@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Antoine, can you try it before r64671?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:40:35 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 05 Jul 2008 20:40:35 +0000
Subject: [issue3239] curses/textpad.py incorrectly and redundantly imports
	ascii
In-Reply-To: <1214774912.88.0.531536472348.issue3239@psf.upfronthosting.co.za>
Message-ID: <1215290435.69.0.409171570606.issue3239@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in r64746. Thank you!!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3239>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:52:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 20:52:46 +0000
Subject: [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289946.29.0.26580115869.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215291163.6037.3.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 05 juillet 2008 ? 20:32 +0000, Benjamin Peterson a ?crit :
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
> 
> Antoine, can you try it before r64671?

Bingo, the regression occurs exactly at r64671.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________

From report at bugs.python.org  Sat Jul  5 22:59:14 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Jul 2008 20:59:14 +0000
Subject: [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1215291554.79.0.61705541911.issue3168@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Can't find that particular message.  Attached is the entire log of one of 
the SUN C builds of Python 2.6b1.

Added file: http://bugs.python.org/file10817/config.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3168>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:06:36 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Jul 2008 21:06:36 +0000
Subject: [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1215291996.34.0.118988416837.issue3168@psf.upfronthosting.co.za>


Changes by Jean Brouwers <MrJean1 at Gmail.com>:


Added file: http://bugs.python.org/file10818/config64.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3168>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:10:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 21:10:13 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1215292213.58.0.365143858797.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This new patch adds re.ASCII in all sensitive places I could find in the
stdlib (except lib2to3 which as far as I understand is maintained in a
separate branch, and even has its own copy of tokenize.py...).

Also, I didn't get an answer to the following question on the ML: should
an inline flag "(?a)" be introduced to mirror the existing "(?u)" - so
as to set the ASCII flag from inside a pattern string.

Added file: http://bugs.python.org/file10819/reunicode4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:17:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 21:17:13 +0000
Subject: [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215292633.77.0.47383722112.issue3291@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a fix (in addition to the one you already committed).

----------
keywords: +patch
Added file: http://bugs.python.org/file10820/rlcompleter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:21:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Jul 2008 21:21:20 +0000
Subject: [issue3291] rlcompleter doesn't work anymore
In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za>
Message-ID: <1215292879.97.0.567838922091.issue3291@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the report and the fix! (committed in r64748)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3291>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:30:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 21:30:05 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1215293405.33.0.884990146827.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

http://codereview.appspot.com/2439

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Sat Jul  5 23:37:35 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jul 2008 21:37:35 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Suggested changes to Lib Ref Manual: Sequence Types --...(3.6 for 2.5)

(These are mostly based on an issue posted on c.l.p. The Plone
Archetypes package (which I know nothing of) was reported as suggesting
that users pass sys.maxint, to indicate 'insert at end', to one of their
functions that uses .insert.  A user with an AMD64 did that ... and I
could not find doc proof that the crash was not a Python bug.)

Main section:

Before the operation list, change "n, i and j are integers:" to "n, i,
j, and k are integers:"

After the above, add "An implementation may limit the range of position
indexes (some uses of i below)."  I do not know if this limitation,
actual for CPython is documented elsewhere, but it should be here.  In
particular, i is used as both position and slice index.

Consider using i only as a magnitude-limited position index (an
'index-sized integer' as one error message puts it) and j,k,l for
unlimited slice and other integers. This would slightly change the
suggestions above and entail replacements in the table here and in
following subsections.

Mutable Sequence Types

In 3.0, .count and .index are general sequence methods and should be
moved up to that section.  (For .index, parameters i & j are not
(limited) position indexes but simply integers for comparison.  The
notation change suggested above would make this clear without one having
to experiment or infer from the comparison rule.)

The line "s.insert(i, x)  same as s[i:i] = [x]" is not true when i is
outside the range of allow position indexes.  If i is not defined as a
limited range integer (and the implementation not changed ;-) add a
footnote "only when i is within the range of allowed position indexes."

Is there a policy on documenting possible operation-specific exceptions?
 I consider them part of the interface.  Or should I bring this up on pydev?

For 3.0, footnotes 3 and 7 (in this subsection) document 2, for 4
different operations.  Here are a couple more related to this issue.

In the main section, for s[i]:
2.x IndexError: cannot fit 'long' into an index-sized integer
3.0 IndexError: cannot fit 'int' into an index-sized integer

In the subsection, for s.insert(i,x):
2.x OverflowError: long int too large to convert to int
3.0 OverflowError: Python int too large to convert to C ssize_t

I actually think the OverflowError should be changed to IndexError since
the problem is the same in both cases, but that is a different issue.

----------
assignee: georg.brandl
components: Documentation
messages: 69302
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Position index limit; s.insert(i,x) not same as s[i:i]=[x]
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:05:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:05:03 +0000
Subject: [issue3293] incorrect comments for PyObject_ReleaseBuffer
In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
Message-ID: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The declaration for PyObject_ReleaseBuffer (in Include/abstract.h) has
the following comments attached to it. But the part about the return
value is wrong since the function is defined as returning void. Also,
PEP 3118 says it always succeeds so it can't return an error code.

By the way, may I suggest that having the buffer API declared in
abstract.h but the Py_buffer struct declared in object.h (and why not in
bufferobject.h?) is slightly confusing.

	/* C-API version of the releasebuffer function call.  It
	   checks to make sure the object has the required function
	   pointer and issues the call.  The obj must have the buffer
	   interface or this function will cause a segfault (i.e. it
	   is assumed to be called only after a corresponding
	   getbuffer which already verified the existence of the
	   tp_as_buffer pointer).

           Returns 0 on success and -1 (with an error raised) on
           failure.  This function always succeeds (as a NO-OP) if
           there is no releasebuffer function for the object so that
           it can always be called when the consumer is done with the
           buffer
        */

----------
components: Interpreter Core
messages: 69303
nosy: pitrou
severity: normal
status: open
title: incorrect comments for PyObject_ReleaseBuffer
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3293>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:20:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Jul 2008 22:20:59 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215296459.52.0.876354241978.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I believe the 2.6 s# processing works correctly; the error is in the
bytearray object. This either shouldn't support the buffer interface, or
it shouldn't reallocate the buffer after having returned a pointer to it.

For 3k, convertbuffer shouldn't call bf_releasebuffer; instead, the
caller of ParseTuple somehow needs to release the buffer. As a
consequence, s# should refuse buffer objects who have a bf_releasebuffer
operation, and another code might get added to fill out a Py_buffer - or
s# can get changed to always produce a Py_buffer (which would affect the
code significantly).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:27:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:27:06 +0000
Subject: [issue3294] SVN repository contains an incorrect symbolic link
In-Reply-To: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za>
Message-ID: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In the py3k SVN branch I can see the following link. I suppose it is a
mistake?

$ ls -la Mac/IDLE/IDLE.app/Contents/MacOS/Python
lrwxrwxrwx 1 antoine antoine 92 2008-07-01 22:33
Mac/IDLE/IDLE.app/Contents/MacOS/Python ->
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python

----------
components: Build, Macintosh
messages: 69305
nosy: pitrou
severity: normal
status: open
title: SVN repository contains an incorrect symbolic link
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3294>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:29:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:29:39 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Astonishingly, PyExc_BufferError is defined in pyerrors.h but it is
defined nowhere. Consequently, any piece of code raising a
PyExc_BufferError will cause the interpreter to crash as soon as it
tries to do something with the exception...

----------
components: Interpreter Core
messages: 69306
nosy: pitrou
severity: normal
status: open
title: PyExc_BufferError is declared but nowhere defined
type: crash
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:39:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:39:00 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1215296459.52.0.876354241978.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215297537.6037.10.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 05 juillet 2008 ? 22:20 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I believe the 2.6 s# processing works correctly; the error is in the
> bytearray object. This either shouldn't support the buffer interface, or
> it shouldn't reallocate the buffer after having returned a pointer to it.

getbuffer and releasebuffer exist in both 2.6 and 3.0, and bytearray
supports those methods in both.

As for array.array, it only implements old buffer API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:40:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:40:14 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1215297614.0.0.956569512612.issue3295@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following patch fixes it.

----------
keywords: +patch
nosy: +teoliphant
Added file: http://bugs.python.org/file10821/buffererror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:47:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:47:19 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215298039.03.0.622302184602.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For reference, here is a proof-of-concept patch which shows how to fix
the bytearray crasher above (it raises a BufferError instead).

Added file: http://bugs.python.org/file10822/bzcrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:47:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:47:54 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215298074.5.0.252829831358.issue3139@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10822/bzcrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:48:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jul 2008 22:48:03 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215298083.15.0.142538838984.issue3139@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file10823/bzcrash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 00:52:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Jul 2008 22:52:43 +0000
Subject: [issue3294] SVN repository contains an incorrect symbolic link
In-Reply-To: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za>
Message-ID: <1215298363.22.0.531403186878.issue3294@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r64749.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3294>
_______________________________________

From report at bugs.python.org  Sun Jul  6 01:31:08 2008
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 05 Jul 2008 23:31:08 +0000
Subject: [issue3296] print function not executed in python 3.0 tutorial
In-Reply-To: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za>
Message-ID: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

It is for sure only a minor issue, but the new tutorial should not
confuse readers as the print function is not executed here and does not
do anything at all. Patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: doc-patch
messages: 69311
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: print function not executed in python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file10824/doc-patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3296>
_______________________________________

From report at bugs.python.org  Sun Jul  6 01:38:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Jul 2008 23:38:44 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1215301123.99.0.306511432758.issue3295@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Done in r64751.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Sun Jul  6 01:40:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Jul 2008 23:40:25 +0000
Subject: [issue3296] print function not executed in python 3.0 tutorial
In-Reply-To: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za>
Message-ID: <1215301225.0.0.843440909951.issue3296@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r64752.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3296>
_______________________________________

From report at bugs.python.org  Sun Jul  6 05:36:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 03:36:26 +0000
Subject: [issue2862] cleanup of freelist management
In-Reply-To: <1210859181.3.0.311974356319.issue2862@psf.upfronthosting.co.za>
Message-ID: <1215315386.53.0.453863423268.issue2862@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

committed to 2.6 trunk in r64753.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2862>
_______________________________________

From report at bugs.python.org  Sun Jul  6 06:04:51 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 04:04:51 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1215317091.76.0.321380137697.issue2632@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

committed to release25-maint in r64754.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
_______________________________________

From report at bugs.python.org  Sun Jul  6 07:37:19 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 05:37:19 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1215322639.62.0.209774813746.issue2620@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10027/issue2620-gps01-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:10:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 06:10:55 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1215324655.79.0.207088909782.issue3292@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please bring it up on python-dev.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:19:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 06:19:03 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1215325143.2.0.00504738234372.issue3290@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think you're right.

However, Martin, what flags except -I can/must we keep?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:28:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 06:28:33 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215325713.59.0.0790516399729.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Fixing this in the methods themselves has the disadvantage that the
error reporting is not that good anymore.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:42:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 06:42:31 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1215326551.91.0.388201456509.issue2620@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

here's an updated patch.  It makes PyMem_NEW and PyMem_RESIZE macros
always do explicit an overflow check before doing the multiplication.

Uses of the the macros have been cleaned up in the couple places I
noticed that would leak memory or corrupt their own state by replacing
the original pointer to their memory with NULL on error before raising
MemoryError.  This bug was already present in the existing code if
realloc ever returned NULL.

(IMHO PyMem_RESIZE & PyMem_Resize are a poorly designed macros.  The
blind pointer assignment should never have been done within the macro. 
But given that it is exposed as an API and presumably used by third
party extension modules the broken API must be maintained.)

Added file: http://bugs.python.org/file10825/issue2620-gps02-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:43:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 06:43:32 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1215326612.77.0.210059793704.issue3290@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Some flags for the compiler are really needed to compile the Python
headers correctly, e.g. -fno-strict-aliasing in 2.6.

So I think an explicit list of options reported would have to be
maintained, either as a blacklist (e.g. -O<n>, -Wall), or as a white list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Sun Jul  6 08:58:44 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2008 06:58:44 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Problem: when you have Unicode characters with a code point greater than
U+FFFF written directly in the source file (that is, not in the form
u'\Uxxxxxxxx' but as normal chars in a u'' string) the interpreter uses
surrogate pairs for representing these characters only if the pyc
doesn't exist. When the pyc is created it uses a "normal" character
(\Uxxxxxxxx instead of the pair \uxxxx\uxxxx). This could lead to an
unexpected behavior while comparing Unicode strings or in other
situations (even if it could be solved without problems in different
ways - using u'\Uxxxxxxx' or u'\uxxx' instead of the characters,
encoding them before comparing - there shouldn't be differences between
a py and its pyc).

Tested on:
Ubuntu 8.04 with python 2.4: Uses a surrogate pair.
Ubuntu 8.04 with python 2.5: Uses a surrogate pair.
Windows XP SP2 with python 2.4: Uses a "normal" character.

Steps to reproduce the problem:
 1a. download the attached file or create it following the next step;
 1b. in a UTF-8-aware console write `print 
unichr(int('10123', 16))` (or any codepoint >= 10000), copy the printed
character (depending on the console it could be a box, two box or a
character) in a file with the lines `# -*- coding: utf-8 -*-`, `print
'Result:', u'<paste here the char>' == u'\U00010123'` and `print
'Repr:', repr(u'<paste here the char>'), repr(u'\U00010123')`. Save the
file in UTF-8;
 2. open a python interpreter and import the file (`import
unicodetest`). It should print `Result: False` and `Repr:
u'\ud800\udd23' u'\U00010123'` (the character is represented as a
surrogate pair). During this step the pyc file is created.
 3. from the python interpreter write `reload(unicodetest)`. Now it
should print `Result: True` and `Repr: u'\U00010123' u'\U00010123'` (the
char is represented as a "normal" character). Any other reload will
print True. If you delete the pyc and reload again it will print False.

(Instead of using reload() is also possible to create a function and
call it from the module when it's loaded and again with
unicodetest.func(), the result will be the same.)

Expected behavior:
The interpreter should use the same representation in both the situation
(and print True in both the tests).
Another solution could be to change the behavior of == to return True if
a normal char is compared with its surrogate pair (if it makes sense).

Further informations:
The character used for the test is part of the "Unicode Plane 1" (see
http://en.wikipedia.org/wiki/Basic_Multilingual_Plane).
More information about the surrogate pairs can be found here:
http://en.wikipedia.org/wiki/Surrogate_pair#Encoding_of_characters_outside_the_BMP

----------
components: Unicode
files: unicodetest.py
messages: 69321
nosy: ezio.melotti, lemburg
severity: normal
status: open
title: Python interpreter uses Unicode surrogate pairs only before the pyc is created
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file10826/unicodetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sun Jul  6 09:18:21 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 07:18:21 +0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1215328700.32.0.3301769736.issue2113@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Fixed as Amaury described in trunk r64756.

still needs backporting to release25-maint.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
_______________________________________

From report at bugs.python.org  Sun Jul  6 09:32:24 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 06 Jul 2008 07:32:24 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215329544.84.0.925013224503.issue3139@psf.upfronthosting.co.za>


Changes by Ismail Donmez <ismail at namtrac.org>:


----------
nosy: +cartman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 09:42:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 07:42:28 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1215330147.93.0.0545137515021.issue2320@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

lowering the priority on this back to normal as there is a workaround:
use close_fds=True.

I agree that this is messy, I'm not sure if we can really fix it or even
if we should.

Running lsof shows the /bin/cat processes on OS X all having a varying
numbers of the same PIPEs open supporting Adam's hypothesis.

----------
assignee: gregory.p.smith -> 
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Sun Jul  6 09:52:37 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Jul 2008 07:52:37 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215330757.53.0.881108898782.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attached updated patch which implements Guido's suggestion from above
(inheritance of __hash__ is blocked at the C level by setting the slot
to PyObject_HashNotImplemented and at the Python level by setting
__hash__ = None).

All tests which don't depend on a -u resource flag still pass (currently
running a -uall set of tests as well).

Added file: http://bugs.python.org/file10827/issue2235_fix_hash_inheritance_with_function_ptr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Sun Jul  6 10:09:53 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Jul 2008 08:09:53 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1215331793.67.0.774366247645.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Two failures in the -uall run (test_codecmaps_hk, test_linuxaudiodev).
However, I see those test failures even after reverting my changes, so
they aren't related to this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Sun Jul  6 15:09:49 2008
From: report at bugs.python.org (Stavros Korokithakis)
Date: Sun, 06 Jul 2008 13:09:49 +0000
Subject: [issue3298] Multiline string with quotes is not parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>


New submission from Stavros Korokithakis <stavros at korokithakis.net>:

A multiline string with quotes next to the ending quote is not parsed 
correctly:

In [1]: """A "test""""
------------------------------------------------------------
   File "<ipython console>", line 1
     """A "test""""
                  ^
<type 'exceptions.SyntaxError'>: EOL while scanning single-quoted string

Is this normal behaviour? It seems to me like the parser should parse 
everything inside the triple double quotes (there is no ambiguity).

----------
components: Interpreter Core
messages: 69326
nosy: Stavros
severity: normal
status: open
title: Multiline string with quotes is not parsed correctly.
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________

From report at bugs.python.org  Sun Jul  6 15:24:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 13:24:55 +0000
Subject: [issue3298] Multiline string with quotes is not parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215350695.65.0.544914723994.issue3298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

There is an ambiguity: did you mean """ " or " """ (spaces added for
clarity). Python does not count quotes, parentheses or similar in
strings, so the first occurrence of """ will close the literal.

You can either use triple single quotes, or escape the first quote, like
that: """A "test\"""".

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________

From report at bugs.python.org  Sun Jul  6 15:35:19 2008
From: report at bugs.python.org (Stavros Korokithakis)
Date: Sun, 06 Jul 2008 13:35:19 +0000
Subject: [issue3298] Multiline string with quotes is not parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215351319.88.0.00243851438009.issue3298@psf.upfronthosting.co.za>


Stavros Korokithakis <stavros at korokithakis.net> added the comment:

Hmm, what would be the meaning of """ " in this particular context? I 
can't think of a situation where
"""A test""" "
would be valid code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________

From report at bugs.python.org  Sun Jul  6 15:38:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 13:38:15 +0000
Subject: [issue3298] Multiline string with quotes is not parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215351495.77.0.956011565042.issue3298@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The last quote starts another string literal, so this is valid Python:

"""A "test"""" B"

and results in a string 'A "test B'. The lexer cannot know whether the
second string literal is terminated or not, yielding valid or invalid code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________

From report at bugs.python.org  Sun Jul  6 15:53:30 2008
From: report at bugs.python.org (Stavros Korokithakis)
Date: Sun, 06 Jul 2008 13:53:30 +0000
Subject: [issue3298] Multiline string with quotes is not parsed correctly.
In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za>
Message-ID: <1215352410.49.0.364928184275.issue3298@psf.upfronthosting.co.za>


Stavros Korokithakis <stavros at korokithakis.net> added the comment:

Ah, interesting, I had forgotten that adjacent strings are merged. 
Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3298>
_______________________________________

From report at bugs.python.org  Sun Jul  6 16:20:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 14:20:44 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

"import re: re.finditer("a", {})" crash on Python 2.x (tested with svn 
trunk) because of an invalid use of PyObject_NEW/PyObject_DEL. The 
error is in pattern_scanner(), in block "if (!string) { ... }".
 - scanner_dealloc() calls Py_DECREF(self->pattern); whereas pattern 
attribute is not initialized
 - scanner_dealloc() calls PyObject_DEL(self); whereas 
scanner_dealloc() is already the destructor of self object!

I wrote a patch to fix these errors. Please review my patch, I don't 
know C API very well.

I also patched _compile(): replace PyObject_DEL() by Py_DECREF(). Is 
it really needed?

----------
components: Library (Lib)
files: re_finditer.patch
keywords: patch
messages: 69331
nosy: haypo
severity: normal
status: open
title: invalid object destruction in re.finditer()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10828/re_finditer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 16:27:59 2008
From: report at bugs.python.org (Bluebird)
Date: Sun, 06 Jul 2008 14:27:59 +0000
Subject: [issue839496] SimpleHTTPServer reports wrong content-length for text
	files
Message-ID: <1215354479.78.0.190370224875.issue839496@psf.upfronthosting.co.za>


Bluebird <phil at freehackers.org> added the comment:

I confirm that the problem is present on python2.5 on windows, and that
the attached patch fixes it.

----------
nosy: +bluebird

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue839496>
_______________________________________

From report at bugs.python.org  Sun Jul  6 16:52:10 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 06 Jul 2008 14:52:10 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

Three Unicode-related problems with urllib.parse.quote and
urllib.parse.unquote in Python 3.0. (Patch attached).

Firstly, unquote appears not to have been modified from Python 2, where
it is designed to output a byte string. In Python 3, it outputs a
unicode string, implicitly decoded as ISO-8859-1 (the code points are
the same as the bytes). RFC 3986 states that the percent-encoded byte
values should be decoded as UTF-8.

http://tools.ietf.org/html/rfc3986 section 2.5.

Current behaviour:
>>> urllib.parse.unquote("%CE%A3")
'??'
(or '\u00ce\u00a3')

Desired behaviour:
>>> urllib.parse.unquote("%CE%A3")
'?'
(or '\u03a3')

Secondly, while quote *has* been modified to encode to UTF-8 before
percent-encoding, it does not work correctly for characters in
range(128, 256), due to a special case in the code which again treats
the code point values as byte values.

Current behaviour:
>>> urllib.parse.quote('\u00e9')
'%E9'

Desired behaviour:
>>> urllib.parse.quote('\u00e9')
'%C3%A9'

Note that currently, quoting characters less than 256 will use
ISO-8859-1, while quoting characters 256 or higher will use UTF-8!

Thirdly, the "safe" argument to quote does not work for characters above
256, since these are excluded from the special case. I thought I would
fix this at the same time, but it's really a separate issue.

Current behaviour:
>>> urllib.parse.quote('??', safe='?')
'%CE%A3%CF%B0'

Desired behaviour:
>>> urllib.parse.quote('??', safe='?')
'?%CF%B0'

A patch which fixes all three issues is attached. Note that unquote now
needs to handle the case where the UTF-8 sequence is invalid. This is
currently handled by "replace" (invalid sequences are replaced by
'\ufffd'). I would like to add an optional "errors" argument to unquote,
defaulting to "replace", to allow the user to override this behaviour,
but I didn't put that in because it would change the interface.

Note I also changed one of the test cases, which had the wrong expected
output. (String literal was manually UTF-8 encoded, designed for Python
2; nonsensical when viewed as a Python 3 Unicode string).

All urllib test cases pass.

Patch is for branch /branches/py3k, revision 64752.

Note: The above unquote issue also manifests itself in Python 2 for
Unicode strings, but it's hazy as to what the behaviour should be, and
would break existing programs, so I'm just patching the Py3k branch.

Commit log:

urllib.parse.unquote: Fixed percent-encoded octets being implicitly
decoded as ISO-8859-1; now decode as UTF-8, as per RFC 3986.

urllib.parse.quote: Fixed characters in range(128, 256) being implicitly
encoded as ISO-8859-1; now encode as UTF-8. Also fixed characters
greater than 256 not responding to "safe", and also not being cached.

Lib/test/test_urllib.py: Updated one test case for unquote which
expected the wrong output. The new version of unquote passes the new
test case.

----------
components: Library (Lib)
files: parse.py.patch
keywords: patch
messages: 69333
nosy: mgiuca
severity: normal
status: open
title: urllib.quote and unquote - Unicode issues
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10829/parse.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Jul  6 17:12:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 15:12:30 +0000
Subject: [issue3301] DoS when lo is negative in bisect.insort_right() / _left()
In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
Message-ID: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

"import bisect; bisect.insort(range(4), -1, -1)" goes into an 
unlimited loop.  Workaround: replace negative lo value by zero. The 
function may raise an exception.

----------
components: Library (Lib)
files: bisect_lo.patch
keywords: patch
messages: 69334
nosy: haypo
severity: normal
status: open
title: DoS when lo is negative in bisect.insort_right() / _left()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10830/bisect_lo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3301>
_______________________________________

From report at bugs.python.org  Sun Jul  6 17:46:48 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 15:46:48 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

msgid of gettext(), dgettext(), dcgettext() C functions can not be 
NULL (domainname can be NULL): "import locale; locale.gettext(None)" 
generates a segfault.

domainname argument of bindtextdomain() have to be a non empty 
string: "locale.bindtextdomain(NULL, NULL)" or 
locale.bindtextdomain('', NULL)" generates an OSError(0).

Attached patch fixes the two bugs.

----------
components: Extension Modules
files: locale_none.patch
keywords: patch
messages: 69335
nosy: haypo
severity: normal
status: open
title: segfault on gettext(None)
versions: Python 2.6
Added file: http://bugs.python.org/file10831/locale_none.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:06:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 16:06:10 +0000
Subject: [issue3303] invalid ref count on locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

If locale.strcoll(a, b) fails because PyUnicode_FromObject(b) fails, 
refcount of a is wrong. Attached patch fixes the problem.

----------
components: Library (Lib)
files: locale_strcoll_rel1.patch
keywords: patch
messages: 69336
nosy: haypo
severity: normal
status: open
title: invalid ref count on locale.strcoll() error
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10832/locale_strcoll_rel1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:07:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 16:07:28 +0000
Subject: [issue3303] invalid ref count on locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1215360448.68.0.117610258006.issue3303@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Example to reproduce the bug:

import locale; locale.strcoll(u"a", None)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:30:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 16:30:22 +0000
Subject: [issue3304] invalid call to PyMem_Free() in fileio_init()
In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
Message-ID: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

fileio_init() calls PyMem_Free(name); whereas name comes from 
PyArg_ParseTupleAndKeywords().

Attached patch removes this invalid call.

The bug may also affect Python3.0.

----------
components: Library (Lib)
files: fileio_pymem_free.patch
keywords: patch
messages: 69338
nosy: haypo
severity: normal
status: open
title: invalid call to PyMem_Free() in fileio_init()
versions: Python 2.6
Added file: http://bugs.python.org/file10833/fileio_pymem_free.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3304>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:54:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 16:54:35 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <4870F8C9.8080306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> RFC 3986 states that the percent-encoded byte
> values should be decoded as UTF-8.

Where precisely do you read such a SHOULD requirement?
Section 2.5 elaborates that the local encoding (of the
resource) is typically used, ignoring cases where URIs
are constructed on the client system (such scenario is
simply ignored in the RFC).

The last paragraph in section 2.5 is the only place that
seems to imply a SHOULD requirement (although it doesn't
use the keyword); this paragraph only talks about new URI
schemes. Unfortunately, for http, the encoding is of
characters is unspecified (this is somewhat solved by the
introduction of IRIs).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:56:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 16:56:31 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1215363391.8.0.526592915636.issue3302@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:56:42 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 16:56:42 +0000
Subject: [issue3303] invalid ref count on locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1215363402.1.0.500309894606.issue3303@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________

From report at bugs.python.org  Sun Jul  6 18:59:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 16:59:32 +0000
Subject: [issue3304] invalid call to PyMem_Free() in fileio_init()
In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
Message-ID: <1215363572.3.0.238138688387.issue3304@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3304>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:01:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 17:01:20 +0000
Subject: [issue3301] DoS when lo is negative in bisect.insort_right() / _left()
In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
Message-ID: <1215363679.98.0.387860520344.issue3301@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The same is true for all other _bisect functions.

The pure Python versions from bisect work with negative indices by
interpreting them as in slice notation. This should probably be harmonized.

----------
assignee:  -> rhettinger
nosy: +georg.brandl, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3301>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:03:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 17:03:39 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215363819.04.0.111830383546.issue3299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This seems to be new in trunk; 2.5.2 raises a TypeError.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:03:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 17:03:43 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215363823.31.0.330747251567.issue3299@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> effbot
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:03:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 17:03:48 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215363828.76.0.527595220148.issue3299@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:08:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 17:08:09 +0000
Subject: [issue3304] invalid call to PyMem_Free() in fileio_init()
In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
Message-ID: <1215364089.68.0.144013906262.issue3304@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks.  fixed in trunk r64758.  i'm assuming that'll be merged into
py3k automagically.

----------
resolution:  -> accepted
versions: +Python 3.0 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3304>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:11:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 17:11:29 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1215364289.41.0.236974383487.issue3302@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:12:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 17:12:01 +0000
Subject: [issue3303] invalid ref count on locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1215364321.23.0.463576232729.issue3303@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:13:40 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 17:13:40 +0000
Subject: [issue3277] socket's OOB data management is broken on OS X and FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215364420.5.0.895442735644.issue3277@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal
title: socket's OOB data management is broken on FreeBSD -> socket's OOB data management is broken on OS X and FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:14:04 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 17:14:04 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work on OS X and
	FreeBSD
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215364444.82.0.900335738052.issue3278@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal
title: socket's SO_OOBINLINE option does not work on FreeBSD -> socket's SO_OOBINLINE option does not work on OS X and FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:20:50 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 17:20:50 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215364850.27.0.34410723765.issue3278@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This also happens on Linux:

read -> x
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/greg/sandbox/python/trunk/Lib/threading.py", line 523, in
__bootstrap_inner
    self.run()
  File "/home/greg/sandbox/python/trunk/Lib/threading.py", line 478, in run
    self.__target(*self.__args, **self.__kwargs)
  File "../socket_oobinline.py", line 20, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: [Errno 22] Invalid argument


I need to look up what the exact behavior should be.

----------
title: socket's SO_OOBINLINE option does not work on OS X and FreeBSD -> socket's SO_OOBINLINE option does not work

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:24:33 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Jul 2008 17:24:33 +0000
Subject: [issue3301] DoS when lo is negative in bisect.insort_right() / _left()
In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
Message-ID: <1215365073.29.0.968635241006.issue3301@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Don't think negative indices make much sense in this context.  Will put 
in a test to raise a ValueError for negative indices.

----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3301>
_______________________________________

From report at bugs.python.org  Sun Jul  6 19:25:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jul 2008 17:25:12 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1215365112.13.0.642663218943.issue3139@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:05:45 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 18:05:45 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215367545.57.0.00682629244309.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

@georg.brandl: The error is an Heisenbug. Yes, sometimes it doesn't 
crash, but recheck in Valgrind ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:17:39 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sun, 06 Jul 2008 18:17:39 +0000
Subject: [issue3277] socket's OOB data management is broken on OS X and FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215368258.98.0.976508709906.issue3277@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I agree with Martin.  Why are you sure that this is a Python bug and not
a FreeBSD bug?  As per the documentation of OOB data, it's not supported
by all operating systems or TCP/IP stacks.

----------
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:27:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 18:27:40 +0000
Subject: [issue3305] Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec
	and MultibyteStreamReader
In-Reply-To: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za>
Message-ID: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

Functions mbstreamwriter_dealloc() and mbstreamreader_dealloc() of 
Modules/cjkcodecs/multibytecodec.c uses Py_DECREF() to free stream 
attribute memory, but this attribute may be NULL if MultibyteCodec or 
MultibyteStreamReader constructor fails.

Simple fix: use Py_XDECREF().

Example:
>>> import _multibytecodec
>>> _multibytecodec.MultibyteStreamReader(None)
Erreur de segmentation (core dumped)

----------
components: Library (Lib)
files: multibytecodec_py_xdecref.patch
keywords: patch
messages: 69347
nosy: haypo
severity: normal
status: open
title: Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec and MultibyteStreamReader
versions: Python 2.6
Added file: http://bugs.python.org/file10834/multibytecodec_py_xdecref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3305>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:28:36 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 06 Jul 2008 18:28:36 +0000
Subject: [issue3277] socket's OOB data management is broken on OS X and FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215368916.03.0.310851215755.issue3277@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Sorry, the first reply of Martin slipped under my radar.
In fact I wasn't sure whether this was related to Python or FreeBSD.
I've filed this same report on the FreeBSD bug tracker:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125258
If you're sure this is not related to python please close it, otherwise
we could wait for someone of the FreeBSD team to reply and confirm that
it's FreeBSD related.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:32:27 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 06 Jul 2008 18:32:27 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215369147.54.0.9462174086.issue3299@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

This report makes no sense to me; at least in Python 2.X, PyObject_Del
removes a chunk of memory from the object heap.  It's designed to be
used from dealloc implementations, to release the actual memory (either
directly, or as the default implementation for the tp_free slot).  It
can also be used in constructors, to destroy an object that was just
created if something goes wrong.

If you change PyObject_Del to Py_DECREF nillywilly, things will indeed
crash.

(with the original 2.5 code, I cannot see how a non-string argument to
finditer() can result in a call to scanner_dealloc(); the argument will
be rejected by getstring(), which causes state_init() to return, which
causes pattern_scanner() to free the object it just created, and return.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 20:44:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 18:44:35 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215369875.77.0.670352426517.issue3278@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

p648 of Unix Network Programming third edition:

"4. If the process has set the SO_OOBINLINE socket option and then tries
to read the out-of-band data by specifying MSG_OOB, EINVAL is returned."

so it does not sound like a bug in Python.

There -does- appear to be a difference in BSD and Linux's socket
implementation here.  select returned the socket in both the read and
exception list on Linux.  While on BSD it only returned it in the
exception list.

The application is presumably supposed to keep track of which sockets it
has set SO_OOBINLINE on to know what to do when select returns them in
the exception state.

That said... OS X (and presumably FreeBSD) behaves oddly.  The socket is
only ever returned in the e list and an attempt to conn.recv(1) from it
raises socket.error "error: [Errno 35] Resource temporarily unavailable"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Sun Jul  6 21:34:42 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jul 2008 19:34:42 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215372882.7.0.0791721269622.issue3299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> It can also be used in constructors, to destroy an object that was just
> created if something goes wrong.

It appears that this is not true in debug builds: PyObject_NEW adds the
object to the global linked list of all objects, which PyObject_DEL
obviously doesn't undo.  Therefore, when the object created immediately
before is deallocated (in this case the argument tuple to finditer()), a
fatal error will be caused.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Jul  6 21:34:44 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 19:34:44 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215372884.19.0.768045316952.issue3278@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

further reading reveals that this is the expected behavior.

p651 in 24.2: "select indicates an exception condition until the process
reads -beyond- the out of band data."  ...  "the solution is to only
select for an exception condition after reading normal data."  with code
examples.

in short: if you want OOB with select there are hoops to jump through
for the edge cases.  its layed out in the book.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Sun Jul  6 21:36:01 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 19:36:01 +0000
Subject: [issue3278] socket's SO_OOBINLINE option does not work
In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za>
Message-ID: <1215372961.28.0.567754318933.issue3278@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

A friend confirms that on NetBSD it matches the Linux behavior.

"read -> x" is printed before the exception.

also fwiw, my OS X version is 10.5.3.

IMNSHO not a python bug.  open it with FreeBSD and Apple.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3278>
_______________________________________

From report at bugs.python.org  Sun Jul  6 21:39:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Jul 2008 19:39:15 +0000
Subject: [issue3277] socket's OOB data management is broken on OS X and FreeBSD
In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za>
Message-ID: <1215373155.17.0.886743006005.issue3277@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

not a python issue.  thanks for opening one with FreeBSD.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3277>
_______________________________________

From report at bugs.python.org  Sun Jul  6 23:36:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 06 Jul 2008 21:36:20 +0000
Subject: [issue839496] SimpleHTTPServer reports wrong content-length for text
	files
Message-ID: <1215380180.66.0.831848532663.issue839496@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r64762.
Maybe a 2.5 backport candidate, but I fear that it may break existing code.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue839496>
_______________________________________

From report at bugs.python.org  Sun Jul  6 23:57:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 21:57:59 +0000
Subject: [issue3306] audioop.findmax() crashs with negative length
In-Reply-To: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za>
Message-ID: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

Example:
>>> import audioop
>>> audioop.findmax(''.join( chr(x) for x in xrange(256)), -2392392)
Erreur de segmentation (core dumped)

The problem is that audioop_findmax() doesn't check len2 for negative 
value. Here is a patch ;-)

----------
components: Library (Lib)
files: audioop_findmax.patch
keywords: patch
messages: 69356
nosy: haypo
severity: normal
status: open
title: audioop.findmax() crashs with negative length
versions: Python 2.6
Added file: http://bugs.python.org/file10835/audioop_findmax.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3306>
_______________________________________

From report at bugs.python.org  Mon Jul  7 00:44:05 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 22:44:05 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215384245.32.0.82025576503.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Hum, the bug is maybe specific to Python build with --with-pydebug. I 
don't know exactly the behaviour changes of the PYDEBUG option.

@effbot: in my patch, I replaced PyObject_DEL (PyObject_FREE) and not 
PyObject_Del (PyMem_Free).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul  7 00:56:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 22:56:01 +0000
Subject: [issue3307] invalid check of _bsddb creation failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

newDBObject(), called by DB_construct(), doesn't check correctly the 
result of all to the external function db_create(). It checks if 
self->db is NULL, but db_create() doesn't change self->db value on 
error. So if self->db is uninitialized, the error is not catched.

Two ideas to fix the bug:
 - check "if (err)" instead of "if (self->db != NULL)"
 - set self->db=NULL before calling db_create()

I implemented the second proposition in the attached patch.

Note: The bug occurs with PYDEBUG, I don't know if PyObject_New() 
fills new allocate memory to zero (I think no, but I'm not sure).

----------
components: Library (Lib)
files: bsddb_create.patch
keywords: patch
messages: 69358
nosy: haypo
severity: normal
status: open
title: invalid check of _bsddb creation failure
versions: Python 2.6
Added file: http://bugs.python.org/file10836/bsddb_create.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________

From report at bugs.python.org  Mon Jul  7 00:59:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jul 2008 22:59:14 +0000
Subject: [issue3307] invalid check of _bsddb creation failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1215385154.5.0.10003536326.issue3307@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

The bug occurs on db_create() failure. Dummy example to reproduce it:
"import _bsddb; _bsddb.DB(None, 29.515)"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________

From report at bugs.python.org  Mon Jul  7 01:23:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 06 Jul 2008 23:23:32 +0000
Subject: [issue3250] datetime.time does not support arithmetic
In-Reply-To: <1215109058.32.0.654905905829.issue3250@psf.upfronthosting.co.za>
Message-ID: <18542.37875.97900.411576@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

George> To handle overflows, I figured it should wrap around a 24-hour
    George> limit.

That's precisely the reason that time objects don't support arithmetic.
There is no obviously best way to handle overflow.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3250>
_______________________________________

From report at bugs.python.org  Mon Jul  7 02:16:22 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 00:16:22 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>


New submission from Roger Binns <python at rogerbinns.com>:

My extension (apsw) builds and runs just fine on Linux, Mac and Windows
for Python 2.3, 2.4 and 2.5.  For Linux and Mac Python 2.6 beta 1 and
Python 3.0 beta 1 also work just fine.  However on Windows using MinGW
and Python 2.6 beta 1 and Python 3.0 beta 1 the pyd fails to load
claiming the "specified procedure cannot be found".  The compile/link is
just fine and pexports shows the procedure is present.  

# Compile lines
c:/python26/python setup.py build --compile=mingw32 install
c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DSQLITE_THREADSAFE=1
-DNDEBUG=1 -DEXPERIMENTAL=1
-DAPSW_USE_SQLITE_AMALGAMATION=\"C:\apsw\sqlite3.c\"
-Ic:\python26\include -Ic:\python26\PC -c apsw.c -o
build\temp.win32-2.6\Release\apsw.o
writing build\temp.win32-2.6\Release\apsw.def
c:\mingw\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.6\Release\apsw.o
build\temp.win32-2.6\Release\apsw.def -Lc:\python26\libs
-Lc:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\apsw.pyd
# Running
ImportError: DLL load failed: The specified procedure could not be found.
# Pexports
C:\apsw>pexports build\lib.win32-2.6\apsw.pyd
LIBRARY apsw.pyd
EXPORTS
initapsw

When using Python 3.0 things are substantially the same except the init
function is PyInit_apsw.

MinGW was installed using the default configuration with the automated
installer http://sourceforge.net/forum/forum.php?forum_id=817299  The
libmsvcr90.a is part of MinGW found in c:\MinGW\lib

----------
components: Distutils
messages: 69361
nosy: rogerbinns
severity: normal
status: open
title: MinGW built extensions do not load (specified procedure cannot be found)
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 02:46:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 00:46:01 +0000
Subject: [issue3309] missing lock release in BZ2File_iternext()
In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
Message-ID: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

Call BZ2File_iternext() on closed file doesn't release the lock.

Example:
-----------
import bz2
obj = bz2.BZ2File('/etc/issue')
obj.close()
try:
    #?acquire the lock
    obj.next()
except ValueError, err:
    #?but don't release the lock
    print err
# DEAD LOCK here
obj.readlines()
-----------

Attached patch fixes this bug.

----------
components: Library (Lib)
files: bz2_lock.patch
keywords: patch
messages: 69362
nosy: haypo
severity: normal
status: open
title: missing lock release in BZ2File_iternext()
versions: Python 2.6
Added file: http://bugs.python.org/file10837/bz2_lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3309>
_______________________________________

From report at bugs.python.org  Mon Jul  7 03:00:53 2008
From: report at bugs.python.org (Alexis Layton)
Date: Mon, 07 Jul 2008 01:00:53 +0000
Subject: [issue3310] Out-of-date example 3.0b1 Tutorial Classes page,
	'issubclass'
In-Reply-To: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>
Message-ID: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>


New submission from Alexis Layton <alex at permabit.com>:

The bullet example for 'issubclass' should be updated since neither
'unicode' or 'basestring' are valid anymore.

----------
assignee: georg.brandl
components: Documentation
messages: 69363
nosy: alexis.layton, georg.brandl
severity: normal
status: open
title: Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass'
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3310>
_______________________________________

From report at bugs.python.org  Mon Jul  7 03:16:06 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 01:16:06 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215393366.65.0.968113870296.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I figured maybe it was something to do with MSVC 90 dlls.  

<pre>
C:\apsw>dir \*msvc*90* /s
 Volume in drive C has no label.
 Volume Serial Number is F4A5-1661

 Directory of C:\MinGW\lib

12/27/2007  08:23 AM           554,136 libmsvcr90.a
12/27/2007  08:23 AM           555,910 libmsvcr90d.a
               2 File(s)      1,110,046 bytes

 Directory of
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

11/06/2007  08:23 PM           224,768 msvcm90.dll
11/07/2007  01:19 AM           568,832 msvcp90.dll
11/07/2007  01:19 AM           655,872 msvcr90.dll
               3 File(s)      1,449,472 bytes

 Directory of
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30411.0_x-ww_71382c73

04/10/2008  10:52 PM           225,280 msvcm90.dll
04/11/2008  04:32 AM           572,928 msvcp90.dll
04/11/2008  04:32 AM           655,872 msvcr90.dll
               3 File(s)      1,454,080 bytes

     Total Files Listed:
               8 File(s)      4,013,598 bytes
               0 Dir(s)  22,924,242,944 bytes free
</pre>

Process Explorer shows Python 2.6 exe using MSVCR90.dll from the
71382c73 WinSxS directory.  Using Process Monitor for the 'import apsw'
invocation shows the cp437 encoding being looked for and found, then the
apsw.pyd being looked for, found, opened, LoadImage, ReadFile and
CloseFile.  Then a file named angle bracket stdin angle bracket it
looked for and not found (presumably to show the error message).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 03:18:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 01:18:41 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

_multiprocessing Connection methods don't check if handle is valid or 
not. If you close the socket/pipe, Python may crash on operations, 
especially in poll() on FD_SET(...handle, &rdfs).

Example of crash:
----------------------
import _multiprocessing
obj = _multiprocessing.Connection(755)
obj.close()
obj.poll()
----------------------

Attached patch is a proposition of fix to check handle in all 
Connection methods using the handle.

----------
components: Library (Lib)
files: multiprocessing_closed.patch
keywords: patch
messages: 69365
nosy: haypo
severity: normal
status: open
title: block operation on closed socket/pipe for multiprocessing
versions: Python 2.6
Added file: http://bugs.python.org/file10838/multiprocessing_closed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________

From report at bugs.python.org  Mon Jul  7 03:45:26 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 07 Jul 2008 01:45:26 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215395126.18.0.281556028365.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Point taken. But the RFC certainly doesn't say that ISO-8859-1 should be
used. Since we're outputting a Unicode string in Python 3, we need to
decode with some encoding, and UTF-8 seems the most sensible and
standardised.
(Even the existing test case in test_urllib.py:466 uses a UTF-8-encoded
URL, and I had to fix it so it decodes into a meaningful string).

Having said that, it's possible that you may wish to use another
encoding, and legal to do so. Therefore, I'd suggest we add an
"encoding" argument to both quote and unquote, which defaults to "utf-8".

Note that in the current implementation, unquote is not an inverse of
quote, because quote uses UTF-8 to encode characters with code points >=
256, while unquote decodes them as ISO-8859-1. I think it's important
these two functions are inverses of each other.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Mon Jul  7 04:26:59 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 02:26:59 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215397619.66.0.878792613046.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I can't prove it since Python gives no further information than a
procedure cannot be found, but using a bunch of other tools I think this
may be due at least to the use of localtime() and it not being present
in the msvcr90.dll but is in the vc version 7 dlls which is why earlier
versions of Python have no issue.

If the above is the case then I have no idea where the actual underlying
cause lies.  Is MinGW missing header information that should mangle
localtime() to one of the other variants used by msvc (_s suffix, _
prefix, 32/64 in there somewhere)?  Is the Python header causing issues?

Attached is a trivial extension providing the issue with localtime.

Added file: http://bugs.python.org/file10839/localtime.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 05:27:11 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Jul 2008 03:27:11 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215401231.01.0.731997039679.issue1580@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Here's a fixed patch, float2.diff. (The previous one tasted of an
earlier attempt.)

Added file: http://bugs.python.org/file10840/float2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:24:27 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:24:27 +0000
Subject: [issue3309] missing lock release in BZ2File_iternext()
In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
Message-ID: <1215404667.75.0.481859804931.issue3309@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3309>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:29:20 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 07 Jul 2008 04:29:20 +0000
Subject: [issue1736101] asyncore should handle also ECONNABORTED in recv
Message-ID: <1215404960.22.0.14751432716.issue1736101@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in 3.0 .

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736101>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:29:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Jul 2008 04:29:42 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215404982.7.0.45648581848.issue3308@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please check the event log at the point of failure, and report
any events it may have recorded?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:33:18 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:33:18 +0000
Subject: [issue3309] missing lock release in BZ2File_iternext()
In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
Message-ID: <1215405198.25.0.970576684107.issue3309@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Fixed in trunk r64767.

Needs backporting to release25-maint.

----------
resolution:  -> accepted
type:  -> behavior
versions: +Python 2.5 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3309>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:36:19 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:36:19 +0000
Subject: [issue3307] invalid check of _bsddb creation failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1215405379.28.0.129137492898.issue3307@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> jcea
nosy: +jcea
priority:  -> normal
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:39:51 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:39:51 +0000
Subject: [issue988761] re.split emptyok flag (fix for #852532)
Message-ID: <1215405591.55.0.518867989355.issue988761@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

take a look at the patch being worked on in issue #3262.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue988761>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:44:06 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 04:44:06 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215405846.88.0.989081049914.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I cleared all event categories, and then ran Python followed by the
import (which fails).  No events in any category appeared.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:44:56 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:44:56 +0000
Subject: [issue3212] ssl module - should test for a wrong cert
In-Reply-To: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>
Message-ID: <1215405896.55.0.415595213589.issue3212@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> janssen
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3212>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:47:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:47:48 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1215406068.5.0.387716172108.issue3119@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
superseder:  -> eliminate recursion in pickling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:48:05 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:48:05 +0000
Subject: [issue2480] eliminate recursion in pickling
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1215406085.73.0.244880919571.issue2480@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
dependencies: +pickle.py is limited by python's call stack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:55:10 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:55:10 +0000
Subject: [issue3183] sha modules & Modules/Setup.dist
In-Reply-To: <1214249909.74.0.55822821087.issue3183@psf.upfronthosting.co.za>
Message-ID: <1215406510.36.0.598415684251.issue3183@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

seems harmless enough.  done in trunk r64769.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> low
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3183>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:56:39 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:56:39 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1215406599.64.0.721131016035.issue3210@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
components: +Library (Lib) -Extension Modules
nosy: +gregory.p.smith
priority:  -> normal
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Mon Jul  7 06:58:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 04:58:34 +0000
Subject: [issue2277] MozillaCookieJar does not support Firefox3 cookie files
In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za>
Message-ID: <1215406714.65.0.233097287375.issue2277@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

sounds like a good idea to add this.  yay firefox 3.  i'll review it.

----------
assignee:  -> gregory.p.smith
components: +Library (Lib)
nosy: +gregory.p.smith
priority:  -> normal
type:  -> feature request
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2277>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:01:53 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 05:01:53 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1215406913.77.0.201365913224.issue3001@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
components: +Interpreter Core, Library (Lib)
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:04:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 05:04:35 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1215407075.51.0.935985952331.issue3120@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
components: +Extension Modules
nosy: +gregory.p.smith
priority:  -> high
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:04:44 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 07 Jul 2008 05:04:44 +0000
Subject: [issue953599] asyncore misses socket closes when poll is used
Message-ID: <1215407084.66.0.741079093438.issue953599@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed for 2.6 in changelist 64768.
Fixed for 3.0 in changelist 64770.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue953599>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:05:12 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 07 Jul 2008 05:05:12 +0000
Subject: [issue1519] async_chat.__init__() parameters
In-Reply-To: <1196346058.65.0.25106672712.issue1519@psf.upfronthosting.co.za>
Message-ID: <1215407112.85.0.921893529245.issue1519@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed for 2.6 in changelist 64768.
Fixed for 3.0 in changelist 64770.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:05:35 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 07 Jul 2008 05:05:35 +0000
Subject: [issue760475] asyncore.py and "handle_error"
Message-ID: <1215407135.88.0.597911746543.issue760475@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed for 2.6 in changelist 64768.
Fixed for 3.0 in changelist 64770.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue760475>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:10:12 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 05:10:12 +0000
Subject: [issue3094] By default,
	HTTPSConnection should send header "Host: somehost" instead of "Host:
	somehost:443"
In-Reply-To: <1213300884.55.0.795438603527.issue3094@psf.upfronthosting.co.za>
Message-ID: <1215407412.59.0.34110590886.issue3094@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r64771.

(and indeed the previous behavior was buggy in the extreemly rare event
that someone ran a https server on port 80 the :80 should have been
supplied).

----------
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3094>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:11:29 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 05:11:29 +0000
Subject: [issue3046] Locking should be removed from the new buffer protocol
In-Reply-To: <1212734828.53.0.490072473192.issue3046@psf.upfronthosting.co.za>
Message-ID: <1215407489.65.0.166145588999.issue3046@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> teoliphant
nosy: +gregory.p.smith
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3046>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:16:58 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 07 Jul 2008 05:16:58 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1215407818.53.0.723677519028.issue3119@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:17:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Jul 2008 05:17:19 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215407839.48.0.165544257594.issue3308@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Do you have a copy of depends.exe? If so, how does it resolve the DLLs
referenced in apsw.pyd?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 07:57:24 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 05:57:24 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215410244.7.0.295516496881.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I didn't have a copy of depends.exe since it doesn't appear to come with
MinGW.  System is basically VirtualBox VM with fresh install of XP Pro
SP2, upgraded to SP3 and TortoiseSVN, Firefox, Xemacs, MinGW and Python
versions installed.

I found a GUI program named depends which is what I used to figure out
that the issue appeared to be localtime() missing in msvcr90.dll.  BTW
did you notice msg69367 and the attached file that shows the problem in
a trivial test case?

The gui depends program found the following issues:

- No localtime in msvcr90.dll
- DWMAPI.DLL not found (not mentioned on link line so no idea why
depends wants it)
- MPR.DLL & SHLWAPI.DLL are red but I don't know why (again not
mentioned on link line)

I think that the localtime() symbol is the underlying cause.  However
this isn't exactly Python's fault (Python's headers don't do anything to
the localtime symbol but there may be defines that cause "secure crt" to
be used which wants localtime_s to be used instead).  Maybe MinGW is
supposed to be redefining localtime to one of the _/32/64/s variants but
isn't.

In any event the net result is that if a Python extension uses current
MinGW and localtime() then it will compile and link correctly on Python
2.3, 2.4, 2.5, 2.6b1 & 3.0b1.  However it won't run on 2.6b1 or 3.0b1
due to some sort of mismatch between those versions of Python using new
MSVC runtime and/or MinGW.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 13:40:02 2008
From: report at bugs.python.org (Filip Salomonsson)
Date: Mon, 07 Jul 2008 11:40:02 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215430802.14.0.505563052744.issue3262@psf.upfronthosting.co.za>


Changes by Filip Salomonsson <filip.salomonsson+bugs.python.org at gmail.com>:


----------
nosy: +filip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Mon Jul  7 14:36:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Jul 2008 12:36:06 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215434166.76.0.900865126116.issue3308@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems that mingw is unable to compile the simplest program containing
a call to localtime():

$ echo "#include <time.h>
> int main() { localtime(NULL); }" > t.c
$ gcc -mno-cygwin t.c -lmsvcr90

Then starting "a.exe" displays a modal box with the message: "The
procedure entry point localtime could not be located in the dynamic link
library msvcr90.dll."

So the problem is not python-specific, and should be reported to Mingw.

However, I discovered that it works if you include time.h this way:

   #define __MSVCRT_VERSION__ 0x0700    /* whatever above 0x0601 */
   #include <time.h>
   #define time_t __time64_t
   #define localtime _localtime64
   #define time _time64

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 14:49:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Jul 2008 12:49:23 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215434963.39.0.856820629378.issue3221@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Bumped priority - an existing module shouldn't crash in 2.6 just because
we started using __package__ as part of the import mechanism and that
module happens to already set an attribute by that name.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Mon Jul  7 14:53:20 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Jul 2008 12:53:20 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1215435200.43.0.160129874046.issue2517@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adding this to my personal to-do list for the next beta release.

----------
assignee: georg.brandl -> ncoghlan
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2517>
_______________________________________

From report at bugs.python.org  Mon Jul  7 14:54:09 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Jul 2008 12:54:09 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215435249.21.0.954401202692.issue3221@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adding to my personal to-do list for next beta.

----------
assignee: twouters -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Mon Jul  7 15:03:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Jul 2008 13:03:02 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1215435782.35.0.965314115125.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The outcome of discussion of this issue on python-dev was that the
lookup methodology for the special methods needs to be better
documented, especially for those cases where the instance *must* be
bypassed in order to avoid metaclass confusion for special methods that
apply to both types and instances (see issue 2517 for such a problem
that currently afffects the lookup of __unicode__). However, we're not
prepared to add a standard delegation mixin to the standard library at
this stage (I may still add a cleaned up version of mine to the SVN
sandbox as an executable reference source for the relevant section of
the documentation though).

While I offered to write that new section of the docs during the
python-dev discussion, I'm not sure when I'll be able to get to it (My
Python time lately has mostly been spent investigating __hash__ fun and
games).

----------
assignee: barry -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Jul  7 15:03:21 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Jul 2008 13:03:21 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1215435801.18.0.23767201822.issue643841@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Jul  7 15:16:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 13:16:52 +0000
Subject: [issue3312] bugs in _sqlite module
In-Reply-To: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za>
Message-ID: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

(A) module_register_adapter() doesn't check microprotocols_add() 
result, whereas it can fails (eg. dict setitem error). 
Example: "import _sqlite3; _sqlite3.register_adapter({}, None)" => 
should raise a TypeError (unhashable type: 'dict').

(B) Connection.set_isolation_level() tries to create the 
string "BEGIN "+isolation_level and the store it as PyString in 
begin_statement. But if the result can not be converted to string, 
Python crashs. Example:

>>> import _sqlite3
>>> c=_sqlite3.Connection("a")
>>> c.isolation_level = u"\xe9"
Erreur de segmentation (core dumped)

Attached patch fix the two bugs.

----------
components: Library (Lib)
files: _sqlite.patch
keywords: patch
messages: 69387
nosy: haypo
severity: normal
status: open
title: bugs in _sqlite module
versions: Python 2.6
Added file: http://bugs.python.org/file10841/_sqlite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3312>
_______________________________________

From report at bugs.python.org  Mon Jul  7 15:24:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2008 13:24:33 +0000
Subject: [issue3313] dlopen() error with no error message from dlerror()
In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
Message-ID: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

Python dl_open() function (from dl module) calls dlopen() and check 
its result: if it's NULL, it's an error. This is correct if I read the 
man page. But with an invalid flag value (-1), dlopen() returns NULL 
but dlerror() also gives a NULL pointer. Example:

>>> import dl
>>> dl.open("/usr/lib/libm.so", -1)
Erreur de segmentation (core dumped)

Workaround: use a static error message if dlerror() returns NULL.

I wrote a patch for dl_open() but other functions (in ctypes module?) 
should also call dlerror().

----------
components: Library (Lib)
files: dl_open.patch
keywords: patch
messages: 69388
nosy: haypo
severity: normal
status: open
title: dlopen() error with no error message from dlerror()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10842/dl_open.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3313>
_______________________________________

From report at bugs.python.org  Mon Jul  7 16:50:30 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 07 Jul 2008 14:50:30 +0000
Subject: [issue3314] urllib.parse doesn't import sys
In-Reply-To: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za>
Message-ID: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urllib.parse doesn't import sys, which is needed on line 368, in an
error condition for urlencode. This is only a problem when urlencode has
a TypeError.

Current behaviour:
>>> urllib.parse.urlencode("foo")
NameError: global name 'sys' is not defined

Desired behaviour:
>>> urllib.parse.urlencode("foo")
TypeError: not a valid non-string sequence or mapping object

Only affects Python 3.0. (After urllib module was split up).

Patch attached, for revision 64772.

Commit log:

urllib/parse.py: Added missing "import sys".

----------
components: Library (Lib)
files: parse.py.patch
keywords: patch
messages: 69389
nosy: mgiuca
severity: normal
status: open
title: urllib.parse doesn't import sys
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file10843/parse.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3314>
_______________________________________

From report at bugs.python.org  Mon Jul  7 16:57:43 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 07 Jul 2008 14:57:43 +0000
Subject: [issue3315] abc.rst little error
In-Reply-To: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za>
Message-ID: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

'make html' with latest py3k sources produces this warning:
WARNING: /home/mishok/doc/python/abc-doc-bug/Doc/library/abc.rst:11:
term not in glossary: abstract base classes
I've applied little patch that fixes this.

----------
assignee: georg.brandl
components: Documentation
files: abc.rst.diff
keywords: patch
messages: 69390
nosy: georg.brandl, mishok13
severity: normal
status: open
title: abc.rst little error
versions: Python 3.0
Added file: http://bugs.python.org/file10844/abc.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3315>
_______________________________________

From report at bugs.python.org  Mon Jul  7 19:03:23 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 07 Jul 2008 17:03:23 +0000
Subject: [issue3306] audioop.findmax() crashs with negative length
In-Reply-To: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za>
Message-ID: <1215450203.59.0.7470374761.issue3306@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in r64775. Thank you very much!!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3306>
_______________________________________

From report at bugs.python.org  Mon Jul  7 20:26:33 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 07 Jul 2008 18:26:33 +0000
Subject: [issue3314] urllib.parse doesn't import sys
In-Reply-To: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za>
Message-ID: <1215455193.06.0.866309661333.issue3314@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in r64781, thank you!!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3314>
_______________________________________

From report at bugs.python.org  Mon Jul  7 21:18:52 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 19:18:52 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215458332.12.0.835517367326.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

In MinGW's defense the MSVC 7 dll does include localtime.  Since
Python/distutils only says that MSVC 9 dll is being used at link time,
how exactly is MinGW (or any other code) supposed to know that localtime
should be provided some other way?  Maybe distutils should be defining 
__MSVCRT_VERSION__ to 0x0900 for the compile phase as well for Python
2.6/3.0.  If that was the case then at least I could work around the
issue (the localtime call isn't actually in my code but a library I
statically link in) and still work correctly on earlier Pythons which
don't need any workarounds.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:19:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Jul 2008 20:19:34 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215410244.7.0.295516496881.issue3308@psf.upfronthosting.co.za>
Message-ID: <48727A4F.6080301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> BTW
> did you notice msg69367 and the attached file that shows the problem in
> a trivial test case?

I didn't understand it, so I ignored it. What use of localtime, by whom,
what tools? The mentioning of localtime seems to come out of nowhere.
(later messages clarified these, apparently: if localtime is called in
an extension, then the extension won't load, otherwise, it will load)

> The gui depends program found the following issues:

That's likely the one that I was asking for.

> In any event the net result is that if a Python extension uses current
> MinGW and localtime() then it will compile and link correctly on Python
> 2.3, 2.4, 2.5, 2.6b1 & 3.0b1.  However it won't run on 2.6b1 or 3.0b1
> due to some sort of mismatch between those versions of Python using new
> MSVC runtime and/or MinGW.

That sounds rather like a bug in MinGW. Can you ask on one of their
lists?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:36:54 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 07 Jul 2008 20:36:54 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

Here is my proposed fix_urllib. The transform function is massive
because there are a lot of cases, so maybe I should break it into
separate functions for each case, and it could maybe do with some more
documentation as well. I also use FromImport from fixer_util.py even
though it warns against doing so for dotted imports because it appears
to work. The temp.py file is a dummy python file that you can test it on
to get an idea of what it does. I think it's got all the desired
functionality, but I'm not an expert on the urllib changes so let me
know if I missed anything. I haven't written tests for it yet, but
assuming it looks reasonable, I can do that later today or tomorrow.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_urllib.diff
keywords: patch
messages: 69395
nosy: brett.cannon, collinwinter, nedds
severity: normal
status: open
title: Proposal for fix_urllib
Added file: http://bugs.python.org/file10845/fix_urllib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:43:40 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 20:43:40 +0000
Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage
In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za>
Message-ID: <1215463420.57.0.391137795276.issue1857@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
keywords: +patch
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1857>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:47:39 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 20:47:39 +0000
Subject: [issue1606] Doc: subprocess wait() may lead to dead lock
In-Reply-To: <1197511478.48.0.254025525321.issue1606@psf.upfronthosting.co.za>
Message-ID: <1215463659.87.0.661699416195.issue1606@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i'll come up with something for the documentation on this.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution:  -> accepted
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:51:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Jul 2008 20:51:00 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1215463860.6.0.164552174972.issue1068268@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - To fix issue #2113 I added handling of a select.error errno.EINTR
being raised during the select.select call in r64756.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Mon Jul  7 22:57:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Jul 2008 20:57:49 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Since r64688, zipfile.py contains duplicated definitions. The attached
patch removes them.

Also, Twisted uses a zipfile item that have been renamed by this change:
zipfile.stringFileHeader (now magicFileHeader).
This makes some tests fail on the community buildbots. See the rightmost
column on
http://www.python.org/dev/buildbot/community/trunk/

I suggest to rename all magicXXX variables back to stringXXX.

----------
assignee: loewis
components: Library (Lib)
messages: 69398
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: duplicate lines in zipfile.py
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Mon Jul  7 23:12:06 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 07 Jul 2008 21:12:06 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215465126.17.0.346937959293.issue3316@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I broke up transform into the logical pieces of it, so I think now the
code is a little bit more clear.

Added file: http://bugs.python.org/file10846/fix_urllib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Mon Jul  7 23:13:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Jul 2008 21:13:44 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215465224.69.0.360556142807.issue3317@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Alan, what do you think?

----------
nosy: +alanmcintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Tue Jul  8 00:20:43 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 07 Jul 2008 22:20:43 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215469243.74.0.389099372895.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

So, after 5 days of silence I present my current status on the patch.
This patch fixes Doc/includes/mp_*.py examples, except for the fact that
I couldn't make mp_distributing.py work, but I'm still working on this
issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file10847/examples.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Tue Jul  8 00:23:21 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 07 Jul 2008 22:23:21 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215469401.58.0.0618372171287.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

And this patch is for Doc/library/multiprocessing.rst. Still, there are
lot of issues, and as you none of you (Jesse or Richard) answered my
email, I'll post them tomorrow here. Right now, the patch. :)

Added file: http://bugs.python.org/file10848/multiprocessing.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Tue Jul  8 00:40:03 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 07 Jul 2008 22:40:03 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215469401.58.0.0618372171287.issue3256@psf.upfronthosting.co.za>
Message-ID: <4B412308-B29A-481A-85B0-AA281CD7A7F9@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks - sorry I didn't reply to the mail yet, had to deal with some  
other stuff first, I should be freed up tonight

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Tue Jul  8 01:39:03 2008
From: report at bugs.python.org (Roger Binns)
Date: Mon, 07 Jul 2008 23:39:03 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215473943.85.0.787025028273.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I will ask on the MinGW lists.  I am still curious as to how MinGW is
supposed to know which MSVC library will be used at compile time since
distutils doesn't tell it until link time.

As a seperate issue Python isn't too helpful when an extension doesn't
load :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Tue Jul  8 03:43:13 2008
From: report at bugs.python.org (unutbu)
Date: Tue, 08 Jul 2008 01:43:13 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
Message-ID: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>


New submission from unutbu <driabslg at yahoo.com>:

Re: http://docs.python.org/lib/module-timeit.html
Where the documentation says "In a typical case, the lowest value gives
a lower bound for how fast your machine can run the given code snippet",
it should read instead,
"In a typical case, the lowest value gives an upper bound for how fast
your machine can run the given code snippet".

Clearly, if a machine can run a code snippet in x seconds with
background processes, then the fastest the machine can run the code
snippet (without background processes) should be <= x seconds. Therefore
x is an upper bound rather than a lower bound.

----------
assignee: georg.brandl
components: Documentation
messages: 69405
nosy: georg.brandl, unutbu
severity: normal
status: open
title: Documentation: timeit: "lower bound" should read "upper bound"
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Tue Jul  8 03:48:46 2008
From: report at bugs.python.org (Roger Binns)
Date: Tue, 08 Jul 2008 01:48:46 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215481726.03.0.4360960073.issue3308@psf.upfronthosting.co.za>


Roger Binns <python at rogerbinns.com> added the comment:

I guess you can close this now.  Unfortunately SourceForge goes out of
its way to not make an easy link for the MinGW mailing list but you can
see the messages on 8th July 2008:
 
http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-users&viewmonth=200807&viewday=8

Basically MinGW erroneously ships a .lib saying localtime is in
MSVCR90.DLL when it isn't.  That means there is no link failure but the
pyd will fail to load without information as to why.  Fixing the .lib
means that localtime is picked up from MSVCRT.DLL (ie no version in
name) and everything appears to work well.

The MinGW project also claims they only support MSVCRT.DLL and not any
of the numbered ones, so basically it is luck they work.  Noone pointed
out any compile time directives to direct versioning of MSVCRT.

I guess this is more fuel for the semi-regular flame war about free
software and free compilers on Windows, but not in this ticket!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Tue Jul  8 04:20:50 2008
From: report at bugs.python.org (Mike Coleman)
Date: Tue, 08 Jul 2008 02:20:50 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215483650.15.0.480114224098.issue3262@psf.upfronthosting.co.za>


Changes by Mike Coleman <mkc at users.sourceforge.net>:


----------
nosy: +mkc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Tue Jul  8 04:27:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Jul 2008 02:27:42 +0000
Subject: [issue3315] abc.rst little error
In-Reply-To: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za>
Message-ID: <1215484062.07.0.127157460007.issue3315@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is fixed on the trunk, and should be merged into Py3k shortly.

----------
nosy: +benjamin.peterson
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3315>
_______________________________________

From report at bugs.python.org  Tue Jul  8 04:36:29 2008
From: report at bugs.python.org (Mike Coleman)
Date: Tue, 08 Jul 2008 02:36:29 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215484589.45.0.886783831344.issue3262@psf.upfronthosting.co.za>


Mike Coleman <mkc at users.sourceforge.net> added the comment:

I don't want to discourage you, but #852532, which is essentially the
same bug report, was closed--without explanation--as 'wont fix' in
April, after four-plus years.  I wish you good luck--this is an
important and irritating bug, in my opinion...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Tue Jul  8 04:37:49 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 08 Jul 2008 02:37:49 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215484669.08.0.490846266025.issue3317@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

I don't see a patch attached, but the duplicated code does need
removing.  If you can attach a patch I'll try it out.

As much as I dislike the "string" names (magicXXX seemed much more
descriptive), I suppose they're publicly available and shouldn't be
renamed without a good reason.  (Unless not being in __all__ counts as
being something one shouldn't depend on as part of the API ;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Tue Jul  8 04:53:26 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 08 Jul 2008 02:53:26 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215485606.93.0.562193449718.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Please have a look at this patch.
- Included a CaseInsensitiveDict Lookup for Headers interface.
- Headers will now be .title()-ed instead of .capitalized() ed.
- Included Tests for the changes made.

In the test_urllib2, I have not removed this line (yet).
"The Request.headers dictionary is not a documented interface.."
- I shall attach the patch to the documentation next. Will this suffice
to remove the declaration of "not a documented interface"?

Please provide your comments on the attached patch. If this is fine, I
shall do the same modifications for py3k and patch docs as well.

Thanks!

Added file: http://bugs.python.org/file10849/issue2275-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Jul  8 05:39:37 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 08 Jul 2008 03:39:37 +0000
Subject: [issue2916] urlgrabber.grabber calls setdefaulttimeout
In-Reply-To: <1211212331.88.0.0515887247336.issue2916@psf.upfronthosting.co.za>
Message-ID: <1215488377.57.0.486087772422.issue2916@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This bug is not related to Python Stdlib. There isn't a module by name
urlgrabber in Python Stdlib and the author is referring to
http://linux.duke.edu/projects/urlgrabber/help/urlgrabber.grabber.html

Author should move his suggestion to urlgrabber project.
We cannot do anything with socket.settimeout()

Please close this issue, Facundo.

Thanks,
Senthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2916>
_______________________________________

From report at bugs.python.org  Tue Jul  8 05:42:48 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 08 Jul 2008 03:42:48 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1215488568.39.0.718315097701.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

>> Senthil, could you handle this?

Sure, I shall take this up, Facundo.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Tue Jul  8 06:32:56 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 08 Jul 2008 04:32:56 +0000
Subject: [issue3045] Windows online help broken when spaces in TEMP environ
In-Reply-To: <1212721889.56.0.323857297959.issue3045@psf.upfronthosting.co.za>
Message-ID: <1215491576.06.0.611914992346.issue3045@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This is a really quick fix. Someone with tracker admin access can apply
the patches and close this.
[Applies to py26 and py3k]

----------
keywords: +patch
versions: +Python 2.6, Python 3.0 -Python 2.5
Added file: http://bugs.python.org/file10850/issue3045-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3045>
_______________________________________

From report at bugs.python.org  Tue Jul  8 06:33:10 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 08 Jul 2008 04:33:10 +0000
Subject: [issue3045] Windows online help broken when spaces in TEMP environ
In-Reply-To: <1212721889.56.0.323857297959.issue3045@psf.upfronthosting.co.za>
Message-ID: <1215491590.06.0.275644622929.issue3045@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file10851/issue3045-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3045>
_______________________________________

From report at bugs.python.org  Tue Jul  8 07:04:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 08 Jul 2008 05:04:44 +0000
Subject: [issue3308] MinGW built extensions do not load (specified procedure
	cannot be found)
In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za>
Message-ID: <1215493484.22.0.364437051494.issue3308@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3308>
_______________________________________

From report at bugs.python.org  Tue Jul  8 07:17:26 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 08 Jul 2008 05:17:26 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215494246.6.0.95298184839.issue3088@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

I managed to hang on Ubuntu, here is the backtrace that I got with CTRL-C:

Process PoolWorker-5:1:
Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
232, in _bootstrap
    test_bsddb test_bsddb3 test_cProfile test_kqueue test_lib2to3
2 skips unexpected on linux2:
    test_bsddb3 test_bsddb
Process PoolWorker-5:3:
Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
232, in _bootstrap
    self.run()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/pool.py", line
57, in worker
    self.run()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/pool.py", line
57, in worker
    task = get()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/queues.py", line
339, in get
    task = get()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/queues.py", line
337, in get
    return recv()
  File "/home/cartman/Sources/py3k/Lib/pickle.py", line 1327, in loads
    racquire()
KeyboardInterrupt
Process PoolWorker-5:2:
Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
232, in _bootstrap
    self.run()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/pool.py", line
57, in worker
    def loads(s, *, encoding="ASCII", errors="strict"):
KeyboardInterrupt
Process PoolWorker-5:4:
Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
232, in _bootstrap
    self.run()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/process.py", line
88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/pool.py", line
57, in worker
    task = get()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/queues.py", line
337, in get
    racquire()
KeyboardInterrupt
    task = get()
  File "/home/cartman/Sources/py3k/Lib/multiprocessing/queues.py", line
337, in get
    racquire()
KeyboardInterrupt
^CError in atexit._run_exitfuncs:
make: *** [testall] Segmentation fault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 09:18:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jul 2008 07:18:01 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215501481.68.0.0551953923787.issue3317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, here is the patch

----------
keywords: +patch
Added file: http://bugs.python.org/file10852/zipfile-removedups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Tue Jul  8 09:23:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jul 2008 07:23:39 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215501819.63.0.323263662847.issue3317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Since the use of "from X import *" is discouraged (and serious projects
try to avoid it), the __all__ list is less and less meaningful.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Tue Jul  8 09:27:57 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Tue, 08 Jul 2008 07:27:57 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1215502077.75.0.957133640397.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

OK, then ignore the previous email, I'll send you a new one, with
updated questions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Tue Jul  8 10:44:06 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Tue, 08 Jul 2008 08:44:06 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>


New submission from Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:

The following call results in a ZeroDivisionError in python 2.5.2 and
python 3.0 alpha 3 (I presume this is also an issue for Python 2.6 but I
can't explicitly confirm):

>>> from test import pystone
>>> pystone.main(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 61, in main
    benchtime, stones = pystones(loops)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 68, in pystones
    return Proc0(loops)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py",
line 131, in Proc0
    return benchtime, (loops / benchtime)
ZeroDivisionError: float division

Note the patch I submitted checks if the benchtime is equal to 0.0
(which apparently happens on my Mac OS 10.5 PPC). If this is the case I
arbitrarily set the benchtime to 1e-6. I'm not sure what the units of
the benchtime variable is (seconds?). Anyhow, this fixes the issue but
can someone review to confirm this is the correct behavior?

Thanks!

-Michael

----------
components: Library (Lib), Tests
files: pystone_patch.txt
messages: 69418
nosy: mokeefe
severity: normal
status: open
title: pystone.main(10) causes ZeroDivisionError
type: behavior
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file10853/pystone_patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Tue Jul  8 10:46:37 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 08 Jul 2008 08:46:37 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215506797.63.0.361625061556.issue3317@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

The patch seems to work just fine for me, all tests pass (including
test_zipfile64) on an Intel Mac.  I'd vote to go ahead and revert the
magicXXX variables back to their original names--I'm sure Twisted isn't
the only project out there that made use of them.

If the magicXXX name change gets checked in along with the current patch
I'll run the zip64 tests on Mac and Linux afterward, since they don't
get run in the standard test run on the buildbots.  I don't currently
have a Windows machine to test with.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Tue Jul  8 10:56:12 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Tue, 08 Jul 2008 08:56:12 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215507372.05.0.728706372071.issue3319@psf.upfronthosting.co.za>


Changes by Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:


Removed file: http://bugs.python.org/file10853/pystone_patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Tue Jul  8 11:02:33 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Tue, 08 Jul 2008 09:02:33 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215507753.76.0.494066315448.issue3319@psf.upfronthosting.co.za>


Michael Patrick O'Keefe <michael.p.okeefe at gmail.com> added the comment:

I'm resubmitting the patch -- I think this one's a little bit better
than my first attempt. I only change the value of loops / benchtime

----------
keywords: +patch
Added file: http://bugs.python.org/file10854/pystone.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Tue Jul  8 11:17:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 08 Jul 2008 09:17:55 +0000
Subject: [issue3018] tkinter demos fixed
In-Reply-To: <1212241760.64.0.0978196091903.issue3018@psf.upfronthosting.co.za>
Message-ID: <1215508675.54.0.0230202867152.issue3018@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3018>
_______________________________________

From report at bugs.python.org  Tue Jul  8 11:24:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jul 2008 09:24:57 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215509097.21.0.433201304889.issue1580@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]

> If you think using 16 (when possible) will stop complaints, think again
> ;-)  For example, ...

Aha!  But using *15* digits would be enough to eliminate all 1, 2, 3, 4, 
..., 15 digit 'surprises', wouldn't it?!  16 digits doesn't quite work, 
essentially because 2**-53 is still a little larger than 10**-16, but 15 
digits ought to be okay.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Tue Jul  8 12:08:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jul 2008 10:08:05 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215511685.36.0.664412307999.issue1580@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the 'proof' that 15 digits should be enough:

Suppose that x is a positive (for simplicity) real number that's exactly 
representable as a decimal with <= 15 digits.  We'd like to know that
'%.15g' % (nearest_float_to_x) recovers x.

There are integers k and m such that 2**(k-1) <= x <= 2**k, and 10**(m-1) 
< x <= 10**m.  (e.g. k = ceiling(log_2(x)), m = ceiling(log_10(x)))

Let y be the closest floating-point number to x.  Then |y-x| <= 2**(k-54).  Hence |y-x| <= x*2**-53 < x/2 * 10**-15 <= 10**(m-15)/2.  It follows that 
x is the closest 15-digit decimal to y, hence that applying '%.15g' to y 
should recover x exactly.

The key step here is in the middle inequality, which uses the fact that
2**-52 < 10**-15.  The above doesn't work for subnormals, but I'm guessing 
that people don't care too much about these.  The argument above also 
depends on correct rounding, but there's actually sufficient leeway here 
(that is, 2**-52 is quite substantially smaller than 10**-15) that the 
whole thing would probably work even in the absence of correct rounding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:25:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jul 2008 12:25:31 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215519931.41.0.327614799901.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Attached patch releases the _active_limbo_lock after a fork(). It is not
a complete solution, since existing Thread objects don't correspond to
anything, but it corrects a problem in test_multiprocessing.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file10855/fork-and-thread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:26:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jul 2008 12:26:54 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215520014.92.0.0324147180127.issue3088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I found that on my Debian64, running test_multiprocessing under gdb
hangs even before the first test is started - somewhere in the
installation of the Manager.

And it appears that the problem is described in issue874900: "threading
module can deadlock after fork".
I don't know if it's a good idea to mix fork and threads, but the patch
I attached to issue874900 seems to correct the hang.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:32:38 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Tue, 08 Jul 2008 12:32:38 +0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>
Message-ID: <1215520358.11.0.636861294647.issue1276@psf.upfronthosting.co.za>


Changes by Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:


----------
nosy: +mokeefe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:50:30 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 08 Jul 2008 12:50:30 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215521430.46.0.714932797396.issue874900@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:51:29 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 08 Jul 2008 12:51:29 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1215520014.92.0.0324147180127.issue3088@psf.upfronthosting.co.za>
Message-ID: <4222a8490807080551x65b4c50n4cda551ea1c7a4ba@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks Amaury - I've been working through the tests and identifying
the "problem children" - I'll finish that up and then try re-running
them with the 874900 patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 14:59:54 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 08 Jul 2008 12:59:54 +0000
Subject: [issue3090] ARCHFLAGS parsing/concatenation in unixccompiler.py
	breaks when set to a string
In-Reply-To: <1213276584.77.0.784242980637.issue3090@psf.upfronthosting.co.za>
Message-ID: <1215521994.36.0.373864538067.issue3090@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Does anyone have a problem with me committing this patch as-is? It's not a 
show stopper, but it's highly annoying.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3090>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:28:11 2008
From: report at bugs.python.org (Alexander Shigin)
Date: Tue, 08 Jul 2008 13:28:11 +0000
Subject: [issue2944] asyncore doesn't handle connection refused correctly
In-Reply-To: <1211462641.02.0.497686644895.issue2944@psf.upfronthosting.co.za>
Message-ID: <1215523691.89.0.39460786743.issue2944@psf.upfronthosting.co.za>


Alexander Shigin <shigin at rambler-co.ru> added the comment:

Here is a new patch against r64768

The new patch raise an exception if asynchronous connect fails.

Added file: http://bugs.python.org/file10856/asyncore-connect-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2944>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:31:24 2008
From: report at bugs.python.org (DSM)
Date: Tue, 08 Jul 2008 13:31:24 +0000
Subject: [issue3320] various doc typos
In-Reply-To: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>
Message-ID: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>


New submission from DSM <dsm001 at users.sourceforge.net>:

Boredom resulted in a handful of doc copyedits against 64789.

One error I did note in the doc tree but didn't correct because it's in
code: includes/mp_distributing.py contains the typo

_logger.propogate = 0

which ISTM will leave the logger's propagate flag on.  I can't imagine
this has any real consequence but I've never used either module.

----------
assignee: georg.brandl
components: Documentation
files: typos1.diff
keywords: patch
messages: 69428
nosy: dsm001, georg.brandl
severity: normal
status: open
title: various doc typos
versions: Python 2.6
Added file: http://bugs.python.org/file10857/typos1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3320>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:34:37 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jul 2008 13:34:37 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215524077.61.0.934984393771.issue1580@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For what it's worth, I'm -0.1 (or should that be -0.10000000000000001?) on 
this change.  It seems better to leave the problems caused by binary 
floating-point out in the open than try to partially hide them, and the 
proposed change just seems a little bit too 'magic'.  The inconsistency in 
the following current behaviour *does* irk me slightly (but only 
slightly):

>>> 0.13
0.13
>>> 0.14
0.14000000000000001

But practical issues aside, my preference would be to go to the other 
extreme: fix this inconsistency by changing the first output to 
0.13000000000000000 rather than changing the second output to 0.14.  That 
is, have repr(float) *always* output 17 digits, possibly except when that 
float is *exactly* representable in 16 or fewer decimal digits (e.g. 3.5, 
0.125, ...).  All the zeros act as a subtle reminder that the stored value 
is not exactly 0.13.  But I suspect this, too, isn't very practical.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:36:23 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 08 Jul 2008 13:36:23 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215524183.37.0.0932101897398.issue2275@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil: patch is fine.

Remember to provide not only a modification for docs, but also to the
Misc/NEWS file.

Thank you!!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:43:51 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 13:43:51 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215524631.69.0.876134310869.issue3088@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm still seeing intermittent lockups on Ubuntu 7.10 - traceback on
ctrl-C is similar to that posted by Ismail above.

Since Jesse seems to be on top of this, I'll stick to using -x
test_multiprocessing for the moment.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:44:56 2008
From: report at bugs.python.org (Alexander Shigin)
Date: Tue, 08 Jul 2008 13:44:56 +0000
Subject: [issue2944] asyncore doesn't handle connection refused correctly
In-Reply-To: <1211462641.02.0.497686644895.issue2944@psf.upfronthosting.co.za>
Message-ID: <1215524696.58.0.6354061968.issue2944@psf.upfronthosting.co.za>


Changes by Alexander Shigin <shigin at rambler-co.ru>:


Removed file: http://bugs.python.org/file10401/asyncore-connect-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2944>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:45:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 13:45:58 +0000
Subject: [issue3313] dlopen() error with no error message from dlerror()
In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
Message-ID: <1215524758.77.0.0388250279291.issue3313@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

As expected, the bug can be reproduced with ctypes.dlopen(). 
py_dl_open() function of Modules/_ctypes/callproc.c should be merged 
with Modules/dlmodule.c.

Here use at least the attached patch for ctypes (same job than the 
other patch: use default string if dlerror() returns NULL).

Added file: http://bugs.python.org/file10858/ctypes_dlopen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3313>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:46:36 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 13:46:36 +0000
Subject: [issue3088] test_multiprocessing hangs on OS X 10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215524795.98.0.871763345283.issue3088@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Bumping back to release blocker for beta 2 (Barry may choose to defer it
again, but it should at least be on his radar).

----------
priority: critical -> release blocker
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:47:48 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 13:47:48 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215524868.39.0.82583420507.issue3088@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Updated issue title to more accurately reflect scope of the problem.

----------
title: test_multiprocessing hangs on OS X 10.5.3 -> test_multiprocessing hangs intermittently on POSIX platforms

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 15:50:35 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 13:50:35 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1215525035.35.0.971725382243.issue3088@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I forgot to mention that I am seeing the intermittent hangs on the trunk
(2.6). I haven't been testing it on Py3k.

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul  8 16:15:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 14:15:02 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1215526502.65.0.608881239762.issue2517@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed in 64791.

Blocked from being merged to Py3k (since there is no longer a
__unicode__ special method).

For MAL: the PyInstance_Check included in the patch for the benefit of
classic classes defined in Python code also covers all of the classic C
extension classes which are not instances of object.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2517>
_______________________________________

From report at bugs.python.org  Tue Jul  8 16:15:53 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jul 2008 14:15:53 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1215526553.85.0.751174503116.issue2517@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2517>
_______________________________________

From report at bugs.python.org  Tue Jul  8 18:19:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jul 2008 16:19:41 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215533981.38.0.332629859822.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A slightly better patch, with tests.

Added file: http://bugs.python.org/file10859/fork-and-thread2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul  8 18:39:19 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 08 Jul 2008 16:39:19 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1215535159.15.0.376964055081.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

There appear to be 2 opinions on this issue:

1. It's a bug, a corner case that got missed.

2. It's always been like this, so it's probably a design decision,
although no-one can't point to where or when the decision was made...

Looking at the code, I think it's a bug.

Expected behaviour: if 'pattern' is a non-capturing regex, then
re.split(pattern, text) == re.sub(pattern, MARKER, text).split(MARKER).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Tue Jul  8 20:24:33 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 08 Jul 2008 18:24:33 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215541472.99.0.892884045832.issue874900@psf.upfronthosting.co.za>


Changes by Adam Olsen <rhamph at gmail.com>:


----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul  8 21:56:48 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 08 Jul 2008 19:56:48 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215547008.1.0.12306804228.issue1758146@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Apparently modwsgi uses subinterpreters because some third-party
packages aren't sufficiently thread-safe - modwsgi can't fix those
packages, so subinterpreters are the next best thing.

http://groups.google.com/group/modwsgi/browse_frm/thread/988bf560a1ae8147/2f97271930870989

This is a weak argument for language design.  Subinterpreters should be
deprecated, the problems with third-party packages found and fixed, and
ultimately subinterpreters ripped out.

If you wish to improve the situation, I suggest you help fix the
problems in the third-party packages.  For example,
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac implies trac
is configured with environment variables - clearly not thread-safe.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Tue Jul  8 22:11:06 2008
From: report at bugs.python.org (Vaclav Slavik)
Date: Tue, 08 Jul 2008 20:11:06 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215547865.97.0.791844110376.issue1758146@psf.upfronthosting.co.za>


Vaclav Slavik <vslavik at fastmail.fm> added the comment:

I'm sorry, did you actually read my comments? Once again, this has
nothing to do with threads and everything to do with isolation of
independent Python apps running in the same *process*. Hope it got
through this time :-/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Tue Jul  8 23:05:32 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jul 2008 21:05:32 +0000
Subject: [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1215551132.15.0.347498268368.issue3167@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm pretty much out of ideas here.  Skip, if you have any time to figure 
out where the math.log call is going wrong, I'd appreciate it.  On Jean's 
machine, the problem was that the call log(-inf) to the C library's log 
function was returning -inf instead of the expected nan.

The actual function call takes place in math_1, in the line 
"r = (*func)(x)" (line 178 of Modules/mathmodule.c in the current trunk, 
r64812).  A couple of printf calls would show the inputs and outputs to 
that function.

Is /usr/bin/ccs/ld Sun's own linker?  If so, why doesn't it accept the -
xlibmieee option?  (Or maybe it does, in which case the question is why 
isn't gcc passing that option to ld properly.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3167>
_______________________________________

From report at bugs.python.org  Tue Jul  8 23:10:11 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 08 Jul 2008 21:10:11 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215551411.68.0.707585634817.issue1758146@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Ahh, I did miss that bit, but it doesn't really matter.

Tell modwsgi to only use the main interpreter ("PythonInterpreter
main_interpreter"), and if you want multiple modules of the same name
put them in different packages.  Any other problems (trac using env vars
for configuration) should be fixed directly.

(My previous comment about building your own import mechanism was
overkill.  Writing a package that uses relative imports is enough - in
fact, that's what relative imports are for.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Tue Jul  8 23:36:46 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jul 2008 21:36:46 +0000
Subject: [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1215553006.75.0.282342709983.issue3167@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some other possibilities to try.  This page:

http://www.redhat.com/docs/wp/solaris_port/x99.html

seems to suggest that linking with -lieee, and possibly also adding the -
ffast-math gcc option, might help.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3167>
_______________________________________

From report at bugs.python.org  Wed Jul  9 00:05:01 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Tue, 08 Jul 2008 22:05:01 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215554701.47.0.574165824719.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

I believe PyThreadState_Swap function in ceval.c has a bug as I stated 
earlier.  However, I have not seen it included in the latest patches so 
now I wonder...

The following line in PyThreadState_Swap...
if (check && check->interp == newts->interp && check != newts)

should read as follows...
if (check && check->interp != newts->interp && check != newts)

since this condition, if true, raises an error.  Why should it raise an 
error if all the interpreters are equal across multiple thread states?  
If we have one interpreter with multiple thread states (i.e. multi-
threaded application) this function will error when switching between 
the thread states within the same interpreter (in DEBUG compile mode 
only since this code is commented out otherwise).  In the forums it 
describes the use of thread states to handle multiple python threads 
running simultaneously and not by using multiple interpreters but only 
one (the main interpreter).

Also the interpreters have be equal because in the documentation for 
the GIL functions it says it doesn't support multiple interpreters.  I 
think this is a typo/bug in the code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 00:25:27 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 08 Jul 2008 22:25:27 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215555927.81.0.721762299086.issue1758146@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Franco, you need to look at the line above that check:

	PyThreadState *check = PyGILState_GetThisThreadState();
	if (check && check->interp == newts->interp && check != newts)
		Py_FatalError("Invalid thread state for this thread");

PyGILState_GetThisThreadState returns the original tstate *for that
thread*.  What it's asserting is that, if there's a second tstate *in
that thread*, it must be in a different subinterpreter.

It doesn't prevent your second and third tstate from sharing the same
subinterpreter, but it probably should, as this check implies it's an
invariant.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 00:45:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 22:45:10 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

_multiprocessing.Connection() allows to use any positive (or nul) 
number has socket handle. If you use an invalid file descriptor, 
poll() method may crash (especially for big positive integer). 
Example:

>>> import _multiprocessing
>>> obj = _multiprocessing.Connection(44977608)
>>> obj.poll()
Erreur de segmentation (core dumped)

Fix: use fstat() to make sure that the handle is valid. Attached patch 
implements this feature.

Another solution would be to reuse code from Modules/selectmodule.c.

----------
components: Library (Lib)
files: _multiprocessing_connection.patch
keywords: patch
messages: 69446
nosy: haypo
severity: normal
status: open
title: _multiprocessing.Connection() doesn't check handle
versions: Python 2.6
Added file: http://bugs.python.org/file10860/_multiprocessing_connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Wed Jul  9 00:45:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 22:45:18 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1215557118.58.0.703227471795.issue3321@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Wed Jul  9 00:58:10 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 22:58:10 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

scanstring_str() and scanstring_unicode() functions don't end value 
whereas it can be outside input string range. A check like this is 
needed:
    if (end < 0 || len <= end) {
        PyErr_SetString(PyExc_ValueError, "xxx");
        return NULL;
    }

next is set to begin but few lines later (before first use of next), 
it's set to end: for (next = end; ...). 

In error message, eg. "Invalid control character at (...)", begin is 
used as character position but I think that the right position is in 
the variable "end" (or maybe "next"?).

I'm unable to fix these functions because I don't understand the code.

----------
components: Library (Lib)
messages: 69447
nosy: haypo
severity: normal
status: open
title: bugs in scanstring_str() and scanstring_unicode() of _json module
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Wed Jul  9 01:54:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2008 23:54:40 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1215561280.04.0.770172247948.issue3321@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Ooops, there is a typo in my last patch: it's "struct stat statbuf;" 
and not "struct stat *statbuf;"! Here is a new version of the patch.

Added file: http://bugs.python.org/file10861/_multiprocessing_connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Wed Jul  9 03:47:39 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 09 Jul 2008 01:47:39 +0000
Subject: [issue2887] bsddb3 needs to be ported to Python 3.0
In-Reply-To: <1210915662.48.0.494614370174.issue2887@psf.upfronthosting.co.za>
Message-ID: <1215568059.51.0.423794773952.issue2887@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

FWIW, I bumped the version of Berkeley DB being used on Windows from 
4.4.20 to 4.7.25 in r64555 (trunk).  I blocked this from being merged 
to py3k.  This block should be removed once bsddb has been updated.

----------
nosy: +Trent.Nelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2887>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:02:09 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 09 Jul 2008 02:02:09 +0000
Subject: [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1215568929.58.0.76541190185.issue3167@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Here's a gdb session using r64812.  gcc 4.2.2.  ldd on math.so shows:

% ldd build/lib.solaris-2.10-i86pc-2.6/math.so 
        libm.so.2 =>     /lib/libm.so.2
        libgcc_s.so.1 =>         /opt/app/nonc++/lib/libgcc_s.so.1
        libc.so.1 =>     /lib/libc.so.1

% gdb ./python 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
(gdb) b math_1
Function "math_1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (math_1) pending.
(gdb) r
Starting program: /home/tuba/skipm/src/python-svn/trunk/build/python 
Python 2.6b1+ (trunk:64812M, Jul  8 2008, 20:43:40) 
[GCC 4.2.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> inf = float('inf')
>>> math.log(-inf)

Breakpoint 1, math_1 (arg=0x81f1fbc, func=0x805e88c <log at plt>, 
can_overflow=0)
    at /home/tuba/skipm/src/python-svn/trunk/Modules/mathmodule.c:171
171     {
(gdb) p func
$1 = (double (*)(double)) 0x805e88c <log at plt>
(gdb) n 
173             x = PyFloat_AsDouble(arg);
(gdb) n
174             if (x == -1.0 && PyErr_Occurred())
(gdb) x
0x0:    Cannot access memory at address 0x0
(gdb) p x
$2 = -inf
(gdb) n
176             errno = 0;
(gdb) n
178             r = (*func)(x);
(gdb) n
180             if (Py_IS_NAN(r)) {
(gdb) p r
$3 = -inf

Does this help?  I don't know how to tell where log at plt is resolved, but 
I suppose it probably comes from /lib/libm.so.2.  It's got a date on my 
system of Jan 22 2005.  Any idea how to tell if there's a Sun patch for 
it?

As for the /usr/ccs/bin/ld thing, it doesn't look like we are using it, 
at least not directly.  Adding the --verbose flag to the link line I get 
this output:

% gcc --verbose -L/opt/app/nonc++/ncurses-5.6/lib -
R/opt/app/nonc++/ncurses-5.6/lib -L/opt/app/nonc++/gdbm-1.8/lib -
R/opt/app/nonc++/gdbm-1.8/lib -L/opt/app/nonc++/readline-4.3/lib -
R/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-8.4/lib -
R/opt/app/nonc++/tcl-8.4/lib -L/opt/app/nonc++/BerkleyDB-4.3/lib -
R/opt/app/nonc++/BerkleyDB-4.3/lib  -o python                 
Modules/python.o                 libpython2.6.a -lresolv -lsocket -lnsl 
-lrt -ldl    -lm
Reading specs from /opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-
solaris2.10/4.2.2/specs
Target: i386-pc-solaris2.10
Configured with: ../configure --prefix=/opt/app/g++lib6/gcc-4.2 --
enable-languages=c,c++,fortran,objc --disable-nls --with-included-
gettext --with-gnu-as --with-as=/usr/sfw/bin/gas --with-target-
tools=/usr/sfw/bin/ --with-gmp=/opt/app/nonc++/gmp-4.2 --with-
mpfr=/opt/app/nonc++/mpfr-2.3
Thread model: posix
gcc version 4.2.2
 /opt/app/g++lib6/gcc-4.2/libexec/gcc/i386-pc-solaris2.10/4.2.2/collect2 
-V -R/opt/app/nonc++/lib -R/opt/app/g++lib6/lib -
R/opt/app/nonc++/ncurses-5.6/lib -R/opt/app/nonc++/gdbm-1.8/lib -
R/opt/app/nonc++/readline-4.3/lib -R/opt/app/nonc++/tcl-8.4/lib -
R/opt/app/nonc++/BerkleyDB-4.3/lib -Y P,/usr/ccs/lib:/usr/lib -Qy -o 
python /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o 
/opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-solaris2.10/4.2.2/crtbegin.o -
L/opt/app/nonc++/ncurses-5.6/lib -L/opt/app/nonc++/gdbm-1.8/lib -
L/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-8.4/lib -
L/opt/app/nonc++/BerkleyDB-4.3/lib -L/opt/app/g++lib6/gcc-
4.2/lib/gcc/i386-pc-solaris2.10/4.2.2 -L/opt/app/g++lib6/gcc-
4.2/lib/gcc/i386-pc-solaris2.10/4.2.2/../../.. Modules/python.o 
libpython2.6.a -lresolv -lsocket -lnsl -lrt -ldl -lm -lgcc -lgcc_eh -lc 
-lgcc -lgcc_eh /opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-
solaris2.10/4.2.2/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482

I don't see /usr/ccs/bin/ld mentioned.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3167>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:30:50 2008
From: report at bugs.python.org (Kevin Watters)
Date: Wed, 09 Jul 2008 02:30:50 +0000
Subject: [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1215570649.89.0.722937463355.issue3258@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

>From reading through PEP 3118 once I'm not entirely clear on the role 
stgdict->format is supposed to be taking here, but I did get comtypes to 
compile and run successfully by changing line 910 from

stgdict->format = alloc_format_string("&", itemdict->format);

to

stgdict->format = alloc_format_string("&", itemdict->format ? itemdict-
>format : "P");

(Where "P" is just struct.pack's void pointer format string.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:46:00 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 09 Jul 2008 02:46:00 +0000
Subject: [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1215571560.65.0.689816249125.issue3167@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Regarding -lieee, I don't see an ieee library on my system.

Regarding -ffast-math, while it changes the log function which is linked 
to, it doesn't appear to modify the result of math.log:

% ldd build/lib.solaris-2.10-i86pc-2.6/math.so 
        libm.so.2 =>     /lib/libm.so.2
        libgcc_s.so.1 =>         /opt/app/nonc++/lib/libgcc_s.so.1
        libc.so.1 =>     /lib/libc.so.1
% gdb ./python
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
(gdb) b math_1
Function "math_1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (math_1) pending.
(gdb) r
Starting program: /home/tuba/skipm/src/python-svn/trunk/build/python 
Python 2.6b1+ (trunk:64812M, Jul  8 2008, 21:40:26) 
[GCC 4.2.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
im>>> import math
>>> inf = float('inf')
>>> math.log(-inf)

Breakpoint 1, math_1 (arg=0x81f19bc, func=0xfee2d6a0 <log>, 
can_overflow=0)
    at /home/tuba/skipm/src/python-svn/trunk/Modules/mathmodule.c:171
171     {
(gdb) func
Undefined command: "func".  Try "help".
(gdb) p func
$1 = (double (*)(double)) 0xfee2d6a0 <log>
(gdb) n
173             x = PyFloat_AsDouble(arg);
(gdb) n
174             if (x == -1.0 && PyErr_Occurred())
(gdb) p x
$2 = -inf
(gdb) n
176             errno = 0;
(gdb) n
178             r = (*func)(x);
(gdb) n
186             else if (Py_IS_INFINITY(r)) {
(gdb) p r
$3 = -inf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3167>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:55:58 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 02:55:58 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215572158.33.0.374366478477.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file10849/issue2275-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:56:23 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 02:56:23 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215572183.89.0.430554779771.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Here is the final patch for Py26 and Py3k including the Docs and Misc/News.

Thanks you,
Senthil

Added file: http://bugs.python.org/file10862/issue2275-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:57:01 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 02:57:01 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215572221.25.0.770963485309.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
versions:  -Python 2.5
Added file: http://bugs.python.org/file10863/issue2275-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  9 04:58:32 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 02:58:32 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215572312.42.0.724173604968.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I also removed the Python 2.5 from the Version, as I don't think these
changes will be back ported.
After the application of patch, this issue can be closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Jul  9 05:03:37 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 03:03:37 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215572617.1.0.633565244723.issue3300@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Jul  9 05:07:04 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 09 Jul 2008 03:07:04 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215572824.3.0.734311352274.issue3316@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul  9 05:12:49 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 09 Jul 2008 03:12:49 +0000
Subject: [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1215573169.34.0.960112594223.issue3167@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

The /lib/libm.so.* files on my Solaris 10 (Opteron) box are equally old:

> ll /lib/libm.so*
lrwxrwxrwx 1 root  root      9 Sep  7  2006 /lib/libm.so -> libm.so.2*
-rwxr-xr-x 1 root  bin   13536 Jan 22  2005 /lib/libm.so.1
-rwxr-xr-x 1 root  bin  337804 Jan 22  2005 /lib/libm.so.2


Also, this looks like a more recent patch for the Math libraries, under 3.2:

  <http://developers.sun.com/sunstudio/downloads/express_readme.html>


Then thare are the Studio patches SUN recommended the other day:

  <http://developers.sun.com/sunstudio/downloads/patches/ss11_patches.html>

If things change after I install those, I will certainly let you know.


/Jean Brouwers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3167>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:02:31 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Wed, 09 Jul 2008 04:02:31 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215576151.54.0.813520893271.issue3319@psf.upfronthosting.co.za>


Changes by Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:


Removed file: http://bugs.python.org/file10854/pystone.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:11:17 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Wed, 09 Jul 2008 04:11:17 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215576677.38.0.126863139856.issue3319@psf.upfronthosting.co.za>


Michael Patrick O'Keefe <michael.p.okeefe at gmail.com> added the comment:

After a more careful study of the documentation on how to make (proper)
patches, I'm submitting the patches again. This patches against the 2.6
trunk and py3k branch (R64812). I compiled both 2.6 and py3k and
confirmed that the ZeroDivisionError does not appear for both sets of code.

----------
versions: +Python 2.6
Added file: http://bugs.python.org/file10864/pystone_1_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:11:57 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Wed, 09 Jul 2008 04:11:57 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215576717.24.0.743302275449.issue3319@psf.upfronthosting.co.za>


Changes by Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:


Added file: http://bugs.python.org/file10865/pystone_1_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:12:47 2008
From: report at bugs.python.org (Michael Patrick O'Keefe)
Date: Wed, 09 Jul 2008 04:12:47 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1215576767.82.0.785546203323.issue3319@psf.upfronthosting.co.za>


Changes by Michael Patrick O'Keefe <michael.p.okeefe at gmail.com>:


Added file: http://bugs.python.org/file10866/pystone_err.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:21:21 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Wed, 09 Jul 2008 04:21:21 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <548137525CD243FCBC8EA6F5CD03113E@Kitchen>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

Thanks Adam

but....

I'm still confused because...

There is a new rule in version 2.3.5.  Which is one interpreter with many 
thread states are supported for the GIL functions.  So this code breaks that 
rule since this if statement is checking if the interpreters are different 
for the current GIL state and the new ts which it can't be (i.e. 
unsupported).   See this email that points to the python documentation for 
2.3.5 regarding this "new" rule...

http://mail.python.org/pipermail/python-dev/2005-May/053840.html

Here is the extract of the email pertaining to this issue...

The documentation (http://docs.python.org/api/threads.html) states
"Note that the PyGILState_*() functions assume there is only one
global interpreter (created automatically by Py_Initialize()). Python
still supports the creation of additional interpreters (using
Py_NewInterpreter()), but mixing multiple interpreters and the
PyGILState_*() API is unsupported. ", so it looks like that using the
PyGilState_XXX functions in the core threadmodule.c means the
Py_NewInterpreter() call (i.e. multiple interpreters) is no longer
supported when threads are involved.

So regardless if we use the GIL functions or the lower level functions it 
all eventually boils down to this Swap function which has this condition 
that doesn't match what the documentation is stating. So which way is it? 
Can't have it both ways.

It seems since 2.3.5 they don't want you to use multiple interpreters is my 
guess when threading is involved.

- Franco

----- Original Message ----- 
From: "Adam Olsen" <report at bugs.python.org>
To: <fdirosa at stny.rr.com>
Sent: Tuesday, July 08, 2008 6:25 PM
Subject: [issue1758146] Crash in PyObject_Malloc

Adam Olsen <rhamph at gmail.com> added the comment:

Franco, you need to look at the line above that check:

PyThreadState *check = PyGILState_GetThisThreadState();
if (check && check->interp == newts->interp && check != newts)
Py_FatalError("Invalid thread state for this thread");

PyGILState_GetThisThreadState returns the original tstate *for that
thread*.  What it's asserting is that, if there's a second tstate *in
that thread*, it must be in a different subinterpreter.

It doesn't prevent your second and third tstate from sharing the same
subinterpreter, but it probably should, as this check implies it's an
invariant.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 06:23:28 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Wed, 09 Jul 2008 04:23:28 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215577408.6.0.870045207015.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

Thanks Adam

but....

I'm still confused because...

There is a new rule in version 2.3.5.  Which is one interpreter with 
many thread states are supported for the GIL functions.  So this code 
breaks that rule since this if statement is checking if the 
interpreters are different for the current GIL state and the new ts 
which it can't be (i.e. unsupported).   See this email that points to 
the python documentation for 2.3.5 regarding this "new" rule...

http://mail.python.org/pipermail/python-dev/2005-May/053840.html

Here is the extract of the email pertaining to this issue...

The documentation (http://docs.python.org/api/threads.html) states
"Note that the PyGILState_*() functions assume there is only one
global interpreter (created automatically by Py_Initialize()). Python
still supports the creation of additional interpreters (using
Py_NewInterpreter()), but mixing multiple interpreters and the
PyGILState_*() API is unsupported. ", so it looks like that using the
PyGilState_XXX functions in the core threadmodule.c means the
Py_NewInterpreter() call (i.e. multiple interpreters) is no longer
supported when threads are involved.

So regardless if we use the GIL functions or the lower level functions 
it all eventually boils down to this Swap function which has this 
condition that doesn't match what the documentation is stating. So 
which way is it? Can't have it both ways.

It seems since 2.3.5 they don't want you to use multiple interpreters 
is my guess when threading is involved.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 07:26:04 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 09 Jul 2008 05:26:04 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215581164.42.0.0500202614042.issue1758146@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

It's only checking that the original tstate *for the current thread* and
the new tstate have a different subinterpreter.  A subinterpreter can
have multiple tstates, so long as they're all in different threads.

The documentation is referring specifically to the PyGILState_Ensure and
PyGILState_Release functions.  Calling these says "I want a tstate, and
I don't know if I had one already".  The problem is that, with
subinterpreters, you may not get a tstate with the subinterpreter you
want.  subinterpreter references saved in globals may lead to obscure
crashes or other errors - some of these have been fixed over the years,
but I doubt they all have.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 09:22:59 2008
From: report at bugs.python.org (Andy)
Date: Wed, 09 Jul 2008 07:22:59 +0000
Subject: [issue3323] Clarify __slots__ behaviour when inheriting
In-Reply-To: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za>
Message-ID: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za>


New submission from Andy <strangefeatures at users.sourceforge.net>:

Suggest clarification on behaviour of the __slots__ attribute when
inheriting from classes that don't have __slots__ defined. Obviously the
superclass automatically creates __dict__, and it seems the subclass
inherits this. I presume this is expected behaviour, but I think it
would be worth clarifying in the 'Notes on using __slots__' section -
perhaps add something like:

"If you define __slots__ on a subclass when its superclass doesn't have
__slots__ defined, the superclass will automatically create a __dict__
instance which will be inherited by the subclass (as will other instance
attributes). Defining __slots__ on the subclass doesn't block this
inheritance."

----------
assignee: georg.brandl
components: Documentation
messages: 69460
nosy: georg.brandl, strangefeatures
severity: normal
status: open
title: Clarify __slots__ behaviour when inheriting
type: feature request
versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3323>
_______________________________________

From report at bugs.python.org  Wed Jul  9 13:27:53 2008
From: report at bugs.python.org (kai zhu)
Date: Wed, 09 Jul 2008 11:27:53 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215602873.21.0.42924575475.issue3238@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

update: these 3k language features have been tested to work in python
2.5.2 w/ the backported opcodes

   pep3104  Access to Names in Outer Scopes
   pep3105  Make print a function
   pep3111  Simple input built-in in Python 3000
   pep3113  Removal of Tuple Parameter Unpacking
   pep3114  Renaming iterator.next() to .__next__()
   pep3115  Metaclasses in Python 3000
   pep3127  Integer Literal Support and Syntax
   pep3129  Class Decorators
   pep3132  Extended Iterable Unpacking

had to backport __build_class__ in bltinmodule.c to get metaclasses
working.  u can go to http://www-rcf.usc.edu/~kaizhu/work/py3to2/ for
more info

install/usage summary:
  1. build python 2.5.2 w/ patched ceval.c & bltinmodule.c
  2. download scripts: py3to2.py & _py3to2.py
  3. ln -s python3.0 python3k
  4. run python2.5 & type 'import py3to2' # it will automatically run
the pep tests

the script provides 3 functions similar to those in __builtin__:
compile_py3k, exec_py3k, eval_py3k

right now, working on backporting pep 3102 & 3107 - annotations &
keyword-only arguments.  apparently appending the co_kwonlyargcount attr
to codeobject in 2.5.2 doesn't seem to affect the build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Wed Jul  9 13:32:14 2008
From: report at bugs.python.org (ThomasH)
Date: Wed, 09 Jul 2008 11:32:14 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

The page http://docs.python.org/inst/search-path.html
contains a broken link to site module documentation.

Is: http://www.python.org/doc/devel/lib/module-site.html
Should be: http://docs.python.org/lib/module-site.html

----------
assignee: georg.brandl
components: Documentation
messages: 69462
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: Broken link in online doc
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Wed Jul  9 14:01:24 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 09 Jul 2008 12:01:24 +0000
Subject: [issue3325] use of cPickle in multiprocessing
In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
Message-ID: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

There are two places in multiprocessing where cPickle (gone from py3k
already) is used.
Both of them are in try .. except, so they don't break code.
Here is a patch that removes these uses.

----------
components: Library (Lib)
messages: 69463
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: use of cPickle in multiprocessing
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3325>
_______________________________________

From report at bugs.python.org  Wed Jul  9 14:05:28 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 09 Jul 2008 12:05:28 +0000
Subject: [issue3325] use of cPickle in multiprocessing
In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za>
Message-ID: <1215605128.41.0.949872490933.issue3325@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

And here is the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file10867/issue3325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3325>
_______________________________________

From report at bugs.python.org  Wed Jul  9 14:11:20 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 09 Jul 2008 12:11:20 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

py3k branch is still using -fno-strict-aliasing but I tested with gcc
4.3.1 and there are no strict aliasing warnings when this flag is removed.

Attached patch for py3k branch removes this flag. After applying the
patch configure should be regenerated with autoconf.

----------
components: Interpreter Core
files: strict-aliasing.patch
keywords: patch
messages: 69465
nosy: cartman
severity: normal
status: open
title: py3k shouldn't use -fno-strict-aliasing anymore
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10868/strict-aliasing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Wed Jul  9 14:32:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 09 Jul 2008 12:32:02 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215606722.32.0.831596827423.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Amaury - your latest patch doesn't seem to apply cleanly to trunk, it's 
choking on the Python/ceval.c changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 14:55:53 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Jul 2008 12:55:53 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215608153.68.0.560000722524.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a third patch with latest trunk.
Did you apply it to a clean checkout?

Added file: http://bugs.python.org/file10869/fork-and-thread3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 15:19:47 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 09 Jul 2008 13:19:47 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215609587.4.0.967965593089.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I had to flip on ignore whitespace to patch:
patch -p0 -l <~/Desktop/fork-and-thread3.patch

Worked. Unfortunately, test_threading is locking up during a make test. 
Here's the verbose regrtest.py output:

woot:python-trunk jesse$ ./python.exe Lib/test/regrtest.py -v 
test_threading
...snip
<thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_join_in_forked_from_thread 
(test.test_threading.ThreadJoinOnShutdown) ...

At this point it hangs (OS/X 10.5 latest)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 15:33:42 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 09 Jul 2008 13:33:42 +0000
Subject: [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

In _PyState_AddModule(), a list of (initially) 20 elements is created, 
but there is no guarantee that all elements are initialized.  In 
particular, it appears that element 0 is always NULL.  This is bad 
since this list is accessible through introspection, e.g. by 
gc.get_objects()

----------
components: Interpreter Core
messages: 69469
nosy: krisvale
severity: normal
status: open
title: NULL member in modules_by_index
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________

From report at bugs.python.org  Wed Jul  9 15:44:20 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 09 Jul 2008 13:44:20 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215611060.68.0.0496449138972.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Amaury, it looks like it's hanging in subprocess:

> /Users/jesse/open_source/subversion/python-
trunk/Lib/test/test_threading.py(338)_run_and_join()
-> p = subprocess.Popen([sys.executable, "-c", script], 
stdout=subprocess.PIPE)
(Pdb) step
...snip...

(Pdb) step
--Call--
> /Users/jesse/open_source/subversion/python-
trunk/Lib/threading.py(788)current_thread()
-> def current_thread():
(Pdb) step
> /Users/jesse/open_source/subversion/python-
trunk/Lib/threading.py(789)current_thread()
-> try:
(Pdb) step
> /Users/jesse/open_source/subversion/python-
trunk/Lib/threading.py(790)current_thread()
-> return _active[_get_ident()]
(Pdb) step
> /Users/jesse/open_source/subversion/python-
trunk/Lib/subprocess.py(1097)_execute_child()
-> data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
(Pdb) step
... lockup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 16:13:13 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Wed, 09 Jul 2008 14:13:13 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1215612793.35.0.179197188412.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

OK,

I think I found my problem.  I was using the main interpreter state 
(the one created by Py_Initialize) to create new thread states with.  
It seems that this interpreter state is reserved for GIL functions so 
one will need to create a new interpreter state with 
PyInterpeterState_New and use that interpreter state when creating the 
cooperating threads.  So now this check makes sense.  If one is 
swapping in a ts belonging to the main interpreter state, it best be 
the GIL thread state.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Wed Jul  9 17:20:50 2008
From: report at bugs.python.org (Tom Pinckney)
Date: Wed, 09 Jul 2008 15:20:50 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215616850.04.0.316970358707.issue3300@psf.upfronthosting.co.za>


Tom Pinckney <thomaspinckney3 at gmail.com> added the comment:

I mentioned this is in a brief python-dev discussion earlier this 
spring, but many popular websites such as Wikipedia and Facebook do use 
UTF-8 as their character encoding scheme for the path and argument 
portion of URLs.

I know there's no RFC that says this is what should be done, but in 
order to make urllib work out-of-the-box on as many common websites as 
possible, I think defaulting to UTF-8 decoding makes a lot of sense. 

Possibly allow an option charset argument to be passed into quote and 
unquote, but default to UTF-8 in the absence of an explicit character 
set being passed in?

----------
nosy: +thomaspinckney3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Jul  9 17:51:52 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 09 Jul 2008 15:51:52 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215618712.42.0.51291899833.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK I've gone back over the patch and decided to add the "encoding" and
"errors" arguments from the str.encode/decode methods as optional
arguments to quote and unquote. This is a much bigger change than I
originally intended, but I think it makes things much better because
we'll get UTF-8 by default (which as far as I can tell is by far the
most common encoding).

(Tom Pinckney just made the same suggestion right as I'm typing this up!)

So my new patch is a bit more extensive, and changes the interface (in a
backwards-compatible way). Both quote and unquote now support "encoding"
and "errors" arguments, defaulting to "utf-8" and "replace", respectively.

Implementation detail: This changes the Quoter class a lot; it now
hashes four fields to ensure it doesn't use the wrong cache.

Also fixed an issue with the previous patch where non-ASCII-compatible
encodings broke for code points < 128.

I then ran the full test suite and discovered two other modules test
cases broke. I've fixed them so the full suite passes, but I'm
suspicious there may be more issues (see below).

* Lib/test/test_http_cookiejar.py: A test case was written explicitly
expecting Latin-1 encoding. I've changed this test case to expect UTF-8.
* Lib/email/utils.py: I extensively analysed this code and discovered
that it kind of "cheats" - it uses the Latin-1 encoding and treats it as
octets, then applies its own encoding scheme. So to fix this, I changed
the email module to call quote and unquote with encoding="latin-1".
Hence it has the same behaviour as before.

Some potential issues:

* I have not updated the documentation yet. If this idea is to go ahead,
the docs will need to show these new optional arguments. (I'll do that
myself but haven't yet).
* While the full test suite passes, I'm sure there will be many more
issues since I've changed the interface. Therefore I don't recommend
this patch is accepted just yet. I plan to do an investigation into all
uses (within the standard lib) of quote and unquote to see if there are
any other compatibility issues, particularly within urllib. Hence I'll
respond to this again in a few days.
* The new patch to "safe" argument of quote allows non-ASCII characters
to be made safe. This correspondingly allows the construction of URIs
with non-ASCII characters. Is it better to allow users to do this if
they really want, or just mysteriously fail to let those characters through?

I would also like to have a separate pair of functions, unquote_raw and
quote_raw, which work on bytes objects instead of strings. (unquote_raw
would take a str and produce a bytes, while quote_raw would take a bytes
and produce a str). As URI encoding is fundamentally an octet encoding,
not a character encoding, this is the only way to do URI encoding
without choosing a Unicode character encoding. (I see some modules such
as "email" treating the implicit Latin-1 encoding as byte encoding,
which is a bit dodgy - they could benefit from raw functions). But as
that requires further changes to the interface, I'll save it for another
day.

Patch (parse.py.patch2) is for branch /branches/py3k, revision 64820.

Commit log:

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets
(previously implicitly decoded as ISO-8859-1). As per RFC 3986, default
is "utf-8".

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded (previously characters in range(128, 256)
were encoded as ISO-8859-1, and characters above that as UTF-8). Also
fixed characters greater than 256 not responding to "safe", and also not
being cached.

Lib/test/test_urllib.py, Lib/test/test_http_cookiejar.py: Updated test
cases which expected output in ISO-8859-1, now expects UTF-8.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file10870/parse.py.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Jul  9 18:48:52 2008
From: report at bugs.python.org (Dominic Lavoie)
Date: Wed, 09 Jul 2008 16:48:52 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>


New submission from Dominic Lavoie <dominic.lavoie at paraxip.com>:

This issue is similar to issue 1229429. In the called Python method, a 
regular expression fails to compile & PyEval_CallMethod() returns 0. 
However, the reference count is incremented by 1 which prevents the 
object from being destroyed.

Could the problem be in classobject.c, in instancemethod_call() ?

		if (newarg == NULL)
			return NULL;
		Py_INCREF(self);
		PyTuple_SET_ITEM(newarg, 0, self);
		for (i = 0; i < argcount; i++) {
			PyObject *v = PyTuple_GET_ITEM(arg, i);
			Py_XINCREF(v);
			PyTuple_SET_ITEM(newarg, i+1, v);
		}
		arg = newarg;
	}
	result = PyObject_Call((PyObject *)func, arg, kw);
	Py_DECREF(arg);
	return result;
}

If result is null, should Py_DECREF(self) be called in the case where 
self was non-null ?

----------
components: Interpreter Core
messages: 69474
nosy: dominic.lavoie
severity: normal
status: open
title: When PyObject_CallMethod fails, refcount is incorrect
type: resource usage
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Wed Jul  9 19:06:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Jul 2008 17:06:38 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1215623198.96.0.107859835668.issue3328@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, PyTuple_SET_ITEM() "steals" a reference to its argument, so that
ownership is transferred to the tuple.
The reference will be released when the tuple is disposed, with
Py_DECREF(arg).

What makes you think that there is a reference leak? Do you have a test
case?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Wed Jul  9 19:07:50 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 09 Jul 2008 17:07:50 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215623270.13.0.850728511017.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Here's the good news, with the patch applied to trunk, I'm not seeing 
hangs in the multiprocessing test suite. I'm running it on a tight loop 
excluding the threading tests to confirm.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 19:12:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Jul 2008 17:12:13 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215623533.54.0.136144352666.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well I was a bit presumptuous that my thread+fork tests would pass on
all platforms out of the box.
We should disable the tests, or have someone with better Unix expertise
examine and correct them.
At least I feel that the actual correction in threading.py goes in the
right direction.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 19:46:21 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 09 Jul 2008 17:46:21 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215625581.02.0.054909456872.issue874900@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

In general I suggest replacing the lock with a new lock, rather than
trying to release the existing one.  Releasing *might* work in this
case, only because it's really a semaphore underneath, but it's still
easier to think about by just replacing.

I also suggest deleting _active and recreating it with only the current
thread.

I don't understand how test_join_on_shutdown could succeed.  The main
thread shouldn't be marked as done.. well, ever.  The test should hang.

I suspect test_join_in_forked_process should call os.waitpid(childpid)
so it doesn't exit early, which would cause the original Popen.wait()
call to exit before the output is produced.  The same problem of
test_join_on_shutdown also applies.

Ditto for test_join_in_forked_from_thread.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 20:14:31 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 09 Jul 2008 18:14:31 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215627271.42.0.275033070454.issue874900@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Looking over some of the other platforms for thread_*.h, I'm sure
replacing the lock is the right thing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul  9 20:23:00 2008
From: report at bugs.python.org (Dominic Lavoie)
Date: Wed, 09 Jul 2008 18:23:00 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215623198.96.0.107859835668.issue3328@psf.upfronthosting.co.za>
Message-ID: <CEEBIBHFMBAAIBBMKMMFOEHLEDAA.dominic.lavoie@paraxip.com>


Dominic Lavoie <dominic.lavoie at paraxip.com> added the comment:

My application is fairly complex so I am currently trying to build a simple test case that reproduces the problem. Will let you know as soon as it is ready.

Regards,

Dominic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Wed Jul  9 20:42:04 2008
From: report at bugs.python.org (Dominic Lavoie)
Date: Wed, 09 Jul 2008 18:42:04 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1215628924.74.0.67736178448.issue3328@psf.upfronthosting.co.za>


Dominic Lavoie <dominic.lavoie at paraxip.com> added the comment:

OK, I have been able to reproduce the problem with a simple test 
program. All you have to do is compile issue328.c and run it. 
issue328.py compiles an invalid regexp. You will see that the refcount 
goes from 1 to 2 if the regexp compilation fails but stays constant if 
the regexp compilation is successful.

Added file: http://bugs.python.org/file10871/issue3328.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Wed Jul  9 21:48:53 2008
From: report at bugs.python.org (Jukka Laurila)
Date: Wed, 09 Jul 2008 19:48:53 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>


New submission from Jukka Laurila <jukka.p.laurila at nokia.com>:

Currently Python always uses the C library malloc/realloc/free as the
underlying mechanism for requesting memory from the OS, but especially
on memory-limited platforms it is often desirable to be able to override
the allocator and to redirect all Python's allocations to use a special
heap. This will make it possible to free memory back to the operating
system without restarting the process, and to reduce fragmentation by
separating Python's allocations from the rest of the program.

The proposal is to make it possible to set the allocator used by the
Python interpreter by calling the following function before Py_Initialize():

void Py_SetAllocator(void* (*alloc)(size_t), void* (*realloc)(void*,
size_t), void (*free)(void*))

Direct function calls to malloc/realloc/free in obmalloc.c must be
replaced with calls through the function pointers set through this
function. By default these would of course point to the C stdlib
malloc/realloc/free.

----------
components: Interpreter Core
messages: 69482
nosy: jlaurila
severity: normal
status: open
title: API for setting the memory allocator used by Python
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Wed Jul  9 21:56:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Jul 2008 19:56:59 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215633419.23.0.363387176083.issue3329@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Is registering pointers to functions really necessary, or would defining
macros work as well? From a performance perspective I would like to
avoid having a pointer indirection step every time malloc/realloc/free
is called.

I guess my question becomes, Jukka, is this more for alternative
implementations of Python where changes to source are already expected,
or for apps that embed Python where a change of malloc/realloc/free
varies from app to app that dynamically loads Python?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Wed Jul  9 22:07:34 2008
From: report at bugs.python.org (Adam Olsen)
Date: Wed, 09 Jul 2008 20:07:34 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215634054.44.0.454666171114.issue3329@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

How would this allow you to free all memory?  The interpreter will still
reference it, so you'd have to have called Py_Finalize already, and
promise not to call Py_Initialize afterwords.  This further supposes the
process will live a long time after killing off the interpreter, but in
that case I recommend putting python in a child process instead.

----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Wed Jul  9 22:26:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 09 Jul 2008 20:26:41 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215635201.32.0.25178960245.issue3300@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Jul  9 22:28:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 09 Jul 2008 20:28:48 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215635328.34.0.490711412016.issue3300@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Assuming the patch is acceptable in the first place (which I personally
have not made my mind up), then it lacks documentation and test suite
changes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Jul  9 23:10:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Jul 2008 21:10:16 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1215637816.73.0.836020566978.issue2542@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

FWIW some comments by Amaury are here:
http://codereview.appspot.com/483

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Wed Jul  9 23:11:25 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Jul 2008 21:11:25 +0000
Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common
	case raises
In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za>
Message-ID: <1215637885.64.0.321998380515.issue2303@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Does anyone care about this still?

I added some comments on
http://codereview.appspot.com/504

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2303>
_______________________________________

From report at bugs.python.org  Wed Jul  9 23:37:00 2008
From: report at bugs.python.org (Adrian Petrescu)
Date: Wed, 09 Jul 2008 21:37:00 +0000
Subject: [issue3330] webbrowser module doesn't correctly handle '|' character.
In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
Message-ID: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>


New submission from Adrian Petrescu <apetresc at gmail.com>:

The webbrowser module seems to treat URLs containing the "|" character
differently based on whether the browser is already running or not.

For instance, consider the following python script:

import webbrowser
url = "http://foo.com/bar.html?var=x|y|z"
webbrowser.open(url)


If you run this script while the browser is already running (so that
webbrowser.open creates a new tab) this behaves as you would expect,
with the given URL as an address.

However, if a browser is not already running, when webbrowser.open
creates it, it seems to interpret the "|" as a seperator character, so
that the browser will open with THREE tabs, one open to
"http://foo.com/bar.html?var=x", one to "http://y" and one to "http://z".

This is clearly a bug, webbrowser module should be smart enough to
escape the "|" character if the browser is interpreting that line
differently.

This happens in Linux with Python 2.5 and Firefox 3.0. Not sure if it
happens with anything else.

----------
components: Library (Lib)
messages: 69488
nosy: AdrianP
severity: normal
status: open
title: webbrowser module doesn't correctly handle '|' character.
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3330>
_______________________________________

From report at bugs.python.org  Wed Jul  9 23:38:56 2008
From: report at bugs.python.org (Adrian Petrescu)
Date: Wed, 09 Jul 2008 21:38:56 +0000
Subject: [issue3330] webbrowser module doesn't correctly handle '|' character.
In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
Message-ID: <1215639536.53.0.428082288233.issue3330@psf.upfronthosting.co.za>


Adrian Petrescu <apetresc at gmail.com> added the comment:

Just as an aside, the reason I consider this a fairly serious bug is
that the Google Charts API urls make heavy use of the '|' character,
which means if I want to have Python use it by opening the user's
browser, it won't work if they don't already have a browser open.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3330>
_______________________________________

From report at bugs.python.org  Thu Jul 10 00:02:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Jul 2008 22:02:37 +0000
Subject: [issue3328] When PyObject_CallMethod fails, refcount is incorrect
In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za>
Message-ID: <1215640957.49.0.754727920482.issue3328@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the short case. It makes everything simpler.
First, note that you get the same behaviour with python-only code:

import re, sys
class Issue3328:
    def f(self):
        # unbalanced parenthesis
        x = re.compile('(123')

o = Issue3328()
sys.getrefcount(o)      # prints 2
o.f()
sys.getrefcount(o)      # prints 3

And this is normal: the last exception contains the traceback (stored in
sys.last_traceback) which contains the live context frames which
reference the "self" variable which is the additional reference to our
object.
Try to provoke another error (any SyntaxError will do) and see the
refcount decrease.

Now, the three variables sys.last_traceback, sys.last_type and
sys.last_value contain the info about the last *uncaught* exception.
An exception is said to be *uncaught* when PyErr_Print() is called to
print it... That's what happens at the interactive prompt, of course,
and in your C code.

Looking at python source code, PyErr_Print() is actually a single call
to PyErr_PrintEx(1), the parameter (1) is named "set_sys_last_vars"
(aha!). You should try to call PyErr_PrintEx(0) instead, and see if this
improves something.

Then a documentation path will be very welcomed ;-)

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3328>
_______________________________________

From report at bugs.python.org  Thu Jul 10 01:05:45 2008
From: report at bugs.python.org (Yarko Tymciurak)
Date: Wed, 09 Jul 2008 23:05:45 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1215644745.08.0.426058194673.issue1662581@psf.upfronthosting.co.za>


Yarko Tymciurak <yarkot1 at gmail.com> added the comment:

Not sure if this is a real-world case of this in particular, but possibly:
http://groups.google.com/group/web2py/browse_thread/thread/59ff2e31698bced6/9bbae2d482d11b88

----------
nosy: +yarkot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_______________________________________

From report at bugs.python.org  Thu Jul 10 01:59:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Jul 2008 23:59:48 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215647988.2.0.404138002795.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A new patch:
- I replaced "_active_limbo_lock.release()" by
"_active_limbo_lock=_allocate_lock()"

- I replaced the successive deletions in _active by a re-creation with
only the current thread. There is no difference in the result, but I
agree that the intent is more clear.

- yes, the main thread is marked as done when the interpreter exits
(hence the convoluted tests with subprocesses): in Modules/main.c,
WaitForThreadShutdown() calls threading._shutdown().

Also, I hope the tests make more sense now.

Added file: http://bugs.python.org/file10872/fork-and-thread4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 10 03:55:01 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 10 Jul 2008 01:55:01 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215654901.53.0.773652038658.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK well here are the necessary changes to the documentation (RST docs
and docstrings in the code).

As I said above, I plan to to extensive testing and add new cases, and I
don't recommend this patch is accepted until that's done.

Patch (parse.py.patch3) is for branch /branches/py3k, revision 64834.

Commit log:

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets
(previously implicitly decoded as ISO-8859-1). As per RFC 3986, default
is "utf-8".

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded (previously characters in range(128, 256)
were encoded as ISO-8859-1, and characters above that as UTF-8). Also
fixed characters greater than 256 not responding to "safe", and also not
being cached.

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface.

Lib/test/test_urllib.py, Lib/test/test_http_cookiejar.py: Updated test
cases which expected output in ISO-8859-1, now expects UTF-8.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file10873/parse.py.patch3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Jul 10 10:05:37 2008
From: report at bugs.python.org (Jukka Laurila)
Date: Thu, 10 Jul 2008 08:05:37 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215677136.98.0.287675991536.issue3329@psf.upfronthosting.co.za>


Jukka Laurila <jukka.p.laurila at nokia.com> added the comment:

Brett, the ability to define the allocator dynamically at runtime could
be a compile time option, turned on by default only on small memory
platforms. On most platforms you can live with plain old malloc and may
want to avoid the indirection. If no other platform is interested in
this, we can just make it a Symbian-specific extension but I wanted to
see if there's general interest in this.

The application would control the lifecycle of the Python heap, and this
seemed like the most natural way for the application to tell the
interpreter which heap instance to use.

Adam, the cleanup would work by freeing the entire heap used by Python
after calling Py_Finalize. In the old PyS60 code we made Python 2.2.2
clean itself completely by freeing the Python-specific heap and making
sure all pointers to heap-allocated items are properly reinitialized.

Yes, there are various static pointers that are initially set to NULL,
initialized to point at things on the heap and not reset to NULL at
Py_Finalize, and these are currently an obstacle to calling
Py_Initialize again. I'm considering submitting a separate ticket about
that since it seems like the ability to free the heap combined with the
ability to reinitialize the static pointers could together make full
cleanup possible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Thu Jul 10 11:31:30 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 09:31:30 +0000
Subject: [issue3287] Fraction constructor should raise TypeError instead of
	AttributeError
In-Reply-To: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za>
Message-ID: <1215682289.91.0.141319942381.issue3287@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r64835.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3287>
_______________________________________

From report at bugs.python.org  Thu Jul 10 11:38:22 2008
From: report at bugs.python.org (Carl Johnson)
Date: Thu, 10 Jul 2008 09:38:22 +0000
Subject: [issue3331] Possible inconsistency in behavior of list comprehensions
	vs. generator expressions
In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
Message-ID: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>


New submission from Carl Johnson <carl at carlsensei.com>:

Compare the following behaviors:

    Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
    [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
    Type "help", "copyright", "credits" or "license" for more 
information.
     >>> def f(x):
    ...  if x > 5: raise StopIteration
    ...
     >>> [x for x in range(100) if not f(x)]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 1, in <listcomp>
      File "<stdin>", line 2, in f
    StopIteration
     >>> list(x for x in range(100) if not f(x))
    [0, 1, 2, 3, 4, 5]

One might object that the behavior of the list comprehension is 
identical to that of a for-loop:

    >>> r = []
    >>> for x in range(100):
    ...  if not f(x):
    ...   r.append(x)
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
      File "<stdin>", line 2, in f
    StopIteration

However, it can be argued that in Python 3 list comprehensions should be 
thought of as "syntatic sugar" for ``list(generator expression)`` not a 
for-loop with an accumulator. (This seems to be the motivation for no 
longer "leaking" variables from list comprehensions into their enclosing 
namespace.)

One interesting question that this raises (for me at least) is whether 
the for-loop should also behave like a generator expression. Of course, 
the behavior of the generator expression can already be simulated by 
writing:

    >>> r = []
    >>> for x in range(100):
    ...  try:
    ...   if f(x):
    ...    r.append(x)
    ...  except StopIteration:
    ...   break
    ... 
    >>> r
    [0, 1, 2, 3, 4, 5]

This raises the question, do we need both a ``break`` statement and 
``raise StopIteration``? Can the former just be made into syntatic sugar 
for the later?

----------
components: Interpreter Core
messages: 69496
nosy: carlj
severity: normal
status: open
title: Possible inconsistency in behavior of list comprehensions vs. generator expressions
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3331>
_______________________________________

From report at bugs.python.org  Thu Jul 10 11:59:17 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Jul 2008 09:59:17 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215683957.42.0.727262284706.issue3329@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given where we are in the release cycle, I've bumped the target releases
to 2.7/3.1. So Symbian are probably going to have to do something
port-specific anyway in order to get 2.6/3.0 up and running.

And in terms of hooking into this kind of thing, some simple macros that
can be overriden in pyport.h (as Brett suggested) may be a better idea
than baking any specific approach into the core interpreter.

----------
nosy: +ncoghlan
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Thu Jul 10 12:11:08 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Jul 2008 10:11:08 +0000
Subject: [issue3274] Py_CLEAR(tmp) seg faults
In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
Message-ID: <1215684667.96.0.370949188366.issue3274@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A better option may be to append _tmp to the passed in token:

#define Py_CLEAR(op)				\
        do {                            	\
                if (op) {			\
                        PyObject *op##_tmp = (PyObject *)(op);	\
                        (op) = NULL;		\
                        Py_DECREF(op##_tmp);		\
                }				\
        } while (0)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3274>
_______________________________________

From report at bugs.python.org  Thu Jul 10 12:12:35 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 10:12:35 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215684755.14.0.0559398223919.issue3329@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think it is reasonable to get a macro definition change into 2.6.
The OP's request is essential for his application (running Python
on Nokia phones) and it would be a loss to wait two years for this.
Also, his request for a macro will enable another important piece
of functionality -- allowing a build to intercept and instrument all
calls to the memory allocator.

Barry, can you rule on whether to keep this open for consideration in 
2.6.   It seems daft to postpone this discussion indefinitely.  If we 
can agree to a simple, non-invasive solution while there is still yet 
another beta, then it makes sense to proceed.

----------
assignee:  -> barry
nosy: +barry, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Thu Jul 10 14:24:58 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 10 Jul 2008 12:24:58 +0000
Subject: [issue3274] Py_CLEAR(tmp) seg faults
In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
Message-ID: <1215692698.89.0.561243267353.issue3274@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Appending _tmp is a good idea, but it won't work when the parameter
isn't a simple symbol.  For example, there's a line in cPickle.c like
this: Py_CLEAR(*p).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3274>
_______________________________________

From report at bugs.python.org  Thu Jul 10 15:29:38 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 13:29:38 +0000
Subject: [issue1700288] Armin's method cache optimization updated for Python
	2.6
Message-ID: <1215696577.99.0.636477195616.issue1700288@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700288>
_______________________________________

From report at bugs.python.org  Thu Jul 10 15:30:24 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 13:30:24 +0000
Subject: [issue1568] PATCH: Armin's attribute lookup caching for 3.0
In-Reply-To: <1197034097.09.0.871896219058.issue1568@psf.upfronthosting.co.za>
Message-ID: <1215696624.92.0.383132929713.issue1568@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1568>
_______________________________________

From report at bugs.python.org  Thu Jul 10 15:59:54 2008
From: report at bugs.python.org (Jens Diemer)
Date: Thu, 10 Jul 2008 13:59:54 +0000
Subject: [issue3332] DocTest and dict sort.
In-Reply-To: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>
Message-ID: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>


New submission from Jens Diemer <bugs.python.org at jensdiemer.de>:

The doctest doesn't work good, if a function returns a dict.

Here a simple example:

def test(d):
    """
    This works:
    >>> test({"A":1, "B":2, "C":3})
    {'A': 1, 'C': 3, 'B': 2}
   
    This failed, because of different dict sort:
    >>> test({"A":1, "B":2, "C":3})
    {'A': 1, 'B': 2, 'C': 3}
   
    The Error messages:

    Failed example:
        test({"A":1, "B":2, "C":3})
    Expected:
        {'A': 1, 'B': 2, 'C': 3}
    Got:
        {'A': 1, 'C': 3, 'B': 2}
    """
    return d


The problem is IMHO that doctest.py [1] OutputChecker.check_output()
does compare the repr() of the dict and not the real dict as data.

One solution: Use eval() to convert the string repr. of the dict into
the real dict:

...
        #-----<add>-----
        try:
            if eval(got) == eval(want):
                return True
        except:
            pass #*pfeif* kein schoener stil, aber pragmatisch
        #-----</add>----
        # We didn't find any match; return false.
        return False

German discuss can be found here:
http://www.python-forum.de/topic-15321.html

[1] http://svn.python.org/view/python/trunk/Lib/doctest.py?view=markup

----------
components: Extension Modules
messages: 69501
nosy: jedie
severity: normal
status: open
title: DocTest and dict sort.
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3332>
_______________________________________

From report at bugs.python.org  Thu Jul 10 16:03:53 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 14:03:53 +0000
Subject: [issue3301] DoS when lo is negative in bisect.insort_right() / _left()
In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za>
Message-ID: <1215698633.13.0.307525354012.issue3301@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in 64845.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3301>
_______________________________________

From report at bugs.python.org  Thu Jul 10 16:06:11 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 10 Jul 2008 14:06:11 +0000
Subject: [issue3332] DocTest and dict sort.
In-Reply-To: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>
Message-ID: <1215698771.1.0.999853528981.issue3332@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is not a bug: dict do not guarantee the ordering of the keys, so it
may change on every run.

A good practice is to test a sorted .items() output of your dict in your
doctest.

----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3332>
_______________________________________

From report at bugs.python.org  Thu Jul 10 16:13:36 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 14:13:36 +0000
Subject: [issue3332] DocTest and dict sort.
In-Reply-To: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za>
Message-ID: <1215699216.92.0.302613073547.issue3332@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Closing as not a bug.

FWIW, here's the relevant text from the docs:
---------------------------------------------
23.2.3.6 Warnings 
doctest is serious about requiring exact matches in expected output. If 
even a single character doesn't match, the test fails. This will 
probably surprise you a few times, as you learn exactly what Python 
does and doesn't guarantee about output. For example, when printing a 
dict, Python doesn't guarantee that the key-value pairs will be printed 
in any particular order, so a test like 


>>> foo()
{"Hermione": "hippogryph", "Harry": "broomstick"}

is vulnerable! One workaround is to do 


>>> foo() == {"Hermione": "hippogryph", "Harry": "broomstick"}
True

instead. Another is to do 


>>> d = foo().items()
>>> d.sort()
>>> d
[('Harry', 'broomstick'), ('Hermione', 'hippogryph')]

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3332>
_______________________________________

From report at bugs.python.org  Thu Jul 10 16:36:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 14:36:32 +0000
Subject: [issue3285] Fraction.from_any()
In-Reply-To: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za>
Message-ID: <1215700592.37.0.0306118944562.issue3285@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Adopted the solution used by functions in the math module.  Functions 
that accept floats also accept integral inputs.  This improves 
usability in face of mixed float/int data or decimal/int data.

See r64846.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3285>
_______________________________________

From report at bugs.python.org  Thu Jul 10 17:06:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Jul 2008 15:06:25 +0000
Subject: [issue3333] Need -3 warning for exec statement becoming a function
Message-ID: <1215702385.26.0.978692514818.issue3333@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: rhettinger
priority: high
severity: normal
status: open
title: Need -3 warning for exec statement becoming a function
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3333>
_______________________________________

From report at bugs.python.org  Thu Jul 10 17:44:11 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 10 Jul 2008 15:44:11 +0000
Subject: [issue3330] webbrowser module doesn't correctly handle '|' character.
In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
Message-ID: <1215704650.98.0.113252448451.issue3330@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I was able to duplicate this, but it's an issue with Firefox, not
Python. webbrowser.open(url) just passes url as a command line argument
to the web browser; it doesn't do any manipulation.

Note that you get the exact same behaviour if you run Firefox from the
command line:

> firefox 'http://foo.com/bar.html?var=x|y|z'

Opens this URL in a new tab if it's already open, but splits on '|' and
opens in 3 separate tabs if Firefox isn't running.

Note also that while this string is a URL, it isn't properly normalized.

This works fine if you call

webbrowser.open("http://foo.com/bar.html?var=x%7Cy%7Cz")

(Which you can only obtain programmatically by generating the URL
properly in the first place, by using urllib.urlencode, or urllib.quote
on the value string "x|y|z").

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3330>
_______________________________________

From report at bugs.python.org  Thu Jul 10 18:05:10 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 10 Jul 2008 16:05:10 +0000
Subject: [issue3331] Possible inconsistency in behavior of list comprehensions
	vs. generator expressions
In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
Message-ID: <1215705910.76.0.273696569479.issue3331@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

You seem to be suggesting that a StopIteration raised in the body of a
for-loop should cause the loop to break. That isn't (as far as I know)
the point of StopIteration. StopIteration is only used to break the
for-loop when raised by the iterator, not the body.

Hence I think the list comprehension is behaving correctly, as the
for-loop is, in that they are both raising the StopIteration you threw,
not catching it. That's valid, because you didn't throw it in the
iterator, you threw it in the condition.

What's more strange (to me) is the fact that the generator expression
stops when it sees a StopIteration. Note that this also happens if you
do it in the head of the generator expression. eg

def f(x):
    if x > 5:
            raise StopIteration
    return x

>>> list((f(x) for x in range(0, 100)))
[0, 1, 2, 3, 4, 5]

However, if you translate that into the full generator function version:

def my_generator_expr():
    for x in range(0, 100):
        yield f(x)

You see that it is behaving correctly.

So I think you discovered an interesting quirk, but it's hard to say
anything here is misbehaving.

By the way this is not a new issue with Python 3.0. Flagging it as a
Python 2.5 issue as well.

----------
nosy: +mgiuca
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3331>
_______________________________________

From report at bugs.python.org  Thu Jul 10 18:13:04 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 10 Jul 2008 16:13:04 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215706384.14.0.192659013615.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Setting Version back to Python 3.0. Is there a reason it was set to
Python 3.1? This proposal will certainly break a lot of code. It's *far*
better to do it in the big backwards-incompatible Python 3.0 release
than a later release.

----------
versions: +Python 3.0 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Jul 10 18:46:13 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Jul 2008 16:46:13 +0000
Subject: [issue3331] Possible inconsistency in behavior of list comprehensions
	vs. generator expressions
In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
Message-ID: <1215708373.65.0.770303082559.issue3331@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

IMO the generator expression is wrong in interpreting the StopIteration
as a break. It should fail just like the list comprehension fails.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3331>
_______________________________________

From report at bugs.python.org  Thu Jul 10 18:55:13 2008
From: report at bugs.python.org (Christian Theune)
Date: Thu, 10 Jul 2008 16:55:13 +0000
Subject: [issue3334] 2to3 looses indentation on import fix
In-Reply-To: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>
Message-ID: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>


New submission from Christian Theune <ct at gocept.com>:

I got this output from 2to3:

(This is from setuptools egg_info.py)

-        import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)
+from . import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69510
nosy: collinwinter, ctheune
severity: normal
status: open
title: 2to3 looses indentation on import fix
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3334>
_______________________________________

From report at bugs.python.org  Thu Jul 10 18:57:11 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 10 Jul 2008 16:57:11 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1215709031.3.0.595533680838.issue3329@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Basically you just want to kick the malloc implementation into doing
some housekeeping, freeing its caches?  I'm kinda surprised you don't
add the hook directly to your libc's malloc.

IMO, there's no use-case for this until Py_Finalize can completely tear
down the interpreter, which requires a lot of special work (killing(!)
daemon threads, unloading C modules, etc), and nobody intends to do that
at this point.

The practical alternative, as I said, is to run python in a subprocess.
 Let the OS clean up after us.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Thu Jul 10 19:10:31 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 10 Jul 2008 17:10:31 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215709831.14.0.848459639115.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

FWIW: the threading tests still hang for me with the latest patch. I'm 
confirming that the patch itself fixes the hanging MP tests though

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 10 19:42:35 2008
From: report at bugs.python.org (Collin Winter)
Date: Thu, 10 Jul 2008 17:42:35 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215711755.02.0.696809410412.issue3316@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

- You should add tests to test_fixers to ensure that this does what you
expect. This will make it much easier for others to modify this fixer
later. You can probably just reuse the tests Brett initially added.

- There's a better data structure for MAPPING: rather than using

MAPPING = {module: [(new_module, [member, member, ..., member])]}

you should probably use

MAPPING = {module: {new_module: [member, member, ..., member]}}

The list-of-2-tuples was a bad idea on my part that didn't scale.

- The "cannot handle star imports" warning isn't strictly correct: star
imports for robotparser and urlparse can both be handled correctly,
since they're just being renamed.

- urlparse and robotparser don't seem to belong to this more specialized
fixer: they can go in fix_imports, since they aren't being broken across
multiple modules.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Thu Jul 10 20:21:49 2008
From: report at bugs.python.org (Justin Harper)
Date: Thu, 10 Jul 2008 18:21:49 +0000
Subject: [issue3335] subprocess lib - opening same command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>


New submission from Justin Harper <justin.harper at gmail.com>:

When I make the same shell call a second time, a weird error occurs.  
It appears that the system is caching the call and then returning the 
same object the second time, which causes a problem because the stream 
is at EOF and there is no way to seek on this sort of file object.

Code:
        fout = subprocess.Popen("owplaces -silent -multi", shell=True, 
stdout=subprocess.PIPE).stdout
        self.output = fout.read()
        
        if self.output != []:
            for line in self.output:
                print line
        
        fout.close()

Error:
Traceback (most recent call last):
  File "./saveSettings.py", line 30, in next_page
    func()
  File "./saveSettings.py", line 62, in save_startup
    fout = subprocess.Popen("owplaces -silent -multi", shell=True, 
stdout=subprocess.PIPE).stdout
  File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 
61, in warn
    warn_explicit(message, category, filename, lineno, module, registry)
  File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 
82, in warn_explicit
    for item in filters:
TypeError: an integer is required


The first time the code works time.  The second (and subsequent times) 
the cryptic error msg is displayed.

Python 2.4.5 running on a Solaris machine.

----------
components: Library (Lib)
messages: 69514
nosy: gtg944q
severity: normal
status: open
title: subprocess lib - opening same command fails
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________

From report at bugs.python.org  Thu Jul 10 20:22:59 2008
From: report at bugs.python.org (Justin Harper)
Date: Thu, 10 Jul 2008 18:22:59 +0000
Subject: [issue3335] subprocess lib - opening same command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1215714179.23.0.600312869758.issue3335@psf.upfronthosting.co.za>


Justin Harper <justin.harper at gmail.com> added the comment:

Correction:  line two should actually be:
self.output = fout.readlines()

The bug still exists with this change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________

From report at bugs.python.org  Thu Jul 10 20:35:44 2008
From: report at bugs.python.org (Erik Stephens)
Date: Thu, 10 Jul 2008 18:35:44 +0000
Subject: [issue1673409] datetime module missing some important methods
Message-ID: <1215714943.97.0.797750636261.issue1673409@psf.upfronthosting.co.za>


Erik Stephens <python at 24ksoftware.com> added the comment:

I'm not sure this is still being considered, so I just wanted to add my
opinion.  This seems like such a simple request being made overly
complicated.  We just want seconds since epoch since that is used in
many other functions and libraries (i.e. the time module,
os.stat().st_mtime).  Why is there toordinal()?!?  If there is going to
be any toxxx() methods, there should definitely be a
tosecs()/totimestamp() method or an 'epoch/timestamp' attribute.  For
boundary cases, I would look to the std time module for guidance.

----------
nosy: +erik.stephens

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673409>
_______________________________________

From report at bugs.python.org  Thu Jul 10 21:39:49 2008
From: report at bugs.python.org (ryanboesch)
Date: Thu, 10 Jul 2008 19:39:49 +0000
Subject: [issue3336] datetime weekday() function
In-Reply-To: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>
Message-ID: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>


New submission from ryanboesch <ryanboesch at gmail.com>:

Leap year ignored each century (2100, 2200, 2300, etc.) except 2000 for
the weekday() function. This code reproduces the error:

import datetime
datetime.date(2100,2,29).weekday()

Error message:
ValueError: day is out of range for the month

Also, this causes the weekday to be 1 day off from March 1st, 2100 to
February 28th 2200 and 2 days off...

----------
messages: 69517
nosy: ryanboesch
severity: normal
status: open
title: datetime weekday() function
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3336>
_______________________________________

From report at bugs.python.org  Thu Jul 10 22:32:55 2008
From: report at bugs.python.org (Tim Peters)
Date: Thu, 10 Jul 2008 20:32:55 +0000
Subject: [issue3336] datetime weekday() function
In-Reply-To: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>
Message-ID: <1215721975.36.0.809386335675.issue3336@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

The error message is correct.  In the Gregorian calendar, years
divisible by 100 are not leap years, unless they're also divisible by
400.  So 2000, 2400, 2800, ..., are leap years, but 2100, 2200, 2300,
2500, 2600, 2700, 2900, ... are not leap years.  Look it up (anywhere ;-)).

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3336>
_______________________________________

From report at bugs.python.org  Thu Jul 10 22:55:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Jul 2008 20:55:43 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215706384.14.0.192659013615.issue3300@psf.upfronthosting.co.za>
Message-ID: <4876774B.2040508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Setting Version back to Python 3.0. Is there a reason it was set to
> Python 3.1? 

3.0b1 has been released, so no new features can be added to 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Jul 11 00:04:55 2008
From: report at bugs.python.org (Christopher Li)
Date: Thu, 10 Jul 2008 22:04:55 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
In-Reply-To: <1214815759.99.0.839974928144.issue1424152@psf.upfronthosting.co.za>
Message-ID: <70318cbf0807101459k220bd3d9s5a3dcd0141931f1b@mail.gmail.com>


Christopher Li <python at chrisli.org> added the comment:

Hi,

After a closer look of your testing program. I believe that your testing
program is not correct. It might be the urllib way of doing things. But
that is not the urllib2 way of doing it. You should add a proxy_handler
rather than directly set_proxy on request objects.

The reason is that, you mess req directly. The urllib2 will not handle
correctly if the request needs rebuild and forward to other handlers.
One example is if the request needs redirect, I believe your test program
will not work.

So the right way of doing things, IMHO, is just adding a proxy handler
which contain the proxy you want. Then that proxy handler will just
automatically set_proxy() to every request it goes out. It even works
if the request needs to be rebuilt.

Then my patch should just work in that case. Try to make it work
for your test script will make things unnecessary complicated.
That defeats the benefit of the handler call chain in urllib2.

Does it make sense to you?

Thanks,

Chris

On Mon, Jun 30, 2008 at 1:49 AM, Nagy Ferenc L?szl?
<report at bugs.python.org> wrote:
> The test program was:
>
> import urllib2
>
> targeturl = 'https://www.paypal.com/'
> proxyhost = 'proxy.xxxxxxxx.hu:3128'
>
> req = urllib2.Request(targeturl)
> req.set_proxy(proxyhost, 'https')
> response = urllib2.urlopen(req)
> print response.info()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Jul 11 00:35:18 2008
From: report at bugs.python.org (John J Lee)
Date: Thu, 10 Jul 2008 22:35:18 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215729316.71.0.157184400698.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

* The patch looks like it will break code that uses .header_items(),
which is not acceptable.

* The patch to the docs seems to muddy the waters even further (than the
current slightly murky state) about whether and why .headers is to be
preferred over the methods, or vice-versa.  I think .headers should
remain undocumented, for the reason stated by the doctest that failed
with Hans-Peter's original patch.  The best course of action is
debatable, but the patch is a regression in this respect, so should not
be committed as-is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 00:38:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jul 2008 22:38:12 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215729492.73.0.60003525252.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a slightly more polished version of the previous patch;  no
behaviour changes.

Let me know if there's anything I can do to help get this in before next 
week's beta.  Anybody want to trade patch reviews?

Added file: http://bugs.python.org/file10874/hex_float4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul 11 00:38:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Jul 2008 22:38:58 +0000
Subject: [issue3333] Need -3 warning for exec statement becoming a function
In-Reply-To: <1215729538.84.0.0566383780098.issue3333@psf.upfronthosting.co.za>
Message-ID: <1215729538.84.0.0566383780098.issue3333@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

No, I don't think we do. This is something that 2to3 can handle well,
and also rather pointless because it would be impossible to get rid of
the warning in 2.x because exec isn't a function in 2.x.(short of
removing the exec completely!)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3333>
_______________________________________

From report at bugs.python.org  Fri Jul 11 01:55:40 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 10 Jul 2008 23:55:40 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215734140.08.0.7274074773.issue2275@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

John:

You say that it will break code because it changes the capitalization
policy, or because other reason? Do you think that there's a way to fix
this issue and not break the code? 

If you really think that this breaks code, please provide a test case.

Regarding .headers, having a public attribute not documented never is a
better solution than document it, with its benefits and its shortcomings. 

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 02:08:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 00:08:03 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1215734883.7.0.653299819798.issue3316@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

What Collin said. =)

I will put robotparser and urlparse into fix_imports myself and continue
to update the docs in 2.x for urllib(2).

Thanks to the both of you for helping with this! It's going to be great
once this fixer is ready to go as it will put PEP 3108 REALLY close to
being finished!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Fri Jul 11 03:51:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 01:51:44 +0000
Subject: [issue3337] Fixer for dbm is failing
In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
Message-ID: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The fixer for dbm to dbm.ndbm fails test_fixers.Test_imports .

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69526
nosy: brett.cannon, collinwinter
priority: critical
severity: normal
status: open
title: Fixer for dbm is failing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3337>
_______________________________________

From report at bugs.python.org  Fri Jul 11 03:52:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 01:52:22 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1215741142.79.0.672901567993.issue2775@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Fixer for dbm is failing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jul 11 03:52:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 01:52:40 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1215741160.9.0.612144848324.issue2775@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +fix_imports does not handle intra-package renames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jul 11 04:21:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 02:21:20 +0000
Subject: [issue3337] Fixer for dbm is failing
In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
Message-ID: <1215742880.63.0.103024108059.issue3337@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The failure seems to be from anydbm being mapped directly to dbm:

import anydbm -> import dbm -> import dbm.ndbm

A separate pass might be needed to handle dbm properly so that an import
is not changed multiple times.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3337>
_______________________________________

From report at bugs.python.org  Fri Jul 11 04:29:39 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 11 Jul 2008 02:29:39 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1215729316.71.0.157184400698.issue2275@psf.upfronthosting.co.za>
Message-ID: <20080711022927.GA3618@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

> John J Lee <jjlee at users.sourceforge.net> added the comment:
> 
> * The patch looks like it will break code that uses .header_items(),
> which is not acceptable.

Nope, it does not break. If the concern was subclassing dict may have adverse
effect on .copy and .update methods, thats taken care because the subclass just passes it to the original dict method, which would behave the same way.

    >>> r.header_items()
    [('Spam-Eggs', 'blah')]
    >>> r.add_header("Foo-Bar", "baz")
    >>> items = r.header_items()
    >>> items.sort()
    >>> items
    [('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]

> * The patch to the docs seems to muddy the waters even further (than the
> current slightly murky state) about whether and why .headers is to be
> preferred over the methods, or vice-versa.  I think .headers should
> remain undocumented, for the reason stated by the doctest that failed
> with Hans-Peter's original patch.

IIRC, Hans-Peter's comment was on the reference to .headers undocumented interface mentioned in the test_urllib2.

>  The best course of action is
> debatable, but the patch is a regression in this respect, so should not
> be committed as-is.

My understanding in this case was to address 1) Title()-ize the headers and 2)
provide a case insensitive lookup.

Is this sufficient now to expose the headers method? If not, what else?
If headers method should not be exposed, then will the 2 cases addressed above
still do, as this issue request was opened for that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 04:44:02 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 11 Jul 2008 02:44:02 +0000
Subject: [issue3159] glob.py improvements
In-Reply-To: <1214041877.01.0.817721592815.issue3159@psf.upfronthosting.co.za>
Message-ID: <1215744242.41.0.296434587358.issue3159@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

If readability is enhanced is questionable, but is rejected on the basis
that cosmetic-only changes are not generally recommended: only
difficults following the code evolution in the repository.

The only change that I see regarding performance is the one involving
startswith, and it's actually wrong:

facundo at pomcat:~$ timeit.py -s "s='qwerty'" "s[0]=='q';s[0]=='x'"
1000000 loops, best of 3: 0.338 usec per loop
facundo at pomcat:~$ timeit.py -s "s='qwerty'"
"s.startswith('q');s.startswith('x')"
1000000 loops, best of 3: 0.854 usec per loop

Thanks anyway!

----------
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3159>
_______________________________________

From report at bugs.python.org  Fri Jul 11 04:55:27 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 11 Jul 2008 02:55:27 +0000
Subject: [issue2674] unittest.TestProgram uses sys.exit()
In-Reply-To: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>
Message-ID: <1215744927.47.0.792207347181.issue2674@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

That class is normally used at the end of the testing suite, as is
recommended in the documentation.

In any case, I don't see that like a bug, so we shouldn't be changing
that behaviour, because of compatibility.

What do you think? Maybe the documentation should be more explicit about
this? Thanks!

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2674>
_______________________________________

From report at bugs.python.org  Fri Jul 11 06:11:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 04:11:32 +0000
Subject: [issue3337] Fixer for dbm is failing
In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
Message-ID: <1215749492.67.0.937963050744.issue3337@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have a potential solution brewing; running the full test suite to verify.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3337>
_______________________________________

From report at bugs.python.org  Fri Jul 11 06:54:22 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 11 Jul 2008 04:54:22 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>


New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:

In at least Python 2.4, using cPickle.Pickler to try and pickle a nested
chain of objects more than about 2590 objects deep causes the Python
interpreter to segfault. This doesn't seem to happen when using the pure
Python pickle module.

It is not memory related (witness that the pure Python module can
achieve depths much greater than this just fine), and does not seem to
be directly related to system architecture (happens on both i386 and on
x86_64 (32bit and 64bit)).

Sample interpreter session to replicate:
>>> # Let's cause cPickle to segfault:
>>> from cPickle import Pickler as cPickler
>>> class rec:
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
...
>>> import sys
>>> sys.setrecursionlimit(10000)
>>> mychain = rec(2600)
>>> from cStringIO import StringIO
>>> stream = StringIO()
>>> p = cPickler(stream, 1)
>>> res = p.dump(mychain)
Segmentation fault

And now the same steps again using the pure Python Pickler:
>>> import sys
>>> from pickle import Pickler as pPickler
>>> from cStringIO import StringIO
>>> class rec:
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> sys.setrecursionlimit(20000)
>>> mychain = rec(2600)
>>> stream = StringIO()
>>> p = pPickler(stream, 1)
>>> p.dump(mychain)
>>> len(stream.getvalue())
48676
>>>

----------
components: Library (Lib)
messages: 69532
nosy: esrever_otua
severity: normal
status: open
title: cPickle segfault with deep recursion
type: crash
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Fri Jul 11 07:57:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 05:57:08 +0000
Subject: [issue3337] Fixer for dbm is failing
In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za>
Message-ID: <1215755828.88.0.115981697621.issue3337@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r64870 has the fix through fix_imports2.

----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3337>
_______________________________________

From report at bugs.python.org  Fri Jul 11 08:49:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Jul 2008 06:49:03 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1215758943.87.0.940002461216.issue3338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you try this for a newer version? For 2.4, such problems will not be
fixed anymore.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Fri Jul 11 09:03:26 2008
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 11 Jul 2008 07:03:26 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215759805.77.0.557528898975.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> 3.0b1 has been released, so no new features can be added to 3.0.

While my proposal is no doubt going to cause a lot of code breakage, I
hardly consider it a "new feature". This is very definitely a bug. As I
understand it, the point of a code freeze is to stop the addition of
features which could be added to a later version. Realistically, there
is no way this issue can be fixed after 3.0 is released, as it
necessarily involves changing the behaviour of this function.

Perhaps I should explain further why this is a regression from Python
2.x and not a feature request. In Python 2.x, with byte strings, the
encoding is not an issue. quote and unquote simply encode bytes, and if
you want to use Unicode you have complete control. In Python 3.0, with
Unicode strings, if functions manipulate string objects, you don't have
control over the encoding unless the functions give you explicit
control. So Python 3.0's native Unicode strings have broken the library.

I give two examples.

Firstly, I believe that unquote(quote(x)) should always be true for all
strings x. In Python 2.x, this is always trivially true (for non-Unicode
strings), because they simply encode and decode the octets. In Python
3.0, the two functions are inconsistent, and break out of the range(0, 256).

>>> urllib.parse.unquote(urllib.parse.quote('?')) # '\u00ff'
'?'
# Works, because both functions work with ISO-8859-1 in this range.

>>> urllib.parse.unquote(urllib.parse.quote('?')) # '\u0100'
'?\x80'
# Fails, because quote uses UTF-8 and unquote uses ISO-8859-1.

My patch succeeds for all characters.
>>> urllib.parse.unquote(urllib.parse.quote('?')) # '\u0100'
'?'

Secondly, a bigger example, but I want to demonstrate how this bug
affects web applications, even very simple ones.

Consider this simple (beginnings of a) wiki system in Python 2.5, as a
CGI app:

#---
import cgi

fields = cgi.FieldStorage()
title = fields.getfirst('title')

print("Content-Type: text/html; charset=utf-8")
print("")

print('<p>Debug: %s</p>' % repr(title))
if title is None:
    print("No article selected")
else:
    print('<p>Information about %s.</p>' % cgi.escape(title))
#---

(Place this in cgi-bin, navigate to it, and add the query string
"?title=Page Title"). I'll use the page titled "M?tt" as a test case.

If you navigate to "?title=M?tt", it displays the text "Debug:
'M\xc3\xa1tt'. Information about M?tt.". The browser (at least Firefox,
Safari and IE I have tested) encodes this as "?title=M%C3%A1tt". So this
is trivial, as it's just being unquoted into a raw byte string
'M\xc3\xa1tt', then written out again as a byte string.

Now consider that you want to manipulate it as a Unicode string, still
in Python 2.5. You could augment the program to decode it as UTF-8 and
then re-encode it. (I wrote a simple UTF-8 printing function which takes
Unicode strings as input).

#---
import sys
import cgi

def printu8(*args):
    """Prints to stdout encoding as utf-8, rather than the current terminal
    encoding. (Not a fully-featured print function)."""
    sys.stdout.write(' '.join([x.encode('utf-8') for x in args]))
    sys.stdout.write('\n')

fields = cgi.FieldStorage()
title = fields.getfirst('title')
if title is not None:
    title = str(title).decode("utf-8", "replace")

print("Content-Type: text/html; charset=utf-8")
print("")

print('<p>Debug: %s.</p>' % repr(title))
if title is None:
    print("No article selected.")
else:
    printu8('<p>Information about %s.</p>' % cgi.escape(title))
#---

Now given the same input ("?title=M?tt"), it displays "Debug:
u'M\xe1tt'. Information about M?tt." Still working fine, and I can
manipulate it as Unicode because in Python 2.x I have direct control
over encoding/decoding.

Now let us upgrade this program to Python 3.0. (Note that I still can't
print Unicode characters directly out, because running through Apache
the stdout encoding is not UTF-8, so I use my printu8 function).

#---
import sys
import cgi

def printu8(*args):
    """Prints to stdout encoding as utf-8, rather than the current terminal
    encoding. (Not a fully-featured print function)."""
    sys.stdout.buffer.write(b' '.join([x.encode('utf-8') for x in args]))
    sys.stdout.buffer.write(b'\n')

fields = cgi.FieldStorage()
title = fields.getfirst('title')
# Note: No call to decode. I have no opportunity to specify the encoding
since
# it comes straight out of FieldStorage as a Unicode string.

print("Content-Type: text/html; charset=utf-8")
print("")

print('<p>Debug: %s.</p>' % ascii(title))
if title is None:
    print("No article selected.")
else:
    printu8('<p>Information about %s.</p>' % cgi.escape(title))
#---

Now given the same input ("?title=M?tt"), it displays "Debug:
'M\xc3\xa1tt'. Information about M??tt." Once again, it is erroneously
(and implicitly) decoded as ISO-8859-1, so I end up with a meaningless
Unicode string. The only possible thing I can do about this as a web
developer is call title.encode('latin-1').decode('utf-8') - a dreadful hack.

With my patch applied, the input ("?title=M?tt") produces the output
"Debug: 'M\xe1tt'. Information about M?tt."

Basically, this bug is going to affect all web developers as soon as
someone types a non-ASCII character. You could argue that supporting
UTF-8 by default is no better than supporting Latin-1 by default, but it
is. UTF-8 supports encoding of all characters where Latin-1 does not,
UTF-8 is the recommended URI encoding by both the URI Syntax RFC[1] and
the W3C HTML 4.01 specification[2], and all major browsers use it to
encode non-ASCII characters in URIs.

My patch may not be the best, or most conservative, solution to this
problem. I'm happy to see other proposals. But it's clearly an important
bug to fix, if I can't even write the simplest web app I can think of
without having to use a kludgey hack to get the string decoded
correctly. What is the point of having nice clean Unicode strings in the
language if the library spits out the wrong characters and it requires
more work to fix them than it used to with byte strings?

[1] http://tools.ietf.org/html/rfc3986#section-2.5
[2] http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Jul 11 09:12:52 2008
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Fri, 11 Jul 2008 07:12:52 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215760372.5.0.885308389729.issue2275@psf.upfronthosting.co.za>


Hans-Peter Jansen <hpj at urpla.net> added the comment:

Facundo, first of all: *really* nice work, thanks a lot.

While I don't fully understand the issues raised lately here, 
especially what broke (user code). I can see, that it completely 
solves my original problem, which is great.

While reading the patch, I noticed, that the modifications to 
Doc/library/urllib2.rst contain two typos ("retrive" instead 
of "retrieve").

The only remaining issue left in this area is using some form of 
ordered dict for headers in order to control - how it comes - the 
order of headers ;-), but that's left for another issue to raise some 
day.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 09:18:48 2008
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 11 Jul 2008 07:18:48 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215760728.32.0.137337519367.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Since I got a complaint that my last reply was too long, I'll summarize it.

It's a bug report, not a feature request.

I can't get a simple web app to be properly Unicode-aware in Python 3,
which worked fine in Python 2. This cannot be put off until 3.1, as any
viable solution will break existing code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Jul 11 09:27:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Jul 2008 07:27:02 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215761222.7.0.790778066608.issue3317@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury, as Alan is fine with these changes, feel free to apply them.

----------
assignee: loewis -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Fri Jul 11 09:52:35 2008
From: report at bugs.python.org (Henk Punt)
Date: Fri, 11 Jul 2008 07:52:35 +0000
Subject: [issue3339] dummy_thread LockType.acquire() always returns None,
	should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>


New submission from Henk Punt <henkpunt at gmail.com>:

Class LockType always seems to be returning None if waitflag is not
specified.

If you look up the documentation for the non dummy lock in lib ref
15.3.1 , none of the possible
results should be ?None?, in fact it would always return True, except
when non-block is specified
And another thread is already holding the lock then it would return False

>From the docs on acquire():

Acquire a lock, blocking or non-blocking. 
When invoked without arguments, block until the lock is unlocked, then
set it to locked, and return true. 
When invoked with the blocking argument set to true, do the same thing
as when called without arguments, and return true. 
When invoked with the blocking argument set to false, do not block. If a
call without an argument would block, return false immediately;
otherwise, do the same thing as when called without arguments, and
return true.

----------
components: Library (Lib)
messages: 69539
nosy: toymachine
severity: normal
status: open
title: dummy_thread LockType.acquire() always returns None, should be True or False
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________

From report at bugs.python.org  Fri Jul 11 10:12:04 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 11 Jul 2008 08:12:04 +0000
Subject: [issue3339] dummy_thread LockType.acquire() always returns None,
	should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215763924.34.0.872976474519.issue3339@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Seems like inconsistency to me, this simple patch should fix it.

----------
keywords: +patch
nosy: +mishok13
Added file: http://bugs.python.org/file10875/issue3339.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________

From report at bugs.python.org  Fri Jul 11 10:17:20 2008
From: report at bugs.python.org (Gerard)
Date: Fri, 11 Jul 2008 08:17:20 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1215764240.83.0.656641875209.issue1519638@psf.upfronthosting.co.za>


Gerard <gjp at gp-net.nl> added the comment:

Hi All,

I found a workaround for the re.sub method so it does not raise an
exception but returns and empty string when backref-ing an empty group.

This is the nutshell:

When doing a search and replace with sub, replace the group represented
as optional for a group represented as an alternation with one empty
subexpression. So instead of this ?(.+?)?? use this ?(|.+?)? (without
the double quotes).

If there?s nothing matched by this group the empty subexpression
matches. Then an empty string is returned instead of a None and the sub
method is executed normally instead of raising the ?unmatched group? error.

A complete description is in my post:
http://www.gp-net.nl/2008/07/11/solved-python-regex-raising-exception-unmatched-group/


Regards,

Gerard.

----------
nosy: +gerardjp
title: Unmatched Group issue -> Unmatched Group issue - workaround

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Fri Jul 11 10:28:31 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jul 2008 08:28:31 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215764911.94.0.216335814894.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Minor modifications to the previous patch,  mostly to the docs.

Setting priority to critical, since this really needs to go in before the 
next beta if it's going to get into 2.6/3.0.

----------
priority:  -> critical
Added file: http://bugs.python.org/file10876/hex_float5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Fri Jul 11 12:46:00 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jul 2008 10:46:00 +0000
Subject: [issue3340] optparse print_usage(),.. methods are not documented
In-Reply-To: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za>
Message-ID: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

optparse API documentation is incomplete. It doesn't mention at least
some useful functions such as print_usage(), get_usage(),
get/print_version() present in optparse.py docstrings.

----------
assignee: georg.brandl
components: Documentation
messages: 69543
nosy: georg.brandl, techtonik
severity: normal
status: open
title: optparse print_usage(),.. methods are not documented
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3340>
_______________________________________

From report at bugs.python.org  Fri Jul 11 13:10:09 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jul 2008 11:10:09 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It would be convenient to have "Suggest a change" link in the bottom of
documentation pages to allow people propose fixes and additions. 

This can be a simple feedback form with an optional "patch" field that
submits mail to a list or simply adds documentation comment.

More complex approach would be construct patch right in the browser.
Then add it for review into "documentation queue". "documentation queue"
is a part of documentation system to automatically submit patches after
review (and optionally incrementally-recompile existing output formats).
In case of page comments review status can be displayed in place
together with comments and patches. The whole edit/review process may
require single sign on system described in issue #2837

----------
assignee: georg.brandl
components: Documentation
messages: 69544
nosy: georg.brandl, techtonik
severity: normal
status: open
title: "Suggest a change" link

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Fri Jul 11 13:11:15 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jul 2008 11:11:15 +0000
Subject: [issue2823] "Report bug" links
In-Reply-To: <1210534928.44.0.636090674533.issue2823@psf.upfronthosting.co.za>
Message-ID: <1215774675.59.0.668302312633.issue2823@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Filed a proposal for online documentation editing tool.
http://bugs.python.org/issue3341

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2823>
_______________________________________

From report at bugs.python.org  Fri Jul 11 13:31:19 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Jul 2008 11:31:19 +0000
Subject: [issue3333] Need -3 warning for exec statement becoming a function
In-Reply-To: <1215729538.84.0.0566383780098.issue3333@psf.upfronthosting.co.za>
Message-ID: <1215775879.35.0.460629125374.issue3333@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3333>
_______________________________________

From report at bugs.python.org  Fri Jul 11 14:03:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 12:03:13 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

r62555 has the unfortunate effect that source lines are no more indented
in tracebacks, as in:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\python\trunk\lib\re.py", line 150, in sub
return _compile(pattern, 0).sub(repl, string, count)
  File "C:\python\trunk\lib\re.py", line 276, in filter
return sre_parse.expand_template(template, match)
  File "c:\python\trunk\lib\sre_parse.py", line 793, in expand_template
raise error, "unmatched group"
sre_constants.error: unmatched group

And IMO, test_traceback.test_traceback_indentation() tests the wrong
behaviour :-(
I join a tentative patch to correct the problem.

----------
files: traceback.patch
keywords: patch
messages: 69546
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Tracebacks are not properly indented
Added file: http://bugs.python.org/file10877/traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 14:12:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 12:12:57 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1215778377.24.0.645794624839.issue3112@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think there is a problem when the source file cannot be opened (a .pyc
without its .py): the four spaces are printed, but not the line, and the
following level is not properly indented.

See issue3342 for a competing patch that corrects the indentation problem.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Fri Jul 11 14:20:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 12:20:49 +0000
Subject: [issue3343] Py_DisplaySourceLine is not documented
In-Reply-To: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>
Message-ID: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This new function is not documented at all.
And I find the error handling not consistent: when filename is NULL, -1
is returned, but no exception is set.

IMO the return code should be as follow:
- return 1 if a line was printed
- return 0 if the line cannot be found
- return -1 in case of error (when calling PyFile_WriteString); an
exception is set.

----------
components: Interpreter Core
messages: 69548
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Py_DisplaySourceLine is not documented
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3343>
_______________________________________

From report at bugs.python.org  Fri Jul 11 14:29:12 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 11 Jul 2008 12:29:12 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215779352.06.0.34796135229.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I can confirm that this seems to clear up the test_multiprocessing hangs 
on my mac, I ran make test in a loop almost all day yesterday without 
hangs. I would really suggest we get this in, minus the new test_threading 
tests for now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Fri Jul 11 15:08:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 13:08:06 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215781686.7.0.00987115616237.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree. My attempt to describe the behaviour of fork+threads in a
platform-independent test is another issue.

Just one more thing: looking at Module/posixmodule.c, os.fork1() calls
PyOS_AfterFork() in both parent and child processes. Is there a "if (pid
== 0)" test missing, just like os.fork()?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Fri Jul 11 15:30:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 13:30:05 +0000
Subject: [issue1779233] PyThreadState_SetAsyncExc and the main thread
Message-ID: <1215783005.56.0.881533405153.issue1779233@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Two things may prevent the exception from being seen:

- First, the async exception is not immediate; it is checked every 100
bytecodes (=sys.getcheckinterval()). When testing from the interactive
prompt, try something like "for x in range(100): pass".

- Then, chances are that the exceptions is actually raised, but silently
swallowed somewhere by the interpreter: for example, if the exception is
raised from inside a __getattr__ function of some object, when called by
hasattr().

SetAsyncExc does not seem very reliable...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1779233>
_______________________________________

From report at bugs.python.org  Fri Jul 11 17:31:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jul 2008 15:31:54 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215790314.59.0.221921953209.issue1580@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Mildly off-topic:  it seems that currently eval(repr(x)) == x isn't 
always true, anyway.  On OS X 10.5.4/Intel, I get:

>>> x = (2**52-1)*2.**(-1074)
>>> x
2.2250738585072009e-308
>>> y = eval(repr(x))
>>> y
2.2250738585072014e-308
>>> x == y
False

This is almost certainly an OS X bug...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul 11 17:43:22 2008
From: report at bugs.python.org (Lukasz Szybalski)
Date: Fri, 11 Jul 2008 15:43:22 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1215791002.39.0.654768799446.issue2054@psf.upfronthosting.co.za>


Lukasz Szybalski <szybalski at gmail.com> added the comment:

Is the ftp-tls able to use certificate to connect to ftps server?
I currently need to connect to state's ftps server which requires
certificate to be present when authenticating. 

Is that option available? What is the current status of this issue?

Thanks,
Lucas

----------
nosy: +lszyba1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:22:40 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 11 Jul 2008 16:22:40 +0000
Subject: [issue1580] Use shorter float repr when possible
In-Reply-To: <1197314007.06.0.227642647262.issue1580@psf.upfronthosting.co.za>
Message-ID: <1215793360.88.0.946231581949.issue1580@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

About (2**52-1)*2.**(-1074):  same outcome under Cygwin 2.5.1, which is
presumably based on David Gay's "perfect rounding" code.  Cool ;-)

Under the native Windows 2.5.1:

>>> x = (2**52-1)*2.**(-1074)
>>> x
2.2250738585072009e-308
>>> y = eval(repr(x))
>>> y
0.0

Hard to say whether that's actually worse :-(

About %.15g, good point!  It probably would "make Guido happy".  It's
hard to know for sure, because despite what people say about this, the
real objection to the status quo is aesthetic, not technical, and
there's no disputing tastes.

My tastes agree that %.17g is a pain in the ass when using the
interactive shell -- I rarely want to see so many digits.  But %.15g,
and even %.12g, would /still/ be a pain in the ass, and for the same
reason.  Most times I'd be happiest with plain old %g (same as %.6g). 
OTOH, sometimes I do want to see all the bits, and sometimes I'd like a
fixed format (like %.2f), and so on.

Alas, all choices suck for strong reasons (either technical or aesthetic
 -- and, BTW, your "lots of trailing zeroes" idea won't fly because of
the latter).

The introduction of hex formats for floats should make this starkly
clear:  using hex I/O for float repr would be the ideal technical
choice:  easy to code, extremely fast, compact representation, and
highly portable.  Those are supposedly repr's goals, regardless of
whether the repr string is easily readable by humans.  But you know
without asking that using hex format for repr(float) has no chance of
being adopted -- because it's ugly :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1580>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:32:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 16:32:08 +0000
Subject: [issue3339] dummy_thread LockType.acquire() always returns None,
	should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215793928.39.0.119316635063.issue3339@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:34:16 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 16:34:16 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215794056.67.0.62605268631.issue3342@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:34:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 16:34:56 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215794096.72.0.574426906669.issue3342@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I really hate how touchy the indentation output is for warnings/tracebacks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:36:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 16:36:46 +0000
Subject: [issue3343] Py_DisplaySourceLine is not documented
In-Reply-To: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>
Message-ID: <1215794206.84.0.557170116188.issue3343@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The function should be made private as it is not expected to be called
by anyone else but the core.

----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3343>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:37:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 16:37:25 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215794245.0.0.222885610374.issue3342@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is why I added an explicit "indent" parameter to Py_DisplaySourceLine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:38:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 16:38:15 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215794295.35.0.343019914403.issue3342@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 18:52:20 2008
From: report at bugs.python.org (Brandon Mintern)
Date: Fri, 11 Jul 2008 16:52:20 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1215795140.22.0.0183355797816.issue1519638@psf.upfronthosting.co.za>


Brandon Mintern <bmintern at gmail.com> added the comment:

Looking at your code example, that solution seems quite obvious now, and
I wouldn't even call it a "workaround". Thanks for figuring this out.
Now if I could only remember what code I was using that for...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Fri Jul 11 20:23:55 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Jul 2008 18:23:55 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1215800635.59.0.843288086509.issue3288@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Fri Jul 11 20:51:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jul 2008 18:51:46 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1215778377.24.0.645794624839.issue3112@psf.upfronthosting.co.za>
Message-ID: <1215802303.6048.8.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 11 juillet 2008 ? 12:12 +0000, Amaury Forgeot d'Arc a
?crit :
> I think there is a problem when the source file cannot be opened (a .pyc
> without its .py): the four spaces are printed, but not the line, and the
> following level is not properly indented.
> 
> See issue3342 for a competing patch that corrects the indentation problem.

Great! Do you plan to commit it soon or should I include it into my
patch?

(and do you have other observations on the present patch?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Fri Jul 11 21:09:31 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 11 Jul 2008 19:09:31 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215803371.93.0.850397840634.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

There already is a test for the breakage, but the patch changes the
expected output to match the new return value of .header_items():

-    [('Foo-bar', 'baz'), ('Spam-eggs', 'blah')]
+    [('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]

Code that previously worked fine, for example code that iterates through
.header_items() and does string comparisons on the header names, or does
"in" tests on the keys of dict(header_items), etc. will break, the
existence of .has_header() notwithstanding.

What is the purpose of this change?  Can you explain how that justifies
breaking working code?

The alternative to this change is to leave the return value of
.header_items() unchanged.  That could be done by performing case
normalisation at a later stage.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 21:44:49 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 11 Jul 2008 19:44:49 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215805489.54.0.180576246499.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

> > * The patch to the docs seems to muddy the waters even further (than the
> > current slightly murky state) about whether and why .headers is to be
> > preferred over the methods, or vice-versa.  I think .headers should
> > remain undocumented, for the reason stated by the doctest that failed
> > with Hans-Peter's original patch.
> 
> IIRC, Hans-Peter's comment was on the reference to .headers
undocumented interface mentioned in the test_urllib2.

I made no reference to Hans-Peter's comment -- only to his patch, so I
don't know what you're getting at here.  Could you respond to my
comment, please?

> >  The best course of action is
> > debatable, but the patch is a regression in this respect, so should not
> > be committed as-is.
> 
> My understanding in this case was to address 1) Title()-ize the
headers and 2)
> provide a case insensitive lookup.

Can you explain why you think providing case-insensitive lookup requires
documenting .headers?


> Is this sufficient now to expose the headers method? If not, what else?
> If headers method should not be exposed, then will the 2 cases
addressed above
> still do, as this issue request was opened for that?

There is no method named "headers".  I think that the .headers attribute
should never be documented, because it does not contain the
"unredirected headers".  Changing that behaviour would break code,
further confuse matters and complicate writing code that works with
multiple versions of Python.  A case *could* be made for changing it (by
including the "unredirected headers"), because other code will have been
broken by the introduction of .unredirected_hdrs; I prefer instead to
stick with old breakage rather than swapping it for new breakage, but as
I say, the best course of action is debatable.  Another choice would be
to start the process of deprecating .headers, and introduce a new
attribute with a similar function.  As long as your chosen solution
isn't actually a step backwards or sharply sideways, I probably won't
object very strongly.  What isn't really debatable is that the patch
makes things worse here: it adds a newly-documented interface which is
subtly and surprisingly different from the other one (an unacceptable
change in itself, IMO) without even explaining the difference between
the two, why they are different, and why one would want to use or avoid
one or other interface.

There are other problems with the documentation patch, but there's no
point in discussing those until the changes are agreed on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 21:56:17 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 11 Jul 2008 19:56:17 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1215806177.2.0.508814715663.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Just to quickly note that by "providing case-insensitive lookup" I don't
necessarily mean via .headers.  But it's you who's providing the patch,
so I'll wait for your next suggestion rather than discuss how I might
change the code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Jul 11 23:28:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 21:28:40 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215811719.95.0.665385933744.issue3317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as 64880.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Fri Jul 11 23:35:50 2008
From: report at bugs.python.org (Kuba Fast)
Date: Fri, 11 Jul 2008 21:35:50 +0000
Subject: [issue2280] parser module chokes on unusual characters
In-Reply-To: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za>
Message-ID: <1215812150.01.0.0866978019488.issue2280@psf.upfronthosting.co.za>


Kuba Fast <kuba.fast at gmail.com> added the comment:

I get no problem in 3.0b1. Should this be closed?

>>> parser.suite('"\u1234"')
<parser.st object at 0xb7ceebd0>

----------
nosy: +kfast

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2280>
_______________________________________

From report at bugs.python.org  Fri Jul 11 23:46:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 21:46:14 +0000
Subject: [issue3343] Py_DisplaySourceLine is not documented
In-Reply-To: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za>
Message-ID: <1215812774.74.0.235705794125.issue3343@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

r64881: Py_DisplaySourceLine is renamed to _Py_DisplaySourceLine

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3343>
_______________________________________

From report at bugs.python.org  Fri Jul 11 23:46:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 21:46:49 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za>
Message-ID: <1215812809.33.0.924108865208.issue3342@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Corrected as r64881.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Fri Jul 11 23:49:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jul 2008 21:49:46 +0000
Subject: [issue3342] Tracebacks are not properly indented
In-Reply-To: <1215812809.33.0.924108865208.issue3342@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807111449i59e4f6f0yab712fbe54cfccc9@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Thanks for fixing this and renaming the function, Amaury!

On Fri, Jul 11, 2008 at 2:46 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Corrected as r64881.
>
> ----------
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3342>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3342>
_______________________________________

From report at bugs.python.org  Sat Jul 12 00:18:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 22:18:22 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1215814702.83.0.234285985293.issue3112@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I committed r64881, which invalidates your patch a bit :-|

BTW, I don't like your comment "Can't be bothered to check all those
PyFile_WriteString() calls". 
In general, it is not a good idea to execute python code with an
exception set, this leads to subtle problems, and some "XXX undetected
error" prints in debug mode. Chaining several calls to PyDict_SetItem
for example is usually not a problem, but PyFile_WriteString does
execute python code in python3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Sat Jul 12 00:22:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Jul 2008 22:22:11 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215814931.27.0.568048615188.issue874900@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I am leaving for the whole next week, so anyone, feel free to commit
(part of) my patch if it helps.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sat Jul 12 00:23:09 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jul 2008 22:23:09 +0000
Subject: [issue1529018] Move firewall warning to "about" menu
Message-ID: <1215814989.24.0.419017137212.issue1529018@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

What if this message was made part of the error message which is
displayed when the connection to the subprocess fails? This way only
users in situations where it is likely that the warning is relevant will
see it.

I suggest this since the original problem for which the warning was
added has become very uncommon, so bugging all of our users with such a
warning (even if it has a "don't show this again" check-box) seems
unnecessary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529018>
_______________________________________

From report at bugs.python.org  Sat Jul 12 00:41:53 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jul 2008 22:41:53 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at users.sourceforge.net>:

Just minor code cleanup.

Only one instance of zip(count(), ...) in EditorWindow.py, where I also
changed 'file' to 'file_name' to avoid overriding the built-in 'file' class.

----------
files: IDLE_EditorWindow_minor.patch
keywords: patch
messages: 69571
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - use enumerate instead of zip(count(), ...)
Added file: http://bugs.python.org/file10878/IDLE_EditorWindow_minor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Sat Jul 12 01:28:00 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jul 2008 23:28:00 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215818880.71.0.853641656669.issue3297@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On my Linux box sys.maxunicode == 1114111 and len(u'\U00010123') == 1,
so it should be a UTF-32 build.
On windows instead sys.maxunicode == 65535 and len(u'\U00010123') == 2,
so it should be a UTF-16 build.
The problem seems then related to UTF-32 builds.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 01:30:06 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 11 Jul 2008 23:30:06 +0000
Subject: [issue3345] Patch for CGIHTTPServer.is_cgi function documentation
In-Reply-To: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za>
Message-ID: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

The current documentation is wrong and does not specify the fact that
this functions sets "cgi_info" (maybe also rename the function?)

----------
assignee: georg.brandl
components: Documentation
files: CGIHTTPServer.py.diff
keywords: patch
messages: 69574
nosy: georg.brandl, tebeka
severity: normal
status: open
title: Patch for CGIHTTPServer.is_cgi function documentation
versions: Python 2.6
Added file: http://bugs.python.org/file10879/CGIHTTPServer.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3345>
_______________________________________

From report at bugs.python.org  Sat Jul 12 01:33:40 2008
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 11 Jul 2008 23:33:40 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215819220.37.0.132294711295.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Simpler way to reproduce this (on linux):

$ rm unicodetest.pyc 
$ 
$ python -c 'import unicodetest'
Result: False
Len: 2 1
Repr: u'\ud800\udd23' u'\U00010123'
$ 
$ python -c 'import unicodetest'
Result: True
Len: 1 1
Repr: u'\U00010123' u'\U00010123'

Storing surrogates in UTF-32 is ill-formed[1], so the first part
definitely shouldn't be failing on linux (with a UTF-32 build).

The repr could go either way, as unicode doesn't cover escape sequences.
 We could allow u'\ud800\udd23' literals to magically become
u'\U00010123' on UTF-32 builds.  We already allow repr(u'\ud800\udd23')
to magically become "u'\U00010123'" on UTF-16 builds (which is why the
repr test always passes there, rather than always failing).

The bigger problem is how much we prohibit ill-formed character
sequences.  We already prevent values above U+10FFFF, but not
inappropriate surrogates.


[1] Search for D90 in http://www.unicode.org/versions/Unicode5.0.0/ch03.pdf

----------
nosy: +Rhamphoryncus
Added file: http://bugs.python.org/file10880/unicodetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 01:20:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jul 2008 23:20:33 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1215814702.83.0.234285985293.issue3112@psf.upfronthosting.co.za>
Message-ID: <1215818423.9784.8.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 11 juillet 2008 ? 22:18 +0000, Amaury Forgeot d'Arc a
?crit :
> I committed r64881, which invalidates your patch a bit :-|

Apparently you committed in trunk rather than py3k? Could you svnmerge
into py3k as well? Then it should be quite easy to rework my patch
around it.

> BTW, I don't like your comment "Can't be bothered to check all those
> PyFile_WriteString() calls". 

It's not my comment, it was already there. I agree it doesn't sound very
meticulous. :-)

> In general, it is not a good idea to execute python code with an
> exception set, this leads to subtle problems, and some "XXX undetected
> error" prints in debug mode.
> Chaining several calls to PyDict_SetItem
> for example is usually not a problem, but PyFile_WriteString does
> execute python code in python3.0.

Well, as said above, I just kept the original method of doing things...
If you think of a simple solution to make things better (and a test case
to validate it), I'm open to integrating it in the patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Sat Jul 12 02:37:34 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 12 Jul 2008 00:37:34 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215823054.36.0.882088993727.issue3297@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16
vs. UTF-32).

The conversions done from the literal escaped representation to the
internal format are done using the unicode-escape and raw-unicode-escape
codecs.

PYC files are written using the marshal module, which uses UTF-8 as
encoding for Unicode objects.

All of these codecs know about surrogates, so there must be a bug
somewhere in the Python tokenizer or compiler.

I checked on Linux using a UCS2 and a UCS4 build of Python 2.5: the
problem only shows up with the UCS4 build.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 02:56:43 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 12 Jul 2008 00:56:43 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215824203.2.0.679701117495.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

No, the configure options are wrong - we do use UTF-16 and UTF-32. 
Although modern UCS-4 has been restricted down to the range of UTF-32
(it used to be larger!), UCS-2 still doesn't support the supplementary
planes (ie no surrogates.)

If it really was UCS-2, the repr wouldn't be u'\U00010123' on windows. 
It'd be a pair of ill-formed code units instead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 05:07:56 2008
From: report at bugs.python.org (David Binger)
Date: Sat, 12 Jul 2008 03:07:56 +0000
Subject: [issue2280] parser module chokes on unusual characters
In-Reply-To: <1215812150.01.0.0866978019488.issue2280@psf.upfronthosting.co.za>
Message-ID: <8C07E5F8-B952-4672-B777-10CCD7FFF6A9@mac.com>


David Binger <davidbinger at mac.com> added the comment:

On Jul 11, 2008, at 5:35 PM, Kuba Fast wrote:

> I get no problem in 3.0b1. Should this be closed?

I think so.  It looks like this has been fixed.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2280>
_______________________________________

From report at bugs.python.org  Sat Jul 12 09:13:28 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jul 2008 07:13:28 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215846808.68.0.106762891444.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated patch that makes the trailing 'p123' exponent optional 
in fromhex.  (This matches the behaviour of C99's strtod and sscanf;  in 
contrast, Java always requires the exponent.)

I'm beginning to wonder whether the '0x' shouldn't also be optional on 
input as well, in the same way that it's optional in int():

>>> int('0x45', 16)
69
>>> int('45', 16)
69

This would then allow, e.g.,

>>> float.fromhex('45')
69.0

Added file: http://bugs.python.org/file10881/hex_float6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul 12 09:53:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jul 2008 07:53:47 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215849227.48.0.627315211005.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

In the spirit of being "liberal in what you accept, but strict in what you 
emit", here's a version that makes both the leading '0x' and the trailing 
'p...' exponent optional on input.  Both of these are still produced on 
output.

Note that this version is still perfectly interoperable with C99 and Java 
1.5+:  fromhex accepts anything produced by C and Java (e.g. via C's '%a', 
or Java's toHexString), and the output of hex can be read by C99's 
strtod/sscanf and Java's Double constructor, and/or used as hex literals 
in C or Java source.

Added file: http://bugs.python.org/file10882/hex_float7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul 12 11:37:07 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 12 Jul 2008 09:37:07 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215855427.58.0.456732436843.issue3297@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Adam, I do know what I'm talking about: I was the lead designer of the
Unicode integration you find in Python and implemented most of it.

What you see as repr() of a Unicode object is the result of applying a
codec to the internal representation. Please don't confuse the output of
the codec ("unicode-escape") with the internal representation.

That said, Ezio did uncover a bug and we need to find the cause. It's
likely caused by the fact that the UTF-8 codec does not recombine
surrogates on UCS4 builds. See this comment in the codec implementation:

        case 3:
            if ((s[1] & 0xc0) != 0x80 ||
                (s[2] & 0xc0) != 0x80) {
                errmsg = "invalid data";
		startinpos = s-starts;
		endinpos = startinpos+3;
		goto utf8Error;
	    }
            ch = ((s[0] & 0x0f) << 12) + ((s[1] & 0x3f) << 6) + (s[2] &
0x3f);
            if (ch < 0x0800) {
		/* Note: UTF-8 encodings of surrogates are considered
		   legal UTF-8 sequences;

		   XXX For wide builds (UCS-4) we should probably try
		       to recombine the surrogates into a single code
		       unit.
		*/
                errmsg = "illegal encoding";
		startinpos = s-starts;
		endinpos = startinpos+3;
		goto utf8Error;
	    }
	    else
		*p++ = (Py_UNICODE)ch;
            break;

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 12:24:51 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 12 Jul 2008 10:24:51 +0000
Subject: [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

This is a rather new regression:

test_ossaudiodev
test test_ossaudiodev failed -- Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line
146, in test_playback
    self.play_sound_file(*sound_info)
  File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line
66, in play_sound_file
    setattr(dsp, attr, 42)
AttributeError: 'ossaudiodev.oss_audio_device' object has no attribute
'closed'

----------
components: Tests
messages: 69582
nosy: cartman
severity: normal
status: open
title: test_ossaudiodev fails
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________

From report at bugs.python.org  Sat Jul 12 13:32:54 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 11:32:54 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215862374.12.0.421131286848.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK I spent awhile writing test cases for quote and unquote, encoding and
decoding various Unicode strings with different encodings. As a result,
I found a bunch of issues in my previous patch, so I've rewritten the
patches to both quote and unquote. They're both actually more similar to
the original version now.

I'd be interested in hearing if anyone disagrees with my expected output
for these test cases.

I'm now confident I have good test coverage directly on the quote and
unquote functions. However, I haven't tested the other library functions
which depend upon them (though the entire test suite passes). Though as
I showed in that big post I made yesterday, other modules such as cgi
seem to be working fine (their behaviour has changed; they use UTF-8
now; but that's the whole point of this patch).

I still haven't figured out what the behaviour of "safe" should be in
quote. Should it only allow ASCII characters (thereby limiting the
output to an ASCII string, as specified by RFC 3986)? Should it also
allow Latin-1 characters, or all Unicode characters as well (perhaps
allowing you to create IRIs -- admittedly I don't know much about IRIs).
The new implementation of quote makes it rather difficult to allow
non-Latin-1 characters to be made "safe", as it encodes the string into
bytes before any processing.

Patch (parse.py.patch4) is for branch /branches/py3k, revision 64891.

Commit log:

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets.
As per RFC 3986, default is "utf-8" (previously implicitly decoded as
ISO-8859-1).

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded. Default is "utf-8" (previously characters
in range(128, 256) were encoded as ISO-8859-1, and characters above that
as UTF-8). Also characters above 128 are no longer allowed to be "safe".

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface.

Lib/test/test_urllib.py: Added several new test cases testing encoding
and decoding Unicode strings with various encodings. This includes
updating one test case to now expect UTF-8 by default.

Lib/test/test_http_cookiejar.py: Updated test case which expected output
in ISO-8859-1, now expects UTF-8.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file10883/parse.py.patch4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sat Jul 12 13:51:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jul 2008 11:51:00 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215863460.14.0.188725659756.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some final tinkering:

 - docstrings and docs expanded slightly;  docs mention interoperability
with C and Java.

 - in float.hex(), there's always a sign included in the exponent (e.g. 
"0x1p+0" instead of "0x1p0").  This just makes for a little bit more 
consistency with repr(float), with C99 and with the way the Decimal module 
behaves (but not with Java, which omits the + sign).

Added file: http://bugs.python.org/file10884/hex_float8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sat Jul 12 14:37:10 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Sat, 12 Jul 2008 12:37:10 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1215866230.33.0.725151205644.issue3338@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Happens with Python 2.5.2 on 64bit also:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', '')
>>> from cPickle import Pickler
>>> class rec:
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> import sys
>>> sys.setrecursionlimit(10000)
>>> mychain = rec(2600)
>>> from cStringIO import StringIO
>>> stream = StringIO()
>>> p = Pickler(stream, 1)
>>> res = p.dump(mychain)
Segmentation fault

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Sat Jul 12 15:46:17 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 13:46:17 +0000
Subject: [issue3347] urllib.robotparser doesn't work in Py3k
In-Reply-To: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>
Message-ID: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urllib.robotparser is broken in Python 3.0, due to a bytes object
appearing where a str is expected.

Example:

>>> import urllib.robotparser
>>> r =
urllib.robotparser.RobotFileParser('http://www.python.org/robots.txt')
>>> r.read()
TypeError: expected an object with the buffer interface

This is because the variable f in RobotFileParser.read is opened by
urlopen as a binary file, so f.read() returns a bytes object.

I've included a patch, which checks if it's a bytes, and if so, decodes
it with 'utf-8'. A more thorough fix might figure out what the charset
of the document is (in f.headers['Content-Type']), but at least this
works, and will be sufficient in almost all cases.

Also there are no test cases for urllib.robotparser.

Patch (robotparser.py.patch) is for branch /branches/py3k, revision 64891.

Commit log:

Lib/urllib/robotparser.py: Fixed robotparser for Python 3.0. urlopen
returns bytes objects where str expected. Decode the bytes using UTF-8.

----------
components: Library (Lib)
files: robotparser.py.patch
keywords: patch
messages: 69586
nosy: mgiuca
severity: normal
status: open
title: urllib.robotparser doesn't work in Py3k
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10885/robotparser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3347>
_______________________________________

From report at bugs.python.org  Sat Jul 12 18:19:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 16:19:28 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The wsgiref "simple server" module has a demo server, which fails to
start in Python 3.0 for a bunch of reasons.

To verify this, just go into the Lib/wsgiref directory, and run:
python3.0 ./simple_server.py
(which launches the demo server).

This opens your web browser and points it at the server, and you get the
following error:

ValueError: need more than 1 value to unpack

I fixed a number of issues which simply killed the server:

* In get_environ, it did not iterate over the headers mapping properly
at all (was expecting a sequence of strings, it actually is a mapping).
I think the email.message.Message class changed. Fixed.
* In demo_app, it calls sort on the output of dict.items() - a list in
Python 2, but an iterator in Python 3, so it fails. Fixed (using "sorted").

Unfortunately, the final issue is a bit harder to fix. It seems when I
run the demo server, it opens a binary stream, but handlers.py sends
strings to be written, giving the error

TypeError: send() argument 1 must be bytes or read-only buffer, not str

However in the test case, it opens a text stream, so handlers.py works fine.

The following *HACK* fixes it so the demo server works, but breaks the
test suite (it is NOT included in the attached patch):

--- Lib/wsgiref/handlers.py	(revision 64895)
+++ Lib/wsgiref/handlers.py	(working copy)
@@ -382,8 +382,8 @@
         self.environ.update(self.base_env)
 
     def _write(self,data):
-        self.stdout.write(data)
-        self._write = self.stdout.write
+        self.stdout.write(data.encode('utf-8'))
+        #self._write = self.stdout.write
 
I can't figure out right away what to do about this, but the best
solution would be to get the demo server to open the socket in text mode.

In any case, the patch is attached for branch /branches/py3k, revision
64895.

Commit log:

* Lib/wsgiref/simple_server.py: Fixed two fatal errors which prevent the
demo server from running (broken due to Python 3.0).
Note: Demo server may still not run due to an issue between strings and
bytes.

----------
components: Library (Lib)
files: simple_server.py.patch
keywords: patch
messages: 69587
nosy: mgiuca
severity: normal
status: open
title: Cannot start wsgiref simple server in Py3k
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10886/simple_server.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Sat Jul 12 18:40:22 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 12 Jul 2008 16:40:22 +0000
Subject: [issue3349] search for 'patch' produces roundup error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

If you'll try to search 'patch' word in this bugtracker, you will likely
to get the error saved in attached file.

----------
files: bugs.python.org.txt
messages: 69588
nosy: techtonik
severity: normal
status: open
title: search for 'patch' produces roundup error
Added file: http://bugs.python.org/file10887/bugs.python.org.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________

From report at bugs.python.org  Sat Jul 12 18:47:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 12 Jul 2008 16:47:12 +0000
Subject: [issue3349] search for 'patch' produces roundup error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215881232.57.0.0644404792781.issue3349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please re-report this at the tracker linked in the lower-right
corner of this page, i.e.

http://psf.upfronthosting.co.za/roundup/meta

Closing it here.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________

From report at bugs.python.org  Sat Jul 12 18:47:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 12 Jul 2008 16:47:54 +0000
Subject: [issue3349] search for 'patch' produces roundup error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215881274.12.0.427017195847.issue3349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

lower-right -> lower-left (i.e. labelled "Report Tracker Problem")

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________

From report at bugs.python.org  Sat Jul 12 19:05:57 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 12 Jul 2008 17:05:57 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1215882357.87.0.545486234904.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

So today I grepped for "urllib" in the entire library in an effort to
track down every dependency on quote and unquote to see exactly how my
patch breaks other code. I've now investigated every module in the
library which uses quote, unquote or urlencode, and my findings are
documented below in detail.

So far I have found no code "breakage" except for the original
email.util issue I fixed in patch 2. Of course that doesn't mean the
behaviour hasn't changed. Nearly all modules in the report below have
changed their behaviour so they used to deal with Latin-1-encoded URLs
and now deal with UTF-8-encoded URLs. As discussed at length above, I
see this as a positive change, since nearly everybody encodes URLs in
UTF-8, and of course it allows for all characters.

I also point out that the http.server module (unpatched) is internally
broken when dealing with filenames with characters outside range(0,256);
my patch fixes it.

I'm attaching patch 5, which adds a bunch of new test cases to various
modules which demonstrate those modules correctly handling UTF-8-encoded
URLs. It also fixes a bug in email.utils which I introduced in patch 2.

Note that I haven't yet fully investigated urllib.request.

Aside from that, the only remaining matter is whether or not it's better
to encode URLs as UTF-8 or Latin-1 by default, and I'm pretty sure that
question doesn't need debate.

So basically I think if there's support for it, this patch is just about
ready to be accepted. I'm hoping it can be included in the 3.0b2 release
next week.

I'd be glad to hear any feedback about this proposal.

Not Yet Investigated
--------------------

./urllib/request.py
    By far the biggest user of quote and unquote.
    username, password, hostname and paths are now all converted
    to/from UTF-8 percent-encodings.
    Other concerns are:
        * Data in the form application/x-www-form-urlencoded
        * FTP access
    I think this needs to be tested further.

Looks fine, not tested
----------------------

./xmlrpc/client.py
    Just used to decode URI auth string (user:pass). This will change
    to UTF-8, but is probably OK.
./logging/handlers.py
    Just uses it in the HTTP handler to encode a dictionary. Probably
    preferable to use UTF-8 to encode an arbitrary string.
./macurl2path.py
    Calls to urllib look broken. Not tested.

Tested manually, fine
---------------------

./wsgiref/simple_server.py
    Just used to set PATH_INFO, fine if URLs are UTF-8 encoded.
./http/server.py
    All uses are for translating between actual file-system paths to
    URLs. This works fine for UTF-8 URLs. Note that since it uses
    quote to create URLs in a dir listing, and unquote to handle
    them, it breaks when unquote is not the inverse of quote.

    Consider the following simple script:

    import http.server
    s = http.server.HTTPServer(('',8000),
            http.server.SimpleHTTPRequestHandler)
    s.serve_forever()

    This will "kind of" work in the unpatched version, using
    Latin-1 URLs, but filenames with characters above 256 will
    break (give a 404 error).
    The patch fixes this.
./urllib/robotparser.py
    No test cases. Manually tested, URLs properly match when
    percent-encoded in UTF-8.
./nturl2path.py
    No test cases available. Manually tested, fine if URLs are
    UTF-8 encoded.

Test cases either exist or added, fine
--------------------------------------

./test/test_urllib.py
    I wrote a large wad of test cases for all the new functionality.
./wsgiref/util.py
    Added test cases expecting UTF-8.
./http/cookiejar.py
    I changed a test case to expect UTF-8.
./email/utils.py
    I changed this file to behave as it used to, to satisfy its
    existing test cases.
./cgi.py
    Added test cases for UTF-8-encoded query strings.

Commit log:

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets.
As per RFC 3986, default is "utf-8" (previously implicitly decoded as
ISO-8859-1).

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded. Default is "utf-8" (previously characters
in range(128, 256) were encoded as ISO-8859-1, and characters above that
as UTF-8). Also characters above 128 are no longer allowed to be "safe".

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface.

Lib/test/test_urllib.py: Added several new test cases testing encoding
and decoding Unicode strings with various encodings. This includes
updating one test case to now expect UTF-8 by default.

Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py,
Lib/test/test_wsgiref.py: Updated and added test cases to deal with
UTF-8-encoded URIs.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file10888/parse.py.patch5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sat Jul 12 20:38:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 18:38:48 +0000
Subject: [issue2280] parser module chokes on unusual characters
In-Reply-To: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za>
Message-ID: <1215887928.12.0.784609988881.issue2280@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2280>
_______________________________________

From report at bugs.python.org  Sat Jul 12 20:41:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 18:41:55 +0000
Subject: [issue3349] search for 'patch' produces roundup error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215888115.44.0.3681085412.issue3349@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I already reported it:
http://psf.upfronthosting.co.za/roundup/meta/issue213 .

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________

From report at bugs.python.org  Sat Jul 12 20:42:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 18:42:27 +0000
Subject: [issue3347] urllib.robotparser doesn't work in Py3k
In-Reply-To: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>
Message-ID: <1215888147.43.0.906020834047.issue3347@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3347>
_______________________________________

From report at bugs.python.org  Sat Jul 12 20:49:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 18:49:56 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1215888596.95.0.452934936714.issue3324@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has been fixed in the development docs:
http://docs.python.org/dev/install/index.html

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:03:52 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 12 Jul 2008 19:03:52 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215889432.77.0.572868807141.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Marc, perhaps Unicode has refined their definitions since you last looked?

Valid UTF-8 *cannot* contain surrogates[1].  If it does, you have
CESU-8[2][3], not UTF-8.

So there are two bugs: first, the UTF-8 codec should refuse to load
surrogates.  Second, since the original bug showed up before the .pyc is
created, something in the parse/compilation/whatever stage is producing
CESU-8.


[1] 4th bullet point of D92 in
http://www.unicode.org/versions/Unicode5.0.0/ch03.pdf
[2] http://unicode.org/reports/tr26/
[3] http://en.wikipedia.org/wiki/CESU-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:11:15 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 12 Jul 2008 19:11:15 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1215889875.08.0.291652989922.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Err, to clarify, the parse/compile/whatever stages is producing broken
UTF-32 (surrogates are ill-formed there too), and that gets transformed
into CESU-8 when the .pyc is saved.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:49:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:49:44 +0000
Subject: [issue2377] Replace import.c with a pure Python implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1215892184.53.0.795311837238.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:50:02 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:50:02 +0000
Subject: [issue2377] Replace import.c with a pure Python implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1215892202.69.0.456596657576.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:50:12 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:50:12 +0000
Subject: [issue2377] Replace import.c with a pure Python implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1215892212.15.0.640226011824.issue2377@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:50:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:50:26 +0000
Subject: [issue2828] Clean up undoc.rst
In-Reply-To: <1210555189.34.0.375488614509.issue2828@psf.upfronthosting.co.za>
Message-ID: <1215892226.03.0.61227144335.issue2828@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2828>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:53:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:53:39 +0000
Subject: [issue2910] Remove plat-mac from 3.0
In-Reply-To: <1211144667.58.0.62394748766.issue2910@psf.upfronthosting.co.za>
Message-ID: <1215892419.0.0.489541537618.issue2910@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I notice that Carbon ended back up in plat-mac. Is that an accident?
What is the status of being able to ditch the directory?

----------
assignee: brett.cannon -> 
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2910>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:55:12 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:55:12 +0000
Subject: [issue2885] Create the urllib package
In-Reply-To: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
Message-ID: <1215892512.89.0.659308668713.issue2885@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Docs have been updated. At this point the fixers for urllib and urllib2
is all that is left.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2885>
_______________________________________

From report at bugs.python.org  Sat Jul 12 21:55:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 19:55:38 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1215892538.76.0.684458867595.issue2775@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies:  -Fixer for dbm is failing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Sat Jul 12 22:07:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 20:07:37 +0000
Subject: [issue2910] Remove plat-mac from 3.0
In-Reply-To: <1211144667.58.0.62394748766.issue2910@psf.upfronthosting.co.za>
Message-ID: <1215893257.25.0.205114151947.issue2910@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Carbon may still be in your wc because svn didn't delete it on update.
(I can't remember the exact behavior of SVN with dir deletes, but it's
weird.) See [1]. I killed plat-mac off in r64896.

[1] http://svn.python.org/view/python/branches/py3k/Lib/plat-mac/

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2910>
_______________________________________

From report at bugs.python.org  Sat Jul 12 22:17:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 20:17:13 +0000
Subject: [issue3320] various doc typos
In-Reply-To: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>
Message-ID: <1215893833.3.0.357187045559.issue3320@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks very much, and feel free to be bored anytime you want! :)
Committed in r64897.

Jesse, can you look at the mp item?

----------
nosy: +benjamin.peterson, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3320>
_______________________________________

From report at bugs.python.org  Sat Jul 12 22:19:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 20:19:14 +0000
Subject: [issue3320] various doc typos
In-Reply-To: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za>
Message-ID: <1215893954.21.0.786098026217.issue3320@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3320>
_______________________________________

From report at bugs.python.org  Sat Jul 12 22:20:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 20:20:35 +0000
Subject: [issue2377] Replace import.c with a pure Python implementation
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1215894035.16.0.567648513525.issue2377@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Jul 12 22:28:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 20:28:35 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215894515.6.0.363989912934.issue874900@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sat Jul 12 23:04:30 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Sat, 12 Jul 2008 21:04:30 +0000
Subject: [issue3317] duplicate lines in zipfile.py
In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za>
Message-ID: <1215896670.51.0.588008184734.issue3317@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Thanks for fixing this, Amaury.  I ran the test_zipfile64 and
test_zipfile tests on Linux and OS X, and they pass.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3317>
_______________________________________

From report at bugs.python.org  Sat Jul 12 23:22:02 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 21:22:02 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215897722.34.0.218653640274.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The existing fork-and-thread4.patch doesn't actually reset
_active_limbo_lock.  Its missing a "global _active_limbo_lock" statement
in the threading._after_fork() function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:11:44 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 12 Jul 2008 22:11:44 +0000
Subject: [issue3349] search for 'patch' produces roundup error
In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za>
Message-ID: <1215900703.97.0.408422340887.issue3349@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3349>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:22:56 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 22:22:56 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215901376.86.0.175759321511.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

and a few more bugs.  a new patch is attached.  With this applied,
pitrou's fork_threading.py bug demonstration script finally does the
right thing.

test_threading, including the new deadlock tests, and
test_multiprocessing both pass.

Tested on x86 MacOS X 10.4 & x86 Ubuntu 8.04.

Would someone please try this on other platforms?

(The new threading test's use of subprocess with [sys.executable, '-c',
"""long script"""] makes me slightly nervous about portability outside
of Linux and BSD.)

----------
versions: +Python 2.5
Added file: http://bugs.python.org/file10889/fork-and-threading5-gps01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:23:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 22:23:20 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215901400.92.0.648082719034.issue874900@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10855/fork-and-thread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:23:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 22:23:26 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215901406.69.0.109817660054.issue874900@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10859/fork-and-thread2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:23:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 22:23:32 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215901412.36.0.965153225494.issue874900@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10869/fork-and-thread3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 00:23:44 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Jul 2008 22:23:44 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215901424.53.0.535929775443.issue874900@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10872/fork-and-thread4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 01:42:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Jul 2008 23:42:11 +0000
Subject: [issue1778443] robotparser.py fixes
Message-ID: <1215906131.78.0.604562529457.issue1778443@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

OK. I committed the patch in r64901. Thanks for the work!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778443>
_______________________________________

From report at bugs.python.org  Sun Jul 13 03:21:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 01:21:46 +0000
Subject: [issue3339] dummy_thread LockType.acquire() always returns None,
	should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215912106.3.0.905256922859.issue3339@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r64903-64905 have the fixes for trunk, 3.0, and 2.5, respectively.
Thanks for reporting this, Henk. Andrii, I never even looked at your
patch since while I was evaluating the bug the problem was rather
obvious and simple, as you said. =) Thanks for the work, though.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________

From report at bugs.python.org  Sun Jul 13 03:22:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 01:22:01 +0000
Subject: [issue3339] dummy_thread LockType.acquire() always returns None,
	should be True or False
In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za>
Message-ID: <1215912121.43.0.776815102559.issue3339@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3339>
_______________________________________

From report at bugs.python.org  Sun Jul 13 03:39:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 01:39:18 +0000
Subject: [issue2828] Clean up undoc.rst
In-Reply-To: <1210555189.34.0.375488614509.issue2828@psf.upfronthosting.co.za>
Message-ID: <1215913158.06.0.803074541947.issue2828@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Only three modules remain; ntpath, posixpath, and sunaudio. Waiting on
python-3000 to reply to my inquiry as to whether I can take sunaudio out.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2828>
_______________________________________

From report at bugs.python.org  Sun Jul 13 08:18:05 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 13 Jul 2008 06:18:05 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1215929885.35.0.765921085818.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I still don't like the _after_fork() implementation.  Its O(n) where n
== number of threads the parent process had.

Very wasteful when the fork() was done in the most common case of being
followed by an exec and calling os._exit().  It won't scale nicely with
system load (forks will start taking longer and longer the more threads
exist).

Could os.fork() be extended to have an optional will_exec_or_die
parameter that determines if _after_fork() is even called at all? 
Things like subprocess should pass in True.  The default should be False
for compatiblity.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Jul 13 12:19:18 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jul 2008 10:19:18 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1215944357.86.0.445177393146.issue3008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

So far this looks good.  Will complete the review on the next leg of my 
flight (about 12 hrs).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Sun Jul 13 15:01:51 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Jul 2008 13:01:51 +0000
Subject: [issue3106] speedup some comparisons
In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za>
Message-ID: <1215954111.71.0.0843417909861.issue3106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Raymond, would you want to take a look?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3106>
_______________________________________

From report at bugs.python.org  Sun Jul 13 17:08:39 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jul 2008 15:08:39 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215961719.31.0.084116596631.issue3221@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed in r64915.

The end result is that the import system now only emits a RuntimeWarning
instead of raising SystemError if it can't find the parent module when
attempting to perform an absolute import (regardless of whether the
parent module name was derived from __package__ or from __name__).
Explicit relative imports will still fail if __package__ is set
incorrectly and setting __package__ to a non-string value will still
result in a ValueError.

----------
assignee: ncoghlan -> 
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Sun Jul 13 18:08:55 2008
From: report at bugs.python.org (kai zhu)
Date: Sun, 13 Jul 2008 16:08:55 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215965335.5.0.484929295663.issue3238@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

import/reload now works.
accomplished by adding 5 lines in parse_source_module (import.c) to 1st
check for the hook __builtins__.parse_source_module_py3k.
the hook will automatically compile in py3k format if it finds the magic
comment: "# import as py3k\n"

* below is a working python 3.0 script integrated w/ numpy.

also added:
  pep3102  Keyword-Only Arguments
  pep3112  Bytes literals in Python 3000

download: http://www-rcf.usc.edu/~kaizhu/work/py3to2/current/

patched files:
  ceval.c (unchanged from last)
  bltinmodule.c (unchanged from last)
  import.c (added 5 continuous lines to parse_source_module)

there r 7 unimplemented pep's remaining: any suggested solutions?
  pep3107  Function Annotations (easy, just haven't gotten around yet)
  pep3109/3110  Exceptions in Python 3000 (hard?)
  pep3120  Using UTF-8 as the default source encoding
  pep3123  Making PyObject_HEAD conform to C (hard/who cares for 2.x?)
  pep3131  Supporting Non-ASCII Identifiers (looks emulable)
  pep3138  String representation in Python 3000

@ any rate, i think its feature complete enough to b useful in certain
areas (for me its scientific computing).

################################################################################
"""
numpy_py3k.py
this is a py3to2 demo showing a python3.0 script being run under python
2.5 &
utilizing numpy, a python2.5 extension module.

add the magic comment '# import as py3k\n' to import / reload a script
in py3k format

interactive usage:
>>> import py3to2
>>> import numpy_py3k
>>> reload(numpy_py3k)

commandline usage: python -c 'import py3to2; import numpy_py3k'
"""

# import as py3k
import numpy

print('pep3102  Keyword-Only Arguments')
# nth order polynomial fit of multiple y data
def polyfits(nth, x, *ys, rcond = None, full = False):
  return [numpy.polyfit(x, y, nth, rcond, full) for y in ys]

fits = polyfits(2, # 2nd order fit
                numpy.arange(16), # x data
                numpy.random.rand(16), numpy.random.rand(16), # multiple
y data
                rcond = numpy.MachAr().eps, # precision
                full = False, # return only coeffs
                )
print('fits', fits); print('#'*64)

print('pep3112  Bytes literals in Python 3000')
x = bytes( numpy.arange(256, dtype = numpy.int8).tostring() )
print('bytes', x); print('#'*64)

print('pep3114  Renaming iterator.next() to .__next__()')
x = (x for x in numpy.arange(16))
print('x.__next__()', x.__next__(), x.__next__(), x.__next__());
print('#'*64)

print('pep3132  Extended Iterable Unpacking')
a,b,*c = numpy.random.rand(4)
print('a = %s, b = %s, c = %s'%(a,b,c)); print('#'*64)
################################################################################

----------
assignee:  -> collinwinter
components: +2to3 (2.x to 3.0 conversion tool), Demos and Tools, Interpreter Core, Tests -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 19:01:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 17:01:08 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215968468.11.0.0311370813787.issue3238@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This isn't dealing with the 2to3 conversion tool. Please do not add it.

----------
assignee: collinwinter -> 
components:  -2to3 (2.x to 3.0 conversion tool), Tests
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 19:01:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 17:01:26 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215968486.45.0.938043352696.issue3238@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy:  -benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 19:45:31 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 17:45:31 +0000
Subject: [issue616013] cPickle documentation incomplete
Message-ID: <1215971131.33.0.75676478704.issue616013@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Is this still desired? If so, I have fairly long list of differences
that I could document. Or maybe, I could backport the _pickle module to
Python 2.6, which doesn't have as many differences.

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue616013>
_______________________________________

From report at bugs.python.org  Sun Jul 13 19:50:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 17:50:27 +0000
Subject: [issue616013] cPickle documentation incomplete
Message-ID: <1215971427.56.0.833298748877.issue616013@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

+1 to backporting _pickle as cPickle. Do bring it up on python-dev.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue616013>
_______________________________________

From report at bugs.python.org  Sun Jul 13 20:20:42 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 18:20:42 +0000
Subject: [issue3350] multiprocessing adds built-in types to the global
	copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

The multiprocessing module modifies the global copyreg.dispatch_table to
extend pickling to several built-in types (mostly callable types). In my
humble opinion, this is unacceptable for a standard library module.

Here is an example of a behaviour change made by multiprocessing:

  >>> import pickle
  >>> pickle.dumps(str.isalpha)
  Traceback (most recent call last):
    ...
  _pickle.PicklingError: Can't pickle <class 'method_descriptor'>:
attribute lookup builtins.method_descriptor failed
  >>> import multiprocessing.util
  >>> pickle.dumps(str.isalpha)
 
b'\x80\x03cbuiltins\ngetattr\nq\x00cbuiltins\nstr\nq\x01X\x07\x00\x00\x00isalphaq\x02\x86q\x03Rq\x04.'

There was some discussion in issue 558238 about allowing methods to be
pickled. However, no consensus was reached.

In addition, there is a bug in the method pickling support added by
multiprocessing in Python 3.0:

  Python 2.6b1+ (trunk:64899:64900, Jul 13 2008, 13:33:02) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import multiprocessing.util, pickle
  >>> class A(object):
  ...   def foo(self): pass
  ... 
  >>> pickle.dumps(A().foo, 2)
 
'\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01)\x81q\x02}q\x03bU\x03fooq\x04\x86q\x05Rq\x06.'
  >>> pickle.dumps(A.foo, 2)
 
'\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01U\x03fooq\x02\x86q\x03Rq\x04.'
  
  Python 3.0b1+ (py3k:64876M, Jul 11 2008, 12:20:51) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import multiprocessing.util, pickle
  >>> class A(object):
  ...   def foo(self): pass
  ... 
  >>> pickle.dumps(A().foo, 2)
  Traceback (most recent call last):
    ...
  pickle.PicklingError: Can't pickle <class 'method'>: it's not found as
builtins.method
  >>> pickle.dumps(A.foo, 2)
  Traceback (most recent call last):
    ...
  pickle.PicklingError: Can't pickle <function foo at 0xb7b1392c>: it's
not found as __main__.foo

A better solution for the interprocess communication needs of
multiprocessing would be to define custom subclass of Pickler with
extended support for built-in types. If needed, I am willing to extend
the _pickle module in Python 3.0 to support modification to its
"dispatch table", like the undocumented dispatch_table attribute in
pickle.Pickler.

----------
components: Library (Lib)
messages: 69615
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: multiprocessing adds built-in types to the global copyreg.dispatch_table
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________

From report at bugs.python.org  Sun Jul 13 20:23:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 18:23:46 +0000
Subject: [issue3350] multiprocessing adds built-in types to the global
	copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1215973426.21.0.103930013564.issue3350@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________

From report at bugs.python.org  Sun Jul 13 20:38:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 13 Jul 2008 18:38:28 +0000
Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common
	case raises
In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za>
Message-ID: <1215974308.12.0.666355325633.issue2303@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

% ./python.exe -mtimeit 'isinstance(3, int)'
1000000 loops, best of 3: 0.269 usec per loop
% ../release25-maint/python.exe -mtimeit 'isinstance(3, int)'1000000
loops, best of 3: 0.335 usec per loop

So I'd say its no longer 4x slower these days.

Looking at the Object/abstract.c it appears the fix to this has already
been checked in.  PyObject_IsInstance already has this in it:

        /* Quick test for an exact match */
        if (Py_TYPE(inst) == (PyTypeObject *)cls)
                return 1;

closing.

----------
nosy: +gregory.p.smith
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2303>
_______________________________________

From report at bugs.python.org  Sun Jul 13 20:55:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 13 Jul 2008 18:55:47 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1215975347.63.0.712586823351.issue2534@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

speedup of this patch confirmed.  Also, it triggers the bugs mentioned
that have their own issues open.  Once #2542 is fixed this should be
looked at again.

Its a big performance regression in 2.6 over 2.5 if we don't get this
in, marking it critical.

----------
dependencies: +PyErr_ExceptionMatches must not fail
nosy: +gregory.p.smith
priority:  -> critical
title: Speed up isinstance and issubclass -> Restore isinstance and issubclass speed in 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Sun Jul 13 21:03:07 2008
From: report at bugs.python.org (kai zhu)
Date: Sun, 13 Jul 2008 19:03:07 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215975787.47.0.0959957856132.issue3238@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

why not?  it allows developers to migrate 2.x scripts one-by-one to
working 3.0 conformant ones while maintaining backwards-compatibility w/
existing 2.x scripts & extension modules (eg. numpy, PIL, zope, ...)

py3to2 can transparently import & mix & match 2.x & 3.0 scripts (but
builtins/extensions must b 2.x - hence its a 2to3 migration tool).

@ the moment, every script compilable by py3to2 should b 3.0 language
conformant, or otherwise it would fail the syntax check & byte-compile
stage performed by the python 3.0 slave interpreter (see Mechanism for
details).

----------
components: +None
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 21:09:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 19:09:54 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1215975787.47.0.0959957856132.issue3238@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807131205w6aaf3c09ud641fcb11e5ecff8@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Sun, Jul 13, 2008 at 2:03 PM, kai zhu <report at bugs.python.org> wrote:
>
> kai zhu <davidbranniganz at gmail.com> added the comment:
>
> why not?  it allows developers to migrate 2.x scripts one-by-one to
> working 3.0 conformant ones while maintaining backwards-compatibility w/
> existing 2.x scripts & extension modules (eg. numpy, PIL, zope, ...)
>
> py3to2 can transparently import & mix & match 2.x & 3.0 scripts (but
> builtins/extensions must b 2.x - hence its a 2to3 migration tool).

Yes, I realize that, but there is another tool called 2to3 that
preforms syntax transformations on 2.x code. That's what the "2to3
conversion" tool component is for.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 22:26:26 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 20:26:26 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1215980786.64.0.61555501213.issue3119@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

On some benchmark of my own, I get a good 2x slowdown when this patch is
applied. The benchmark consists of loading ~1.4 millions objects (mostly
dict, list, str and int) from a pickle string. It is basically a torture
test for the inner function calls overhead.

Anyway, the slowdown doesn't bother me much. I think a "stackless"
pickle module would be well appreciated by many Python users. 

There is a few things that stops me from applying this patch. First, the
patch will break subclasses of Pickler that relies on the save() method
(Although the method is an implementation detail that shouldn't used).
Therefore, any patches that modifies the API of save() is straight out
for 2.x. And for Python 3.0, your patch should also remove recursion
from the _pickle module (the transparent C accelerator for pickle).

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Sun Jul 13 22:43:46 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 20:43:46 +0000
Subject: [issue3274] Py_CLEAR(tmp) seg faults
In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za>
Message-ID: <1215981826.82.0.696093562094.issue3274@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed the fix r64927. Thanks.

----------
nosy: +alexandre.vassalotti
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3274>
_______________________________________

From report at bugs.python.org  Sun Jul 13 22:45:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Jul 2008 20:45:47 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1215981947.12.0.874023678617.issue3112@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch incorporating Amaury's better indentation fix for
tracebacks. It should be ready for consumption (all the tests pass).

And for the code review junkies: http://codereview.appspot.com/2448

Added file: http://bugs.python.org/file10890/exc_reporting2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Sun Jul 13 22:56:04 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 20:56:04 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1215982563.97.0.824797747729.issue3326@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

With gcc 4.2.3, I see a whole bunch of warnings:

Objects/exceptions.c: In function ?UnicodeDecodeError_init?:
Objects/exceptions.c:1472: warning: dereferencing type-punned pointer
will break strict-aliasing rules

Objects/frameobject.c: In function ?frame_setlineno?:
Objects/frameobject.c:151: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicode_DecodeUTF7Stateful?:
Objects/unicodeobject.c:1804: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:1815: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:1827: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeUTF8Stateful?:
Objects/unicodeobject.c:2140: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2147: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeUTF32Stateful?:
Objects/unicodeobject.c:2419: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2419: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2420: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2431: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeUTF16Stateful?:
Objects/unicodeobject.c:2693: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2693: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2694: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2705: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeUnicodeEscape?:
Objects/unicodeobject.c:2911: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2923: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:2962: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3004: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3018: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3030: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeRawUnicodeEscape?:
Objects/unicodeobject.c:3295: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3327: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3333: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?_PyUnicode_DecodeUnicodeInternal?:
Objects/unicodeobject.c:3502: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3512: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeASCII?:
Objects/unicodeobject.c:3875: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:3880: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_DecodeCharmap?:
Objects/unicodeobject.c:4176: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:4226: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:4249: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:4276: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_Join?:
Objects/unicodeobject.c:5724: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:5745: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c: In function ?PyUnicodeUCS2_Format?:
Objects/unicodeobject.c:8841: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:9158: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Objects/unicodeobject.c:9223: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Python/bltinmodule.c: In function ?source_as_string?:
Python/bltinmodule.c:513: warning: dereferencing type-punned pointer
will break strict-aliasing rules
./Modules/_codecsmodule.c: In function ?unicode_internal_decode?:
./Modules/_codecsmodule.c:243: warning: dereferencing type-punned
pointer will break strict-aliasing rules
./Modules/_codecsmodule.c: In function ?unicode_internal_encode?:
./Modules/_codecsmodule.c:700: warning: dereferencing type-punned
pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/_struct.c: In function ?s_pack_into?:
/home/alex/src/python.org/py3k/Modules/_struct.c:1782: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/audioop.c: In function
?audioop_findfit?:
/home/alex/src/python.org/py3k/Modules/audioop.c:480: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/audioop.c:480: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/audioop.c: In function
?audioop_findfactor?:
/home/alex/src/python.org/py3k/Modules/audioop.c:537: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/audioop.c:537: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/audioop.c: In function
?audioop_findmax?:
/home/alex/src/python.org/py3k/Modules/audioop.c:570: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/nismodule.c: In function
?nis_xdr_ypmaplist?:
/home/alex/src/python.org/py3k/Modules/nismodule.c:293: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/nismodule.c: In function
?nis_xdr_ypresp_maplist?:
/home/alex/src/python.org/py3k/Modules/nismodule.c:319: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/_cursesmodule.c: In function
?PyCurses_UngetMouse?:
/home/alex/src/python.org/py3k/Modules/_cursesmodule.c:1846: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_hk.c: In
function ?big5hkscs_codec_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_hk.c:23:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_hk.c:23:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c: In
function ?ksx1001_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:573:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:574:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c: In
function ?jisx0208_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:609:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:610:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c: In
function ?jisx0212_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:650:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:651:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c: In
function ?jisx0213_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:688:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:690:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:692:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:694:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:696:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:698:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:700:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:700:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c: In
function ?gb2312_init?:
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:957:
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/alex/src/python.org/py3k/Modules/cjkcodecs/_codecs_iso2022.c:958:
warning: dereferencing type-punned pointer will break strict-aliasing rules

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Sun Jul 13 22:58:26 2008
From: report at bugs.python.org (kai zhu)
Date: Sun, 13 Jul 2008 20:58:26 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1215982706.21.0.820479537214.issue3238@psf.upfronthosting.co.za>


kai zhu <davidbranniganz at gmail.com> added the comment:

then the 2 can complement each other well ;) i don't c any competition
between them as they have completely different objectives

2to3 -> convert 2x scripts to 3k
py3to2 <- use the newly created 3k scripts in existing 2x environ

u have to admit migrating to 3k is quite painful & slow
w/ its lack of 2x's vast extension base. given py3to2's potential to
alleviate this problem for migrating developers,
don't u think that possibly merits its mention in the 2to3 category?

btw, py3to2's patches minimally affects 2.x compatibility:
  ceval.c - backports missing 3.0 opcodes (8 in python 2.5.2)
  bltinmodule.c - backports missing 3.0 function __build_class__
  import.c - adds a 5 line hook to function parse_source_module
             allowing automatic checking for and compiling of 3k scripts
             during import/reload

i just ran 'make test' w/ a patched build of python 2.5.2 w/ following
results on redhat, x86_64:
285 tests OK.
37 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
    test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gdbm test_gl test_imageop test_imgfile
    test_linuxaudiodev test_macfs test_macostools test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_rgbimg
    test_scriptpackages test_socket_ssl test_socketserver
    test_startfile test_sunaudiodev test_timeout test_urllib2net
    test_urllibnet test_winreg test_winsound test_zipfile64
1 skip unexpected on linux2:
    test_gdbm

not bad considering it now supports 11 of the 18 (soon to b 12 & likely
more...) 3000 series pep's ^_^

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Sun Jul 13 23:02:41 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 13 Jul 2008 21:02:41 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1215982961.77.0.73591373771.issue3326@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Wow thats no good, I will test with -fstrict-aliasing to be sure, if there 
are such problems still we should start with fixing those towards 3.1 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Sun Jul 13 23:07:58 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sun, 13 Jul 2008 21:07:58 +0000
Subject: [issue3221] SystemError: Parent module 'foo' not loaded on import
	statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1215983278.05.0.768025212684.issue3221@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Thanks Nick for fixing this in a timely manner.
BTW I've seen this when trying to run doctests with py.test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3221>
_______________________________________

From report at bugs.python.org  Sun Jul 13 23:09:51 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 13 Jul 2008 21:09:51 +0000
Subject: [issue3238] backport python 3.0 language functionality to python 2.6
	by adding 7 opcodes to ceval.c
In-Reply-To: <1215982706.21.0.820479537214.issue3238@psf.upfronthosting.co.za>
Message-ID: <487A6F1C.9080600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> don't u think that possibly merits its mention in the 2to3 category?

Please trust our judgment on how to use the bug tracker. This isn't a
competition for publicity; it's a tool to help organizing work among
committers and other contributors.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3238>
_______________________________________

From report at bugs.python.org  Mon Jul 14 00:07:10 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 22:07:10 +0000
Subject: [issue3153] sqlite leaks on error
In-Reply-To: <1213997766.53.0.685117931663.issue3153@psf.upfronthosting.co.za>
Message-ID: <1215986830.3.0.843036173415.issue3153@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Fixed in r64930 (trunk) and r64931 (py3k). Thanks.

----------
nosy: +alexandre.vassalotti
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3153>
_______________________________________

From report at bugs.python.org  Mon Jul 14 00:29:29 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Jul 2008 22:29:29 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1215988169.59.0.191164929593.issue3208@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Extension modules can use PyFunction_GetAnnotations() to access and
modify the annotations dictionary. In addition,
PyFunction_SetAnnotations() can be used to add annotations.

I added some documentation for these functions in r64934.

----------
nosy: +alexandre.vassalotti
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Mon Jul 14 00:42:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 22:42:59 +0000
Subject: [issue2885] Create the urllib package
In-Reply-To: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
Message-ID: <1215988979.77.0.504196510463.issue2885@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Proposal for fix_urllib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2885>
_______________________________________

From report at bugs.python.org  Mon Jul 14 01:04:42 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 23:04:42 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1215990282.58.0.908566682935.issue2874@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Another option is to eliminate the use of PyStructSequence and handle
the creation of a named tuple and a class with the methods in os.py.
Then stat() can just return a tuple and the Python code can create the
instances from that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Mon Jul 14 01:32:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Jul 2008 23:32:20 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1215990282.58.0.908566682935.issue2874@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807131632n1a003d57i29e59f0a9e448ceb@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Jul 13, 2008 at 4:04 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> Another option is to eliminate the use of PyStructSequence and handle
> the creation of a named tuple and a class with the methods in os.py.
> Then stat() can just return a tuple and the Python code can create the
> instances from that.
>

Although I noticed that what fields are available are affected by
compile-time info, so that might not be the best solution.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Mon Jul 14 01:35:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jul 2008 23:35:22 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1215992122.56.0.861050404098.issue3218@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Mon Jul 14 02:20:31 2008
From: report at bugs.python.org (Collin Winter)
Date: Mon, 14 Jul 2008 00:20:31 +0000
Subject: [issue3182] 2to3 Slight Patch
In-Reply-To: <1214241944.19.0.631532213789.issue3182@psf.upfronthosting.co.za>
Message-ID: <1215994831.03.0.558142430295.issue3182@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

So, revisiting this...

On the face of it, I'm not convinced that the isinstance(x, Leaf) ->
type(x) is Leaf changes are correct: certain fixers have in the past
utilized their own subclasses of Node, and I can foresee this being done
again in the future. Reverting those changes seems to remove the speedup
you observed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3182>
_______________________________________

From report at bugs.python.org  Mon Jul 14 02:34:28 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 14 Jul 2008 00:34:28 +0000
Subject: [issue3182] 2to3 Slight Patch
In-Reply-To: <1214241944.19.0.631532213789.issue3182@psf.upfronthosting.co.za>
Message-ID: <1215995668.26.0.67350301502.issue3182@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Fair enough. I guess that even though there's a little bit of a
performance improvement from this, it does hurt extensibility, so its
probably not a worthwhile change after all.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3182>
_______________________________________

From report at bugs.python.org  Mon Jul 14 02:55:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Jul 2008 00:55:32 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1215996932.05.0.99186108773.issue2874@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I just finished taking Georg's idea and fleshing it out. Problem is that
when I went to change the docs for 'stat', I noticed how many other
function in the os module rely on the stat module for its constants.
Should we move the constants over to the os module? Add an os.stats
module? Or only deprecate the functions?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Mon Jul 14 03:11:23 2008
From: report at bugs.python.org (Collin Winter)
Date: Mon, 14 Jul 2008 01:11:23 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1215997883.05.0.218877333328.issue3218@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

fix_imports.diff fails to apply cleanly against HEAD of fix_imports.py.
Also, fix_imports2 now inherits from fix_imports, so it needs to be
fixed as well.


+         yield """power< module_name=%r 
+                  trailer<'.' import_as_names< any > > any* >
+               """ % old_module

Why are you using import_as_names here? That's meant to match a series
of "NAME [as NAME]" in import statements, where this part of the pattern
is meant to match usages of "urllib.foo()" in the code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Mon Jul 14 03:40:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 01:40:03 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1215999603.59.0.955230059805.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Valgrind output for Python trunk compiled with pydebug option:
==29848== Invalid read of size 4
==29848==    at 0x809AF61: _Py_ForgetReference (object.c:2044)
==29848==    by 0x809AFCF: _Py_Dealloc (object.c:2065)
==29848==    by 0x80FE635: call_function (ceval.c:3653)
==29848==    by 0x80F9C83: PyEval_EvalFrameEx (ceval.c:2350)
==29848==    by 0x80FC2D1: PyEval_EvalCodeEx (ceval.c:2914)
==29848==    by 0x80FEAFE: fast_function (ceval.c:3747)
==29848==    by 0x80FE75F: call_function (ceval.c:3672)
==29848==    by 0x80F9C83: PyEval_EvalFrameEx (ceval.c:2350)
==29848==    by 0x80FC2D1: PyEval_EvalCodeEx (ceval.c:2914)
==29848==    by 0x80F1219: PyEval_EvalCode (ceval.c:495)
==29848==    by 0x812838E: run_mod (pythonrun.c:1330)
==29848==    by 0x8128324: PyRun_FileExFlags (pythonrun.c:1316)
==29848==  Address 0x4475680 is 8 bytes inside a block of size 896 free'd
==29848==    at 0x402237F: free (vg_replace_malloc.c:233)
==29848==    by 0x809C51D: PyObject_Free (obmalloc.c:1114)
==29848==    by 0x809C86E: _PyObject_DebugFree (obmalloc.c:1361)
==29848==    by 0x814ECBD: pattern_scanner (_sre.c:3371)
==29848==    by 0x814C245: pattern_finditer (_sre.c:2148)
==29848==    by 0x81708D6: PyCFunction_Call (methodobject.c:81)
==29848==    by 0x80FE5C9: call_function (ceval.c:3651)
==29848==    by 0x80F9C83: PyEval_EvalFrameEx (ceval.c:2350)
==29848==    by 0x80FC2D1: PyEval_EvalCodeEx (ceval.c:2914)
==29848==    by 0x80FEAFE: fast_function (ceval.c:3747)
==29848==    by 0x80FE75F: call_function (ceval.c:3672)
==29848==    by 0x80F9C83: PyEval_EvalFrameEx (ceval.c:2350)
Fatal Python error: UNREF invalid object

The error comes from invalid use of PyObject_DEL(): as said by
georg.brandl, "PyObject_NEW adds the
object to the global linked list of all objects, which PyObject_DEL
obviously doesn't undo". An invalid object will stay in the object list
until it is used and then Python crash.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 04:08:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 02:08:34 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216001314.61.0.998151536538.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

F*ck, Firefox just crashed! I have to rewrite my long comment...

First, to explain why the problem only occurs in pydebug mode: a 
PyObject has only _ob_next and _ob_prev attributes if Py_TRACE_REFS is 
set (eg. by pydebug). PyObject_NEW() and PyObject_NEW_VAR() call 
PyObject_Init() which register the new object to the object list, 
whereas PyObject_DEL() only free the memory.

PyObject_DEL() doesn't the dealloc() method nor removing the object 
from the object list. So Py_DECREF() should be used instead: it calls 
the dealloc method and remove the object from the object list.

PyObject_DEL() is misused in _sre and in curses modules. See attached 
patches.

Added file: http://bugs.python.org/file10891/_sre-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 04:08:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 02:08:44 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216001324.18.0.783170810381.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Removed file: http://bugs.python.org/file10828/re_finditer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 04:10:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 02:10:17 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216001417.0.0.141785712798.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Added file: http://bugs.python.org/file10892/_curses_panel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 04:31:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 02:31:13 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216002673.17.0.188111021136.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Other examples of invalid use of PyObject_Del().

Don't apply the patch, i didn't check it. Eg. element_dealloc() should 
crash if self->tag is NULL... and at line 331, self->tag is NULL 
whereas I called element_dealloc() using Py_DECREF()!

Added file: http://bugs.python.org/file10893/pyobject_del.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 04:38:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 02:38:21 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216003101.74.0.651935515771.issue3299@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

About _curses_panel.patch: same as pyobject_del.patch, i didn't tested 
the code, and is looks like PyCursesPanel_Dealloc() expects that the 
object is properly initialized.

It looks like this bug (invalid use of PyObject_Del/PyObject_DEL) is 
not an easy job and may changes many lines of code to fix it. Instead 
of replacing PyObjectDel/PyObjectDEL by Py_DECREF, another solution 
would be to patch PyObjectDel/PyObjectDEL for the case when 
Py_TRACE_REFS is defined (and then call _Py_ForgetReference()).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Mon Jul 14 05:07:33 2008
From: report at bugs.python.org (yiyuan)
Date: Mon, 14 Jul 2008 03:07:33 +0000
Subject: [issue3351] Python crashed
In-Reply-To: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za>
Message-ID: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za>


New submission from yiyuan <support at proxyshell.com>:

Hi,

I'm new here and I'm not sure whether this should be reported here.

OS: CentOS 2.6.9-67.0.15.EL
Memory: 512M
Python Version: 2.5.1

The crash happened after our web program writen with python running for
many days (maybe 20 days).

Here are the logs I found in /var/log/messages

Jul 14 04:30:38  kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000002
Jul 14 04:30:38  kernel:  printing eip:
Jul 14 04:30:38  kernel: 00000002
Jul 14 04:30:38  kernel: *pde = 0c223067
Jul 14 04:30:38  kernel: Oops: 0000 [#1]
Jul 14 04:30:38  kernel: Modules linked in: ipt_state ipt_TOS
iptable_mangle ip_conntrack_ftp ip_conntrack_irc ip_conntrack ipt_REJECT
ipt_LOG ipt_limit iptable_filter ipt_multiport ip_tables autofs4 sunrpc
loop dm_mirror dm_mod ohci_hcd ehci_hcd k8_edac edac_mc snd_atiixp
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore
snd_page_alloc tg3 floppy ext3 jbd sata_sil libata sd_mod scsi_mod
Jul 14 04:30:38  kernel: CPU:    0
Jul 14 04:30:38  kernel: EIP:    0060:[<00000002>]    Not tainted VLI
Jul 14 04:30:38  kernel: EFLAGS: 00010202   (2.6.9-67.0.15.EL) 
Jul 14 04:30:38  kernel: EIP is at 0x2
Jul 14 04:30:38  kernel: eax: c11bf760   ebx: c11bf760   ecx: c11bf760 
 edx: 00000002
Jul 14 04:30:38  kernel: esi: 00000000   edi: 0000c000   ebp: c5a2e1a8 
 esp: c7198ecc
Jul 14 04:30:38  kernel: ds: 007b   es: 007b   ss: 0068
Jul 14 04:30:38  kernel: Process python (pid: 16598, threadinfo=c7198000
task=c8cccbd0)
Jul 14 04:30:38  kernel: Stack: c01514ee c015ab59 0dfbb067 00080000
1ec5e000 c0411074 1ec5e000 1ecde000 
Jul 14 04:30:38  kernel:        d3a2e1f0 c0411074 c015ac29 00080000
00000000 1ec5e000 d3a2e1f0 1ecde000 
Jul 14 04:30:38  kernel:        c0411074 c015ac88 00080000 00000000
c7198f7c 1ec5e000 cd708b4c 1edac000 
Jul 14 04:30:38  kernel: Call Trace:
Jul 14 04:30:38  kernel:  [<c01514ee>] set_page_dirty+0x2c/0x41
Jul 14 04:30:38  kernel:  [<c015ab59>] zap_pte_range+0x191/0x21f
Jul 14 04:30:38  kernel:  [<c015ac29>] zap_pmd_range+0x42/0x65
Jul 14 04:30:38  kernel:  [<c015ac88>] unmap_page_range+0x3c/0x5f
Jul 14 04:30:38  kernel:  [<c015ad9c>] unmap_vmas+0xf1/0x1df
Jul 14 04:30:38  kernel:  [<c015f5d0>] unmap_region+0x61/0xc6
Jul 14 04:30:38  kernel:  [<c015f8a8>] do_munmap+0x144/0x1b1
Jul 14 04:30:38  kernel:  [<c015f966>] sys_munmap+0x51/0x68
Jul 14 04:30:38  kernel:  [<c031dfc3>] syscall_call+0x7/0xb
Jul 14 04:30:38  kernel: Code:  Bad EIP value.
Jul 14 04:30:38  kernel:  <0>Fatal exception: panic in 5 seconds
Jul 14 04:30:38  kernel: bad: scheduling while atomic!
Jul 14 04:30:38  kernel:  [<c031b251>] schedule+0x2d/0x606
Jul 14 04:30:38  kernel:  [<c031c921>] schedule_timeout+0x158/0x17c
Jul 14 04:30:38  kernel:  [<c012e839>] process_timeout+0x0/0x13
Jul 14 04:30:38  kernel:  [<c012491b>] printk+0xe/0x11
Jul 14 04:30:38  kernel:  [<c0106938>] die+0x21a/0x22b
Jul 14 04:30:38  kernel:  [<c011db6d>] do_page_fault+0x380/0x4dc
Jul 14 04:30:38  kernel:  [<c014fcf9>] buffered_rmqueue+0x1c4/0x1e7
Jul 14 04:30:38  kernel:  [<c014fdd0>] __alloc_pages+0xb4/0x2a6
Jul 14 04:30:38  kernel:  [<c011d7ed>] do_page_fault+0x0/0x4dc
Jul 14 04:30:38  kernel:  [<c031ea5b>] error_code+0x2f/0x38
Jul 14 04:30:38  kernel:  [<c01514ee>] set_page_dirty+0x2c/0x41
Jul 14 04:30:38  kernel:  [<c015ab59>] zap_pte_range+0x191/0x21f
Jul 14 04:30:38  kernel:  [<c015ac29>] zap_pmd_range+0x42/0x65
Jul 14 04:30:38  kernel:  [<c015ac88>] unmap_page_range+0x3c/0x5f
Jul 14 04:30:38  kernel:  [<c015ad9c>] unmap_vmas+0xf1/0x1df
Jul 14 04:30:38  kernel:  [<c015f5d0>] unmap_region+0x61/0xc6
Jul 14 04:30:38  kernel:  [<c015f8a8>] do_munmap+0x144/0x1b1
Jul 14 04:30:38  kernel:  [<c015f966>] sys_munmap+0x51/0x68
Jul 14 04:30:38  kernel:  [<c031dfc3>] syscall_call+0x7/0xb

What caused this problem? Run out of memory? Please tell me what I can do.

Regards

YiYuan

----------
components: Interpreter Core
messages: 69640
nosy: yiyuan
severity: normal
status: open
title: Python crashed
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3351>
_______________________________________

From report at bugs.python.org  Mon Jul 14 06:54:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 14 Jul 2008 04:54:28 +0000
Subject: [issue3351] Python crashed
In-Reply-To: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za>
Message-ID: <1216011268.55.0.321229643791.issue3351@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a Linux kernel crash, and has nothing to do with Python. No
matter what errors Python or your script may have - the operating system
kernel should not crash.

Please report this in a Linux forum, or try to upgrade to a newer kernel.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3351>
_______________________________________

From report at bugs.python.org  Mon Jul 14 07:18:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 14 Jul 2008 05:18:33 +0000
Subject: [issue3026] mmap broken with large files on 64bit system
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1216012712.95.0.38982404597.issue3026@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So would anybody like to contribute a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3026>
_______________________________________

From report at bugs.python.org  Mon Jul 14 07:18:34 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 14 Jul 2008 05:18:34 +0000
Subject: [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1216012714.33.0.847333042138.issue3346@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Works with today's SVN, please close as invalid.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________

From report at bugs.python.org  Mon Jul 14 07:23:41 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 14 Jul 2008 05:23:41 +0000
Subject: [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1216013021.29.0.455496498425.issue3346@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Scratch that, it still fails in the second phase of make testall with
the same error.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________

From report at bugs.python.org  Mon Jul 14 08:19:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Jul 2008 06:19:20 +0000
Subject: [issue3335] subprocess lib - opening same command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1216016360.44.0.947148288699.issue3335@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I am unable to reproduce this (using release24-maint on OS X 10.4).  the
script I used is attached.

Does this script fail for you?  If not, please upload something that fails.

----------
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file10894/subprocess-isue3335.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________

From report at bugs.python.org  Mon Jul 14 08:50:55 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 14 Jul 2008 06:50:55 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1216018255.26.0.0491924580996.issue3326@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

I tested with -fstrict-aliasing -O3 and there is no aliasing warning,
this is with

gcc 4.3.1
x86_64 linux

what you see might be a compiler deficiency :-/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Mon Jul 14 11:57:56 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Jul 2008 09:57:56 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The "PEP 8 compliant" API for multiprocessing and threading needs to be
cleaned up before release as per the thread on python-dev. The release
manager gave approval for this change during that discussion [1].

Changes needed:
- remove Py3k warnings from the threading module (old API is going to be
kept around even in Py3k)
- change get_name/set_name into a "name" property
- change is_daemon/set_daemon into a "daemon" property

(Note that changing "is_alive" to be a property is not on that list -
that can be a fairly expensive thing to check for the multiprocessing
library. I also left out active_count(), as I think the underscore adds
clarity in that case)

[1] http://mail.python.org/pipermail/python-dev/2008-June/080285.html

----------
components: Library (Lib)
messages: 69647
nosy: ncoghlan
priority: release blocker
severity: normal
status: open
title: Deficiencies in multiprocessing/threading API
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Jul 14 12:36:37 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 14 Jul 2008 10:36:37 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216031797.72.0.960757392187.issue3352@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Does this mean that all multiprocessing get_*/set_* methods should be
changed to be properties?
For example, multiprocessing.process.Process class defines not only
set_name/get_name and is_daemon/set_daemon methods, but also
get/set_authkey, get/set_exitcode and get_ident (this method is later
used as 'getx' argument of 'pid' property, so we could get rid of this
using simple decorator).

----------
nosy: +jnoller, mishok13

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Jul 14 12:39:25 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 14 Jul 2008 10:39:25 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216031965.48.0.57341288308.issue3352@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Actually, 'getx' -> 'fget'. Sorry for the typo. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Jul 14 13:33:16 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Mon, 14 Jul 2008 11:33:16 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>


New submission from Fredrik Lundh <effbot at users.sourceforge.net>:

CPython provides a Python-level API to the parser, but not to the
tokenizer itself.  Somewhat annoyingly, it does provide a nice C API,
but that's not properly exposed for external modules.  

To fix this, the tokenizer.h file should be moved from the Parser
directory to the Include directory, and the (semi-public) functions that
already available must be flagged with PyAPI_FUNC, as shown below.

The PyAPI_FUNC fix should be non-intrusive enough to go into 2.6 and
3.0; moving stuff around is perhaps better left for a later release
(which could also include a Python binding).

Index: tokenizer.h
===================================================================
--- tokenizer.h (revision 514)
+++ tokenizer.h (working copy)
@@ -54,10 +54,10 @@
        const char* str;
 };

-extern struct tok_state *PyTokenizer_FromString(const char *);
-extern struct tok_state *PyTokenizer_FromFile(FILE *, char *, char *);
-extern void PyTokenizer_Free(struct tok_state *);
-extern int PyTokenizer_Get(struct tok_state *, char **, char **);
+PyAPI_FUNC(struct tok_state *) PyTokenizer_FromString(const char *);
+PyAPI_FUNC(struct tok_state *) PyTokenizer_FromFile(FILE *, char *,
char *);
+PyAPI_FUNC(void) PyTokenizer_Free(struct tok_state *);
+PyAPI_FUNC(int) PyTokenizer_Get(struct tok_state *, char **, char **);

 #ifdef __cplusplus
 }

----------
components: Interpreter Core
messages: 69650
nosy: effbot
severity: normal
status: open
title: make built-in tokenizer available via Python C API
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Mon Jul 14 14:54:23 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 14 Jul 2008 12:54:23 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

When you sort a list with list.sort() or sorted(list), and set the
reverse parameter to None, then you get the following misleading error
message:

    TypeError: an integer is required

I would expect a more proper error message for the reverse parameter,
such as "reverse must be a boolean", and maybe reverse=None also
accepted as default value, i.e. False.

----------
components: Interpreter Core
messages: 69651
nosy: cito
severity: normal
status: open
title: sort(reverse=None) prints misleading error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:01:05 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jul 2008 13:01:05 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1216040465.53.0.82623107456.issue3321@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Removed file: http://bugs.python.org/file10860/_multiprocessing_connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:28:25 2008
From: report at bugs.python.org (Justin Harper)
Date: Mon, 14 Jul 2008 13:28:25 +0000
Subject: [issue3335] subprocess lib - opening same command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1216042105.03.0.0372922642945.issue3335@psf.upfronthosting.co.za>


Justin Harper <justin.harper at gmail.com> added the comment:

Further research reveals that the problem appears to be with the 
gtk.Assistant class in PyGTK 2.10, not the subprocess lib.

Report can be closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:28:44 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2008 13:28:44 +0000
Subject: [issue3106] speedup some comparisons
In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za>
Message-ID: <1216042124.88.0.434834412823.issue3106@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3106>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:31:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 13:31:56 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216042316.33.0.985970221267.issue3354@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Well, booleans technically are integers.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:35:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 13:35:54 +0000
Subject: [issue3335] subprocess lib - opening same command fails
In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za>
Message-ID: <1216042554.98.0.239434790533.issue3335@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3335>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:40:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 13:40:09 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216042809.52.0.236214915352.issue3354@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 15:46:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 13:46:10 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216043170.2.0.605378714637.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think we should still keep the py3k warnings on (I'll change them to
PendingDeprecationWarnings if you want.), so the API doesn't abruptly
change on people. With your approval, I'll make it so.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Jul 14 16:03:54 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 14 Jul 2008 14:03:54 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216044234.89.0.228814193143.issue3218@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Yeah that import_as_names definitely shouldn't be there. I don't know
what I was thinking at the time, but that should just be an any I
believe. I'll clean this up today or tomorrow, update fix_imports2 as
well, and try to fix the tests for fix_imports.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Mon Jul 14 16:34:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 14:34:48 +0000
Subject: [issue2512] decide what to do with gettext API
In-Reply-To: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za>
Message-ID: <1216046088.29.0.496864137682.issue2512@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

done in r64947.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2512>
_______________________________________

From report at bugs.python.org  Mon Jul 14 17:20:24 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 14 Jul 2008 15:20:24 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216048824.93.0.661999042453.issue3354@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

The problem is not only that the error message "TypeError: an integer is
required" has "integer" instead of "boolean", but it does not mention
the attribute name "reverse", i.e. it does not even say *where* the
integer is required. I firmly believe error messages should not only be
technically correct, but also precise, meaningful and helpful for the user.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 17:23:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 15:23:53 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216049033.8.0.897338640464.issue3354@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Patches are welcome.

----------
priority:  -> low
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 19:10:45 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 14 Jul 2008 17:10:45 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216055445.91.0.270028962877.issue3354@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


----------
nosy: +mishok13

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 20:23:32 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 14 Jul 2008 18:23:32 +0000
Subject: [issue3354] sort(reverse=None) prints misleading error message
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216059812.77.0.848775842372.issue3354@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

The unspecific error message is thrown by the vgetargskeywords()
function, so changing this behavior would be a larger, more difficult
and general issue (similar to #1283289). We could go another path and
require an object for 'reverse' instead of an integer in the format
parameter, and then do our own checks and error messages on 'reverse'.
This looks reasonable if we want to change the behavior anyway, so that
reverse=None is accepted (cmp=None and key=None are also accepted), or
even an implicit bool(reverse) is used (but this could hide possible
errors). If we want to keep the behavior and only fix the error message,
then a more general fix of vgetargskeywords() seems to be the proper
solution.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 21:31:42 2008
From: report at bugs.python.org (Kumar McMillan)
Date: Mon, 14 Jul 2008 19:31:42 +0000
Subject: [issue3355] Display bug in :show-inheritance: for class with standard
	docstring
In-Reply-To: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za>
Message-ID: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za>


New submission from Kumar McMillan <kumar.mcmillan at gmail.com>:

Using Sphinx 0.4.1 I noticed a slight display bug in rendering
:show-inheritance: for a class with a PEP 8 / PEP 257 style docstring.

i.e. multi-line docstrings are recommended by the PEPs to look like:

class Foo(SomeFoo):
    """Return a foobang

    Optional plotz says to frobnicate the bizbaz first.
    """

Using Sphinx autodoc extension, the default skin, and...

.. autoclass:: path.to.Foo
   :show-inheritance:

...will show a link to bases but immediately after it (no line break) is
the first line of the doc.  This is confusing to read.  However,
changing the docstring of the class to add a break like:

class Foo(SomeFoo):
    """
    Return a foobang

    Optional plotz says to frobnicate the bizbaz first.
    """

fixes the problem.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 69660
nosy: georg.brandl, kumar303
severity: normal
status: open
title: Display bug in :show-inheritance: for class with standard docstring
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3355>
_______________________________________

From report at bugs.python.org  Mon Jul 14 23:15:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jul 2008 21:15:29 +0000
Subject: [issue3356] some tests fail in debug mode (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

With the latest py3k, some tests fail when run in debug mode:

- test_distutils fails with the following message:

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_distutils.py", line 17, in <module>
test_main()
  File "Lib/test/test_distutils.py", line 13, in test_main
test.support.run_unittest(distutils.tests.test_suite())
  File "/home/antoine/py3k/pristine/Lib/test/support.py", line 717, in
run_unittest
_run_suite(suite)
  File "/home/antoine/py3k/pristine/Lib/test/support.py", line 700, in
_run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File
"/home/antoine/py3k/pristine/Lib/distutils/tests/test_build_ext.py",
line 48, in test_build_ext
    import xx
AttributeError: mro

- test_set crashes with the following message:

./python Lib/test/test_set.py 
test_add (__main__.TestSet) ... ok
test_and (__main__.TestSet) ... ok
test_badcmp (__main__.TestSet) ... ok
test_c_api (__main__.TestSet) ... Fatal Python error:
Objects/setobject.c:2429 object at 0xb797ce04 has negative ref count -1
Abandon

----------
components: Tests
messages: 69661
nosy: pitrou
severity: normal
status: open
title: some tests fail in debug mode (test_distutils, test_set)
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Mon Jul 14 23:44:23 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2008 21:44:23 +0000
Subject: [issue3354] Improve error reporting for the argument parsing API
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216071863.47.0.99460635021.issue3354@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think this is closer to a language wide change and should probably be 
addressed for 2.7 and 3.1.  It would be great to change the C argument 
parsing API to make its error messages more specific.

For Py2.6, I think things are fine as it stands.  This isn't a bug 
(tests pass, it matches results from previous pythons, etc)  
Reclassifying as a feature request for improved error reports for the 
argument parsing API.

----------
nosy: +rhettinger
title: sort(reverse=None) prints misleading error message -> Improve error reporting for the argument parsing API
type: behavior -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Mon Jul 14 23:45:37 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2008 21:45:37 +0000
Subject: [issue3356] some tests fail in debug mode (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216071937.45.0.339247033975.issue3356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll look at the test_set failure if no one else gets to it first.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Tue Jul 15 00:16:28 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Jul 2008 22:16:28 +0000
Subject: [issue3026] mmap broken with large files on 64bit system
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1216073788.03.0.0162276234368.issue3026@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

this patch adds a digest_update function.
digest_update calls EVP_DigestUpdate(..) with chunks of 16 MB size and
also checks for signals.
I didn't write any tests (as they will most probably annoy many people
cause they would need much memory).

testbigfile.py however now works.

----------
keywords: +patch
Added file: http://bugs.python.org/file10895/large_digest_update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3026>
_______________________________________

From report at bugs.python.org  Tue Jul 15 00:25:54 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Jul 2008 22:25:54 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216074354.63.0.733898385637.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At this stage I'm still inclined to skip the warnings completely - at
the very least, any eventual removals will go through a full deprecation
cycle in 2.7/3.1 before being removed in 2.8/3.2.

It's also much easier to be sure we aren't adversely affecting
performance of the old methods that way (with a
PendingDeprecationWarning, performance of the deprecated methods is
going to suffer a bit since the warnings machinery will still have to be
invoked to discover that the warning has been filtered out). That said,
the methods we're changing aren't likely to be something one invokes in
speed critical sections of an application, so I wouldn't object if the
old names emitted PDW in both 2.6 and 3.0.

Regarding the additional get/set properties on multiprocessing.Process,
it depends on whether or not they are cheap to calculate and whether or
not they involve any I/O operations. auth_key looked like it may be
expensive to set (since I assume there is a crypto calculation involved
there), exit_code may involve waiting for the other process to finish,
and get_ident may involve waiting for it to start. So my initial
reaction is that these are OK to keep as methods rather than trying to
turn them into properties.

The following pretty undesirable behaviour should probably be discussed
on python-dev before beta3 (if not beta2):

Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types
>>> mp.Lock.__name__
'Lock'
>>> mp.Lock.__module__
'multiprocessing'
>>> mp.Lock().__class__.__name__
'Lock'
>>> mp.Lock().__class__.__module__
'multiprocessing.synchronize'

The delayed import functions in multiprocessing.__init__ look like a
serious misfeature to me. I'd be inclined to replace them with "from
.synchronize import *" and "from .process import *" (leaving anything
which isn't covered by those two imports to be retrieved directly from
the relevant mp submodule)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Jul 15 00:54:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 14 Jul 2008 22:54:34 +0000
Subject: [issue3356] some tests fail in debug mode (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216076074.14.0.66261671257.issue3356@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Neither of these fail for me on MacOS.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Tue Jul 15 01:17:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jul 2008 23:17:45 +0000
Subject: [issue3356] some tests fail in debug mode (test_distutils, test_set)
In-Reply-To: <1216076074.14.0.66261671257.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216077457.6110.3.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

On another machine, with another distro (Debian stable) and another gcc
version (4.1.2 instead of 4.3.1), I even get a segmentation fault on
test_distutils:

$ ./python Lib/test/test_set.py 
test_add (__main__.TestSet) ... ok
test_and (__main__.TestSet) ... ok
test_badcmp (__main__.TestSet) ... ok
test_c_api (__main__.TestSet) ... Fatal Python error:
Objects/setobject.c:2429 object at 0xb761ce04 has negative ref count -1
Abandon

$ ./python Lib/test/test_distutils.py 
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ...
Erreur de segmentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Tue Jul 15 01:37:51 2008
From: report at bugs.python.org (Chester)
Date: Mon, 14 Jul 2008 23:37:51 +0000
Subject: [issue3357] A bug in the __doc__ string of the sys module
In-Reply-To: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za>
Message-ID: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za>


New submission from Chester <wxpythoner at gmail.com>:

This relates to Python 3.x.  Do this please:
import sys; print(sys.__doc__)

Please fix the following line of text in that __doc__ file of the sys
module:
stdin -- standard input file object; used by raw_input() and input()

This line of text should just be
stdin -- standard input file object; used by input()
because raw_input() does not exist anymore in Python 3.x.

----------
assignee: georg.brandl
components: Documentation
messages: 69668
nosy: cheDu, georg.brandl
severity: normal
status: open
title: A bug in the __doc__ string of the sys module
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3357>
_______________________________________

From report at bugs.python.org  Tue Jul 15 01:40:26 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 14 Jul 2008 23:40:26 +0000
Subject: [issue3354] Improve error reporting for the argument parsing API
In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za>
Message-ID: <1216078826.4.0.800253519833.issue3354@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

Agree. Seems to be a more general weakness of the argument parsing of
builtin functions and methods, that calls for a general solution instead
of a local patch. Luckily there are not so many cases where the errors
are misleading, since the builtin functions have very few and mostly
positioned parameters, so the problem is not as bad as it seems. There
may be only very few cases, like the example above, where the errors are
really too unspecific or misleading.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3354>
_______________________________________

From report at bugs.python.org  Tue Jul 15 02:31:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 00:31:13 +0000
Subject: [issue3357] A bug in the __doc__ string of the sys module
In-Reply-To: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za>
Message-ID: <1216081873.88.0.379249737517.issue3357@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks. Fixed in r64956.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3357>
_______________________________________

From report at bugs.python.org  Tue Jul 15 04:28:55 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Jul 2008 02:28:55 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216088935.03.0.545070409039.issue3008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patch looks good.  I would coded hex_from_char() using a lookup 
into "0123456789abcdef" which uses no unpredicatable branches.  
Likewise, I would done hex_from_char() with a case statement (limiting 
the call to single unpredicatable branch).

Question:  are the ("0x0p+0") and ("-0x0p+0") special cases standard?

The docs need a "new in py2.6"

Coding style:  move the inner si++ to a separate line so there are no 
side-effects and the order of execution is obvious.

Question:  should the "inf" string checks be made case sensitive on 
insensitive?  Is there a standard?

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 06:12:30 2008
From: report at bugs.python.org (Nick Edds)
Date: Tue, 15 Jul 2008 04:12:30 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

Here is an iterative replacement to _recursive_matches for Wildcard
Patterns. It's not really much faster now, although I think there is
some room to improve it. It's doesn't seem like the most elegant
solution, but it works. It passes all of the tests, although I had to
rewrite one because it was generating the same matches but in a
different order.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: iterative.diff
keywords: patch
messages: 69672
nosy: collinwinter, nedds
severity: normal
status: open
title: 2to3 Iterative Wildcard Matching
Added file: http://bugs.python.org/file10896/iterative.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Tue Jul 15 07:21:51 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jul 2008 05:21:51 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

'rU' universal newline support is useless, because read lines end with
'\n' regardless of actual line end in the source file. Applications that
care about line ends still open file in binary mode and gather the stats
manually. 

So, to make this mode useful - the 'rbU' should be addded. Otherwise it
doesn't worth complication both in C code and in documentation.

----------
components: Library (Lib)
messages: 69673
nosy: techtonik
severity: normal
status: open
title: add 'rbU' mode to open()
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Tue Jul 15 08:01:18 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Jul 2008 06:01:18 +0000
Subject: [issue3356] some tests fail in debug mode (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1216101678.83.0.216521114285.issue3356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I can't reproduce the error using Windows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Tue Jul 15 11:26:46 2008
From: report at bugs.python.org (kundeng)
Date: Tue, 15 Jul 2008 09:26:46 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1216114005.72.0.890569039714.issue643841@psf.upfronthosting.co.za>


kundeng <kundeng06 at gmail.com> added the comment:

Hi, I was trying to implement a generic proxy class with some
restricting behaviors and then I bumped into this complication.  May I
ask what the conclusion is going to be in the long run? 

I guess my question is that 

1> is it just going to be a documentation change (first)?

2> is it technically difficult(other things are going to be broken
because of this change) or very inefficient to make the behavior of
special method lookup same as normal methods?

2> Otherwise, what is the rationale behind keeping the differences? 

thank you.

----------
nosy: +kundeng06

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Tue Jul 15 11:52:18 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Jul 2008 09:52:18 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1216115537.93.0.453145448789.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There are both speed and correctness reasons for special methods being
looked up the way they are, so the behaviour isn't going to change.

Aside from providing additional details in the language reference on how
special methods are looked up (and the reasons things are done that
way), the only change that might eventually happen in this area is the
inclusion of a mixin class in the standard library to assist in writing
classes which delegate most operations to another object. That part
won't happen before 2.7/3.1 though (if it happens at all).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Tue Jul 15 12:45:38 2008
From: report at bugs.python.org (Richard B. Kreckel)
Date: Tue, 15 Jul 2008 10:45:38 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>


New submission from Richard B. Kreckel <richyk at users.sourceforge.net>:

When constructing a floating-point value, literals are apparently
sometimes interpreted as octal integral types, although they contain
exponent marker or/and decimal point. The presence of exponent marker
or/and decimal point should suffice to identify it as floating-point.

Example:
>>> x = 02120246124e0
>>> x = 02120246124.0
>>> x = 021202461241e0
ValueError: invalid literal for long() with base 8: '021202461241e0'
>>> x = 021202461241.0
ValueError: invalid literal for long() with base 8: '021202461241.0'

I am using Python 2.5.1 from openSuSE 10.3.

----------
components: Interpreter Core
messages: 69677
nosy: richyk
severity: normal
status: open
title: Inconsistent type-deduction of decimal floating-point
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Tue Jul 15 12:52:14 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Tue, 15 Jul 2008 10:52:14 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216119133.98.0.942619817219.issue3208@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

Sorry I haven't state the issue clearly. For this issue I mean the
built-in function should able to define an __annotations__ attribute,
just like the __doc__ attribute, but not to access it in extension module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Tue Jul 15 13:47:48 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 15 Jul 2008 11:47:48 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216122468.37.0.122218421522.issue3359@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The whole idea of universal newline mode is that the various possible
line endings ('\r', '\n' and '\r\n') are all mapped to '\n' precisely
so the user doesn't have to detect and fiddle with them.  Using 'b' and
'U' together makes no sense.

* If you really want to see the line endings use 'rb'.
* If you don't care about the line endings regardless of source, use 'rU'.
* Otherwise use 'r'.

----------
nosy: +skip.montanaro
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Tue Jul 15 13:54:56 2008
From: report at bugs.python.org (Wolfgang Langner)
Date: Tue, 15 Jul 2008 11:54:56 +0000
Subject: [issue3361] pypi issue tracker link (python.org)
In-Reply-To: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za>
Message-ID: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za>


New submission from Wolfgang Langner <tds333 at gmail.com>:

Some links still point to the sourceforge bug tracker.
(one from http://pypi.python.org/pypi bug reports).
Check if there are others and let them point to the new bug tracker.

----------
components: None
messages: 69680
nosy: tds333
severity: normal
status: open
title: pypi issue tracker link (python.org)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3361>
_______________________________________

From report at bugs.python.org  Tue Jul 15 15:34:36 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 13:34:36 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1216128876.5.0.427429284863.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Tue Jul 15 15:34:45 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 13:34:45 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1216128885.21.0.921974406688.issue3321@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +roudkerk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Tue Jul 15 15:38:11 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 13:38:11 +0000
Subject: [issue3350] multiprocessing adds built-in types to the global
	copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1216129091.11.0.664669116565.issue3350@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +roudkerk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________

From report at bugs.python.org  Tue Jul 15 15:50:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 13:50:12 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1216129811.37.0.831254032755.issue3112@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Antonine, do you have a patch address the review comments?

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Tue Jul 15 15:52:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 13:52:02 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1216129921.94.0.199284644261.issue3270@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

The connection patch was applied r64961

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:22:30 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:22:30 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>


New submission from cfr <margali at imapmail.org>:

Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, locale
>>> locale.getpreferredencoding()
Bus error

Sample crash report excerpt follows (plenty more available on request!).
Note that the version of python given in the crash report is *not* the
same as the version of python actually in use. I have never had an alpha
version of python installed. The current version is the standard version
of 2.5.2 available as a dmg download from python.org i.e. the universal
framework build for 10.4.

OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: Python
Path:   
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Parent:  bash [27154]

Version: 2.5a0 (2.5alpha0)

PID:    4692
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   com.apple.CoreFoundation 	0x907beac0 CFStringGetCStringPtr + 408
1   _locale.so               	0x000f1cd8 PyLocale_getdefaultlocale + 328
(_localemodule.c:435)
2   org.python.python        	0x002b393c PyEval_EvalFrameEx + 17036
(ceval.c:3557)
3   org.python.python        	0x002b5e50 PyEval_EvalCodeEx + 2096
(ceval.c:2836)
4   org.python.python        	0x002b3f48 PyEval_EvalFrameEx + 18584
(ceval.c:3669)
5   org.python.python        	0x002b5e50 PyEval_EvalCodeEx + 2096
(ceval.c:2836)
6   org.python.python        	0x002b5ff0 PyEval_EvalCode + 48 (ceval.c:500)
7   org.python.python        	0x002dbb24 PyRun_InteractiveOneFlags + 772
(pythonrun.c:1274)
8   org.python.python        	0x002dbd30 PyRun_InteractiveLoopFlags +
288 (pythonrun.c:725)
9   org.python.python        	0x002dc3f0 PyRun_AnyFileExFlags + 176
(pythonrun.c:693)
10  org.python.python        	0x002eba9c Py_Main + 3052 (main.c:523)
11  org.python.python        	0x000019bc 0x1000 + 2492
12  org.python.python        	0x000016c0 0x1000 + 1728

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x00000000907beac0 srr1: 0x000000000000d030                    
   vrsave: 0x0000000000000000
    cr: 0x84244224          xer: 0x0000000020000004   lr:
0x00000000907be930  ctr: 0x00000000907be928
    r0: 0x00000000a07bb678   r1: 0x00000000bfffd3a0   r2:
0x00000000a07bb278   r3: 0x0000000000000000
    r4: 0x0000000000000000   r5: 0x00000000bfffd2e0   r6:
0x0000000000000005   r7: 0x0000000000000007
    r8: 0x0000000000702333   r9: 0x000000000000001c  r10:
0x0000000090bb4bb8  r11: 0x00000000000f33d8
   r12: 0x00000000907be928  r13: 0x0000000000058b24  r14:
0x0000000000071e40  r15: 0x000000000006aa20
   r16: 0x0000000000000000  r17: 0x0000000000000001  r18:
0x00000000000732a8  r19: 0x0000000000619410
   r20: 0x0000000000000000  r21: 0x000000000006a9b0  r22:
0x0000000000000000  r23: 0x0000000000058b39
   r24: 0x00000000000f1b90  r25: 0x00000000006001d0  r26:
0x000000000007e300  r27: 0x0000000000000000
   r28: 0x0000000000000000  r29: 0x00000000a07bbb6c  r30:
0x0000000000000000  r31: 0x00000000907be930

Binary Images Description:
    0x1000 -     0x1fff org.python.python 2.5a0 (2.5alpha0)
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
   0xa2000 -    0xd9fff readline.so 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/readline.so
   0xf0000 -    0xf2fff _locale.so 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_locale.so
  0x205000 -   0x323fff org.python.python 2.5a0 (2.5)
/Library/Frameworks/Python.framework/Versions/2.5/Python
  0x705000 -   0x74afff libncurses.5.dylib 
/Library/Frameworks/Python.framework/Versions/2.5/lib/libncurses.5.dylib
  0x7de000 -   0x7e1fff operator.so 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so
0x8fe00000 - 0x8fe52fff dyld 46.16	/usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib 	/usr/lib/libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib 
/usr/lib/system/libmathCommon.A.dylib
0x907bb000 - 0x90895fff com.apple.CoreFoundation 6.4.11 (368.35)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x908e0000 - 0x909e2fff libicucore.A.dylib 	/usr/lib/libicucore.A.dylib
0x90a3c000 - 0x90ac0fff libobjc.A.dylib 	/usr/lib/libobjc.A.dylib
0x90aea000 - 0x90b5afff com.apple.framework.IOKit 1.4 (???)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90b70000 - 0x90b82fff libauto.dylib 	/usr/lib/libauto.dylib
0x90b89000 - 0x90e60fff com.apple.CoreServices.CarbonCore 681.17
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x91111000 - 0x9111ffff libz.1.dylib 	/usr/lib/libz.1.dylib
0x91122000 - 0x912ddfff com.apple.security 4.6 (29770)
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x913dc000 - 0x913e5fff com.apple.DiskArbitration 2.1.2
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x913ec000 - 0x913f4fff libbsm.dylib 	/usr/lib/libbsm.dylib
0x913f8000 - 0x91420fff com.apple.SystemConfiguration 1.8.3
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91433000 - 0x9143efff libgcc_s.1.dylib 	/usr/lib/libgcc_s.1.dylib
0x945e4000 - 0x94604fff libmx.A.dylib 	/usr/lib/libmx.A.dylib

I have got as far as I can tracking this issue down but would be happy
to provide further information if somebody would give me (a pointer to)
instructions or a hint.

----------
messages: 69683
nosy: cfr
severity: normal
status: open
title: locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:24:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jul 2008 14:24:14 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1216131854.51.0.485561878081.issue3112@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antonine, do you have a patch address the review comments?

Yes, although I've forgotten to upload it here - you will find it at
http://codereview.appspot.com/2448

PS: it is Antoine not Antonine :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:31:53 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:31:53 +0000
Subject: [issue3362] python version incorrectly reported in crash reports on
	Mac OS X 10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216132313.46.0.783489026691.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Although the active version of python on my machine is 2.5.2 and I have
never had an alpha version installed, crash reports for python report
the version as "2.5a0 (2.5alpha0)".

Version details: active version of python is from the current python.org
dmg download for Mac OS X 10.4 i.e. the universal framework build. When
starting python, I get:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

but in crash reports, I get:

Command: Python
Path:   
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Parent:  bash [27154]

Version: 2.5a0 (2.5alpha0)

and python is given as version 2.5a0 in the binary image listing which
follows.

Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC

I think I did have 2.5.1 installed prior to installing 2.5.2 and I also
have two older versions of python installed - 2.4 (also the python.org
build) and 2.3 (as pre-installed by Apple) - but I never installed 2.5.0
or any version/candidate in the 2.5 line prior to 2.5.1.

I'm not sure what further information might be helpful but would be
happy to provide it on request.

----------
components: +None
title: locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC -> python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:35:09 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:35:09 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216132509.3.0.730187981457.issue3362@psf.upfronthosting.co.za>


Changes by cfr <margali at imapmail.org>:


----------
title: python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC -> locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:36:52 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:36:52 +0000
Subject: [issue3363] python version incorrectly reported in crash reports on
	Mac OS X 10.4.11 PPC
In-Reply-To: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>
Message-ID: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>


New submission from cfr <margali at imapmail.org>:

Although the active version of python on my machine is 2.5.2 and I have
never had an alpha version installed, crash reports for python report
the version as "2.5a0 (2.5alpha0)".

Version details: active version of python is from the current python.org
dmg download for Mac OS X 10.4 i.e. the universal framework build. When
starting python, I get:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

but in crash reports, I get:

Command: Python
Path:   
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Parent:  bash [27154]

Version: 2.5a0 (2.5alpha0)

and python is given as version 2.5a0 in the binary image listing which
follows.

Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC

I think I did have 2.5.1 installed prior to installing 2.5.2 and I also
have two older versions of python installed - 2.4 (also the python.org
build) and 2.3 (as pre-installed by Apple) - but I never installed 2.5.0
or any version/candidate in the 2.5 line prior to 2.5.1.

I'm not sure what further information might be helpful but would be
happy to provide it on request.

----------
components: None
messages: 69686
nosy: cfr
severity: normal
status: open
title: python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3363>
_______________________________________

From report at bugs.python.org  Tue Jul 15 16:40:13 2008
From: report at bugs.python.org (cfr)
Date: Tue, 15 Jul 2008 14:40:13 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216132813.89.0.185708697615.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Please ignore the second message. I thought I was creating a second bug
report and cannot figure out anyway to edit it now I realise my error.
I've just copied that to a second report with an appropriate header as I
am assuming the two issues I'm seeing are distinct.

This bug report is intended to cover the bus error I see triggered by
locale.getpreferredencoding().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:23:59 2008
From: report at bugs.python.org (Chester)
Date: Tue, 15 Jul 2008 15:23:59 +0000
Subject: [issue3364] An ortographical typo in Zen of Python text
In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
Message-ID: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>


New submission from Chester <wxpythoner at gmail.com>:

I hope I chose the correct component type for this issue report. Anyway,
if you do  import this  in the Python 3.x interactive interpreter, you
get the Zen of Python by Tim Peters. This text has a line which has an
ortographical typo in it. Please look at this line of text from the Zen
of Python:

There should be one-- and preferably only one --obvious way to do it.

Now this line has the typo I am talking about, and the typo is the lack
of a space before the first dash (actually before the double-hyphen) and
the space after the second dash (or double-hyphen).

Please note that the dash punctuation mark is by ortographical rules
separated from the words, so there are two spaces separating a dash from
the surrounding words. By writing the dashes in the way that are in the
above sentence from the Zen of Python, we don't achieve any effect as
sometimes ortographical rules can be broken to create some special
effect in the sentence (like in a line that uses the asteriskes to
emphasize the word 'right' with writing it as *right*), but here in the
above line it is clearly a normal sentence, not needing any special
effect, which is also incorrect from this point of view. So please fix
the above line like this:

There should be one -- and preferably only one -- obvious way to do it.

Consider the fact that the last sentence is written correctly and that
the dash in it is separated from the surrounding words as the
ortographic rules demand. So having one line of text with an incorrectly
used dash and some other line with the correctly used dash, makes the
whole text either inconsistent or just bad. Okay, it isn't *really* bad
but it's incorrect and it needs a little fix. And it's not too much
trouble to add two missing spaces in that line of text.

I think that ortography is our friend in the Python world. ;)

----------
assignee: georg.brandl
components: Documentation
messages: 69688
nosy: cheDu, georg.brandl
severity: normal
status: open
title: An ortographical typo in Zen of Python text
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:30:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 15:30:36 +0000
Subject: [issue3364] An ortographical typo in Zen of Python text
In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
Message-ID: <1216135836.66.0.00525173841392.issue3364@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm sorry, but syntax is part of poetry, too. Please stop misusing the
tracker.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:32:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 15:32:30 +0000
Subject: [issue3112] implement PEP 3134 exception reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1216135947.8.0.465697572252.issue3112@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, Antoine! The patch is in with r64965.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:35:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 15:35:20 +0000
Subject: [issue3113] Document exception chaining
In-Reply-To: <1213475513.28.0.247169838861.issue3113@psf.upfronthosting.co.za>
Message-ID: <1216136120.04.0.220405800852.issue3113@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3113>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:42:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 15:42:48 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216136568.55.0.566044725827.issue3008@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:49:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Jul 2008 15:49:23 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1216136963.14.0.516625062829.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed for 2.6 in r64962 and the underlying PyObject_HashNotImplemented
mechanic forward ported to 3.0 in r64967.

Still need to update the C API documentation and the library reference,
as well as implement the Py3k warning in 2.6, but I won't get to those
for this beta - dropping priority to deferred blocker.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:52:44 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 15:52:44 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216137164.1.0.47889878262.issue874900@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:57:15 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 15:57:15 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216137435.93.0.14439386817.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated patch that addresses Raymond's concerns.

> The patch looks good.  I would coded hex_from_char() using a lookup 
> into "0123456789abcdef" which uses no unpredicatable branches.  
> Likewise, I would done hex_from_char() with a case statement (limiting 
> the call to single unpredicatable branch).

Done.

> Question:  are the ("0x0p+0") and ("-0x0p+0") special cases standard?

Not entirely.  Java outputs "0x0.0p0" and "-0x0.0p0".  The C99 standard 
doesn't specify exactly how the output should look, except to say that 
the exponent should be 0.  The '+' is there for consistency.

I can change '0x0p+0' to '0x0.0p+0' if people think this looks prettier.
On consideration, this does look better to me.  Changed.

> The docs need a "new in py2.6"

Fixed.

> Coding style:  move the inner si++ to a separate line so there are no 
> side-effects and the order of execution is obvious.

Done.  (And the same with s++ in float_fromhex.)

> Question:  should the "inf" string checks be made case sensitive on 
> insensitive?  Is there a standard?

Everything I've seen, except Java, seems to like case-insensitivity.  
The C99 standard says case should be ignored, as does the IBM Decimal 
standard.  Python's float('nan') and float('inf') also currently ignore 
case.  So I think these checks should be case insensitive.

(Java insists on infinity being spelt "Infinity", and nan being spelt 
"NaN".)

Thank you for reviewing this, Raymond!

I aim to check this in when (if?) I get approval from Barry.

Added file: http://bugs.python.org/file10897/hex_float9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 18:13:45 2008
From: report at bugs.python.org (TanaT)
Date: Tue, 15 Jul 2008 16:13:45 +0000
Subject: [issue3365] in module math,
	PI value seems to be wrong after digit 17th
In-Reply-To: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za>
Message-ID: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za>


New submission from TanaT <anatole.ng at free.fr>:

Hello,
This is my first Issue creation (I looked for "PI" in issue tracker and
found nothing): Please forgive any mistake.

Here is the point :
I typed the following commands :
>>> import math
>>> print '%1.26f' % math.pi
3.14159265358979311599796347
In fact, PI value is
3,14159265358979323846264338327950288...
                 ^
I don't know if PI value is computed in Python : If it is, this issue is
probably already dead ! But if PI is just saved in math library, there
could be an improvement.

----------
components: None
messages: 69693
nosy: TanaT
severity: normal
status: open
title: in module math, PI value seems to be wrong after digit 17th
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3365>
_______________________________________

From report at bugs.python.org  Tue Jul 15 18:19:21 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 16:19:21 +0000
Subject: [issue3365] in module math,
	PI value seems to be wrong after digit 17th
In-Reply-To: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za>
Message-ID: <1216138761.26.0.652777011843.issue3365@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug (though it's commonly reported as such :-) ).  Given 
that not all real numbers can be represented as floats, math.pi is 
necessarily an approximation to true Pi, and you're
printing that approximation out to high precision.

No, pi isn't computed in Python;  it's a constant, stored as an IEEE 754 
double.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3365>
_______________________________________

From report at bugs.python.org  Tue Jul 15 18:34:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 16:34:22 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216139662.06.0.521585660777.issue3360@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I get the same behavior in the trunk (on OS X 10.5), though it's not a 
problem in the py3k branch.

I agree that this is undesirable behaviour, and I think it should be 
fixed.  For me, the crossover seems to occur at 2*10**10:

>>> 020000000000.0
ValueError: invalid literal for long() with base 8: '020000000000.0'
>>> 019999999999.0
19999999999.0

----------
assignee:  -> marketdickinson
nosy: +marketdickinson
priority:  -> high
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Tue Jul 15 19:16:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 17:16:26 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216142186.16.0.576868526959.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've been testing greg's latest patch and it seems to work for me - I'm 
not seeing any test_multiprocessing hangs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul 15 19:16:51 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 17:16:51 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216142211.34.0.649217837094.issue3088@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
dependencies: +threading module can deadlock after fork

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Tue Jul 15 19:27:50 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 15 Jul 2008 17:27:50 +0000
Subject: [issue3258] ctypes assertion failure in trunk
In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za>
Message-ID: <1216142870.47.0.251696757383.issue3258@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks for the heads up.  Fixed in trunk (rev 64971) and py3k (rev 64972).

I used "&B" (pointer to bytes) as the format string for pointer to
incomplete structure, not "&P".

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3258>
_______________________________________

From report at bugs.python.org  Tue Jul 15 19:37:54 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Jul 2008 17:37:54 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>From Py3000 list: in C99 standard math library, but need code when not
yet in particular implementation.  
Dickinson: open and assign to me
Stutzbach: I suggest using the versions from newlib's libm.  They contain
extensive comments explaining the math and have a generous license,
e.g.,:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src

----------
assignee: marketdickinson
components: Library (Lib)
messages: 69698
nosy: marketdickinson, tjreedy
severity: normal
status: open
title: Add gamma and error functions to math module
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Jul 15 19:42:26 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jul 2008 17:42:26 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216143746.99.0.490532467909.issue3366@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:10:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 18:10:16 +0000
Subject: [issue3231] re.compile fails with some bytes patterns
In-Reply-To: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>
Message-ID: <1216145416.35.0.0642609428304.issue3231@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Can we make sure this is fixed for beta 3? (Beta 2 would be great too,
but it's getting late.)

----------
nosy: +gvanrossum
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3231>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:28:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 18:28:06 +0000
Subject: [issue3231] re.compile fails with some bytes patterns
In-Reply-To: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>
Message-ID: <1216146486.16.0.193918967509.issue3231@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Antoine's patch (with a 3 character fix) looks just fine to me. Guido,
I'm assigning this to you because svn annotate tells me, you made this
change.

----------
assignee:  -> gvanrossum
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3231>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:30:47 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Jul 2008 18:30:47 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1216146646.97.0.682592281282.issue3270@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I made a mistake and reverted r64961 - self._address is used pretty 
heavily, and altering it the way outlined in the patch does not fix all 
instances.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:33:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 18:33:36 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216146816.43.0.276888948427.issue3316@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:33:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jul 2008 18:33:52 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216146832.45.0.429816728859.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I still don't like the _after_fork() implementation.  Its O(n) where n
> == number of threads the parent process had.

It may be O(n) but the inner loop looks very cheap. Even with n == 1000
I'm not sure it would make a difference.

However, are you sure the system thread identifier stays the same after
a fork? I see that in _after_fork() you reuse the old ident for
new_active instead of getting it from get_ident().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:35:12 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 15 Jul 2008 18:35:12 +0000
Subject: [issue3313] dlopen() error with no error message from dlerror()
In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
Message-ID: <1216146912.06.0.248472731657.issue3313@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I can confirm the problem on ubuntu linux.

----------
assignee:  -> theller
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3313>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:35:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 18:35:29 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216146929.29.0.534412686058.issue3316@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nick, are you going to be able to get this cleaned up today for the beta
release tomorrow?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:38:25 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 18:38:25 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216147105.77.0.0661973592955.issue3008@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

If you two can agree that this code is good, I'm ok with the API.

I would emphasize in the docs and NEWS entry though that .hex() is an
*instance* method while .fromhex() is a *class* method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:45:54 2008
From: report at bugs.python.org (Nick Edds)
Date: Tue, 15 Jul 2008 18:45:54 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216147554.52.0.0860846922227.issue3316@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I should be able to. What time would you need it by?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:48:38 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Jul 2008 18:48:38 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216147718.25.0.775154578597.issue3008@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, please go ahead and apply so the buildbots will have time to give 
it a run on all the platforms before beta 2 is cut.  Be sure to make 
Guido's edits to the Misc/NEWS entry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 20:52:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 18:52:22 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216147941.94.0.297011830606.issue3316@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Today or tomorrow.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Tue Jul 15 21:05:45 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jul 2008 19:05:45 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216148745.81.0.952117625519.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

If you open file with 'r' - all line endings will be mapped precisely to
'\n' anyways, so it has nothing to do with 'U' mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Tue Jul 15 21:06:13 2008
From: report at bugs.python.org (Richard B. Kreckel)
Date: Tue, 15 Jul 2008 19:06:13 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216148773.01.0.251599849233.issue3360@psf.upfronthosting.co.za>


Richard B. Kreckel <richyk at users.sourceforge.net> added the comment:

Some additional information:

My original report was with an x86 system.

Now, I'm sitting in front of an x86_64 system running Python 2.4.4 (from
Debian stable) and Python 2.5.2 (from Debian testing), both 64 bit
userland. On these systems, the behavior I described does not exist:
Assignment always appears to result in an IEEE754 double-precision float.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Tue Jul 15 21:09:28 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 19:09:28 +0000
Subject: [issue3008] Let bin/oct/hex show floats
In-Reply-To: <1212133665.79.0.610497521222.issue3008@psf.upfronthosting.co.za>
Message-ID: <1216148968.17.0.272941987847.issue3008@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed, r64974

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3008>
_______________________________________

From report at bugs.python.org  Tue Jul 15 21:35:10 2008
From: report at bugs.python.org (Tim Peters)
Date: Tue, 15 Jul 2008 19:35:10 +0000
Subject: [issue3364] An ortographical typo in Zen of Python text
In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
Message-ID: <1216150510.19.0.355536032386.issue3364@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I'm afraid you missed the joke ;-)  While you believe spaces are
required on both sides of an em dash, there is no consensus on this
point.  For example, most (but not all) American authorities say /no/
spaces should be used.  That's the joke.  In writing a line about "only
one way to do it", I used a device (em dash) for which at least two ways
to do it (with spaces, without spaces) are commonly used, neither of
which is obvious -- and deliberately picked a third way just to rub it in.

This will never change ;-)

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________

From report at bugs.python.org  Tue Jul 15 21:50:15 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 15 Jul 2008 19:50:15 +0000
Subject: [issue3313] dlopen() error with no error message from dlerror()
In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za>
Message-ID: <1216151415.16.0.69253028849.issue3313@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks for the patch, fixed in trunk rev 64977 and py3k rev 64978.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3313>
_______________________________________

From report at bugs.python.org  Tue Jul 15 22:21:05 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 20:21:05 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

If a PyTokenizer_FromString() is called with an empty string, the 
tokenizer's line_start member never gets initialized.  Later, it is 
compared with the token pointer 'a' in parsetok.c:193 and that behavior 
can result in undefined behavior.
Found using Rational Purify for windows.
A patch is provided.

----------
files: tmp1.patch
keywords: easy, patch, patch
messages: 69714
nosy: krisvale
severity: normal
status: open
title: Uninitialized value read in parsetok.c
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10898/tmp1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Tue Jul 15 22:39:57 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 20:39:57 +0000
Subject: [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1216154397.96.0.276914092115.issue3327@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Added a patch for this issue.  Please comment.

----------
keywords: +easy, patch
Added file: http://bugs.python.org/file10899/tmp2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________

From report at bugs.python.org  Tue Jul 15 22:45:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Jul 2008 20:45:49 +0000
Subject: [issue3361] pypi issue tracker link (python.org)
In-Reply-To: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za>
Message-ID: <1216154749.0.0.245388941706.issue3361@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The link on PyPI is correct. It doesn't point to the Python bug tracker,
but the PyPI bug tracker, which is on SF.

I have checked, and did not find any further links to the SF Python bug
tracker.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3361>
_______________________________________

From report at bugs.python.org  Tue Jul 15 22:50:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 20:50:04 +0000
Subject: [issue3327] NULL member in modules_by_index
In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za>
Message-ID: <1216155004.25.0.707180939093.issue3327@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3327>
_______________________________________

From report at bugs.python.org  Tue Jul 15 22:51:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Jul 2008 20:51:41 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216155101.06.0.930270183847.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It would be good to find out what the code inside
PyLocale_getdefaultlocale precisely is doing. I.e. what is the value of
name at that point, and is that perhaps an illegal parameter for
CFStringGetCStringPtr somehow? If the debugger can't help (not even
after compiling Python with --with-pydebug), augment the source code
with a printf, and rebuild Python.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:06:35 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 15 Jul 2008 21:06:35 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1216155995.46.0.278076962387.issue3324@psf.upfronthosting.co.za>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

What? You have fixed it in some development version, and left the
current online version broken? How much can it take to fix a broken link
on a web page? If that's the net effect, I shouldn't have gone through
all the efforts of filing this issue!

Rather than closing the bug somebody should have asked the question how
broken links can creep into the Python web site at all, and how to
prevent this situation from re-occurring.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:18:36 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:18:36 +0000
Subject: [issue3368] Memory leak in import.c
In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
Message-ID: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Failure to deallocate a buffer returned by PyArg_ParseTuple.  Patch is 
attached.
Found using purify while running the testsuite.

----------
components: Interpreter Core
files: tmp3.patch
keywords: easy, patch, patch
messages: 69719
nosy: krisvale
severity: normal
status: open
title: Memory leak in import.c
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file10900/tmp3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3368>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:26:45 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 21:26:45 +0000
Subject: [issue1503] test_xmlrpc is still flakey
In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
Message-ID: <1216157205.39.0.896705484714.issue1503@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Does anybody still care about this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:42:26 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:42:26 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When a nan or inf is generated in PyFloat_FromString(), a temporary 
buffer may be left behind.
Patch attached.
Found using Purify

----------
components: Interpreter Core
files: tmp4.patch
keywords: easy, patch, patch
messages: 69721
nosy: krisvale
severity: normal
status: open
title: memory leak in floatobject.c
versions: Python 3.0
Added file: http://bugs.python.org/file10901/tmp4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:42:37 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:42:37 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216158157.29.0.654911671447.issue3369@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Tue Jul 15 23:44:10 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 15 Jul 2008 21:44:10 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1216158250.14.0.0028434949781.issue3367@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:10:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 22:10:22 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216159822.52.0.0393814998369.issue3360@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> userland. On these systems, the behavior I described does not exist:

Not even with really large values?  What happens on 64-bit with

>>> x = 0800000000000000000000.0

? (that's 20 zeros between the 8 and the decimal point...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:20:36 2008
From: report at bugs.python.org (Matt McCredie)
Date: Tue, 15 Jul 2008 22:20:36 +0000
Subject: [issue3370] importing with_statement causes exec to raise syntax
	error on block that doesn't end with a newline
In-Reply-To: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za>
Message-ID: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za>


New submission from Matt McCredie <mccredie at gmail.com>:

The following session demonstrates the issue:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exec "def foo():\n    return 0" # no ending newline works fine
>>> foo()
0
>>> exec "def foo():\n    return 1\n" # with an ending newline works fine
>>> foo()
1
>>> from __future__ import with_statement
>>> exec "def foo():\n    return 2\n" # with an ending newline works fine
>>> foo()
2
>>> exec "def foo():\n    return 3" # without an ending new line... breaks

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2
    return 3
          ^ 


Possibly related to http://bugs.python.org/issue1184112, and/or
http://bugs.python.org/issue501622?

----------
components: Interpreter Core
messages: 69723
nosy: mccredie
severity: normal
status: open
title: importing with_statement causes exec to raise syntax error on block that doesn't end with a newline
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3370>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:25:04 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Jul 2008 22:25:04 +0000
Subject: [issue1503] test_xmlrpc is still flakey
In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
Message-ID: <1216160704.89.0.593598255111.issue1503@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I still think that blocking mode should be turned on in socket.accept.
settimeout implicitly sets non-blocking mode (which might be a bit
surprising).
The sockets returned from accept() being in non-blocking mode is
surprising (as this bug shows).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:25:21 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:25:21 +0000
Subject: [issue3368] Memory leak in import.c
In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
Message-ID: <1216160721.33.0.0296405001486.issue3368@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3368>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:25:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:25:46 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1216160746.53.0.865601596358.issue3367@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:25:57 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:25:57 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216160757.22.0.300890512479.issue3369@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:33:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:33:43 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216161223.95.0.875115338694.issue3369@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:33:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:33:58 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1216161238.01.0.938509541228.issue3367@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:34:13 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 22:34:13 +0000
Subject: [issue3368] Memory leak in import.c
In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
Message-ID: <1216161253.83.0.205489892125.issue3368@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3368>
_______________________________________

From report at bugs.python.org  Wed Jul 16 00:38:39 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jul 2008 22:38:39 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216161519.32.0.784196710937.issue3369@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Does this also apply to 2.6?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:05:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jul 2008 23:05:10 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1216163110.78.0.0494114553309.issue3324@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

For Python 2.6 and 3.0, we have transitioned over from LaTex to a new
document format, reST. For this reason, we are not backporting fixes to
the docs. However, when 2.7 and 3.1 become the development focus, we
will again backport fixes. I'm sorry for the misunderstanding and thank
you for your time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:40:46 2008
From: report at bugs.python.org (Joel Madigan)
Date: Tue, 15 Jul 2008 23:40:46 +0000
Subject: [issue3370] importing with_statement causes exec to raise syntax
	error on block that doesn't end with a newline
In-Reply-To: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za>
Message-ID: <1216165246.88.0.182586983587.issue3370@psf.upfronthosting.co.za>


Joel Madigan <dochoncho at gmail.com> added the comment:

Confirmed in Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)

Seems to be fixed in 2.6b1.

----------
nosy: +dochoncho

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3370>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:41:55 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:41:55 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1216165315.03.0.607201029491.issue2271@psf.upfronthosting.co.za>


Ben Beasley <forumuser at musicinmybrain.net> added the comment:

Apparent duplicates are at http://bugs.python.org/issue1298962 and
http://bugs.python.org/issue1565468. This bug seems to have something to
do with "power user" user privileges.

I can duplicate this problem with the MSI installers for Python 2.4.4,
2.5.2, 2.6b1, and 3.0b1. According to some of the other issues, this
problem has been around since 2005; I really, really would like to see
it fixed by the final releases of 2.6 and 3.0, because, as Ross said,
this bug can be a showstopper for many enterprise users who encounter
it. (Or, at least, it forces us to find an administrator to install
Python even though we theoretically have install privileges for it.)

I've attached two logs from a Python 2.6b1 install on Windows XP, one
for a "just me" installation and one for an "all users" installation. In
both cases, I selected all options except for registering extensions.
Since I did this on my work computer, I have search-and-replaced the
values of LogonUser, UserSID, USERNAME, and COMPANYNAME to make them
generic.

Adding at least TARGETDIR to the SecureCustomProperties with Orca allows
me to install where I want to. It may take some investigation to
determine which properties should be added to this list and which don't
need to be.

I'd be happy to provide any more information that can help get this
resolved.

----------
nosy: +music
versions: +Python 2.4, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10902/msi_bug_logs.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:43:02 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:43:02 +0000
Subject: [issue1298962] MSI installer does not pass values as SecureProperty
	from UI
Message-ID: <1216165382.92.0.951916302271.issue1298962@psf.upfronthosting.co.za>


Ben Beasley <forumuser at musicinmybrain.net> added the comment:

http://bugs.python.org/issue1298962 appears to be a duplicate, with some
more recent activity.

----------
nosy: +music

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298962>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:43:57 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:43:57 +0000
Subject: [issue1565468] Install on WinXP always goes to C:\
Message-ID: <1216165437.24.0.12302063558.issue1565468@psf.upfronthosting.co.za>


Ben Beasley <forumuser at musicinmybrain.net> added the comment:

http://bugs.python.org/issue2271 and http://bugs.python.org/issue1298962
appear to be duplicates of this issue, with the former having the most
recent activity.

----------
nosy: +music

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565468>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:44:08 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:44:08 +0000
Subject: [issue1298962] MSI installer does not pass values as SecureProperty
	from UI
Message-ID: <1216165448.84.0.634141076634.issue1298962@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
versions: +Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298962>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:44:16 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:44:16 +0000
Subject: [issue1565468] Install on WinXP always goes to C:\
Message-ID: <1216165456.06.0.467024477942.issue1565468@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
versions: +Python 2.4, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565468>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:44:34 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:44:34 +0000
Subject: [issue1298962] MSI installer does not pass values as SecureProperty
	from UI
Message-ID: <1216165474.37.0.658015380869.issue1298962@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298962>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:44:42 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:44:42 +0000
Subject: [issue1565468] Install on WinXP always goes to C:\
Message-ID: <1216165482.79.0.413598334136.issue1565468@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565468>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:44:37 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 15 Jul 2008 23:44:37 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216165477.19.0.112859669879.issue3316@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I would really like to get this in by beta2, but it's not quite enough
to hold up the release.  Please try to get this cleaned up and committed
by July 16 for beta 2.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:45:09 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:45:09 +0000
Subject: [issue1298962] MSI installer does not pass values as SecureProperty
	from UI
Message-ID: <1216165509.45.0.81230949199.issue1298962@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298962>
_______________________________________

From report at bugs.python.org  Wed Jul 16 01:45:15 2008
From: report at bugs.python.org (Ben Beasley)
Date: Tue, 15 Jul 2008 23:45:15 +0000
Subject: [issue1565468] Install on WinXP always goes to C:\
Message-ID: <1216165515.89.0.266449229187.issue1565468@psf.upfronthosting.co.za>


Changes by Ben Beasley <forumuser at musicinmybrain.net>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565468>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:01:57 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 00:01:57 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1216166517.67.0.286875600004.issue3131@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think we'll defer this as a blocker.  It would be good to get 2to3
working right for the betas, but I don't think it should hold up beta2.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:10:21 2008
From: report at bugs.python.org (Nick Edds)
Date: Wed, 16 Jul 2008 00:10:21 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216167021.14.0.536682043609.issue3316@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I've got it finished, I just need to write some tests for it. It will
all be done later tonight.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:12:02 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 00:12:02 +0000
Subject: [issue3226] can't install on OSX 10.4
In-Reply-To: <1214671532.34.0.878967964042.issue3226@psf.upfronthosting.co.za>
Message-ID: <1216167122.33.0.741338962106.issue3226@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

What's the plan to fix this?  I'm not going to hold up beta2 for this.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3226>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:22:31 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 00:22:31 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1216167021.14.0.536682043609.issue3316@psf.upfronthosting.co.za>
Message-ID: <0F2C3F11-7150-48EE-AD9A-CD0E88FF52A9@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 15, 2008, at 8:10 PM, Nick Edds wrote:

> Nick Edds <nedds at uchicago.edu> added the comment:
>
> I've got it finished, I just need to write some tests for it. It will
> all be done later tonight.

Great!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH0/RHEjvBPtnXfVAQIdvAP/Sxz4XayNMlBWIicFVmmQ/C85Fujsb7wN
tqznDWfM7rqCiChkSe2dMPoMTQsOntCIEze+d1Usc5SqqVQk45dSX/ARs2qVtI6g
siVDSAxt2e1DWVCpko7hDySfP70e+1Id+Uv9obrHDJ6p6l7tx2hcZeS24NtQ+7aX
vrCfAtAJZxk=
=vtPk
-----END PGP SIGNATURE-----

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:31:22 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Jul 2008 00:31:22 +0000
Subject: [issue3083] Add alternate (#) formatting for bin, oct,
	hex output for str.format()
In-Reply-To: <1213219327.93.0.0491657155546.issue3083@psf.upfronthosting.co.za>
Message-ID: <1216168282.18.0.822073363717.issue3083@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Implemented in trunk in r64958 and r64984; in py3k in r64960 and r64985.

----------
resolution:  -> accepted
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3083>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:38:04 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 00:38:04 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216168684.87.0.879742805179.issue3088@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Sadly _multiprocessing apparently doesn't even build on my Ubuntu 8.04
machine and it still hangs on my 10.5 machine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:43:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 00:43:21 +0000
Subject: [issue3371] 2to3 fails in 3.0
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I'm disabling lib2to3 in the trunk because it fails just for Python 2.6.
(Python 2.5 and 3.0 are fine.)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 69739
nosy: benjamin.peterson, collinwinter
priority: deferred blocker
severity: normal
status: open
title: 2to3 fails in 3.0
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:42:57 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 00:42:57 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1216168684.87.0.879742805179.issue3088@psf.upfronthosting.co.za>
Message-ID: <F2DF03CD-5362-4200-97B9-AED5FB40D2DC@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Jul 15, 2008, at 8:38 PM, "Barry A. Warsaw"  
<report at bugs.python.org> wrote:

>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Sadly _multiprocessing apparently doesn't even build on my Ubuntu 8.04
> machine and it still hangs on my 10.5 machine.
>

There is no reason it shouldn't compile on ubuntu - without the patch  
for the bug I added as a dependency, we will keep seeing hangs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul 16 02:45:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 00:45:18 +0000
Subject: [issue3371] 2to3 fails in Python 2.6
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216169118.96.0.59013116697.issue3371@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
title: 2to3 fails in 3.0 -> 2to3 fails in Python 2.6
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:31:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 01:31:02 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1216168684.87.0.879742805179.issue3088@psf.upfronthosting.co.za>
Message-ID: <8241780B-602A-43CE-B2D7-92F158F8A8B5@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Barry - can you email the compile errors?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:38:53 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Wed, 16 Jul 2008 01:38:53 +0000
Subject: [issue3372] socket.setsockopt() is broken for multicast TTL and Loop
	options
In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>
Message-ID: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>


New submission from Niall O'Higgins <niallo at unworkable.org>:

socket.setsockopt() sets an optlen of '4' in the setsockopt system call
for options IP_MULTICAST_TTL and IP_MULTICAST_LOOP.  On OpenBSD, this
causes the kernel to hit an error condition and set errno 22 when these
options are set:

socket.error: (22, 'Invalid argument')

Yielded by e.g. socket.setsockopt(socket.IPPROTO_IP,
socket.IP_MULTICAST_TTL, 1)

According to both FreeBSD and OpenBSD manual pages (see e.g.
http://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html),
these fields are in fact both 8 bit unsigned, and the manuals suggest
the following:

u_char ttl;     /* range: 0 to 255, default = 1 */                     
                    
setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

While '4' (sizeof int) is correct for many options, special casing is
needed in Modules/socketmodule.c.  The following diff fixes the issue
for me on OpenBSD:

 @@ -1716,12 +1719,8 @@ sock_setsockopt(PySocketSockObject *s, PyObject
*args)
 
        if (PyArg_ParseTuple(args, "iii:setsockopt",
                             &level, &optname, &flag)) {
-               buflen = sizeof flag;
-               /* Multi cast options take shorter arguments */
-               if (optname == IP_MULTICAST_TTL
-                   || optname == IP_MULTICAST_LOOP)
-                       buflen = sizeof(u_char);
                buf = (char *) &flag;
+               buflen = sizeof flag;
        }
        else {
                PyErr_Clear();

----------
components: Library (Lib)
messages: 69741
nosy: niallo
severity: normal
status: open
title: socket.setsockopt() is broken for multicast TTL and Loop options
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3372>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:39:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 01:39:11 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216172351.3.0.318302134265.issue3359@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> If you open file with 'r' - all line endings will be mapped precisely to
> '\n' anyways, so it has nothing to do with 'U' mode.

No they won't -- only the platform-specific newline will. On Unix, 'r'
and 'rb' are the same.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:39:16 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Wed, 16 Jul 2008 01:39:16 +0000
Subject: [issue3372] socket.setsockopt() is broken for multicast TTL and Loop
	options
In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>
Message-ID: <1216172356.25.0.441948922319.issue3372@psf.upfronthosting.co.za>


Niall O'Higgins <niallo at unworkable.org> added the comment:

This also appears to be a bug in Python 2.4.

----------
versions: +Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3372>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:41:19 2008
From: report at bugs.python.org (cfr)
Date: Wed, 16 Jul 2008 01:41:19 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216172479.37.0.736555274036.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

I downloaded the current source (2.5.2) and confirmed that (1) python
will build as a framework (for me) and (2) that the problem occurs for
my build, too. I did not build it as a universal binary just in case
that helped but mostly to speed things up.

I then tried to add the --with-pydebug flag to my configure script and
build that way. I used separate build directories for the two builds to
keep the source clean. Unfortunately, make fails with the following
error in that case:

if test ""; then \
        gcc -o Python.framework/Versions/2.5/Python -arch i386 -arch ppc
-dynamiclib \
                -isysroot "" \
                -all_load libpython2.5.a -Wl,-single_module \
                -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python \
                -compatibility_version 2.5 \
                -current_version 2.5; \
        else \
        /usr/bin/libtool -o Python.framework/Versions/2.5/Python
-dynamic  libpython2.5.a \
                 -lSystem -lSystemStubs -arch_only ppc -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python
-compatibility_version 2.5 -current_version 2.5 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/2.5/Python] Error 1

I am guessing that eprintf has something to do with the debug option
because the symbol occurs in the debug version of libpython2.5.a but not
the plain version as far as I can tell. But I'm not sure how to fix it.

I am not even sure I am running the debugger correctly with the existing
version of python. I tried passing "-v -v" and "-d" to python after
reading the man page and that didn't get me any extra information.
Nothing useful-looking, at least. ("-v -v" produced a lot of output
beforehand but not around the point the error occurs.) Is that what you
meant or should I be looking at something else?

I am sorry but I don't know how to augment the source code with printf
and that is such a common term I'm not sure what to google to find
instructions for doing it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Jul 16 03:44:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 01:44:03 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1216172643.03.0.175491515468.issue3324@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In addition to what Benjamin said, the Python docs are released together
with the source, so even if the issue was corrected in the 2.5 docs now,
the correction would not show up until 2.5.3 is released, which is not
even planned before 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:06:58 2008
From: report at bugs.python.org (cfr)
Date: Wed, 16 Jul 2008 02:06:58 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216174018.55.0.908506588535.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

I figured out how to do this:

Python 2.5.2 (r252:60911, Jul 16 2008, 01:44:22) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
>>> import sys, os, locale
>>> pdb.run('locale.getpreferredencoding()')                      
> <string>(1)<module>()
(Pdb) continue
Bus error

though I'm not sure if that is what I was meant to do either. (But it
strikes me as another plausible possibility.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:29:08 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 02:29:08 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216175348.17.0.723227794237.issue3088@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Something's very strange.  The first make after configure fails to build
_multiprocessing, but a subsequent make succeeds.  I'll see if I can
capture the compilation error message.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:33:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 02:33:37 +0000
Subject: [issue3090] ARCHFLAGS parsing/concatenation in unixccompiler.py
	breaks when set to a string
In-Reply-To: <1213276584.77.0.784242980637.issue3090@psf.upfronthosting.co.za>
Message-ID: <1216175617.22.0.476553512571.issue3090@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd say go ahead.

----------
nosy: +georg.brandl
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3090>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:40:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 02:40:35 +0000
Subject: [issue3336] datetime weekday() function
In-Reply-To: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za>
Message-ID: <1216176035.07.0.840143093829.issue3336@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3336>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:41:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 16 Jul 2008 02:41:26 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1216165315.03.0.607201029491.issue2271@psf.upfronthosting.co.za>
Message-ID: <487D5FD3.2010608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'd be happy to provide any more information that can help get this
> resolved.

Contribution of a patch would be the best way to resolve this quickly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:48:51 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 16 Jul 2008 02:48:51 +0000
Subject: [issue3371] 2to3 fails in Python 2.6
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216176531.81.0.260283376952.issue3371@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Reverting r64742 would have had the same effect (IMO, it shouldn't have
been checked in in the first place, as it causes the test suite to fail).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:52:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 02:52:00 +0000
Subject: [issue3371] 2to3 fails in Python 2.6
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216176720.2.0.0169111529115.issue3371@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

That revision caused the test suite to fail because it caused to be
actually run. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 04:54:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 16 Jul 2008 02:54:55 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216176895.59.0.772948241842.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The Python debugger (pdb) won't help here; you'ld have to use the system
debugger (gdb).

Please add the line

  printf("The value of name is %p\n", name);
  printf("It points to '%s'\n", name);

right before the call to CFStringGetCStringPtr in Modules/_localemodule.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:00:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 16 Jul 2008 03:00:27 +0000
Subject: [issue3371] 2to3 fails in Python 2.6
In-Reply-To: <1216176720.2.0.0169111529115.issue3371@psf.upfronthosting.co.za>
Message-ID: <487D6449.4010904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> That revision caused the test suite to fail because it caused to be
> actually run. :)

Right - but now you've disabled the test again, when the original
introduction of the resource lib2to3 already had the (desirable)
effect of disabling the test.

IOW, this is a duplicate of issue2969.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:06:09 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 03:06:09 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216177569.17.0.373936037939.issue3088@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Here's the 'make' output.  What's strange is that moving
_multiprocessing{_failed,}.so, the import works just fine.

building '_multiprocessing' extension
creating
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I.
-I/home/barry/projects/python/python30/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/barry/projects/python/python30/Include
-I/home/barry/projects/python/python30 -c
/home/barry/projects/python/python30/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/multiprocessing.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I.
-I/home/barry/projects/python/python30/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/barry/projects/python/python30/Include
-I/home/barry/projects/python/python30 -c
/home/barry/projects/python/python30/Modules/_multiprocessing/socket_connection.c
-o
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/socket_connection.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I.
-I/home/barry/projects/python/python30/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/barry/projects/python/python30/Include
-I/home/barry/projects/python/python30 -c
/home/barry/projects/python/python30/Modules/_multiprocessing/semaphore.c -o
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/semaphore.o
gcc -pthread -shared
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/multiprocessing.o
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/socket_connection.o
build/temp.linux-i686-3.0/home/barry/projects/python/python30/Modules/_multiprocessing/semaphore.o
-L/usr/local/lib -o build/lib.linux-i686-3.0/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: No
module named _multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:17:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 03:17:31 +0000
Subject: [issue3371] 2to3 fails in Python 2.6
In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za>
Message-ID: <1216178251.65.0.436006687277.issue3371@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

> IOW, this is a duplicate of issue2969.
and so it is.

Well, it's disabled now, so no point in arguing how.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3371>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:19:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 03:19:41 +0000
Subject: [issue2969] Test_imports fails in 2.6
In-Reply-To: <1211728751.03.0.714435224741.issue2969@psf.upfronthosting.co.za>
Message-ID: <1216178381.38.0.343663978561.issue2969@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2969>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:27:05 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 03:27:05 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1216178825.68.0.643248379701.issue3338@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Hmm, looks like this dup's 2702... Funny how two people find the same
thing within a short window of each other *sighs* so looks like it's
probably fixed. I'll test /trunk against the failing testcase below and
make sure all is OK.

D

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Wed Jul 16 05:58:10 2008
From: report at bugs.python.org (Nick Edds)
Date: Wed, 16 Jul 2008 03:58:10 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216180690.83.0.879683403342.issue3316@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Here is a working version with tests. I believe it has all the desired
functionality, but correct me if I'm wrong Brett. Also, I did not model
MAPPING as suggested by Collin because order was important in generating
tests, so I didn't think using a dictionary would be appropriate. As for
star imports, right now they aren't supported, although I don't quite
understand why they couldn't be. Also, if this looks good, could
somebody commit it for me. I don't think I have write privileges. Sorry
this took me until so late tonight to submit, I hadn't realized the high
priority it had until this morning.

Added file: http://bugs.python.org/file10903/fix_urllib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:01:53 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 04:01:53 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>


New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:

The system recursion limit seems to be wildly different in its behaviour
on 2.6/trunk versus, for example, 2.5 or 2.4, EG:

On Python 2.4:
Python 2.4.3 (#1, Dec 11 2006, 11:38:52) 
[GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> mychain = rec(998)
>>>

On Python 2.6/trunk:
Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class rec(object):
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> mychain = rec(249)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __init__
[...snip...]
  File "<stdin>", line 5, in __init__
RuntimeError: maximum recursion depth exceeded
>>>

In both cases sys.getrecursionlimit() shows 1000.

Is this behaviour intentional? It looks a lot like a regression of some
sort. It appears to be effectively 4x shorter when creating the nested
object graph.

----------
components: Interpreter Core
messages: 69758
nosy: esrever_otua
severity: normal
status: open
title: sys recursion limit a lot shorter on trunk?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:07:56 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 04:07:56 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1216181276.48.0.352523598879.issue3338@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

No, I've just tested /trunk, including r64595, and the Segmentation
fault is still present, eg:

Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.setrecursionlimit(40000)
>>> class rec(object):
...   child = None
...   def __init__(self, counter):
...     if counter > 0:
...       self.child = rec(counter-1)
... 
>>> mychain = rec(2600)
>>> from cPickle import Pickler
>>> from cStringIO import StringIO
>>> stream = StringIO()
>>> p = Pickler(stream, 1)
>>> p.dump(mychain)
Segmentation fault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:12:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 04:12:20 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216181540.83.0.519866710864.issue3373@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

A lot of crashers were fixed for 2.6 where the recursion limit was not
being used at all. That is probably what you are seeing.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:12:23 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 04:12:23 +0000
Subject: [issue2702] pickling of large recursive structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1216181543.88.0.140368071768.issue2702@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Please check issue #3338 for a dup of this issue with a testcase that
continues to fail after the application of r64595

----------
nosy: +esrever_otua

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2702>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:18:32 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 04:18:32 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216181912.22.0.137428442564.issue3373@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Hmmm, I'm not certain I agree; on 2.4/2.5 doing rec(999) hits the
recursion limit, as expected (makes sense that there would be an item or
two on the stack prior to the immediate call to rec() ). This looks more
like the interpreter is adding 4x the number of items to the stack
during the construction of the nested object, which seems pretty
surprising/broken...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 06:39:42 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 04:39:42 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216183182.34.0.935349927699.issue3316@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I got your patch and it looks good overall. I made some style changes
and upped the code reuse in some places. I am running the test suite now
before I commit.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 07:08:17 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jul 2008 05:08:17 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216184897.43.0.53847773049.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That's weird and the worst is that it is not documented. Manual says:

"If Python is built without universal newline support a mode with 'U' is
the same as normal text mode." 

but no information about what is "normal text mode" behaviour.

The way Python works that you describe is weird, but true. If developer
uses Windows platform - Unix and Windows files will be handled in the
same way, but not files from Mac platform. The worst that developer
can't know this, because he is unlikely to have any Mac files to test.

This behavior is like a long standing mine to collate Windows and Mac
Python users. Why not to fix it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Wed Jul 16 07:13:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 05:13:47 +0000
Subject: [issue3316] Proposal for fix_urllib
In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za>
Message-ID: <1216185227.95.0.640206177489.issue3316@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r65002 has the patch. Thanks, Nick!

----------
resolution:  -> accepted
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3316>
_______________________________________

From report at bugs.python.org  Wed Jul 16 07:28:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 05:28:49 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216186129.66.0.0717249563657.issue3373@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, probably the best way to find out would be to run under gdb and
see who is incrementing the recursion count.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 09:16:13 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 16 Jul 2008 07:16:13 +0000
Subject: [issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
In-Reply-To: <1213613487.11.0.64218401652.issue3122@psf.upfronthosting.co.za>
Message-ID: <1216192573.57.0.298850553424.issue3122@psf.upfronthosting.co.za>


Robert Schuppenies <okkotonushi at googlemail.com> added the comment:

Fixed in r64842.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3122>
_______________________________________

From report at bugs.python.org  Wed Jul 16 10:29:23 2008
From: report at bugs.python.org (ThomasH)
Date: Wed, 16 Jul 2008 08:29:23 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1216172643.03.0.175491515468.issue3324@psf.upfronthosting.co.za>
Message-ID: <de6ef73d0807160129h119780ecucbc5c49df33f45fe@mail.gmail.com>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

Thank you for both of your feedback. I was sure that there is a
release and deployment process in place for the docs. But if the
process doesn't allow links to be fixed on a web page, there is
probably something wrong with it. It's hard to believe you would leave
such a trivial thing unfixed, accepting hundreds or thousands of
people running into a dead end. Don't you run a link checker on the
online version? Does anybody check the web server logs for misses?

It's also hard to understand why you would treat a (flexible) online
presentation like  (inflexible) released software.

At the very least, could you fix the existing link
(http://www.python.org/doc/devel/lib/module-site.html), which is
seemingly a development URL, to redirect to the correct page?! Or does
this also interfer with policies and procedures?!

"Essence over ceremony" (after Neil Ford)

On Wed, Jul 16, 2008 at 3:44 AM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> In addition to what Benjamin said, the Python docs are released together
> with the source, so even if the issue was corrected in the 2.5 docs now,
> the correction would not show up until 2.5.3 is released, which is not
> even planned before 2.6.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3324>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Wed Jul 16 11:01:46 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jul 2008 09:01:46 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216198906.94.0.24914282055.issue3360@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>  >>> x = 0800000000000000000000.0
Urk.  That should be:

>>> x = 01000000000000000000000.0

The problem is in the parsenumber function in Python/ast.c.  The 
solution seems to be very simple:  just remove the entire branch that 
starts with
"if (s[0] == '0')";  that branch is clearly a holdover from pre-Python 
2.4 days when some octal literals were supposed to produce a negative 
int.

Now I just have to figure out where to add tests for this.  Maybe there 
should be a test_float_literal to parallel test_int_literal?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Wed Jul 16 11:42:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jul 2008 09:42:05 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216201325.82.0.521182806476.issue3360@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Now I just have to figure out where to add tests for this.

Found it.  Tests in test_compile.py.

Fixed in the trunk in r65005.  This should probably also be backported to 
2.5.

Thanks for the report, Richard!

----------
resolution:  -> fixed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Wed Jul 16 13:05:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jul 2008 11:05:12 +0000
Subject: [issue3360] Inconsistent type-deduction of decimal floating-point
In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za>
Message-ID: <1216206312.09.0.77183218817.issue3360@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in the 2.5 branch, r65007.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3360>
_______________________________________

From report at bugs.python.org  Wed Jul 16 13:20:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Jul 2008 11:20:31 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216207231.1.0.609908466679.issue3373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why was 1000 chosen in the first place? If it's just an arbitrary value
then we can bump it to 4000 so that people don't get bad surprises when
upgrading their Python.

> This looks more
> like the interpreter is adding 4x the number of items to the stack
> during the construction of the nested object, which seems pretty
> surprising/broken...

Well PyObject_Call increases the recursion count, and entering __init__
will increase it once more. That explains the 2x, not the 4x though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:21:37 2008
From: report at bugs.python.org (Dan Uznanski)
Date: Wed, 16 Jul 2008 12:21:37 +0000
Subject: [issue3374] Bisect upgrades: key/cmp/reverse, parameterized handedness
In-Reply-To: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>
Message-ID: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>


New submission from Dan Uznanski <duznanski at gmail.com>:

Attached find a unified diff that upgrades the bisect module in two 
important ways:

1. bisect and friends now understand cmp, key, and reverse, the same way 
that list.sort does.

2. bisect and insort now have parameterized handedness: instead of using 
two different functions depending on whether you want new items to show 
up before or after existing ones, bisect and insort now take a flag 
called 'right' which can change the handedness on the fly.

Currently this code fails two existing regression tests: 
test_backcompatibility, because bisect is no longer the same as 
bisect_right; and test_non_sequence, because insort now raises 
AttributeError instead of TypeError when called on an int.

Still to do, in order of priority as perceived by me:

1. A C version of the code needs to be written.

2. The error handling should be worked over by somebody with more 
knowledge than I - the regression tests assume that particular failures 
(len-only, get-only, and non-sequence) will happen with one of TypeError 
or AttributeError when in reality they may raise the other.

3. The tests for new functionality should be made more exhaustive.

4. The in-module documentation probably needs cleaning; the rst 
documentation needs my name added to it (a good deal of the existing 
writing is still Fred L Drake's, so I won't replace) and needs to have 
the "section 3.6.4" part linked to Mutable Sequence Types; I couldn't 
find an actual example of that linkage.

5. The godawful conditions in bisect should probably get cleaned up.

----------
components: Library (Lib)
files: bisect-2.7.diff
keywords: patch
messages: 69773
nosy: dan.uznanski
severity: normal
status: open
title: Bisect upgrades: key/cmp/reverse, parameterized handedness
versions: Python 2.7
Added file: http://bugs.python.org/file10904/bisect-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3374>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:33:04 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:33:04 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1216211584.02.0.655266430212.issue3139@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not blocking beta 2 because there's not enough time for the fix, but
this will definitely block beta 3.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:50:31 2008
From: report at bugs.python.org (cfr)
Date: Wed, 16 Jul 2008 12:50:31 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216212631.88.0.465220448557.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Thanks.

I couldn't get anything from gdb which wasn't already in the crash log -
likely because I don't know how to elicit the information correctly.

Output from a build with the augmented _localemodule.c:

./python.exe 
Python 2.5.2 (r252:60911, Jul 16 2008, 01:44:22) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
iType "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, locale
>>> locale.getpreferredencoding()
The value of name is 0x0
It points to '(null)'
Bus error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:54:43 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:54:43 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216212883.73.0.77921377211.issue3352@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Is anybody working on a patch for this?  Nick, I agree with you about
undesirable behavior, however if there is no patch currently under
development, I'm inclined to defer blocking until beta3.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:56:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 12:56:11 +0000
Subject: [issue3374] Bisect upgrades: key/cmp/reverse, parameterized handedness
In-Reply-To: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>
Message-ID: <1216212971.47.0.237658196404.issue3374@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3374>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:57:16 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:57:16 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

_multiprocessing.so has build problems on both OS X 10.5 and Ubuntu
Linux 8.04.  It's very strange though because there are no apparent
errors in compilation, however when the build process tries to import
the module, that fails and it gets moved to _multiprocessing_failed.so.
 Interestingly enough, a subsequent 'make' succeeds, as does just
renaming the lib back to _multiprocessing.so.

Sorry, I have no more clues than that, but see also but 3088.

----------
components: Build
messages: 69777
nosy: barry
priority: release blocker
severity: normal
status: open
title: _multiprocessing.so build problems
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:57:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:57:51 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216213071.14.0.776196834405.issue3375@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Er, make that bug 3088

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 14:58:01 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 12:58:01 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216213081.37.0.010540443544.issue3375@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
dependencies: +test_multiprocessing hangs intermittently on POSIX platforms

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:00:35 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Jul 2008 13:00:35 +0000
Subject: [issue3374] Bisect upgrades: key/cmp/reverse, parameterized handedness
In-Reply-To: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za>
Message-ID: <1216213235.83.0.349125086818.issue3374@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Issues:

1. In Py3.0, the cmp argument has been dropped completely.  It has been 
supplanted by the key function.

2. Previous feature requests for cmp/key/reverse have been rejected. 
The problem is that in a series of searches or insertions the key 
function should not be called more than once (as it is with sort), but 
the bisect functions potentially call it many times will the same 
argument.  The granularity is wrong.  Adding the cmp/key/reverse 
arguments tends to discourage correct design with a separate key table 
and a set of indexes.

3. Guido has articulated as design principle that prefer separate 
functions to having a flag, so the separate handedness functions should 
not be combined.  Also, the current design reflects typical use cases 
where an app decides on a handedness and never changes that decision.  
It would be a waste to repeated pass in a handedness argument that 
never changes.

Marking this as rejected so that you don't lose more time writing C 
versions and whatnot.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3374>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:12:05 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:12:05 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216213925.2.0.373659277368.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I don't want to change the API or any other code before we get the change 
in for issue874900 which should fix/resolve issue3088

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:13:31 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:13:31 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216214011.28.0.231197656097.issue3375@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'll try with a clean tree, but I've seen this before and I'm quite 
mystified.

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:23:30 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 13:23:30 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216213925.2.0.373659277368.issue3352@psf.upfronthosting.co.za>
Message-ID: <F5FF8512-D5CA-49CD-888C-39CCBD570358@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jul 16, 2008, at 9:12 AM, Jesse Noller wrote:

> I don't want to change the API or any other code before we get the  
> change
> in for issue874900 which should fix/resolve issue3088

What's the holdup on 874900?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:25:10 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:25:10 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216214710.81.0.711386955376.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I don't know, but I am going to ping Antoine and Greg and see if they 
don't mind me applying it as-is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:25:37 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:25:37 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216214737.34.0.22356231882.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Greg/Antoine - do you have any problem with me applying the latest patch 
as-is today?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:26:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:26:26 +0000
Subject: [issue3090] ARCHFLAGS parsing/concatenation in unixccompiler.py
	breaks when set to a string
In-Reply-To: <1213276584.77.0.784242980637.issue3090@psf.upfronthosting.co.za>
Message-ID: <1216214786.71.0.495165016809.issue3090@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This has been applied as of r65012 on trunk

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3090>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:27:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 13:27:39 +0000
Subject: [issue3376] Use Python 3 lexer for 3.0 docs
Message-ID: <1216214859.34.0.300378511478.issue3376@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl
components: Documentation, Documentation tools (Sphinx)
nosy: georg.brandl
priority: low
severity: normal
status: open
title: Use Python 3 lexer for 3.0 docs
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3376>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:29:00 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 13:29:00 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216214940.82.0.25293918734.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This should not block the release of beta 2 IMHO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:44:27 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 13:44:27 +0000
Subject: [issue3377] Invalid child node access in ast.c
In-Reply-To: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>
Message-ID: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Purify complained about reading uninitialized memory in ast.c:752 of 
two bytes which corresponds to the type field.  Looking into this, line 
750 increments i without checking that there are in fact this many 
children.
If you add the line:
assert(i < NCH(n));
after line 750 you get an assertion failure when you run 
test_keywordonlyarg in the testsuite

----------
components: Interpreter Core
messages: 69787
nosy: krisvale
severity: normal
status: open
title: Invalid child node access in ast.c
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3377>
_______________________________________

From report at bugs.python.org  Wed Jul 16 15:52:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 13:52:15 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216216335.73.0.860432343899.issue3352@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Wed Jul 16 16:07:12 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 14:07:12 +0000
Subject: [issue3378] Memory leak in pythonrun.c
In-Reply-To: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za>
Message-ID: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

In some cases, an error string generated by parsetok.c is not cleared 
by err_input().  A patch is provided.

----------
components: Interpreter Core
files: tmp5.patch
keywords: patch, patch
messages: 69788
nosy: krisvale
severity: normal
status: open
title: Memory leak in pythonrun.c
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file10905/tmp5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3378>
_______________________________________

From report at bugs.python.org  Wed Jul 16 16:10:24 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 14:10:24 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216217424.17.0.999682488276.issue3375@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Barry, I can't seem to repro this against trunk on both my Ubuntu and OS/X 
machines. If you get a chance, can you see if you can get the output from 
a make -d?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 16:35:44 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 14:35:44 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1216218944.08.0.541739805294.issue3125@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Amaury's patch is applied in r65016 to trunk, all tests pass 

This needs to be merged forward, and then Lib/multiprocessing/managers.py in py3k has to have:

      for view_type in view_types:
         copy_reg.pickle(view_type, rebuild_as_list)

changed to:

      for view_type in view_types:
         ForkingPickler.register(view_type, rebuild_as_list)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3125>
_______________________________________

From report at bugs.python.org  Wed Jul 16 17:13:22 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 15:13:22 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>


New submission from J. Pablo Fern?ndez <pupeno at pupeno.com>:

Added an option, called exit, that when set to false, will make the
tests not exit at the end. This is useful when you are doing Lisp-like
development having a REPL (interpreter/prompt) opened in Emacs and
running the tests over and over on it.
Currently, the tests will exit the interpreter, causing the in-Emacs
interpreter to close as well.
It is by default set to false, so the default behavior is still the
same. When set to true the default behavior shouldn't change much
because at the end of the tests you are going to exit anyway. The only
difference is that no exit code will be provided. There's actually
something else, because the Python test suite hangs in a test case when
this is set to true, but this should be of no concern, as default is false.

----------
components: Library (Lib)
files: add_avoid_exit_option.diff
keywords: patch
messages: 69791
nosy: pupeno
severity: normal
status: open
title: Option to not-exit on test
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10906/add_avoid_exit_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 17:21:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 15:21:00 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216221660.23.0.726674813939.issue3379@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is related to (maybe a duplicate of) #2674.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:11:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 16:11:45 +0000
Subject: [issue2969] Test_imports fails in 2.6
In-Reply-To: <1211728751.03.0.714435224741.issue2969@psf.upfronthosting.co.za>
Message-ID: <1216224705.25.0.159564687457.issue2969@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I have fixed this in r65017 and am currently merging it into the trunk
and py3k. Martin, do you still want to keep the lib2to3 resource around?

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2969>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:14:38 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 16:14:38 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216224878.56.0.962175080936.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Alas, I don't have a windows machine - I agree we should leave it open 
though

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:20:56 2008
From: report at bugs.python.org (John Williams)
Date: Wed, 16 Jul 2008 16:20:56 +0000
Subject: [issue3380] documentation for ElementTree is unusable
In-Reply-To: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>
Message-ID: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>


New submission from John Williams <jrw at pobox.com>:

The documentation for the xml.etree.ElementTree package
(http://www.python.org/doc/2.5/lib/module-xml.etree.ElementTree.html)
does not include the Element type (http://effbot.org/zone/element.htm),
making it impossible to use this package without referring to external
documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 69796
nosy: georg.brandl, jrw at pobox.com
severity: normal
status: open
title: documentation for ElementTree is unusable
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3380>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:21:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 16:21:37 +0000
Subject: [issue3380] documentation for ElementTree is unusable
In-Reply-To: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>
Message-ID: <1216225297.55.0.12628057388.issue3380@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It is found in the new docs: http://doc.python.org/dev/

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3380>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:27:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 16 Jul 2008 16:27:09 +0000
Subject: [issue3380] documentation for ElementTree is unusable
In-Reply-To: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za>
Message-ID: <1216225629.17.0.842759590314.issue3380@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Here's the link:
http://docs.python.org/dev/library/xml.etree.elementtree.html#the-element-interface

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3380>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:06:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Jul 2008 16:06:07 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216224367.77.0.750641673821.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice to test under Windows first, if you can.
Also, this bug entry should stay open until we discuss the remaining
details.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:35:28 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 16 Jul 2008 16:35:28 +0000
Subject: [issue2702] pickling of large recursive structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1216226128.19.0.68840469124.issue2702@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Thanks Darryl.

We'll continue in that issue, as the patched commited in this one did
not introduce a regression (it just didn't fix the other bug also).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2702>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:36:06 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 16 Jul 2008 16:36:06 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216226166.39.0.427927580241.issue3375@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Attached the log of 'make -d' on clean checkout of py3k branch. This is
on Ubuntu 8.04.1.

----------
nosy: +mishok13
Added file: http://bugs.python.org/file10907/make-d.log.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:37:38 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 16:37:38 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216226258.39.0.32843465287.issue3375@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Andrii gave me make -d output with the failure:

building '_multiprocessing' extension
creating build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c 
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiprocessin
g.c -o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiproces
sing.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c 
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_connect
ion.c -o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_conn
ection.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c 
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.c -o 
build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.o
gcc -pthread -shared build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiproces
sing.o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_conn
ection.o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.o 
-L/usr/local/lib -o build/lib.linux-i686-3.0/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: No 
module named _multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 18:38:48 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 16:38:48 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216226328.28.0.943914082147.issue3375@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Even with that output it's not clear what's happening during the compile 
step. Barry - is this on trunk and py3k?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:01:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 16 Jul 2008 17:01:09 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1216227669.12.0.757121008635.issue3338@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Confirmed in... 

Python 2.6b1+ (trunk:65017M, Jul 16 2008, 13:37:00) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

...with a more simple case:

"""
import sys, cPickle
sys.setrecursionlimit(10405) 

class rec(object):
    child = None
    def __init__(self, counter):
      if counter > 0:
        self.child = rec(counter-1)

mychain = rec(2600)
cPickle.dumps(mychain)
"""

Note that if we put the recursion limit in 10405 we get a segfault, but
if we put it 10404, we get a "RuntimeError: maximum recursion depth
exceeded". 

Considering that 10400 is exactly 2600 * 4, maybe this is a useful hint.

Another behaviour I got: With a recursion limit big big enough, doing
rec(1670) works ok, and rec(1671) segfaults.

And a very nasty one:

I put rec(1671) to see in which recursion limit we have the conversion
of RecursionLimit to SegFault. Testing, I tried with recursion limit in
6700, and sometimes it worked ok, and sometimes it segfaulted. Yes,
*sometimes*, :(

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:14:12 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 17:14:12 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216228452.49.0.887903501982.issue3375@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

py3k.  i think the thing to do is to try to figure out why the import is
failing even though the compilation appears to succeed.  it's the
suppressed import error that's going to be the clue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:37:37 2008
From: report at bugs.python.org (Trent Mick)
Date: Wed, 16 Jul 2008 17:37:37 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>


New submission from Trent Mick <trentm at gmail.com>:

Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86
because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).

The failure looks like this:

----------------------------
$ ./configure --enable-framework --enable-universalsdk
...
checking for log1p... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
See `config.log' for more details.
----------------------------

And the appropriate details in config.log are:
----------------------------
...
configure:21540: checking size of wchar_t
configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2  -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk  conftest.c  >&5
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
directory)
configure:21878: $? = 1
configure: program exited with status 1
configure: failed program was:
...
----------------------------

The command being run:

  gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2  -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk  conftest.c

is "$ac_link". Here is a dump of relevant variables at that point in
"configure":

------------------
LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk "
CFLAGS is "-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2"
CPPFLAGS is ""
CC is "gcc"
ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS >&5"
------------------

The problem is that r63997
(http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
added this line to "configure.in" for Mac OS X:

    CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"


That results in the failure above: "ld" complaining about
-isysroot/-syslibroot being specified twice on the command line.

Ronald,
What was the "build issue on OSX 10.4" that the was meant to be fixed.
Can it be fixed without that "configure" change to "CFLAGS"?

----------
components: Build
messages: 69805
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `./configure --enable-framework --enable-universalsdk`  fails because of change in r63997
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:45:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 17:45:13 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216230313.44.0.560973377331.issue3381@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:48:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 17:48:24 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216230504.03.0.096541662513.issue3218@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I've fixed the tests, so you can cross that one off your list. However,
the buildbots are now failing because lib2to3 takes too long to test.
How soon can we have this optimization applied?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:51:30 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 17:51:30 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216230690.12.0.132421668879.issue3379@psf.upfronthosting.co.za>


Changes by J. Pablo Fern?ndez <pupeno at pupeno.com>:


Added file: http://bugs.python.org/file10908/add_avoid_exit_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:51:37 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 17:51:37 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216230697.7.0.969985853118.issue3379@psf.upfronthosting.co.za>


Changes by J. Pablo Fern?ndez <pupeno at pupeno.com>:


Removed file: http://bugs.python.org/file10906/add_avoid_exit_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 19:52:52 2008
From: report at bugs.python.org (Nick Edds)
Date: Wed, 16 Jul 2008 17:52:52 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216230772.01.0.833814675898.issue3218@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I can hopefully have it all fixed up by tonight or tomorrow.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:11:29 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 18:11:29 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216231889.75.0.190176809611.issue3379@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Indeed this patch can be considered a fix for #2674, but, it should be
documented appropriately. Should that be in
http://docs.python.org/dev/3.0/library/unittest.html ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:25:34 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 16 Jul 2008 18:25:34 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216232734.66.0.319050532115.issue3379@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Added some documentation.

Added file: http://bugs.python.org/file10909/add_avoid_exit_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:25:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 18:25:48 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216207231.1.0.609908466679.issue3373@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807161125m6ecc6426u2cff891deb044962@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 16, 2008 at 4:20 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Why was 1000 chosen in the first place? If it's just an arbitrary value
> then we can bump it to 4000 so that people don't get bad surprises when
> upgrading their Python.
>

It was originally 10,000, but people wanted thread switches to occur more often.

>> This looks more
>> like the interpreter is adding 4x the number of items to the stack
>> during the construction of the nested object, which seems pretty
>> surprising/broken...
>
> Well PyObject_Call increases the recursion count, and entering __init__
> will increase it once more. That explains the 2x, not the 4x though.

As I said, without a comparison of traces this is continue to just be
speculation (and I don't have the time to do that).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:28:15 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Jul 2008 18:28:15 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

See http://mail.python.org/pipermail/python-dev/2008-July/081242.html
for the discussion.  Basically, 'F' did the same as 'f' because it was
assumed that neither would ever produce an exponent.  But they do, for
numbers greater than about 1e50.  Also, 'F' should produce 'NAN' for
cases where 'f' produces 'nan'.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 69811
nosy: eric.smith
severity: normal
status: open
title: Make '%F' and float.__format__('F') convert results to upper case.
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:28:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 18:28:19 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216232899.89.0.0423503023457.issue3373@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett:
>It was originally 10,000, but people wanted thread switches to occur
>more often.

I thought that was managed by sys.setcheckinterval.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:30:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 18:30:43 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216232899.89.0.0423503023457.issue3373@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807161130h16ff251crde9ddc51ef472ba6@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 16, 2008 at 11:28 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Brett:
>>It was originally 10,000, but people wanted thread switches to occur
>>more often.
>
> I thought that was managed by sys.setcheckinterval.
>

Yes it is; sorry, brain is slow today.

I know the current value usually does not lead to a segfault on any of
the common platforms that Python runs on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:31:53 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 16 Jul 2008 18:31:53 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

ctypes.util assumes several things of its environment which sometimes
don't hold:

  * It depends on objdump being in $PATH.  If it isn't, it will fail to
read the SONAME from a library, even if it has determined the path to it.
  * If it uses ldconfig (which, unlike objdumb, it assumes it knows the
full path to and doesn't rely on $PATH to find), it fails to interpret
the results because the regular expression it applies doesn't define any
groups.

The attached patch is what I used to work around these issues in one
particular environment.  I don't claim the fixes to be general, and the
patch includes no unit tests.

----------
assignee: theller
components: ctypes
files: ctypes-util.patch
keywords: patch
messages: 69814
nosy: exarkun, theller
severity: normal
status: open
title: ctypes.util fails to find libc in some environments
versions: Python 2.5
Added file: http://bugs.python.org/file10910/ctypes-util.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:31:55 2008
From: report at bugs.python.org (Joshua Kugler)
Date: Wed, 16 Jul 2008 18:31:55 +0000
Subject: [issue3384] Documentation for re.findall and re.finditer lacks
	"ordering" information
In-Reply-To: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>
Message-ID: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>


New submission from Joshua Kugler <jkugler at bigfoot.com>:

According to a discussion on comp.lang.python, re.findall and 
re.finditer scan strings from left to right, and returns them in the 
order it found them.  It would be nice to note that in documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 69815
nosy: georg.brandl, jkugler
severity: normal
status: open
title: Documentation for re.findall and re.finditer lacks "ordering" information
type: feature request
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3384>
_______________________________________

From report at bugs.python.org  Wed Jul 16 20:45:41 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 16 Jul 2008 18:45:41 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1216233941.1.0.0713099487595.issue3338@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:01:37 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 19:01:37 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

I was attempting the patch for issue3125 to py3k, and in it Amaury 
defines a new ForkingPickler:

from pickle import Pickler
class ForkingPickler(Pickler):
    dispatch = Pickler.dispatch.copy()

This is also related to issue3350 I suspect. However, using the 
pickle.Pickler module under py3k, there is no dispatch() method on the 
class:

Trunk:
Python 2.6b1+ (trunk:65015M, Jul 16 2008, 10:15:51) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> dir(pickle.Pickler)
['_BATCHSIZE', '__doc__', '__init__', '__module__', '_batch_appends', 
'_batch_setitems', 'clear_memo', 'dispatch', 'dump', 'get', 'memoize', 
'persistent_id', 'put', 'save', 'save_bool', 'save_dict', 
'save_empty_tuple', 'save_float', 'save_global', 'save_inst', 
'save_int', 'save_list', 'save_long', 'save_none', 'save_pers', 
'save_reduce', 'save_string', 'save_tuple', 'save_unicode']
>>> 

py3k:
Python 3.0b1+ (py3k:65011M, Jul 16 2008, 11:50:11) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> dir(Pickler)
['__class__', '__delattr__', '__doc__', '__eq__', '__format__', 
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', 
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 
'bin', 'clear_memo', 'dump', 'fast', 'memo', 'persistent_id']

I think the fix for 3125 resolves your complaint in 3350, but is the 
lack of the dispatch method intentional?

----------
assignee: alexandre.vassalotti
components: Extension Modules
messages: 69816
nosy: alexandre.vassalotti, jnoller
severity: normal
status: open
title: cPickle to pickle conversion in py3k missing methods
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:20:32 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:20:32 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216236032.35.0.371487389362.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is rather annoying, gcc doesn't accept multipe -isysroot flags on 
10.4, yet we need to specify -isysroot during configure to ensure that 
tests are done using the right SDK, otherwise most of configure will use 
the system headers instead of the SDK specified using the --enable-
universalsdk option.

I'm currently trying to teach configure to only add -isysroot to the 
configure-time CFLAGS when the OS version is 10.5 or later, because 
that's the only platform where -isysroot is really needed in the 
configure-time CFLAGS.

The patch should be ready later tonight, I'll post it here instead of 
committing to avoid interfering with the release process.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:21:19 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 19:21:19 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1216236079.29.0.71010378412.issue3125@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Here is a proposed patch for py3k generated from an svn merge of amaury's 
patch into py3k. This is currently blocked due to issue3385.

Added file: http://bugs.python.org/file10911/py3k_no_copyreg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3125>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:26:37 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 19:26:37 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216236397.0.0.499993397945.issue3375@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:31:13 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:31:13 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216236673.54.0.0172019955037.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

configure-patch-3381.txt should fix the issue, but I cannot test on 10.4 
as I recently had to convert my only 10.4 machine to 10.5.

Added file: http://bugs.python.org/file10912/configure-patch-3381.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:36:35 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:36:35 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216236995.42.0.329534440917.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Note to self: never rush a patch

configure-patch-3881-1.txt is the better patch, the other looks right but 
using square brackets which don't survive autoconf.

BTW. the patch is only for configure.in, run autoconf to update the actual 
configure script.

Added file: http://bugs.python.org/file10913/configure-patch-3381-1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:37:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 16 Jul 2008 19:37:44 +0000
Subject: [issue2969] Test_imports fails in 2.6
In-Reply-To: <1216224705.25.0.159564687457.issue2969@psf.upfronthosting.co.za>
Message-ID: <487E4E05.2010204@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I have fixed this in r65017 and am currently merging it into the trunk
> and py3k. Martin, do you still want to keep the lib2to3 resource around?

Last I tried, running test_import still took a very long time
(issue2968). If that was fixed, the resource would not be needed
anymore. OTOH, if it's only me complaining about this issue, it's
ok to remove the resource even without fixing the issue first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2969>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:39:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 19:39:33 +0000
Subject: [issue2969] Test_imports fails in 2.6
In-Reply-To: <1211728751.03.0.714435224741.issue2969@psf.upfronthosting.co.za>
Message-ID: <1216237173.11.0.266756505914.issue2969@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I understand that #3218 helps test_import a lot, so once that patch is
when I'll remove the resource.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2969>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:50:27 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:50:27 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216237827.28.0.519511524178.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Yet another version: configure-patch-3381-2.txt is a slight enhancement 
of the first version.

This version also moves the calculation of MACOSX_DEPLOYMENT_TARGET a 
lot 
earlier in configure.in, to ensure that the right value is active 
whenever
the compiler is used.

This turns out to be necessary to build using the 10.4 SDK on OSX 10.5.

BTW. Feel free to commit if the patch works for you, I'm rather swamped 
at work and won't be able to test on 10.4 anytime soon.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:58:23 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:58:23 +0000
Subject: [issue3226] can't install on OSX 10.4
In-Reply-To: <1214671532.34.0.878967964042.issue3226@psf.upfronthosting.co.za>
Message-ID: <1216238303.04.0.482604086967.issue3226@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch should fix this issue. I cannot test on 10.4 though.

BTW. The patch only updates configure.in, run autoconf afterwards to 
update the configure script itself.

Added file: http://bugs.python.org/file10914/configure-patch-3226.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3226>
_______________________________________

From report at bugs.python.org  Wed Jul 16 21:58:48 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 19:58:48 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216238328.11.0.482355446973.issue3381@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
priority:  -> deferred blocker
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:05:15 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 16 Jul 2008 20:05:15 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216238715.68.0.28176154805.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've applied Greg's patch in 65032 on trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:18:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 20:18:21 +0000
Subject: [issue3226] can't install on OSX 10.4
In-Reply-To: <1214671532.34.0.878967964042.issue3226@psf.upfronthosting.co.za>
Message-ID: <1216239501.26.0.225628161605.issue3226@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r65033.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3226>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:24:13 2008
From: report at bugs.python.org (Trent Mick)
Date: Wed, 16 Jul 2008 20:24:13 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216237827.28.0.519511524178.issue3381@psf.upfronthosting.co.za>
Message-ID: <6db0ea510807161324xcf94c6ckd304e588101b7a75@mail.gmail.com>


Trent Mick <trentm at gmail.com> added the comment:

> BTW. Feel free to commit if the patch works for you, I'm rather swamped
> at work and won't be able to test on 10.4 anytime soon.

Thanks for the quick patches. Other than verifying that `configure &&
make` works on 10.4 what specifically should I do "to ensure that
tests are done using the right SDK" (as you said in an earlier
comment)?

----------
title: `./configure --enable-framework --enable-universalsdk`  fails because of change in r63997 -> `./configure --enable-framework --enable-universalsdk` fails because of change in r63997

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:30:56 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jul 2008 20:30:56 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216240256.38.0.87982261786.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The easiest way to test the configure bits would be to build on 10.5 with 
--enable-universalsdk and --enable-universalsdk=/. Both should work on 
10.5, while using different SDKs (with slightly different unix APIs).


However: it shouldn't be necessary to test that specific bit, I introduced 
issue3381 when I fixed the "configure should use the right CFLAGS" issue 
for 10.5 and my patch for issue3381 doesn't change the compiler flags on 
10.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:40:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 20:40:53 +0000
Subject: [issue1366] popen spawned process may not write to stdout under
	windows
In-Reply-To: <1193824783.73.0.865697244253.issue1366@psf.upfronthosting.co.za>
Message-ID: <1216240853.52.0.656626676808.issue1366@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Did you want to close this, Sean?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1366>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:53:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jul 2008 20:53:23 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216241603.72.0.627556443915.issue3369@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Does this also apply to 2.6?

Looks like it doesn't.  :-).

The patch needs to touch the newly arrived
comparison with "infinity", as well as the
"inf" and "nan" comparisons.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:53:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 20:53:55 +0000
Subject: [issue2138] Add a factorial function
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1216241635.37.0.529004301702.issue2138@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That was fixed by Raymond in 64365.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
_______________________________________

From report at bugs.python.org  Wed Jul 16 22:57:22 2008
From: report at bugs.python.org (Trent Mick)
Date: Wed, 16 Jul 2008 20:57:22 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216237827.28.0.519511524178.issue3381@psf.upfronthosting.co.za>
Message-ID: <6db0ea510807161357r1e00b7fk4a350c5bbd468bfb@mail.gmail.com>


Trent Mick <trentm at gmail.com> added the comment:

> Yet another version: configure-patch-3381-2.txt is a slight enhancement
> of the first version.

Ronald,
Did that accidentally not get attached?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:04:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 16 Jul 2008 21:04:10 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216242250.45.0.189959079579.issue3375@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Okay, I have more information, but still no diagnosis.  I stuck a
'raise' in the setup.py so that when the ImportError occurs, it doesn't
get swallowed.  Instead it stops the build process in its tracks.  The
attached file contains the relevant output.

Added file: http://bugs.python.org/file10915/3375.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:06:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:06:01 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1216242361.61.0.499336590968.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this is under consideration.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:08:58 2008
From: report at bugs.python.org (Florian Mayer)
Date: Wed, 16 Jul 2008 21:08:58 +0000
Subject: [issue3310] Out-of-date example 3.0b1 Tutorial Classes page,
	'issubclass'
In-Reply-To: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>
Message-ID: <1216242538.66.0.758652449792.issue3310@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

This patch removes incompatibility to Python 3.0, though it also removes
the "common ancestor" part.

----------
keywords: +patch
nosy: +segfaulthunter
Added file: http://bugs.python.org/file10916/classes.txt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3310>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:10:54 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 16 Jul 2008 21:10:54 +0000
Subject: [issue3386] distutils.sysconfig.get_python_lib prefix argument broken
In-Reply-To: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za>
Message-ID: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

get_python_lib supports an optional prefix argument:

    If 'prefix' is supplied, use it instead of sys.prefix or
    sys.exec_prefix -- i.e., ignore 'plat_specific'.

However the NT and OS2 platforms don't use the prefix argument when 
specified.

This problem was brought up a while ago here: http://mail.python.org/pipermail/distutils-sig/2002-November/003099.html

Andrew (the OS2 maintainer) claimed in the thread that fixing this would 
break OS2, but I don't see how. All callers of get_python_lib in the 
stdlib don't specify a prefix anyway. Anyone calling it with a prefix 
and expecting it not to be used is broken.

----------
components: Distutils
files: get_python_lib-r65033.diff
keywords: patch
messages: 69836
nosy: pjenvey
severity: normal
status: open
title: distutils.sysconfig.get_python_lib prefix argument broken
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10917/get_python_lib-r65033.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3386>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:12:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:12:02 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1216242722.13.0.138734313931.issue2874@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't like the name "os.stats". The os module is already so full of
constants and functions that one could argue the few from stat won't
hurt anymore :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:19:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:19:38 +0000
Subject: [issue3045] Windows online help broken when spaces in TEMP environ
In-Reply-To: <1212721889.56.0.323857297959.issue3045@psf.upfronthosting.co.za>
Message-ID: <1216243178.21.0.237061610326.issue3045@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65035.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3045>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:21:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:21:40 +0000
Subject: [issue3310] Out-of-date example 3.0b1 Tutorial Classes page,
	'issubclass'
In-Reply-To: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za>
Message-ID: <1216243300.34.0.141111265563.issue3310@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r65036, thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3310>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:31:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:31:52 +0000
Subject: [issue1608818] Sloppy error checking in listdir() for Posix
Message-ID: <1216243912.4.0.863039914717.issue1608818@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65037.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1608818>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:32:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 21:32:14 +0000
Subject: [issue3115] os.listdir randomly fails on occasions when it shouldn't
In-Reply-To: <1213483378.87.0.0889155831871.issue3115@psf.upfronthosting.co.za>
Message-ID: <1216243934.09.0.72687806521.issue3115@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed patch in #1608818 in r65037.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3115>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:40:00 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Wed, 16 Jul 2008 21:40:00 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1216244400.05.0.912777252752.issue3338@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

That is a very interesting observation (x4), especially in light of #3373

Unfortunately I don't really have the (p|g)db -foo to debug either of
these properly :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Wed Jul 16 23:57:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jul 2008 21:57:46 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1216242722.13.0.138734313931.issue2874@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807161457u5517cb5j41c83c63a8595f9c@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 16, 2008 at 2:12 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> I don't like the name "os.stats". The os module is already so full of
> constants and functions that one could argue the few from stat won't
> hurt anymore :)
>

Yeah, I was thinking it might work out to just deprecate the functions
and leave the module around for the constants.

-Brett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:04:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:04:29 +0000
Subject: [issue3305] Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec
	and MultibyteStreamReader
In-Reply-To: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za>
Message-ID: <1216245869.68.0.996003365538.issue3305@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65038.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3305>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:05:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:05:15 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216245915.68.0.160068486945.issue3359@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This behavior is inherited from the C-level fopen() and therefore
"normal text mode" is whatever that defines.

Is this really nowhere documented?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:05:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:05:37 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1216245937.01.0.650722907571.issue2874@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why deprecate the functions then?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:09:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:09:28 +0000
Subject: [issue3345] Patch for CGIHTTPServer.is_cgi function documentation
In-Reply-To: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za>
Message-ID: <1216246168.48.0.246539596264.issue3345@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65039.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3345>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:14:04 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:14:04 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
Message-ID: <1216246444.62.0.728465967647.issue3318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I disagree. An ideal machine is not useful in practice, so any assertion
about it isn't helpful.

In that light, the snippet is correct in saying that if execution of a
snippet is done enough times, the lowest value is a lower bound for
execution speed.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:24:36 2008
From: report at bugs.python.org (Florian Mayer)
Date: Wed, 16 Jul 2008 22:24:36 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1216247076.89.0.887280720635.issue3288@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

I tried to include the method in the Python 3.0 Tutorial but also to
mention problems with floating point arithmetic that express in
returning different numbers than what one entered.

----------
keywords: +patch
nosy: +segfaulthunter
Added file: http://bugs.python.org/file10918/issue3288.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:33:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:33:36 +0000
Subject: [issue3312] bugs in _sqlite module
In-Reply-To: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za>
Message-ID: <1216247616.33.0.0381049043797.issue3312@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65040.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3312>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:35:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 22:35:17 +0000
Subject: [issue988761] re.split emptyok flag (fix for #852532)
Message-ID: <1216247717.18.0.748490147589.issue988761@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as a duplicate of #3262, which seems to be active.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue988761>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:41:00 2008
From: report at bugs.python.org (Mike Coleman)
Date: Wed, 16 Jul 2008 22:41:00 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1216248060.17.0.930151059858.issue3262@psf.upfronthosting.co.za>


Mike Coleman <mkc at users.sourceforge.net> added the comment:

I think it's probably both.  The original design was incorrect, though
this probably wasn't apparent to the designer.  But as a significant
user of 're', it really stands out as a problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Thu Jul 17 00:59:43 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Jul 2008 22:59:43 +0000
Subject: [issue3387] undefined array passed to CryptGenRandomBytes
In-Reply-To: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>
Message-ID: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The CryptGenRandomBytes uses whatever data is already in the buffer as 
seed for the output.  So, the buffer is effectively an in/out buffer.  
Now, since we are generating random data anyway, the fact that we are 
using an undefined seed for the data shouldn't matter.  However, this 
does create a bunch of false positives for analysis tools such as 
Purify, that track the copying and usage of uninitialized data.
An easy patch is to clear the buffer before submitting it to 
CryptGenRandomBytes, and is attached.

----------
components: Interpreter Core
files: tmp6.patch
keywords: easy, patch, patch
messages: 69853
nosy: krisvale
severity: normal
status: open
title: undefined array passed to CryptGenRandomBytes
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10919/tmp6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3387>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:10:45 2008
From: report at bugs.python.org (Florian Mayer)
Date: Wed, 16 Jul 2008 23:10:45 +0000
Subject: [issue3388] With keyword not mentioned in Input Output tutorial
In-Reply-To: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za>
Message-ID: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think that the Python 3.0 Tutorial should show the reader that the
with keyword is an excellent way of reading data from a file and closing
it afterwards, even if exceptions occur.

----------
assignee: georg.brandl
components: Documentation
files: with_tutorial.patch
keywords: patch
messages: 69854
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: With keyword not mentioned in Input Output tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file10920/with_tutorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3388>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:28:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 23:28:15 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216250895.88.0.889592359359.issue3218@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can we expect this in the next 2 hours? It's fine if not, I just need to
know whether the 2to3 tests should be disabled for the beta.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:32:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 23:32:47 +0000
Subject: [issue3156] bytes type has inconsistent methods (append, insert)
In-Reply-To: <1214004899.96.0.722439580753.issue3156@psf.upfronthosting.co.za>
Message-ID: <1216251167.86.0.451615211469.issue3156@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in 2.6 r65041, and 3k r65043.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3156>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:36:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jul 2008 23:36:20 +0000
Subject: [issue3388] With keyword not mentioned in Input Output tutorial
In-Reply-To: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za>
Message-ID: <1216251380.79.0.479552821107.issue3388@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed a similar patch in r65048.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3388>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:38:49 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 16 Jul 2008 23:38:49 +0000
Subject: [issue3389] [PATCH] Allow custom logging Handlers in logging config
	files
In-Reply-To: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>
Message-ID: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

Python 2.5 added support for specifying a custom logging Formatter class 
in logging configuration files. Handler classes can also be specified, 
but your choice is limited to classes that live in the logging module. 

A current workaround this is to manually add your custom Handler class 
to the logging module prior to loading the logging config file, but then 
you're no longer driving logging configuration purely from a config file 
(which is the entire point). This is particularly important for apps 
that are driven entirely from a config file that also includes logging 
information (such as Pylons applications)

The following patch will cause Handler classes to be resolved just like 
Formatter classes if the check for the Handler class in the logging 
module fails.

FYI this patch has been used in Paste (in particular for Pylons apps) 
for over a year so I consider it stable

----------
components: Library (Lib)
files: logging-custom-Handler_r65033.diff
keywords: patch
messages: 69858
nosy: pjenvey, vsajip
severity: normal
status: open
title: [PATCH] Allow custom logging Handlers in logging config files
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10921/logging-custom-Handler_r65033.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3389>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:40:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Jul 2008 23:40:10 +0000
Subject: [issue3389] [PATCH] Allow custom logging Handlers in logging config
	files
In-Reply-To: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>
Message-ID: <1216251610.36.0.978625961257.issue3389@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


----------
assignee:  -> vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3389>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:51:31 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 16 Jul 2008 23:51:31 +0000
Subject: [issue3386] [PATCH] distutils.sysconfig.get_python_lib prefix
	argument broken
In-Reply-To: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za>
Message-ID: <1216252291.14.0.00170330639421.issue3386@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at users.sourceforge.net>:


----------
title: distutils.sysconfig.get_python_lib prefix argument broken -> [PATCH] distutils.sysconfig.get_python_lib prefix argument broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3386>
_______________________________________

From report at bugs.python.org  Thu Jul 17 01:58:07 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 16 Jul 2008 23:58:07 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216252687.64.0.943278134342.issue3373@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Darryl, was your trunk version built as debug?  If so, can you try 
without?

----------
nosy: +Trent.Nelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Jul 17 02:05:22 2008
From: report at bugs.python.org (cfr)
Date: Thu, 17 Jul 2008 00:05:22 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216253122.77.0.414558338197.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

On the off chance this might be helpful:

I get the same error with python 2.4.3.

Python 2.4.3 (#1, Apr  7 2006, 10:54:33) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, locale
>>> locale.getpreferredencoding()
Bus error

I do not get the error with the Apple-supplied python 2.3.5:

Python 2.3.5 (#1, Mar 20 2005, 20:38:20) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, locale
>>> locale.getpreferredencoding()
'US-ASCII'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Thu Jul 17 02:53:20 2008
From: report at bugs.python.org (Nick Edds)
Date: Thu, 17 Jul 2008 00:53:20 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216256000.58.0.580802570478.issue3218@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

It should be done tonight, but probably not until around 11 central
time. Sorry for the delay.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Thu Jul 17 03:01:37 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 17 Jul 2008 01:01:37 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216148745.81.0.952117625519.issue3359@psf.upfronthosting.co.za>
Message-ID: <18558.39404.884345.328631@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

anatoly> If you open file with 'r' - all line endings will be mapped
    anatoly> precisely to '\n' anyways, so it has nothing to do with 'U'
    anatoly> mode.

Before 3.0 at least, if you copy a text file from, say, Windows to Mac, and
open it with 'r', you get lines which end in '\r\n'.  Here's a simple
example:

    >>> open("dos.txt", "rb").read()
    'a single line\r\nanother line\r\n'
    >>> f = open("dos.txt")
    >>> f.next()
    'a single line\r\n'
    >>> f = open("dos.txt", "r")
    >>> f.next()
    'a single line\r\n'
    >>> f.next()
    'another line\r\n'

If, on the other hand, you open it with 'rU', the '\r\n' literal line ending
is converted, even though CRLF is not the canonical Mac line ending:

    >>> f = open("dos.txt", "rU")
    >>> f.next()
    'a single line\n'
    >>> f.next()
    'another line\n'

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 17 03:18:44 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Thu, 17 Jul 2008 01:18:44 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216257524.01.0.390590016566.issue3373@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Hi Trent,

No, my build did not invoke --with-pydebug. In other words, the process
I used was simply:

svn co http://svn.python.org/projects/python/trunk python-trunk
cd python-trunk
./configure --prefix=/home/dixond/throwaway
make
make install

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Jul 17 03:56:52 2008
From: report at bugs.python.org (Nick Edds)
Date: Thu, 17 Jul 2008 01:56:52 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216259812.29.0.430149781635.issue3218@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Sorry I couldn't have this done earlier today. I updated the test suite,
and this is now passing all tests. Collin, could you verify that is has
all the functionality you were expecting? If the member functionality
turns out to actually be important for any of the modules in
fix_imports, it probably makes the most sense to break them out into
their own fixer. As an added note, I think there is still further room
to optimize fix_imports, specifically the very large pattern it still
generates, so I'm going to work on that at some point.

Added file: http://bugs.python.org/file10922/fix_imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Thu Jul 17 04:05:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 02:05:28 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1216260328.33.0.460995909068.issue3218@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Thanks very much for getting this done! I checked in the changes in
r65053, so they can make beta 2. I'm leaving the issue open, though, in
case Collin wants to make more changes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Thu Jul 17 04:34:00 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 17 Jul 2008 02:34:00 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216262040.19.0.914178347556.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The omission of the dispatch dictionary was sort of intentional. But 
now, I think it would be a good idea to add it to _pickle.Pickler. I 
will write a patch ASAP.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Thu Jul 17 05:21:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Jul 2008 03:21:34 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216264894.18.0.823244011574.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I added a Misc/NEWS note for this in r65057.


This is a good candidate for backporting to release25-maint.


To answer Antoine Pitrou's question about using the old ident vs the new
_get_ident().  I don't know if the forked process will have the same
thread id.  I expect so.  If not, the code as recently committed will
die on an assertion failure because current_thread() is simply an
_active[_get_ident()] dict lookup that returns a DummyThread instance if
the lookup fails.


As for Windows, Windows doesn't support os.fork and I don't see any
calls to PyOS_AfterFork outside of the Modules/posixmodule.c.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 05:23:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 03:23:43 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216265023.11.0.965686384238.issue874900@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Can somebody also merge this into Py3k, please?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 06:47:50 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 04:47:50 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216270070.01.0.582759337604.issue3375@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

When a second 'make' fixes things, that usually means that there's a
dependency on another extension that is built later in the normal build
sequence. I vaguely we had this before and fixed it by reordering things.

Grepping the sources of _multiprocessing for Import, I wonder if it
could be _pickle?  Or something that _pickle imports?  (Since _pickle
seems to be built before _multiprocessing.)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Thu Jul 17 06:51:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 04:51:20 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216270280.39.0.388795072151.issue3375@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Here is the output of python -v during "import _multiprocessing". Maybe
this gives someone a clue?

>>> import _multiprocessing
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so",
2);
# /Users/guido/p3/Lib/pickle.pyc matches /Users/guido/p3/Lib/pickle.py
import pickle # precompiled from /Users/guido/p3/Lib/pickle.pyc
import marshal # builtin
# /Users/guido/p3/Lib/struct.pyc matches /Users/guido/p3/Lib/struct.py
import struct # precompiled from /Users/guido/p3/Lib/struct.pyc
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_struct.so", 2);
import _struct # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_struct.so
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/binascii.so", 2);
import binascii # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/binascii.so
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_pickle.so", 2);
import _pickle # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_pickle.so
import multiprocessing # directory /Users/guido/p3/Lib/multiprocessing
# /Users/guido/p3/Lib/multiprocessing/__init__.pyc matches
/Users/guido/p3/Lib/multiprocessing/__init__.py
import multiprocessing # precompiled from
/Users/guido/p3/Lib/multiprocessing/__init__.pyc
# /Users/guido/p3/Lib/multiprocessing/process.pyc matches
/Users/guido/p3/Lib/multiprocessing/process.py
import multiprocessing.process # precompiled from
/Users/guido/p3/Lib/multiprocessing/process.pyc
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/itertools.so", 2);
import itertools # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/itertools.so
import _multiprocessing # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so
import _multiprocessing # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so
>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Thu Jul 17 06:59:12 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 17 Jul 2008 04:59:12 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216270752.05.0.582927580854.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Forgot to upload updated patch

Added file: http://bugs.python.org/file10923/configure-patch-3381-2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Thu Jul 17 07:06:29 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 05:06:29 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216271189.32.0.820251722471.issue3375@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The order thing was a red herring.  However, I understand what's going
on now.  Somebody else can fix it hopefully.

So what's going on:  In the Python instance that runs setup.py,
importing _multiprocessing fails.  But if I start a new Python instance
in exactly the same environment, it works.  Why?  Because at the *start*
of running setup.py, the directory .../build/lib.macosx-10.3-i386-3.0
doesn't exist, and this is being cached in sys.path_importer_cache,
which has a NullImporter instance for that key.  Maybe the solution is
to remove that cache entry (if it exists) in the code that creates that
directory?

I found this by (a) disabling the two except clauses in setup.py that
catch exceptions from the attempt to import the module that was just
built, and (b) adding a -i flag to the Python instance invoked by the
Makefile to run setup.py.  This gave me an interactive interpreter at
the moment the "import _multiprocessing" failed.  Poking around I could
see that sys.path_importer_cache had a NullImporter instance for the
directory from which _multiprocessing.so was to be imported.  I could
even delete that cache entry, and then the import would pass!

Good luck fixing...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Thu Jul 17 07:29:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jul 2008 05:29:49 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1216245937.01.0.650722907571.issue2874@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807162229s9dd6059w40414383c77884a0@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 16, 2008 at 3:05 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Why deprecate the functions then?
>

If they are made into methods on the object returned by os.stat(),
what is the point of having them around? Or are you suggesting to skip
adding the methods?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Thu Jul 17 07:40:22 2008
From: report at bugs.python.org (Ron Longo)
Date: Thu, 17 Jul 2008 05:40:22 +0000
Subject: [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1216273222.84.0.351120638053.issue2638@psf.upfronthosting.co.za>


Ron Longo <ron.longo at cox.net> added the comment:

Correct.  overrideredirect only enables/disables borders.  However, 
what appears as a "flash" when the dialog box first appears is actually 
a window with only borders being drawn (no contents).  Disabling 
borders BEFORE drawing anything prevents this "flash".  I cannot say if 
this "flash" occurs on all platforms, but it does occur on all windows 
XP platforms that I've tried it on.  In each of these cases the "fixed" 
tkSimpleDialog.py prevents this "flash".  While not vital to 
application reliability, this fix does make applications appear more 
professional.

----------
nosy: +ronlongo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2638>
_______________________________________

From report at bugs.python.org  Thu Jul 17 07:45:58 2008
From: report at bugs.python.org (Ron Longo)
Date: Thu, 17 Jul 2008 05:45:58 +0000
Subject: [issue1230] Tix HList class missing method implementation for
	info_bbox
In-Reply-To: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za>
Message-ID: <1216273558.0.0.401100472375.issue1230@psf.upfronthosting.co.za>


Changes by Ron Longo <ron.longo at cox.net>:


Added file: http://bugs.python.org/file10924/Tix.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230>
_______________________________________

From report at bugs.python.org  Thu Jul 17 08:30:26 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jul 2008 06:30:26 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1216276226.12.0.689573551878.issue3341@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Any links to alpha code?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Thu Jul 17 08:46:42 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jul 2008 06:46:42 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216277202.96.0.794644992496.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> This behavior is inherited from the C-level fopen() and therefore
> "normal text mode" is whatever that defines.

> Is this really nowhere documented?

Relation to fopen() function may be documented, but there is no
explanation of what "normal text mode" is. Is it really pythonic that a
script writer without former experience with C, stdio and fopen should
be aware of inherited fopen "behavior" when programming Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 17 09:41:41 2008
From: report at bugs.python.org (engelbert gruber)
Date: Thu, 17 Jul 2008 07:41:41 +0000
Subject: [issue3390] [PATCH] replace last has_key in unittest by in operator
In-Reply-To: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>
Message-ID: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>


New submission from engelbert gruber <grubert at users.sourceforge.net>:

take the line from python-3

----------
components: Library (Lib)
files: lib_unittest-r65058
messages: 69877
nosy: grubert
severity: normal
status: open
title: [PATCH] replace last has_key in unittest by in operator
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10925/lib_unittest-r65058

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3390>
_______________________________________

From report at bugs.python.org  Thu Jul 17 11:02:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 09:02:22 +0000
Subject: [issue874900] threading module can deadlock after fork
In-Reply-To: <1216264894.18.0.823244011574.issue874900@psf.upfronthosting.co.za>
Message-ID: <1216285330.487f0a925585a@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon "Gregory P. Smith" <report at bugs.python.org>:
>
> To answer Antoine Pitrou's question about using the old ident vs the new
> _get_ident().  I don't know if the forked process will have the same
> thread id.

Then wouldn't it be safer to use _get_ident() rather than re-using the old
thread ID? It doesn't make the code any more complicated as far as I know :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 11:51:56 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 17 Jul 2008 09:51:56 +0000
Subject: [issue3391] Idle uses old showwarning signature
In-Reply-To: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za>
Message-ID: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <okkotonushi at googlemail.com>:

Idle does not use the 'line' argument for its showwarning function. This
results in the DeprecationWarning "functions overriding
warnings.showwarning() must support the 'line' argument", or, when
called from within Idle "TypeError: idle_formatwarning_subproc() takes
exactly 4 arguments (5 given)".

The error can be reproduced from within Idle as well as demonstrated
with verify.py.

The attached patch applies the behavior of the default warnings
implementation.

----------
components: IDLE
files: idle.patch
keywords: patch
messages: 69879
nosy: brett.cannon, schuppenies
priority: normal
severity: normal
status: open
title: Idle uses old showwarning signature
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10926/idle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3391>
_______________________________________

From report at bugs.python.org  Thu Jul 17 11:53:23 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 17 Jul 2008 09:53:23 +0000
Subject: [issue3391] Idle uses old showwarning signature
In-Reply-To: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za>
Message-ID: <1216288403.88.0.782210192421.issue3391@psf.upfronthosting.co.za>


Changes by Robert Schuppenies <okkotonushi at googlemail.com>:


Added file: http://bugs.python.org/file10927/verify.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3391>
_______________________________________

From report at bugs.python.org  Thu Jul 17 13:25:41 2008
From: report at bugs.python.org (=?utf-8?q?Mattias_Engdeg=C3=A5rd?=)
Date: Thu, 17 Jul 2008 11:25:41 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>


New submission from Mattias Engdeg?rd <yorick at users.sourceforge.net>:

If the stdin/out file descriptors are too large to be used with
select(), subprocess will fail in .communicate(). Example:

# raise the fd limit to something like 2048 before running this
import subprocess
somefiles = [open("/etc/passwd") for i in xrange(2000)]
print subprocess.Popen(["date"], stdout=subprocess.PIPE).communicate()

The solution would be to use select.poll() in subprocess instead.

----------
components: Library (Lib)
messages: 69880
nosy: yorick
severity: normal
status: open
title: subprocess fails in select when descriptors are large
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Thu Jul 17 16:03:55 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Thu, 17 Jul 2008 14:03:55 +0000
Subject: [issue3377] Invalid child node access in ast.c
In-Reply-To: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>
Message-ID: <1216303435.97.0.572189976199.issue3377@psf.upfronthosting.co.za>


Changes by Jeremy Hylton <jeremy at alum.mit.edu>:


----------
assignee:  -> jhylton
nosy: +jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3377>
_______________________________________

From report at bugs.python.org  Thu Jul 17 16:05:05 2008
From: report at bugs.python.org (Chester)
Date: Thu, 17 Jul 2008 14:05:05 +0000
Subject: [issue3364] An ortographical typo in Zen of Python text
In-Reply-To: <1216150510.19.0.355536032386.issue3364@psf.upfronthosting.co.za>
Message-ID: <670cc5db0807170704o15d0ab74q4ab34d4d4c9aea60@mail.gmail.com>


Chester <wxpythoner at gmail.com> added the comment:

You're a strange man, Mr. Peters, a strange man...

On Tue, Jul 15, 2008 at 9:35 PM, Tim Peters <report at bugs.python.org> wrote:

>
> Tim Peters <tim.peters at gmail.com> added the comment:
>
> I'm afraid you missed the joke ;-)  While you believe spaces are
> required on both sides of an em dash, there is no consensus on this
> point.  For example, most (but not all) American authorities say /no/
> spaces should be used.  That's the joke.  In writing a line about "only
> one way to do it", I used a device (em dash) for which at least two ways
> to do it (with spaces, without spaces) are commonly used, neither of
> which is obvious -- and deliberately picked a third way just to rub it in.
>
> This will never change ;-)
>
> ----------
> nosy: +tim_one
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3364>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080717/ceb83625/attachment.txt>

From report at bugs.python.org  Thu Jul 17 17:15:24 2008
From: report at bugs.python.org (David Goodger)
Date: Thu, 17 Jul 2008 15:15:24 +0000
Subject: [issue3364] An ortographical typo in Zen of Python text
In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za>
Message-ID: <1216307724.35.0.052986082349.issue3364@psf.upfronthosting.co.za>


Changes by David Goodger <goodger at python.org>:


Removed file: http://bugs.python.org/file10928/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3364>
_______________________________________

From report at bugs.python.org  Thu Jul 17 17:41:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 15:41:08 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216309268.21.0.933280945796.issue3375@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about simply doing sys.path_importer_cache.clear() at the right
point in setup.py? I don't think the performance loss would be
overwhelming...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:00:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 16:00:13 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216310413.89.0.79030825927.issue3381@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Ok applied in r65061.

----------
nosy: +benjamin.peterson
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:00:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 16:00:31 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1216310430.02.0.824158634826.issue2690@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Has a resolution been made on this?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:04:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 16:04:06 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1216310646.42.0.557608919706.issue2523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If nobody objects I'll commit Alexandre's patch in a few days (after
beta 2 though).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:26:13 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 16:26:13 +0000
Subject: [issue3375] _multiprocessing.so build problems
In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za>
Message-ID: <1216311973.73.0.644951750767.issue3375@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I've checked in a fix (r65063) that simply clear sys.path_importer_cache
right before the attempted import of the freshly-built extension.  This
seems to work.

----------
assignee: jnoller -> gvanrossum
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:30:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 16:30:42 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216312242.06.0.62782040939.issue3369@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:37:43 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Thu, 17 Jul 2008 16:37:43 +0000
Subject: [issue3377] Invalid child node access in ast.c
In-Reply-To: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za>
Message-ID: <1216312663.44.0.961097389386.issue3377@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Committed revision 65064.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3377>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:50:34 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 16:50:34 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216313434.5.0.93220384294.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've merged the change to py3k in r65065

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 18:57:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 16:57:08 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216313828.02.0.322209706181.issue874900@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

test_3_join_in_forked_from_thread hangs for me in Py3k.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:02:48 2008
From: report at bugs.python.org (Trent Mick)
Date: Thu, 17 Jul 2008 17:02:48 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>


New submission from Trent Mick <trentm at gmail.com>:

http://svn.python.org/view?rev=63955&view=rev
"MacOS X: Enable 4-way universal builds ..."

This revision made the following change to Mac/Makefile.in:
http://svn.python.org/view/python/trunk/Mac/Makefile.in?rev=63955&view=diff&r1=63955&r2=63954&p1=python/trunk/Mac/Makefile.in&p2=/python/trunk/Mac/Makefile.in

The last hunk (part of the "installmacsubtree" target) and a bit of the
preceding hunk uses `arch` with arguments:
---------------------------------
 install_BuildApplet:
-	$(RUNSHARED) $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \
+	$(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON)
$(srcdir)/scripts/BuildApplet.py \
 		--destroot "$(DESTDIR)" \
-		--python $(INSTALLED_PYTHONAPP) \
+	
--python=$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)`test
-f
"$(DESTDIR)$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)-32"
&& echo "-32"`  \
 		--output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app" \
 		$(srcdir)/scripts/BuildApplet.py
 
@@ -225,7 +279,7 @@
 	done
 
 
-	$(RUNSHARED) $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST)
$(DESTDIR)$(MACTOOLSDEST)
+	$(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v
$(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST)
 	$(RUNSHARED) $(BUILDPYTHON) -Wi -tt $(compileall) -d $(MACTOOLSDEST)
-x badsyntax $(DESTDIR)$(MACTOOLSDEST)
 	$(RUNSHARED) $(BUILDPYTHON) -O -Wi -tt $(compileall) -d
$(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST)
---------------------------------

That form of calling `arch` is only supported on Mac OS X 10.5
(Leopard), I believe.

----------------------------------
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S2167
$ man arch | cat

ARCH(1)                   BSD General Commands Manual                 
ARCH(1)

NAME
     arch -- print architecture type

SYNOPSIS
     arch

DESCRIPTION
     The arch command displays the machine's architecture type.

SEE ALSO
     machine(1)

Mac OS                          August 20, 1997                        
Mac OS
----------------------------------


Here is the current man page for arch (I had to look to try to see what
Ronald was trying to do with the Makefile change) :)
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/arch.1.html

I don't fully understand why the "arch -ppc -i386" is necessary for
"$(BUILDPYTHON)".


I'm not sure what the easiest solution to this would be... or if
supporting "make frameworkinstallframework" (which eventually calls this
target) on Mac OS X <10.5 is considered important enough.

Perhaps a new 
  RUNARCH=@RUNARCH@
could be added to Mac/Makefile.in with the associated configure support
to have that be blank unless `--with-universal-archs=all` was specified?

----------
components: Build
messages: 69890
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:11:38 2008
From: report at bugs.python.org (Trent Mick)
Date: Thu, 17 Jul 2008 17:11:38 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216314698.32.0.253525347176.issue3393@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Similar change in Mac/IDLE/Makefile.in:

-----------------------------
--- python/trunk/Mac/IDLE/Makefile.in	(original)
+++ python/trunk/Mac/IDLE/Makefile.in	Thu Jun  5 14:58:24 2008
@@ -42,7 +42,7 @@
 		$(srcdir)/../Icons/PythonSource.icns \
 		$(srcdir)/../Icons/PythonCompiled.icns Info.plist
 	rm -fr IDLE.app
-	$(RUNSHARED) $(BUILDPYTHON) $(BUNDLEBULDER) \
+	$(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(BUNDLEBULDER) \
 		--builddir=. \
 		--name=IDLE \
 		--link-exec \
-----------------------------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:20:45 2008
From: report at bugs.python.org (Trent Mick)
Date: Thu, 17 Jul 2008 17:20:45 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216315245.37.0.0973802109008.issue3393@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Alternative potential solution: use the ARCHPREFERENCE environment
variable as described in the Mac OS X 10.5 arch man page. Ronald, if you
could test if that works for you on 10.5, then presumably setting that
environment var would be safely ignored on Mac OS X <10.5. Thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:35:04 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 17:35:04 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216316104.84.0.394980632663.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

To add to ben's comment, under py3k the third test hangs, if you pull 
out the basic script code being executed in subprocess:

if 1:
        import sys, os, time, threading

        # a thread, which waits for the main program to terminate
        def joiningfunc(mainthread):
            mainthread.join()
            print('end of thread')
    
if 1:
    main_thread = threading.current_thread()
    def worker():
        childpid = os.fork()
        if childpid != 0:
            os.waitpid(childpid, 0)
            sys.exit(0)

        t = threading.Thread(target=joiningfunc,
                             args=(main_thread,))
        print('starting worker')
        t.start()
        print('joining worker')
        t.join() # Should not block: main_thread is already stopped

    w = threading.Thread(target=worker)
    w.start()

You'll note it hangs promptly at the join()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:41:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 17:41:02 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216316462.6.0.505941072791.issue874900@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ben commented out the hanging test, lowering this from a release blocker 
as the patch is on both trunk and 3k, and minus that third new test, 
test_threading and test_multiprocessing are both passing

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:41:48 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 17:41:48 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216316508.2.0.431410200283.issue3088@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Issue 874900's patch seems to have resolve the hangs. I am closing this 
issue as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Thu Jul 17 19:48:04 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Thu, 17 Jul 2008 17:48:04 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216316884.58.0.297468807597.issue3379@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Added tests.

Added file: http://bugs.python.org/file10929/add_avoid_exit_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Thu Jul 17 20:35:24 2008
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Jul 2008 18:35:24 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1216319724.93.0.585805767941.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Implemented for trunk in r65069; for py3k in r65073.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Thu Jul 17 21:01:34 2008
From: report at bugs.python.org (Stephen Warren)
Date: Thu, 17 Jul 2008 19:01:34 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>


New submission from Stephen Warren <s-t-pybugs at wwwdotorg.org>:

Run the following Python script, on Unix/Linux:

==========
import zipfile

z = zipfile.ZipFile('zipbad.zip', 'w')
z.writestr('filebad.txt', 'Some content')
z.close()

z = zipfile.ZipFile('zipgood.zip', 'w')
zi = zipfile.ZipInfo('filegood.txt')
zi.external_attr = 0660 << 16L
z.writestr(zi, 'Some content')
z.close()
==========

Like this:

python testzip.py  && unzip zipbad.zip && unzip zipgood.zip && ls -l
file*.txt

You'll see:

----------  1 swarren swarren   12 2008-07-17 12:54 filebad.txt
-rw-rw----  1 swarren swarren   12 1980-01-01 00:00 filegood.txt

Note that filebad.txt is extracted with mode 000.

The WAR (used for filegood.txt) is to pass writestr a ZipInfo class with
external_attr pre-initialized. However, writestr should perform this
assignment itself, to be consistent with write. I haven't checked, but
there's probably a bunch of other stuff in write that writestr should do
too.

----------
components: Extension Modules
messages: 69898
nosy: swarren
severity: normal
status: open
title: zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Thu Jul 17 21:02:02 2008
From: report at bugs.python.org (Stephen Warren)
Date: Thu, 17 Jul 2008 19:02:02 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216321322.91.0.569083553825.issue3394@psf.upfronthosting.co.za>


Stephen Warren <s-t-pybugs at wwwdotorg.org> added the comment:

Oops. Forgot to set "type" field.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Thu Jul 17 21:20:17 2008
From: report at bugs.python.org (Roman Petrichev)
Date: Thu, 17 Jul 2008 19:20:17 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1216322417.62.0.5607222576.issue1432@psf.upfronthosting.co.za>


Roman Petrichev <tier at inbox.ru> added the comment:

Senthil, please read the RFC3986 text, not only examples.
[Page 31] contains exact algorithm how to handle this case.
--cut--
if (R.path == "") then
   T.path = Base.path;
   if defined(R.query) then
      T.query = R.query;
   else
      T.query = Base.query;
   endif;
--cut--

I.e. instead of:
>>> urljoin('http://www.ya.ru/index.php', '?o=30&a=l')
'http://www.ya.ru/?o=30&a=l'
python SHOULD do:
>>> urljoin('http://www.ya.ru/index.php', '?o=30&a=l')
'http://www.ya.ru/index.php?o=30&a=l'

Look at any browser's handling this case.

----------
nosy: +tier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Thu Jul 17 21:21:38 2008
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Jul 2008 19:21:38 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1216322498.41.0.56695398188.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Changes backed out, pending fixing on Windows.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:03:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Jul 2008 20:03:02 +0000
Subject: [issue3324] Broken link in online doc
In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za>
Message-ID: <1216324982.22.0.30765712423.issue3324@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've backported the fix to the 2.5 branch. This will go live with the
release of 2.5.3.

For those who do not want to use the released documentation we do offer
the 2.6 documentation under development under http://docs.python.org/dev
-- it is very usable for 2.5 too, since anything new in 2.6 will be
clearly marked as such.

When 2.6 is released, handling of the docs will be different in any
case, since comments and change suggestions will be possible and handled
in a timely manner, I hope.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3324>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:07:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 20:07:04 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216325224.0.0.88699473161.issue3373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a small script that shows various possibilities depending on how
object creation is done, and here is the output with the trunk:

rec1 stopped at 1000
rec2 stopped at 1000
rec3 stopped at 500
rec4 stopped at 334
rec5 stopped at 334
rec6 stopped at 250

With 2.5, the output is:

rec1 stopped at 1000
rec2 stopped at 1000
rec3 stopped at 500
rec4 stopped at 1000
rec5 stopped at 1000
rec6 stopped at 1000

I think we should just acknowledge that recursion count has gotten
stricter (PyObject_Call() increases it, and then PyEval_EvalFrameEx()
will increase it a second time if Python code is entered), and bump the
default recursion limit.

(the reason calling Python functions directly doesn't increase the
recursion count twice is that there are optimization shortcuts in
ceval.c to avoid calling PyObject_Call() - not the case though when
calling a type object)

Added file: http://bugs.python.org/file10930/rec.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:09:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 20:09:16 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216325356.58.0.576142156199.issue3373@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:29:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 20:29:07 +0000
Subject: [issue3395] typo in test_multiprocessing.py: should _debugInfo be
	_debug_info ?
In-Reply-To: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>
Message-ID: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In _TestZZZNumberOfObjects in test_multiprocessing.py, at around line 1040  
(this is r65075 on the trunk), there's a line:

            print self.manager._debugInfo()

Should this be

            print self.manager._debug_info()

?

While running test_multiprocessing directly (./python.exe 
Lib/test/test_multiprocessing) I got the following traceback:

Macintosh-3:trunk dickinsm$ ./python.exe Lib/test/test_multiprocessing.py
test_array (__main__.WithProcessesTestArray) ... ok
test_getobj_getlock_obj (__main__.WithProcessesTestArray) ... ok
...
[snip lots of passing tests]
...
test_rawvalue (__main__.WithManagerTestValue) ... ok
test_value (__main__.WithManagerTestValue) ... ok
test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ... 
ERROR

======================================================================
ERROR: test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1040, in 
test_number_of_objects
    print self.manager._debugInfo()
AttributeError: 'SyncManager' object has no attribute '_debugInfo'

----------------------------------------------------------------------
Ran 121 tests in 10.446s

FAILED (errors=1)
[53431 refs]

----------
assignee: jnoller
keywords: easy
messages: 69904
nosy: jnoller, marketdickinson
severity: normal
status: open
title: typo in test_multiprocessing.py:  should _debugInfo be _debug_info ?
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3395>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:42:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 20:42:09 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a regression caused by #449227. When typing e.g. "int." and then
pressing tab, none of the int members is proposed. It worked until just
before r64664.

----------
components: Library (Lib)
messages: 69905
nosy: facundobatista, pitrou
priority: normal
severity: normal
status: open
title: rlcompleter can't autocomplete members of callable objects
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:42:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 20:42:35 +0000
Subject: [issue449227] rlcompleter add "(" to callables feature
Message-ID: <1216327355.56.0.76346465485.issue449227@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This issue caused a regression in #3396.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue449227>
_______________________________________

From report at bugs.python.org  Thu Jul 17 22:48:02 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 20:48:02 +0000
Subject: [issue3395] typo in test_multiprocessing.py: should _debugInfo be
	_debug_info ?
In-Reply-To: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>
Message-ID: <1216327682.11.0.382213635278.issue3395@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I can not reproduce this using r65075 of python-trunk:

test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ... 
ok

----------------------------------------------------------------------
Ran 121 tests in 9.165s

This is with a clean build of python against trunk it also doesn't fail 
with regrtest:

thumper:python-trunk jesse$ ./python.exe Lib/test/regrtest.py 
test_multiprocessing


This is a clean checkout

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3395>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:01:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 21:01:26 +0000
Subject: [issue3395] typo in test_multiprocessing.py: should _debugInfo be
	_debug_info ?
In-Reply-To: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za>
Message-ID: <1216328486.6.0.0392287952101.issue3395@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fixed, r65077 on trunk

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3395>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:31:19 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 17 Jul 2008 21:31:19 +0000
Subject: [issue3397] Mac 3.0 build cannot find cachersrc.py
In-Reply-To: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za>
Message-ID: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165

./configure --enable-framework
make
...
make install
Creating directory
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe
./scripts/cachersrc.py -v
/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac
/Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools
../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No
such file or directory
make[1]: *** [installmacsubtree] Error 2
make: *** [frameworkinstallmaclib] Error 2

----------
components: Build
messages: 69909
nosy: barry-scott
severity: normal
status: open
title: Mac 3.0 build cannot find cachersrc.py
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3397>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:52:22 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 17 Jul 2008 21:52:22 +0000
Subject: [issue3398] mac build 3.0 no MacOS module
In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
Message-ID: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165

./configure --enable-framework
make
...
make install
...

DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe
./scripts/BuildApplet.py \
        --destroot "" \
        --python
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python
\
        --output "/Applications/Python 3.0/Build Applet.app" \
        ./scripts/BuildApplet.py
Traceback (most recent call last):
  File "./scripts/BuildApplet.py", line 14, in <module>
import MacOS
ImportError: No module named MacOS
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2

----------
components: Build
messages: 69910
nosy: barry-scott
severity: normal
status: open
title: mac build 3.0 no MacOS module
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3398>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:52:52 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 17 Jul 2008 21:52:52 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216331572.07.0.533390639218.issue3396@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This is somewhat obscure to notice but the problem is towards that
getattr on attr_matches. For "int" specifically, it will try to get the
attribute '__abstractmethods__' (which is a member of int.__class__) and
will raise an AttributeError but then the exception is discarded by the
readline module.
A workaround is to change that getattr to:

try:
    val = getattr(object, word)
except AttributeError:
    continue

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:53:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 21:53:46 +0000
Subject: [issue3398] mac build 3.0 no MacOS module
In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
Message-ID: <1216331626.6.0.381037901865.issue3398@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

I assume this is only 3.0 beta 1. This has been fixed for beta 2.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3398>
_______________________________________

From report at bugs.python.org  Thu Jul 17 23:55:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 21:55:28 +0000
Subject: [issue3397] Mac 3.0 build cannot find cachersrc.py
In-Reply-To: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za>
Message-ID: <1216331728.45.0.144414331477.issue3397@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

This is fixed in beta 2.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3397>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:00:45 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 17 Jul 2008 22:00:45 +0000
Subject: [issue3398] mac build 3.0 no MacOS module
In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
Message-ID: <1216332045.17.0.957482738116.issue3398@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I don't see beta 2 on python.org or I'd have used it...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3398>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:01:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 22:01:33 +0000
Subject: [issue3398] mac build 3.0 no MacOS module
In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za>
Message-ID: <1216332093.44.0.231216669263.issue3398@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

It's supposed to be release tonight. Sorry for the confusion. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3398>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:01:42 2008
From: report at bugs.python.org (Jose Antonio Martin H)
Date: Thu, 17 Jul 2008 22:01:42 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1216332102.08.0.864480361575.issue2234@psf.upfronthosting.co.za>


Jose Antonio Martin H <jamartinh at fdi.ucm.es> added the comment:

I have the same problem, i have patched the file and now it works ok.

----------
nosy: +jamartinh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2234>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:15:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jul 2008 22:15:16 +0000
Subject: [issue3390] [PATCH] replace last has_key in unittest by in operator
In-Reply-To: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>
Message-ID: <1216332916.31.0.184229484944.issue3390@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3390>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:22:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 22:22:25 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

As of revision 65077 of the trunk, I'm getting errors in 
test_multiprocessing that seem to point to memory corruption in object 
allocation/deallocation.  The failures are intermittent, and of a 
similar nature to the errors I was seeing previously, outlined in issue 
3088.

The platform is OS X 10.5.4 (not a fresh install---it was an upgrade 
from OS X 10.4, in case this makes any difference), running on a MacBook 
Pro.  I'm running a freshly checked out debug build of the trunk.

Here's what I did:

(1) make a fresh svn+ssh checkout of the trunk
(2) ./configure --with-pydebug && make
(3) ./python.exe Lib/test/test_multiprocessing.py
(4) repeat step (3) until something nasty happens.

The results vary from run to run, and 80-90% of the runs of 
test_multiprocessing pass.  Here are 3 of the failures I've seen, 
occurring on three separate runs of test_multiprocessing.

Failure 1:

test_notify_all (__main__.WithManagerTestCondition) ... Assertion 
failed: (pool->ref.count > 0), function PyObject_Free, file 
Objects/obmalloc.c, line 1100.

Failure 2:

test_imap_unordered (__main__.WithManagerTestPool) ...
python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb:
pointer being reallocated was not allocated
*** set a breakpoint in malloc_error_break to debug
python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb:
Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
Fatal Python error: UNREF invalid object
ERROR

Failure 3:

test_imap_unordered (__main__.WithManagerTestPool) ... Fatal Python
error: UNREF invalid object
ERROR


I have very little (i.e. no) experience of debugging this kind of 
failure, and little understanding of how the multiprocessing module 
works.  But I can and will follow instructions and suggestions about how 
to debug this.

Stupid question:  it appears from reading the comments in that file that 
obmalloc.c is (intentionally) not thread-safe.  Could this have anything 
to do with the failures above?

----------
assignee: jnoller
components: Extension Modules
messages: 69917
nosy: jnoller, marketdickinson
severity: normal
status: open
title: Memory corruption in multiprocessing module, OS X 10.5.4
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:24:18 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jul 2008 22:24:18 +0000
Subject: [issue3400] dis module: undocumented new bytecodes
In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
Message-ID: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

dis / Python Bytecode Instructions is missing
UNPACK_EX
STORE_LOCALS
LOAD_BUILD_CLASS
MAKE_BYTES
which appear in dis.opname (3.0 version).

Suggestion: After entry for UNPACK_SEQUENCE(count), add
UNPACK_EX(bytepair)
Used for starred assignment.  Similar to UNPACK_SEQUENCE except 1) the
lo and hi bytes of the argument are the number of unstarred targets
before and after the starred target and 2) the values between the first
lo and last hi are collected into a list for the starred target.

I deduced this because *a,b; a,*b; *a,b,c; a,*b,c; and a,b,*c as targets
produce byte pairs of 0,1; 1,0; 0,2; 1,1; and 2,0 (arguments 256, 1,
512, 257, and 2).

The other three are new since 2.5 but do not make much sense to me.  I
will ask on pydev for clarification.  I do not have 2.6 to check its
version of .opname to determine which of these belong there too.

----------
assignee: georg.brandl
components: Documentation
messages: 69918
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: dis module: undocumented new bytecodes
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3400>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:26:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 22:26:12 +0000
Subject: [issue3400] dis module: undocumented new bytecodes
In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
Message-ID: <1216333572.49.0.00973397743257.issue3400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

LOAD_BUILD_CLASS is 3.0 only and I documented it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3400>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:34:47 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 17 Jul 2008 22:34:47 +0000
Subject: [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1216334087.62.0.82386084946.issue2638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

It would be more appropriate to properly use withdraw and deiconify
then. I'm attaching a patch that uses them.

----------
keywords: +patch
Added file: http://bugs.python.org/file10931/issue_2638.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2638>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:46:56 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 22:46:56 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216334816.61.0.187599726349.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And one more:

Failure 4:

test_make_pool (__main__.WithManagerTestPool) ... Assertion failed: (bp != 
NULL), function PyObject_Malloc, file Objects/obmalloc.c, line 746.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:47:01 2008
From: report at bugs.python.org (Christopher Brannon)
Date: Thu, 17 Jul 2008 22:47:01 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216334821.01.0.29303854521.issue3394@psf.upfronthosting.co.za>


Christopher Brannon <cmbrannon at cox.net> added the comment:

What value should the new archive entry's external_attr attribute have?
ZipFile.write sets it to the permissions of the file being archived, but
writestr is archiving a string, not a file.  Setting it to 0600 &lt;&lt; 16
seems reasonable.

Stephen's script exposed a second bug in writestr.  When passed a name
rather than a ZipInfo instance, the new archive member receives a timestamp
of 01/01/1980.  However, the docs say that the timestamp should correspond to
the current date and time.
ZipFile.writestr begins with the following code:

    def writestr(self, zinfo_or_arcname, bytes):
        """Write a file into the archive.  The contents is the string
        'bytes'.  'zinfo_or_arcname' is either a ZipInfo instance or
        the name of the file in the archive."""
        if not isinstance(zinfo_or_arcname, ZipInfo):
            zinfo = ZipInfo(filename=zinfo_or_arcname,
                            date_time=time.localtime(time.time())[:6])
            zinfo.compress_type = self.compression

The "date_time=" line should read:

                            zinfo.date_time=time.localtime(time.time())[:6])

----------
nosy: +cbrannon
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Fri Jul 18 00:53:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 17 Jul 2008 22:53:31 +0000
Subject: [issue3400] dis module: undocumented new bytecodes
In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
Message-ID: <1216335211.9.0.592890634765.issue3400@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Terry, would you like to contribute a patch (even if only for the one
you understand)?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3400>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:13:38 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 23:13:38 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216336418.5.0.688621455274.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And another:

Failure 5:

test_notify (__main__.WithManagerTestCondition) ... Assertion failed: 
(usable_arenas->freepools == NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 809.
ERROR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:13:55 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 17 Jul 2008 23:13:55 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <AB9DF0FC-07D2-47E9-818E-16EE33CB81D9@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Jul 17, 2008, at 6:22 PM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> New submission from Mark Dickinson <dickinsm at gmail.com>:
>
> As of revision 65077 of the trunk, I'm getting errors in
> test_multiprocessing that seem to point to memory corruption in object
> allocation/deallocation.  The failures are intermittent, and of a
> similar nature to the errors I was seeing previously, outlined in  
> issue
> 3088.
>
> The platform is OS X 10.5.4 (not a fresh install---it was an upgrade
> from OS X 10.4, in case this makes any difference), running on a  
> MacBook
> Pro.  I'm running a freshly checked out debug build of the trunk.
>
> Here's what I did:
>
> (1) make a fresh svn+ssh checkout of the trunk
> (2) ./configure --with-pydebug && make
> (3) ./python.exe Lib/test/test_multiprocessing.py
> (4) repeat step (3) until something nasty happens.
>
> The results vary from run to run, and 80-90% of the runs of
> test_multiprocessing pass.  Here are 3 of the failures I've seen,
> occurring on three separate runs of test_multiprocessing.
>

I am/was going to help you with this when you emailed me your last  
email - I'm disturbed none of my machines or the buildbots for that  
matter are seeing this. Can you post the output from:

Echo $LD_LIBRARY_PATH
which gcc
gcc -v

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:17:40 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jul 2008 23:17:40 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216336660.79.0.996785578985.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

LD_LIBRARY_PATH isn't set.  gcc is the system gcc from Apple:

Macintosh-3:trunk dickinsm$ echo $LD_LIBRARY_PATH

Macintosh-3:trunk dickinsm$ which gcc
/usr/bin/gcc
Macintosh-3:trunk dickinsm$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5484~1/src/configure --disable-
checking -enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-
]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-
slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-
tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5484)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:22:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Jul 2008 23:22:07 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1216336927.04.0.792216439469.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

None yet. :(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:33:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Jul 2008 23:33:47 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216337627.51.0.726049366922.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Jesse: thanks for doing the py3k merge.

Antoine: yeah it might be safer to use _get_ident() but since the
len(_active) == 1 assert is not firing we're probably fine as is.

A change to this that I was considering making to this code has been
attached as threading-874900-improvement-gps01.diff.

-gps

Added file: http://bugs.python.org/file10932/threading-874900-improvement-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:53:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 23:53:35 +0000
Subject: [issue3401] wsgiref can't handle unicode environments
In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
Message-ID: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:

The following errors pop up on the Windows trunk build bot because the
LIB environmental variable is unicode not str. This causes the
validation to fail.


Re-running test 'test_wsgiref' in verbose mode
testAbstractMethods (test.test_wsgiref.HandlerTests) ... ok
testBasicErrorOutput (test.test_wsgiref.HandlerTests) ... ok
testCGIEnviron (test.test_wsgiref.HandlerTests) ... ok
testContentLength (test.test_wsgiref.HandlerTests) ... ok
testEnviron (test.test_wsgiref.HandlerTests) ... ERROR
testErrorAfterOutput (test.test_wsgiref.HandlerTests) ... ok
testHeaderFormats (test.test_wsgiref.HandlerTests) ... ok
testScheme (test.test_wsgiref.HandlerTests) ... ok
testExtras (test.test_wsgiref.HeaderTests) ... ok
testMappingInterface (test.test_wsgiref.HeaderTests) ... ok
testRequireList (test.test_wsgiref.HeaderTests) ... ok
test_plain_hello (test.test_wsgiref.IntegrationTests) ... ok
test_simple_validation_error (test.test_wsgiref.IntegrationTests) ... FAIL
test_validated_hello (test.test_wsgiref.IntegrationTests) ... FAIL
testAppURIs (test.test_wsgiref.UtilityTests) ... ok
testCrossDefaults (test.test_wsgiref.UtilityTests) ... ok
testDefaults (test.test_wsgiref.UtilityTests) ... ok
testFileWrapper (test.test_wsgiref.UtilityTests) ... ok
testGuessScheme (test.test_wsgiref.UtilityTests) ... ok
testHopByHop (test.test_wsgiref.UtilityTests) ... ok
testNormalizedShifts (test.test_wsgiref.UtilityTests) ... ok
testReqURIs (test.test_wsgiref.UtilityTests) ... ok
testSimpleShifts (test.test_wsgiref.UtilityTests) ... ok

======================================================================
ERROR: testEnviron (test.test_wsgiref.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 437, in testEnviron
    self.checkOSEnviron(h)
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 429, in checkOSEnviron
    self.assertEqual(env[k],v)
KeyError: 'AUTH_TYPE'

======================================================================
FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 157, in test_simple_validation_error
    "AssertionError: Headers (('Content-Type', 'text/plain')) must"
AssertionError: "AssertionError: Environmental variable LIB is not a
string: <type 'unicode'> (value: u'C:\\\\Program Files\\\\Microsoft
Visual Studio 9.0\\\\VC\\\\LIB;C:\\\\Program Files\\\\Microsoft
SDKs\\\\Windows\\\\v6.0A\\\\lib;c:\\\\program files\\\\microsoft visual
studio .NET 2003\\\\vc7\\\\atlmfc\\\\lib;c:\\\\program
files\\\\microsoft visual studio .NET 2003\\\\vc7\\\\lib;c:\\\\program
files\\\\microsoft visual studio .NET
2003\\\\vc7\\\\PlatformSDK\\\\lib;C:\\\\Program Files\\\\Microsoft
Visual Studio .NET 2003\\\\SDK\\\\v1.1\\\\Lib\\\\')" != "AssertionError:
Headers (('Content-Type', 'text/plain')) must be of type list: <type
'tuple'>"

======================================================================
FAIL: test_validated_hello (test.test_wsgiref.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 145, in test_validated_hello
    self.check_hello(out, has_length=False)
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py",
line 134, in check_hello
    "\r\n"
AssertionError: 'HTTP/1.0 500 Dude, this is whack!\r\nDate: Thu, 17 Jul
2008 22:45:20 GMT\r\nServer: WSGIServer/0.1
Python/2.6b1+\r\nContent-Type: text/plain\r\nContent-Length: 59\r\n\r\nA
server error occurred.  Please contact the administrator.' != 'HTTP/1.0
200 OK\r\nServer: WSGIServer/0.1 Python/2.6b1+\r\nContent-Type:
text/plain\r\nDate: Mon, 05 Jun 2006 18:49:54 GMT\r\n\r\nHello, world!'

----------
messages: 69929
nosy: benjamin.peterson
severity: normal
status: open
title: wsgiref can't handle unicode environments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3401>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:54:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Jul 2008 23:54:09 +0000
Subject: [issue3401] wsgiref can't handle unicode environments
In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
Message-ID: <1216338849.77.0.447343167973.issue3401@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


----------
components: +Library (Lib)
priority:  -> high
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3401>
_______________________________________

From report at bugs.python.org  Fri Jul 18 01:58:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Jul 2008 23:58:08 +0000
Subject: [issue3401] wsgiref can't handle unicode environments
In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za>
Message-ID: <1216339088.21.0.33334742889.issue3401@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pje
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3401>
_______________________________________

From report at bugs.python.org  Fri Jul 18 02:13:27 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 18 Jul 2008 00:13:27 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216336660.79.0.996785578985.issue3399@psf.upfronthosting.co.za>
Message-ID: <4079D833-1FF8-4970-9099-29B17667CBDC@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Can you try removing the --with-pydebug flag from configure and  
running that way?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 03:56:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 01:56:33 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:

The 3.0 Solaris buildbot keeps hanging on test_nis.

----------
components: Tests
messages: 69931
nosy: benjamin.peterson
priority: deferred blocker
severity: normal
status: open
title: test_nis is hanging on Solaris
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:45:40 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:45:40 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1216352740.95.0.0429108093652.issue2235@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:45:55 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:45:55 +0000
Subject: [issue3231] re.compile fails with some bytes patterns
In-Reply-To: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>
Message-ID: <1216352755.14.0.925389423117.issue3231@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3231>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:46:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:46:10 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1216352770.51.0.728030187954.issue3131@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:46:29 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:46:29 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1216352789.23.0.305347315668.issue3139@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:46:43 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:46:43 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1216352803.47.0.134177135744.issue3352@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:46:56 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 03:46:56 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1216352816.49.0.377994464757.issue3402@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Fri Jul 18 05:57:37 2008
From: report at bugs.python.org (Stephen Warren)
Date: Fri, 18 Jul 2008 03:57:37 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216353457.17.0.719403197404.issue3394@psf.upfronthosting.co.za>


Stephen Warren <s-t-pybugs at wwwdotorg.org> added the comment:

I'd probably argue for at least 0660<<16, if not 0666<<16, since group
permissions are pretty typically set, but even 0666<<16 would be OK,
since the umask on extraction would take away any permissions the
extracting user didn't want.

But, as long as the chosen mask includes at least 0600, I'd consider the
issue fixed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Fri Jul 18 07:19:11 2008
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Fri, 18 Jul 2008 05:19:11 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1216358351.36.0.294219166443.issue1432@psf.upfronthosting.co.za>


Changes by Alexandr Zamaraev <shura_zam at users.sourceforge.net>:


----------
nosy: +shura_zam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Fri Jul 18 07:22:53 2008
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Fri, 18 Jul 2008 05:22:53 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216358573.31.0.997185260845.issue3396@psf.upfronthosting.co.za>


Manuel Murad?s <mmuradas at dieresys.com.ar> added the comment:

Oops, you are right. If that is the way we should handle this
regression, I could upload a patch. I also thought we could use
"hasattr", but that means using "getattr" twice. Something like:

if word[:n] == attr and word != "__builtins__" and hasattr(object, word):
    val = getattr(object, word)

What do you think about it?

----------
nosy: +dieresys

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Fri Jul 18 07:45:39 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Jul 2008 05:45:39 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216359939.48.0.61781312855.issue3393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This patch is wrong, it drops the call to 'arch' entirely even when the 
call is needed.

The suggestion for "ARCHPREFERENCE" won't work though, "arch" doesn't take 
arguments at all on 10.4.


BTW. This is a duplicate of issue 3381, which includes a patch for fixing 
the issue.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Fri Jul 18 07:49:11 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Jul 2008 05:49:11 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216360151.61.0.0336869929457.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Whoops, issue 3393 is a duplicate of this issue and notes that 
Mac/IDLE/Makefile.in is also affected.

I've fixed that makefile in r65091.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:08:09 2008
From: report at bugs.python.org (Trent Mick)
Date: Fri, 18 Jul 2008 06:08:09 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216361289.7.0.674912213552.issue3381@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Ronald,

The @ARCH_RUN_32BIT@ also needs to be added to two places in
Mac/Makefile.in (as indicated in issue 3393), no? Would you like me to
make that change?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:15:59 2008
From: report at bugs.python.org (Christopher Brannon)
Date: Fri, 18 Jul 2008 06:15:59 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216353457.17.0.719403197404.issue3394@psf.upfronthosting.co.za>
	(Stephen Warren's message of "Fri\, 18 Jul 2008 03\:57\:37 +0000")
Message-ID: <878wvzraia.fsf@cox.net>


Christopher Brannon <cmbrannon at cox.net> added the comment:

Here is a patch containing code and a unit test.  I set external_attr
to 0600, for the following reason.
When I extract with Infozip, my umask is ignored when setting permissions of
extracted entries.  They have the permissions assigned to them when archived.
tar does respect umask, but it's not pertinent.
The following shell script demonstrates Infozip's behavior:

=====begin=====
#!/bin/sh
mkdir ziptest_dir
echo hello > ziptest_dir/foo.txt
chmod 666 ziptest_dir/foo.txt
zip -r ziptest_file.zip ziptest_dir/
rm -rf ziptest_dir
umask 077
unzip ziptest_file.zip
=====end=====

Setting permissions to 0600 seems like the safest course.

I'm not sure if this patch should be accompanied by some documentation,
since the zipfile docs don't say much about external_attr or permissions.

PS.  My earlier comments about timestamps were incorrect and spurious!

----------
keywords: +patch
Added file: http://bugs.python.org/file10933/writestr_usable_permissions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: writestr_usable_permissions.diff
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080718/16c898f4/attachment.txt>

From report at bugs.python.org  Fri Jul 18 08:17:01 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Jul 2008 06:17:01 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216361821.42.0.764461673355.issue3393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The current trunk should be correct, there are no explicit calls to the 
arch command left, all go through the configure replacement magic.

To test if everything is correct now someone should test the following 
scenarios:

* Build --enable-framework --enable-universalsdk on 10.4

* Build --enable-framework --enable-universalsdk on 10.5

* Build --enable-framework --enable-universalsdk --with-universal-
archs=all on 10.5

I cannot test the first one, and will test the last one (which is the 
one I'm most interested in).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:18:12 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 18 Jul 2008 06:18:12 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za>
Message-ID: <1216361892.04.0.433551074315.issue3393@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. There is a "--with-framework-name" argument to configure that makes 
it possible to have several indepenend framework installations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:25:08 2008
From: report at bugs.python.org (Trent Mick)
Date: Fri, 18 Jul 2008 06:25:08 +0000
Subject: [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X <
	10.5 because of r63955
In-Reply-To: <1216361821.42.0.764461673355.issue3393@psf.upfronthosting.co.za>
Message-ID: <6db0ea510807172325wc1e131et4f0cf435f8c51ed0@mail.gmail.com>


Trent Mick <trentm at gmail.com> added the comment:

> The current trunk should be correct, there are no explicit calls to the
> arch command left, all go through the configure replacement magic.

--------------------
$ svn info
Path: .
URL: svn+ssh://pythondev at svn.python.org/python/trunk/Mac
Repository Root: svn+ssh://pythondev at svn.python.org
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 65091
Node Kind: directory
Schedule: normal
Last Changed Author: ronald.oussoren
Last Changed Rev: 65091
Last Changed Date: 2008-07-17 22:48:03 -0700 (Thu, 17 Jul 2008)
Properties Last Updated: 2008-07-17 22:55:32 -0700 (Thu, 17 Jul 2008)

[trentm at mower:~/src/python/Mac]
$ svn up Makefile.in
At revision 65091.
[trentm at mower:~/src/python/Mac]
$ grep "arch -" Makefile.in
        $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON)
$(srcdir)/scripts/BuildApplet.py \
        $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v
$(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST)
--------------------

Apologies if I am missing something. Your patches for issue 3381 did
not include a change to Mac/Makefile.in.

Trent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3393>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:37:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jul 2008 06:37:49 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216363069.06.0.870439647235.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay:  I just tried the following:

(1) clean svn checkout
(2) ./configure && make
(3) 100 runs of test_multiprocessing, via the shell command:
for ((i=0;i<100;i+=1)); do ./python.exe 
Lib/test/test_multiprocessing.py; sleep 1; done

I got 4 failed runs out of those 100 runs (details below);  2 hangs in 
test_notify_all, a KeyError in test_remote, and a failure of 
test_number_of_objects.

Failed run 1
------------
test_notify_all (__main__.WithManagerTestCondition) ... Process Process-
48:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 600, in f
    cond.acquire()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 946, in acquire
    return self._callmethod('acquire', (blocking,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 718, in _callmethod
    self._connect()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 705, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/connection.py", 
line 133, in Client
    c = SocketClient(address)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/connection.py", 
line 254, in SocketClient
    s.connect(address)
  File "<string>", line 1, in connect
error: [Errno 61] Connection refused
^CProcess PoolWorker-5:4:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
Process PoolWorker-5:3:
Traceback (most recent call last):
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 337, in get
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
    racquire()
KeyboardInterrupt
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 337, in get
    racquire()
KeyboardInterrupt
Process PoolWorker-5:1:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
Process Process-50:
Process Process-49:
Traceback (most recent call last):
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 339, in get
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 602, in f
    return recv()
KeyboardInterrupt
    cond.wait(timeout)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 959, in wait
    return self._callmethod('wait', (timeout,))
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1786, in <module>
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt
    main()
  File "Lib/test/test_multiprocessing.py", line 1783, in main
    test_main(unittest.TextTestRunner(verbosity=2).run)
  File "Lib/test/test_multiprocessing.py", line 1773, in test_main
    run(suite)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 750, 
in run
Process PoolWorker-5:2:
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 461, 
in __call__
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 457, 
in run
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 461, 
in __call__
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 457, 
in run
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 300, 
in __call__
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 279, 
in run
    testMethod()
  File "Lib/test/test_multiprocessing.py", line 701, in test_notify_all
    sleeping.acquire()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 946, in acquire
    return self._callmethod('acquire', (blocking,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 602, in f
    cond.wait(timeout)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 959, in wait
    return self._callmethod('wait', (timeout,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt
Traceback (most recent call last):


Failed run 2
------------
test_task_done (__main__.WithManagerTestQueue) ... ok
test_remote (__main__.WithManagerTestRemoteManager) ... ERROR
test_bounded_semaphore (__main__.WithManagerTestSemaphore) ... ok
test_semaphore (__main__.WithManagerTestSemaphore) ... ok
test_timeout (__main__.WithManagerTestSemaphore) ... ok
test_getobj_getlock (__main__.WithManagerTestValue) ... ok
test_rawvalue (__main__.WithManagerTestValue) ... ok
test_value (__main__.WithManagerTestValue) ... ok
test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ... 
ok

======================================================================
ERROR: test_remote (__main__.WithManagerTestRemoteManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1157, in test_remote
    queue = manager2.get_queue()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 635, in temp
    authkey=self._authkey, exposed=exp
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 887, in AutoProxy
    incref=incref)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 696, in __init__
    self._incref()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 743, in _incref
    dispatch(conn, None, 'incref', (self._id,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 79, in dispatch
    raise convert_to_error(kind, result)
RemoteError: 
------------------------------------------------------------------------
---
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 181, in handle_request
    result = func(c, *args, **kwds)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 397, in incref
    self.id_to_refcount[ident] += 1
KeyError: '5bf968'
------------------------------------------------------------------------
---

----------------------------------------------------------------------
Ran 121 tests in 9.230s

FAILED (errors=1)

Failed run 3
------------
test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ...   
680490:       refcount=1
    <threading._Semaphore object at 0x680490>
  680bd0:       refcount=1
    <multiprocessing.pool.Pool object at 0x680bd0>
FAIL

======================================================================
FAIL: test_number_of_objects 
(__main__.WithManagerTestZZZNumberOfObjects)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1042, in 
test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 2 != 1

----------------------------------------------------------------------
Ran 121 tests in 9.228s

FAILED (failures=1)

Failed run 4
------------
test_notify_all (__main__.WithManagerTestCondition) ... Process Process-
50:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 600, in f
    cond.acquire()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 946, in acquire
    return self._callmethod('acquire', (blocking,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 718, in _callmethod
    self._connect()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 705, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/connection.py", 
line 133, in Client
    c = SocketClient(address)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/connection.py", 
line 254, in SocketClient
    s.connect(address)
  File "<string>", line 1, in connect
error: [Errno 61] Connection refused
^CProcess PoolWorker-5:4:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
Process PoolWorker-5:3:
Traceback (most recent call last):
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 337, in get
    racquire()
    self.run()
KeyboardInterrupt
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 337, in get
    racquire()
KeyboardInterrupt
Process PoolWorker-5:1:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
Process Process-48:
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
    task = get()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 339, in get
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    return recv()
KeyboardInterrupt
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 602, in f
    cond.wait(timeout)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 959, in wait
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1786, in <module>
    return self._callmethod('wait', (timeout,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt
    main()
  File "Lib/test/test_multiprocessing.py", line 1783, in main
    test_main(unittest.TextTestRunner(verbosity=2).run)
  File "Lib/test/test_multiprocessing.py", line 1773, in test_main
Process PoolWorker-5:2:
    run(suite)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 750, 
in run
Traceback (most recent call last):
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 461, 
in __call__
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 457, 
in run
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 461, 
in __call__
    self.run()
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 457, 
in run
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/pool.py", line 
57, in worker
    test(result)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 300, 
in __call__
    return self.run(*args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/unittest.py", line 279, 
in run
    task = get()
    testMethod()
  File "Lib/test/test_multiprocessing.py", line 701, in test_notify_all
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/queues.py", 
line 337, in get
    sleeping.acquire()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 946, in acquire
    racquire()
KeyboardInterrupt
    return self._callmethod('acquire', (blocking,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt
Process Process-49:
Traceback (most recent call last):
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    self.run()
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 602, in f
    cond.wait(timeout)
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 959, in wait
    return self._callmethod('wait', (timeout,))
  File 
"/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", 
line 722, in _callmethod
    kind, result = conn.recv()
KeyboardInterrupt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 08:40:19 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jul 2008 06:40:19 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216363219.12.0.0501015339327.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I should add to the previous message that this was revision 65090, and
that it was a non-debug build.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 10:41:36 2008
From: report at bugs.python.org (SukkoPera)
Date: Fri, 18 Jul 2008 08:41:36 +0000
Subject: [issue3403] Unexpected default arguments behaviour
In-Reply-To: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za>
Message-ID: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za>


New submission from SukkoPera <sr at sukkology.net>:

I have just encountered a Python behaviour I wouldn't expect. Take
the following code:

------------------------------------------------------------------------
class Parent:
        a = 1

        def m (self, param = a):
                print "param = %d" % param

class Child (Parent):
        a = 2

p = Parent ()
p.m ()

c = Child ()
c.m ()
------------------------------------------------------------------------

I would expect to receive the following output:
param = 1
param = 2

But actually I get:
param = 1
param = 1

Is this the correct behaviour, and then why, or is it a bug? For
reference, I am using Python 2.5.1 on GNU/Linux.

There has been a short discussion about this at
http://groups.google.it/group/comp.lang.python/browse_thread/thread/9f740eea131e7ef2/56fd4e120a069a1d#56fd4e120a069a1d.

----------
components: None
messages: 69943
nosy: SukkoPera
severity: normal
status: open
title: Unexpected default arguments behaviour
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3403>
_______________________________________

From report at bugs.python.org  Fri Jul 18 11:01:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 09:01:10 +0000
Subject: [issue3403] Unexpected default arguments behaviour
In-Reply-To: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za>
Message-ID: <1216371670.22.0.374026252891.issue3403@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is another "problem" due to the fact that parameter defaults are
evaluated once during function definition, not every time the function
is called. This is expected and will not change.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3403>
_______________________________________

From report at bugs.python.org  Fri Jul 18 11:02:05 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 18 Jul 2008 09:02:05 +0000
Subject: [issue3389] [PATCH] Allow custom logging Handlers in logging config
	files
In-Reply-To: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za>
Message-ID: <1216371724.89.0.872653447452.issue3389@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Checked into SVN.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3389>
_______________________________________

From report at bugs.python.org  Fri Jul 18 11:37:12 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Fri, 18 Jul 2008 09:37:12 +0000
Subject: [issue2674] unittest.TestProgram uses sys.exit()
In-Reply-To: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>
Message-ID: <1216373832.76.0.0307278877054.issue2674@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

I was bothered by this 'bug' ages ago, and I was work-arounding it. So
now I've spent some time in 'fixing' it with the patches on issue #3379.

----------
nosy: +pupeno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2674>
_______________________________________

From report at bugs.python.org  Fri Jul 18 12:40:27 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 18 Jul 2008 10:40:27 +0000
Subject: [issue3404] wrong precision in float formatting
In-Reply-To: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>
Message-ID: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

This seems to be wrong:

>>> "{0:.2}".format(1.2345)
'1.2'

The same happens for format specifiers "g" and "n", but not for "f":

>>> "{0:.2f}".format(1.2345)
'1.23'

With empty format specifier it can even get really wrong:

>>> "{0:.1}".format(1.2345)
'1.0'

----------
components: Interpreter Core
messages: 69947
nosy: hagen
severity: normal
status: open
title: wrong precision in float formatting
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3404>
_______________________________________

From report at bugs.python.org  Fri Jul 18 12:54:33 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 18 Jul 2008 10:54:33 +0000
Subject: [issue3404] wrong precision in float formatting or doc error
In-Reply-To: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>
Message-ID: <1216378473.42.0.740992820725.issue3404@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Just found it documented for the % operator: There precision is number
of digits before and after decimal point for format "g". 

But then the documentation for 2.6 is wrong:

"The precision is a decimal number indicating how many digits should be
displayed after the decimal point for a floating point value."

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
title: wrong precision in float formatting -> wrong precision in float formatting or doc error
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3404>
_______________________________________

From report at bugs.python.org  Fri Jul 18 13:15:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 11:15:18 +0000
Subject: [issue3404] wrong precision in float formatting or doc error
In-Reply-To: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za>
Message-ID: <1216379718.74.0.985894522035.issue3404@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed docs in r65099.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3404>
_______________________________________

From report at bugs.python.org  Fri Jul 18 14:32:00 2008
From: report at bugs.python.org (cfr)
Date: Fri, 18 Jul 2008 12:32:00 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216384320.2.0.801541614521.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

A work-around when using python from a shell environment (e.g. from a
bash shell in Terminal) is to issue

export __CF_USER_TEXT_ENCODING=0x1F5:0:0

before starting python. I haven't yet worked out how to apply this to
GUI apps. I tried editing ~/.MacOSX/environment.plist and
~/.CFUserTextEncoding but neither strategy prevents the crash.

I assume the fix works because it means one of the explicitly listed
encodings matches so things never get as far as the code which triggers
the error.

Without the fix, my environment contained

__CF_USER_TEXT_ENCODING=0x1F5:39:79

which does not, apparently, correspond to any of the encodings
explicitly listed in _localemodule.c.

- cfr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Fri Jul 18 14:52:46 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 18 Jul 2008 12:52:46 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Follows a patch that adds support for the new data option supported
event generate. It allows virtual events to pass a tcl object.

This patch is only intended to correctly support tcl objects, trying to
pass other objects (like a dict) will result in None being returned. If
you want to correctly pass and receive a dict, make it an attribute of
the tcl object being passed.

E.g.:

import Tkinter

def handle_it(event):
    print event.data.something

root = Tkinter.Tk()
root.something = {1: 2}
root.after(1, lambda: root.event_generate('<<Test>>', data=root))
root.bind('<<Test>>', handle_it)
root.mainloop()

----------
components: Tkinter
files: event_generate__data.diff
keywords: patch
messages: 69951
nosy: gpolo
severity: normal
status: open
title: Add support for the new data option supported by event generate (Tk 8.5)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10934/event_generate__data.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Fri Jul 18 15:02:52 2008
From: report at bugs.python.org (WoLpH)
Date: Fri, 18 Jul 2008 13:02:52 +0000
Subject: [issue3406] LocaleTextCalendar and LocaleHTMLCalendar break without a
	locale
In-Reply-To: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za>
Message-ID: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za>


New submission from WoLpH <Rick.van.Hattem at Fawo.nl>:

Steps to reproduce:
>>> import calendar
>>> calendar.LocaleHTMLCalendar()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/calendar.py", line 540, in __init__
    locale = locale.getdefaultlocale()
AttributeError: 'NoneType' object has no attribute 'getdefaultlocale'

The same goes for LocaleTextCalendar, the problem is caused by this 
code which obviously would never work:
if locale is None:
    locale = locale.getdefaultlocale()

The fix should be quite easy, rename the local variable and it will 
work again :)

----------
components: Extension Modules
messages: 69952
nosy: WoLpH
severity: normal
status: open
title: LocaleTextCalendar and LocaleHTMLCalendar break without a locale
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3406>
_______________________________________

From report at bugs.python.org  Fri Jul 18 15:07:16 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 18 Jul 2008 13:07:16 +0000
Subject: [issue3372] socket.setsockopt() is broken for multicast TTL and Loop
	options
In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za>
Message-ID: <1216386436.06.0.202159748177.issue3372@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This is already fixed in release24-maint, release25-maint, trunk and py3k.

----------
nosy: +gpolo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3372>
_______________________________________

From report at bugs.python.org  Fri Jul 18 15:13:34 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 18 Jul 2008 13:13:34 +0000
Subject: [issue3406] LocaleTextCalendar and LocaleHTMLCalendar break without a
	locale
In-Reply-To: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za>
Message-ID: <1216386814.27.0.739972444769.issue3406@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This was fixed in r45302 and r58936

----------
nosy: +gpolo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3406>
_______________________________________

From report at bugs.python.org  Fri Jul 18 16:43:02 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 18 Jul 2008 14:43:02 +0000
Subject: [issue3088] test_multiprocessing hangs intermittently on POSIX
	platforms
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1216392182.53.0.94496326406.issue3088@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I confirm this is solved for me in beta 2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3088>
_______________________________________

From report at bugs.python.org  Fri Jul 18 17:08:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jul 2008 15:08:52 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216393732.81.0.0875181107279.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like this isn't just me.  See the buildbot output at:

http://www.python.org/dev/buildbot/all/x86%20osx.5%20trunk/builds/33/ste
p-test/0

which shows:

test_multiprocessing
Assertion failed: (bp != NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 746.
test test_multiprocessing failed -- errors occurred; run in verbose mode 
for details

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Jul 18 18:10:49 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 18 Jul 2008 16:10:49 +0000
Subject: [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1216397448.83.0.659411921632.issue3346@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Works fine in beta2.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________

From report at bugs.python.org  Fri Jul 18 18:11:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 16:11:44 +0000
Subject: [issue3346] test_ossaudiodev fails
In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za>
Message-ID: <1216397504.43.0.342655704081.issue3346@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3346>
_______________________________________

From report at bugs.python.org  Fri Jul 18 19:00:21 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 18 Jul 2008 17:00:21 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1216400421.09.0.963019027948.issue3358@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Just as an added note: with the new changes made to fix_imports, this is
now noticeably slower than the recursive approach, even after I made a
few optimizations like removing the unnecessary len() in the while loop.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Fri Jul 18 19:25:12 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 18 Jul 2008 17:25:12 +0000
Subject: [issue3334] 2to3 looses indentation on import fix
In-Reply-To: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>
Message-ID: <1216401912.28.0.846521692059.issue3334@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I believe the problem was that in the case of this fix, rather than
using set_prefix to give the new node the same prefix as before,
new.prefix = was used. Here is the one line fix which preserves the
prefix in the example given.

----------
keywords: +patch
nosy: +nedds
Added file: http://bugs.python.org/file10935/fix_import.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3334>
_______________________________________

From report at bugs.python.org  Fri Jul 18 19:50:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 17:50:58 +0000
Subject: [issue3376] Use Python 3 lexer for 3.0 docs
In-Reply-To: <1216403458.56.0.508505661401.issue3376@psf.upfronthosting.co.za>
Message-ID: <1216403458.56.0.508505661401.issue3376@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:

I'm attaching two patches. One, for the Sphinx trunk, adds a
pygments_default_lexer option. The other, for the py3k branch, changes
the default lexer to python3. It also includes a rather hacky, overriden
highlightlang directive that changes the lexer from 'python' to
'python3' and calls the real highlightlang directive. This would
probably be better solved by adding a lexer_aliases option or something
to Sphinx. Note this doesn't work because the pygments version in SVN
doesn't have the Python 3 lexer.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file10936/default_lexer_option.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3376>
_______________________________________

From report at bugs.python.org  Fri Jul 18 19:51:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 17:51:35 +0000
Subject: [issue3376] Use Python 3 lexer for 3.0 docs
In-Reply-To: <1216403458.56.0.508505661401.issue3376@psf.upfronthosting.co.za>
Message-ID: <1216403495.12.0.913225143172.issue3376@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


Added file: http://bugs.python.org/file10937/for_py3k_branch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3376>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:00:50 2008
From: report at bugs.python.org (Ron Longo)
Date: Fri, 18 Jul 2008 18:00:50 +0000
Subject: [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1216404050.95.0.100851757402.issue2638@psf.upfronthosting.co.za>


Ron Longo <ron.longo at cox.net> added the comment:

Excellent!  That solution works as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2638>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:10:53 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 18 Jul 2008 18:10:53 +0000
Subject: [issue2894] 2to3 discards comments before import statements
In-Reply-To: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
Message-ID: <1216404653.83.0.0473664556008.issue2894@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

This seems to have been the same problem that was causing whitespace to
get lost before some imports. I believe the fix_import change I provided
in that issue, issue 3334, also corrects this problem.

----------
nosy: +nedds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2894>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:27:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 18:27:08 +0000
Subject: [issue2894] 2to3 discards comments before import statements
In-Reply-To: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
Message-ID: <1216405628.56.0.735005995414.issue2894@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

I still this problem with the latest version of 2to3.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2894>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:29:26 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 18 Jul 2008 18:29:26 +0000
Subject: [issue2894] 2to3 discards comments before import statements
In-Reply-To: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
Message-ID: <1216405766.07.0.642338197846.issue2894@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Yeah sorry. I can't commit changes, so I have the diff in the other
issue but it has not yet been committed. Here it is again for redundancy.

----------
keywords: +patch
Added file: http://bugs.python.org/file10938/fix_import.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2894>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:35:23 2008
From: report at bugs.python.org (Karen Tracey)
Date: Fri, 18 Jul 2008 18:35:23 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1216406122.98.0.954292591281.issue1242657@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

This behavior has reappeared in the 2.6 beta releases:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class F(object):
...     def __iter__(self):
...         yield 23
...     def __len__(self):
...         print 'len called, raising KeyboardInterrupt'
...         raise KeyboardInterrupt
... 
>>> f = F()
>>> list(f)
len called, raising KeyboardInterrupt
[23]

Should a new bug be opened for this?  (I can't find one but I'm not too
experienced searchign Python's bug tracker.)

----------
nosy: +kmtracey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:35:38 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 18 Jul 2008 18:35:38 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1216406138.14.0.793571709366.issue2532@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

My iterative pattern matching doesn't break on this file, but as
mentioned elsewhere, the iterative solution is slower. I'll work on
speeding it up, but I don't immediately see a good way to do so. Any
ideas would be greatly appreciated.

----------
nosy: +nedds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2532>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:38:30 2008
From: report at bugs.python.org (engelbert gruber)
Date: Fri, 18 Jul 2008 18:38:30 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1216406310.68.0.290492609722.issue1513299@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

and now it is 2.6 ?

----------
nosy: +grubert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:42:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 18:42:31 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1216406551.0.0.28992176058.issue1513299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

May even be too late for 2.6. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:46:36 2008
From: report at bugs.python.org (engelbert gruber)
Date: Fri, 18 Jul 2008 18:46:36 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
In-Reply-To: <1216406551.0.0.28992176058.issue1513299@psf.upfronthosting.co.za>
Message-ID: <ac12bf3a0807181146h434151c7lb95ce9e48c342562@mail.gmail.com>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

i just wanted to get rid of one "python2.6 -3" warning in string and
found that a patch was already waiting. from this thing i conclude
smaller patches might get committed earlier , do they ?

On Fri, Jul 18, 2008 at 8:42 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> May even be too late for 2.6. :)
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1513299>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:47:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 18:47:46 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1216406866.24.0.862536528393.issue1513299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is true. Barry might not want to allow a large catch-all patch; but
since those changes are not adding new features, simple small ones can
certainly get in before beta3.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:47:54 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 18 Jul 2008 18:47:54 +0000
Subject: [issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
Message-ID: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) with Python 2.6b2 (and 3.0b2), see 
below.

The same test also failed for Python 2.6b1 but was not reported as a test failure.


% ./python.exe 
Python 2.6b2 (r26b2:65082, Jul 18 2008, 09:00:40) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

% ./python.exe Lib/test/test_urllib2_localnet.py
test_proxy_qop_auth_int_works_or_throws_urlerror (__main__.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (__main__.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (__main__.ProxyAuthTests) ... ok
test_proxy_with_no_password_raises_httperror (__main__.ProxyAuthTests) ... ok

----------------------------------------------------------------------
Ran 4 tests in 4.233s

OK
test_200 (__main__.TestUrlopen) ... ok
test_200_with_parameters (__main__.TestUrlopen) ... ok
test_404 (__main__.TestUrlopen) ... ok
test_bad_address (__main__.TestUrlopen) ... FAIL
test_basic (__main__.TestUrlopen) ... ok
test_geturl (__main__.TestUrlopen) ... ok
test_info (__main__.TestUrlopen) ... ok
test_redirection (__main__.TestUrlopen) ... ok
test_sending_headers (__main__.TestUrlopen) ... ok

======================================================================
FAIL: test_bad_address (__main__.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address
    urllib2.urlopen, "http://www.python.invalid./")
AssertionError: IOError not raised

----------------------------------------------------------------------
Ran 9 tests in 9.486s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_urllib2_localnet.py", line 491, in <module>
    test_main()
  File "Lib/test/test_urllib2_localnet.py", line 488, in test_main
    test_support.run_unittest(TestUrlopen)
  File ".../Python-2.6b2/Lib/test/test_support.py", line 731, in run_unittest
    _run_suite(suite)
  File ".../Python-2.6b2/Lib/test/test_support.py", line 714, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address
    urllib2.urlopen, "http://www.python.invalid./")
AssertionError: IOError not raised

----------
components: Tests
messages: 69971
nosy: MrJean1
severity: normal
status: open
title: test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3407>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:50:23 2008
From: report at bugs.python.org (engelbert gruber)
Date: Fri, 18 Jul 2008 18:50:23 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
In-Reply-To: <1216406866.24.0.862536528393.issue1513299@psf.upfronthosting.co.za>
Message-ID: <ac12bf3a0807181150td635e01g8892fbb50c83d355@mail.gmail.com>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

so i add a one liner replacing map(None with list ?

On 7/18/08, Georg Brandl <report at bugs.python.org> wrote:
>
>  Georg Brandl <georg at python.org> added the comment:
>
>
> That is true. Barry might not want to allow a large catch-all patch; but
>  since those changes are not adding new features, simple small ones can
>  certainly get in before beta3.
>
>
>  _______________________________________
>  Python tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue1513299>
>  _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:51:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 18:51:02 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1216407062.02.0.0555703717765.issue1242657@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reopening. For reference, the revision in which Raymond supposedly fixed
this is r39305.

----------
nosy: +georg.brandl
priority: normal -> critical
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:53:38 2008
From: report at bugs.python.org (vizcayno)
Date: Fri, 18 Jul 2008 18:53:38 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>


New submission from vizcayno <vizcaynot at gmail.com>:

I am under Win XP sp 3:
After importing urllib it only shows a few objects when using dir() 
urllib2 module does not exist.

.python
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> dir(urllib)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__pa
th__']
>>> import urllib2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named urllib2
>>>

----------
components: Windows
messages: 69974
nosy: vizcayno
severity: normal
status: open
title: urllib incomplete and urllib2 does not exist
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:53:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 18:53:58 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1216407238.77.0.516283489487.issue1513299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I can replace those too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:56:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 18:56:15 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216407375.18.0.380088956178.issue3408@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is expected. (Most of) the content of Python 2's urllib and urllib2
modules is now in the urllib.request submodule.  Look at the
documentation in http://docs.python.org/dev/3.0/library/urllib.request
for more details.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 20:57:35 2008
From: report at bugs.python.org (engelbert gruber)
Date: Fri, 18 Jul 2008 18:57:35 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
In-Reply-To: <1216407238.77.0.516283489487.issue1513299@psf.upfronthosting.co.za>
Message-ID: <ac12bf3a0807181157m3bae9eb8w65a59639bafdc63f@mail.gmail.com>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

it is only one in string.py, but then again it is save to do.

thanks

On 7/18/08, Georg Brandl <report at bugs.python.org> wrote:
>
>  Georg Brandl <georg at python.org> added the comment:
>
>
> I can replace those too.
>
>
>  _______________________________________
>  Python tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue1513299>
>  _______________________________________
>

Added file: http://bugs.python.org/file10939/lib_string-r65106

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_string-r65106
Type: application/octet-stream
Size: 925 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080718/0003e93f/attachment.obj>

From report at bugs.python.org  Fri Jul 18 20:58:15 2008
From: report at bugs.python.org (Karen Tracey)
Date: Fri, 18 Jul 2008 18:58:15 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1216407495.49.0.814099763715.issue1242657@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

Thanks for responding.

It had been fixed.  2.4/2.5 behave like so:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class F(object):
...     def __iter__(self):
...         yield 23
...     def __len__(self):
...         print 'len called, raising KeyboardInterrupt'
...         raise KeyboardInterrupt
... 
>>> f = F()
>>> list(f)
len called, raising KeyboardInterrupt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in __len__
KeyboardInterrupt
>>> 

It just seems to have regressed in 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:00:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 19:00:02 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1216407602.31.0.38545049138.issue1242657@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm sorry, my use of "supposedly" was wrong here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:06:59 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 19:06:59 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1216408019.46.0.232936588809.issue1513299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I nixed the "simple" uses of map(None, a).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:15:05 2008
From: report at bugs.python.org (engelbert gruber)
Date: Fri, 18 Jul 2008 19:15:05 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
In-Reply-To: <1216408019.46.0.232936588809.issue1513299@psf.upfronthosting.co.za>
Message-ID: <ac12bf3a0807181215o15a54d6am46ac48d9afe5279f@mail.gmail.com>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

http://bugs.python.org/issue3390 is similar trivial , replacing has_key by in
(this small patches might be considered tweaking the bugfix statistic)

i am off now (tell me if you think i should stay there)

On 7/18/08, Georg Brandl <report at bugs.python.org> wrote:
>
>  Georg Brandl <georg at python.org> added the comment:
>
>
> OK, I nixed the "simple" uses of map(None, a).
>
>
>  _______________________________________
>  Python tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue1513299>
>  _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1513299>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:22:21 2008
From: report at bugs.python.org (vizcayno)
Date: Fri, 18 Jul 2008 19:22:21 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216408941.94.0.747786346904.issue3408@psf.upfronthosting.co.za>


vizcayno <vizcaynot at gmail.com> added the comment:

Thanks Georg.
Python 3.0b2 on line manual continues indicating with explanation and 
some examples that import urllib and import urllib2 are valid. Do you 
recommend me to open another issue about this?
Regards.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:26:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 19:26:52 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216409212.35.0.299514116882.issue3408@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, but you can also post them here, I'll fix it ASAP.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:30:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 19:30:23 +0000
Subject: [issue3390] [PATCH] replace last has_key in unittest by in operator
In-Reply-To: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za>
Message-ID: <1216409423.48.0.872835510021.issue3390@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed in r65111.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3390>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:41:19 2008
From: report at bugs.python.org (vizcayno)
Date: Fri, 18 Jul 2008 19:41:19 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216410079.21.0.459060660673.issue3408@psf.upfronthosting.co.za>


vizcayno <vizcaynot at gmail.com> added the comment:

Ok.

In the python 3.0b2 on line documentation that comes with the .msi 
installer:

1) Search with word urllib and access the fourth line found: "urllib ? 
Open arbitrary resources by URL" 

2) Search with word urllib2 and select first line found: urllib2 ? 
extensible library for opening URLs.

In these cases documentation refers to 3.0b1, I must say.

Many thanks for your attention and guidelines.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:45:25 2008
From: report at bugs.python.org (Uwe Hoffmann)
Date: Fri, 18 Jul 2008 19:45:25 +0000
Subject: [issue3409] ElementPath.Path.findall problem with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>


New submission from Uwe Hoffmann <qual at tiscali.de>:

if you call Element.findall(u".......") some silent errors can 
occure because of the isinstance(....,type("")) check. I'm
not sure if it is even allowed to call findall with a unicode parameter.
The attached diff solves *my* problem.

----------
components: Library (Lib), Unicode
files: ElementPath.diff
keywords: patch
messages: 69986
nosy: qual
severity: normal
status: open
title: ElementPath.Path.findall problem with unicode input
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10940/ElementPath.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________

From report at bugs.python.org  Fri Jul 18 21:49:55 2008
From: report at bugs.python.org (Felipe Portella)
Date: Fri, 18 Jul 2008 19:49:55 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>


New submission from Felipe Portella <felipe at portella.com.br>:

Using Vista in Portuguese platform.version is returning "32bits" 
instead of "6.0.6001". This is because in file platform.py line 379 
thee regular expression try to search for the word "Version" in 
english, while in Portuguese the command ver will return "Vers?o".

To solve this issue simple change:

'Version ([\d.]+))')

for

 '\S+ ([\d.]+))')

----------
components: Library (Lib)
messages: 69987
nosy: portella
severity: normal
status: open
title: platform.version() don't work as expected in Vista in portuguese
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Fri Jul 18 22:09:22 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 18 Jul 2008 20:09:22 +0000
Subject: [issue3411] str.format() on negative floats
In-Reply-To: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>
Message-ID: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

This happens with an empty type field in the format specification:

>>> "{0:1}".format(-1.23)
'.0-1.23'

With type "g" it's ok:

>>> "{0:1g}".format(-1.23)
'-1.23'

----------
components: Library (Lib)
messages: 69988
nosy: hagen
severity: normal
status: open
title: str.format() on negative floats
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3411>
_______________________________________

From report at bugs.python.org  Fri Jul 18 22:51:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 20:51:39 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1216414299.51.0.171173198792.issue3410@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


----------
assignee:  -> lemburg
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Fri Jul 18 22:53:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jul 2008 20:53:39 +0000
Subject: [issue3411] str.format() on negative floats
In-Reply-To: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>
Message-ID: <1216414419.25.0.816381268393.issue3411@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin.peterson at usfamily.net>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3411>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:00:28 2008
From: report at bugs.python.org (Jeremy Hylton)
Date: Fri, 18 Jul 2008 21:00:28 +0000
Subject: [issue3347] urllib.robotparser doesn't work in Py3k
In-Reply-To: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za>
Message-ID: <1216414828.7.0.311624012112.issue3347@psf.upfronthosting.co.za>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Committed revision 65118.

I applied a simple version of this patch and added a unittest.

----------
assignee:  -> jhylton
nosy: +jhylton
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3347>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:19:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 21:19:53 +0000
Subject: [issue3408] urllib incomplete and urllib2 does not exist
In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za>
Message-ID: <1216415993.88.0.90840705913.issue3408@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I see. The CHM file includes some old files that weren't cleaned up
after the urllib and urllib2 modules were removed. This should be fixed
for the coming releases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3408>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:28:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 21:28:14 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216416494.65.0.596779017277.issue3379@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Barry, this looks useful and shouldn't be at all disruptive even after
beta2. May I check it in?

----------
assignee:  -> barry
nosy: +barry, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:36:09 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 18 Jul 2008 21:36:09 +0000
Subject: [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think that when floating point number limitations are mentioned we
should also tell that there are alternatives for processing numbers with
decimal extensions. I wrote a text that introduces the Decimal and the
Fraction type to the reader.

----------
assignee: georg.brandl
components: Documentation
files: floating
messages: 69992
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: Fraction and Decimal in the Tutorial
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10941/floating

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:36:23 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 18 Jul 2008 21:36:23 +0000
Subject: [issue3410] platform.version() don't work as expected in Vista in
	portuguese
In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za>
Message-ID: <1216416983.33.0.135104132534.issue3410@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Could you please check whether this is still the case with the current
version of platform.py we have in SVN ?

http://svn.python.org/view/python/trunk/Lib/platform.py?rev=64233&view=markup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3410>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:45:50 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jul 2008 21:45:50 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216417550.88.0.921759165074.issue3379@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm not sure it's a good idea.  When exit=False, don't you lose the
results?  It would be better to return the results, but then that makes
for an ugly API (changing the return value based on an argument is a
general no-no in Python).

It would seem better to add a new method that returned the results
instead of exiting.  You'd probably want to refactor runTests().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:49:25 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 18 Jul 2008 21:49:25 +0000
Subject: [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216417765.72.0.574687129218.issue3412@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Updated file to fix a minor problem

Added file: http://bugs.python.org/file10942/floating.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________

From report at bugs.python.org  Fri Jul 18 23:49:29 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 18 Jul 2008 21:49:29 +0000
Subject: [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216417769.41.0.393755668784.issue3412@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file10941/floating

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________

From report at bugs.python.org  Sat Jul 19 00:45:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jul 2008 22:45:49 +0000
Subject: [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216421149.6.0.978120664966.issue3412@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll build-out the discussion a bit and mention the new float.hex() and 
float.as_integer_ratio() methods.  Will also add references to decimal 
and fractions.

----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________

From report at bugs.python.org  Sat Jul 19 00:52:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Jul 2008 22:52:46 +0000
Subject: [issue3355] Display bug in :show-inheritance: for class with standard
	docstring
In-Reply-To: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za>
Message-ID: <1216421566.68.0.693079324727.issue3355@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65123. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3355>
_______________________________________

From report at bugs.python.org  Sat Jul 19 00:54:32 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 18 Jul 2008 22:54:32 +0000
Subject: [issue3412] Fraction and Decimal in the Tutorial
In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za>
Message-ID: <1216421672.13.0.814562347588.issue3412@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file10943/floating.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3412>
_______________________________________

From report at bugs.python.org  Sat Jul 19 02:34:33 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 19 Jul 2008 00:34:33 +0000
Subject: [issue3411] str.format() on negative floats
In-Reply-To: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za>
Message-ID: <1216427673.68.0.147518536883.issue3411@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Thanks for catching this.  I was not skipping the leading sign char when
looking for the decimal point in the string, which was causing me to
incorrectly determine that a decimal wasn't present.

Fixed in r65125 (trunk) and r65126 (py3k).

----------
components: +Interpreter Core -Library (Lib)
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3411>
_______________________________________

From report at bugs.python.org  Sat Jul 19 02:56:13 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 19 Jul 2008 00:56:13 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1216428973.05.0.390256763447.issue2772@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee: eric.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Sat Jul 19 04:19:25 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jul 2008 02:19:25 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1216433965.02.0.327440307344.issue3344@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Sat Jul 19 04:27:06 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jul 2008 02:27:06 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1216434426.18.0.673475616561.issue3344@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This looks as straightforward as patches get.
I verified that itertools.count is not used elsewhere in the file,
so it is ok to zap the import.  Suggest apply.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Sat Jul 19 04:35:26 2008
From: report at bugs.python.org (George Boutsioukis)
Date: Sat, 19 Jul 2008 02:35:26 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1216434926.71.0.544799308946.issue1869@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

The issue is that the implementation of round includes multiplying the
number by 10**ndigits, thus unnecessarily losing some precision for
large numbers within the IEEE754 double limits. This means that even
smaller numbers can produce these results for higher ndigit values, eg.

>>> round(56294995342131.5, 3) #one less digit
56294995342131.508

In the submitted patch I used modf to split the number and keep the
integral intact.

----------
keywords: +patch
nosy: +gboutsioukis
Added file: http://bugs.python.org/file10944/round_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Sat Jul 19 04:48:34 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 19 Jul 2008 02:48:34 +0000
Subject: [issue3413] typo in Mac/Makefile.in breaks installing IDLE
In-Reply-To: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za>
Message-ID: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

There's a slight typo in Mac/Makefile.in, where DESDIR was used instead of DESTDIR. This 
patch fixes it:

--- /tmp/Makefile.in	2008-07-18 19:42:29.000000000 -0700
+++ Mac/Makefile.in	2008-07-18 19:42:33.000000000 -0700
@@ -216,7 +216,7 @@
 	test -d "$(DESTDIR)$(PYTHONAPPSDIR)" || mkdir -p "$(DESTDIR)$(PYTHONAPPSDIR)"
 	-test -d "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app" && rm -r 
"$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app"
 	cp -PR IDLE/IDLE.app "$(DESTDIR)$(PYTHONAPPSDIR)"
-	ln -sf $(INSTALLED_PYTHONAPP) 
"$(DESDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python"
+	ln -sf $(INSTALLED_PYTHONAPP) 
"$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python"
 	touch "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app"
 
 $(INSTALLED_PYTHONAPP): install_Python

----------
components: Build
messages: 70001
nosy: erickt
severity: normal
status: open
title: typo in Mac/Makefile.in breaks installing IDLE
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3413>
_______________________________________

From report at bugs.python.org  Sat Jul 19 04:57:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 02:57:08 +0000
Subject: [issue3413] typo in Mac/Makefile.in breaks installing IDLE
In-Reply-To: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za>
Message-ID: <1216436228.28.0.0155187285846.issue3413@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Thanks! Fixed in r65129.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3413>
_______________________________________

From report at bugs.python.org  Sat Jul 19 05:59:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jul 2008 03:59:29 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1216439969.19.0.577672156444.issue2772@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think this is premature until be know for sure that % formatting will 
in-fact be deprecated in Py3.1.  Time will tell how well the new format 
options get accepted.  Likewise, we'll learn more about how readily 
legacy code can get converted.

Guido, can you pronouce?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Sat Jul 19 06:07:32 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 19 Jul 2008 04:07:32 +0000
Subject: [issue3414] frameworkinstall doesn't create Python.app,
	which breaks python
In-Reply-To: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za>
Message-ID: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Hello again!

It looks like doing "make frameworkinstall maninstall" isn't creating 
"Python.framework/Versions/3.0/Resources/Python.app", so when I try to 
run python it errors out with: "python3.0: execv: 
/opt/local/Library/Frameworks/Python.framework/Versions/3.0/Resources/Py
thon.app/Contents/MacOS/Python: No such file or directory". In order to 
get that file created, I need to manually run "cd Mac && make 
install_Python".

This patch fixes it, but I'm not sure if this is the proper fix:

--- Mac/Makefile.in.old	2008-07-18 20:59:44.000000000 -0700
+++ Mac/Makefile.in	2008-07-18 20:57:44.000000000 -0700
@@ -46,7 +46,7 @@
 compileall=$(srcdir)/../Lib/compileall.py
 
 installapps: install_PythonLauncher install_IDLE checkapplepython 
install_pythonw \
-	install_versionedtools
+	install_versionedtools install_Python
 
 installapps4way: install_Python4way install_BuildApplet 
install_PythonLauncher install_IDLE install_pythonw4way 
install_versionedtools

----------
components: Build
messages: 70004
nosy: erickt
severity: normal
status: open
title: frameworkinstall doesn't create Python.app, which breaks python
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3414>
_______________________________________

From report at bugs.python.org  Sat Jul 19 07:32:35 2008
From: report at bugs.python.org (Nir)
Date: Sat, 19 Jul 2008 05:32:35 +0000
Subject: [issue3415] Interpreter error when running a script under debugger
	control
In-Reply-To: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>
Message-ID: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>


New submission from Nir <nir at winpdb.org>:

Interpreter error results in erroneous exception when running a script
under debugger control.

Full repro description:
On Windows System, try to run idle.py under the inspection of pdb.py. 
Note that you must set a breakpoint somewhere otherwise pdb will not
trace the script and the issue will not surface.

You should get the bad exception in line 295 of multicall.py

Python complains that a local variable has been used before being
declared while in effect it has been a couple of lines before that point.

Nir

----------
components: Interpreter Core
messages: 70005
nosy: nirai
severity: normal
status: open
title: Interpreter error when running a script under debugger control
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3415>
_______________________________________

From report at bugs.python.org  Sat Jul 19 08:39:44 2008
From: report at bugs.python.org (engelbert gruber)
Date: Sat, 19 Jul 2008 06:39:44 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1216449583.94.0.902645506884.issue2532@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

The much simpler input might be another problem::

  # this is accepted
  b = ("a = 0\n" * 100)
  # this one breaks it
  ("a = 0\n" * 100)

this looks similar to ``map(None, t)`` on a line by itself is 
translated to ``list(map(None, t))`` and the message "You should use a 
for loop her"

----------
nosy: +grubert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2532>
_______________________________________

From report at bugs.python.org  Sat Jul 19 10:21:40 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 19 Jul 2008 08:21:40 +0000
Subject: [issue2772] Add PendingDeprecationWarning for % formatting
In-Reply-To: <1210083250.98.0.889504486731.issue2772@psf.upfronthosting.co.za>
Message-ID: <1216455700.28.0.903348090024.issue2772@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree.  That's one of the reasons I un-assigned it to me.

Well, that and I couldn't get it to pass all tests.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2772>
_______________________________________

From report at bugs.python.org  Sat Jul 19 11:37:06 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 19 Jul 2008 09:37:06 +0000
Subject: [issue3307] invalid check of _bsddb creation failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1216460226.28.0.0328287049447.issue3307@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Solved in my SVN repository. Revision 527. Testsuite updated.

Will be available in bsddb 4.7.2.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________

From report at bugs.python.org  Sat Jul 19 11:37:50 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 19 Jul 2008 09:37:50 +0000
Subject: [issue3307] invalid check of _bsddb creation failure
In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za>
Message-ID: <1216460270.34.0.489525106766.issue3307@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3307>
_______________________________________

From report at bugs.python.org  Sat Jul 19 11:44:36 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 19 Jul 2008 09:44:36 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216460676.38.0.174784500973.issue2960@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Gregory, could you possibly try my svn, revision 529?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Sat Jul 19 11:58:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 09:58:21 +0000
Subject: [issue3414] frameworkinstall doesn't create Python.app,
	which breaks python
In-Reply-To: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za>
Message-ID: <1216461501.0.0.466861667706.issue3414@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65130.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3414>
_______________________________________

From report at bugs.python.org  Sat Jul 19 12:09:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 10:09:02 +0000
Subject: [issue3378] Memory leak in pythonrun.c
In-Reply-To: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za>
Message-ID: <1216462142.68.0.166533864549.issue3378@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r65131.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3378>
_______________________________________

From report at bugs.python.org  Sat Jul 19 12:13:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 10:13:27 +0000
Subject: [issue3368] Memory leak in import.c
In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za>
Message-ID: <1216462407.82.0.896261551443.issue3368@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r65132.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3368>
_______________________________________

From report at bugs.python.org  Sat Jul 19 12:31:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 10:31:57 +0000
Subject: [issue3415] Interpreter error when running a script under debugger
	control
In-Reply-To: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>
Message-ID: <1216463517.66.0.629036389226.issue3415@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

For reference, here is the output of the pdb session:

gbr at lap ~/devel/python> ./python Lib/pdb.py Lib/idlelib/idle.py
> /home/gbr/devel/python/Lib/idlelib/idle.py(1)<module>()
-> try:
(Pdb) break multicall.py:300
***  'multicall.py' not found from sys.path
(Pdb) break idle.py:10
Breakpoint 1 at /home/gbr/devel/python/Lib/idlelib/idle.py:10
(Pdb) c
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/pdb.py", line 1275, in main
    pdb._runscript(mainpyfile)
  File "/home/gbr/devel/python/Lib/pdb.py", line 1192, in _runscript
    self.run(statement)
  File "/home/gbr/devel/python/Lib/bdb.py", line 366, in run
    exec cmd in globals, locals
  File "<string>", line 1, in <module>
  File "Lib/idlelib/idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "/home/gbr/devel/python/Lib/idlelib/PyShell.py", line 1396, in main
    shell = flist.open_shell()
  File "/home/gbr/devel/python/Lib/idlelib/PyShell.py", line 275, in
open_shell
    self.pyshell = PyShell(self)
  File "/home/gbr/devel/python/Lib/idlelib/PyShell.py", line 816, in
__init__
    OutputWindow.__init__(self, flist, None, None)
  File "/home/gbr/devel/python/Lib/idlelib/OutputWindow.py", line 16, in
__init__
    EditorWindow.__init__(self, *args)
  File "/home/gbr/devel/python/Lib/idlelib/EditorWindow.py", line 108,
in __init__
    self.text = text = MultiCallCreator(Text)(
  File "/home/gbr/devel/python/Lib/idlelib/MultiCall.py", line 294, in
MultiCallCreator
    class MultiCall (widget):
  File "/home/gbr/devel/python/Lib/idlelib/MultiCall.py", line 295, in
MultiCall
    assert issubclass(widget, Tkinter.Misc)
NameError: free variable 'widget' referenced before assignment in
enclosing scope
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /home/gbr/devel/python/Lib/idlelib/MultiCall.py(295)MultiCall()
-> assert issubclass(widget, Tkinter.Misc)
(Pdb) 


I *think* we had some similar issue with trace functions and class
scopes in the past, but can't remember where.

----------
assignee:  -> jhylton
nosy: +georg.brandl, jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3415>
_______________________________________

From report at bugs.python.org  Sat Jul 19 12:59:49 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jul 2008 10:59:49 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1216465189.42.0.77445701883.issue3302@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Added file: http://bugs.python.org/file10945/locale_none-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sat Jul 19 12:59:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jul 2008 10:59:57 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1216465197.48.0.667470475145.issue3302@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Removed file: http://bugs.python.org/file10831/locale_none.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sat Jul 19 13:17:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jul 2008 11:17:00 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216466220.47.0.337009792447.issue3322@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

To reproduce the crash, try very big negative integer as second 
argument. Example:

>>> _json.scanstring("test", -23492394)
Erreur de segmentation (core dumped)

>>> _json.scanstring(u"test", -1239239)
Erreur de segmentation (core dumped)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sat Jul 19 13:57:13 2008
From: report at bugs.python.org (Yu Xin)
Date: Sat, 19 Jul 2008 11:57:13 +0000
Subject: [issue3416] Wrong inherit in PickleHTMLBuilder
In-Reply-To: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za>
Message-ID: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za>


New submission from Yu Xin <scaner at gmail.com>:

I use sphinx-0.4.1. When I make pickle, I saw the error message:
Traceback (most recent call last):
  File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/__init__.py",
line 135, in main
    app.builder.build_update()
  File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 202, in build_update
    'out of date' % len(to_build))
  File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 241, in build
    self.write(docnames, updated_docnames, method)
  File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 277, in write
    self.write_doc(docname, doctree)
  File
"/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py",
line 459, in write_doc
    self.handle_page(docname, ctx, event_arg=doctree)
TypeError: handle_page() got an unexpected keyword argument 'event_arg'.

I inspect the class in sphinx/builder.py. 
handle_page in StandaloneHTMLBuilder is defined as "def ndle_page(self,
pagename, addctx, templatename='page.html', outfilename=None,
event_arg=None):

but handle_page in PickleHTMLBuilder is defined as "def
handle_page(self, pagename, ctx, templatename='page.html',
outfilename=None):"

the last param event_arg is missing.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70015
nosy: georg.brandl, is
severity: normal
status: open
title: Wrong inherit in PickleHTMLBuilder
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3416>
_______________________________________

From report at bugs.python.org  Sat Jul 19 14:39:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 12:39:25 +0000
Subject: [issue3302] segfault on gettext(None)
In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za>
Message-ID: <1216471165.1.0.0497095152851.issue3302@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65133.

----------
assignee: loewis -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3302>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:00:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:00:43 +0000
Subject: [issue3319] pystone.main(10) causes ZeroDivisionError
In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za>
Message-ID: <1216472443.5.0.886374867069.issue3319@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in trunk in r65135, will be merged to Py3k automatically.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3319>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:00:46 2008
From: report at bugs.python.org (webograph)
Date: Sat, 19 Jul 2008 13:00:46 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1216472446.83.0.0545614226693.issue2706@psf.upfronthosting.co.za>


webograph <webograph at eml.cc> added the comment:

this is the mentioned patch without the function pointers, in case it
better fits the python coding style.

Added file: http://bugs.python.org/file10946/datetime_datetime_division_dupcode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:01:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:01:58 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216472518.79.0.364330296678.issue3322@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bob, do you know how to fix this?

----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:02:56 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:02:56 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1216472576.79.0.599106746909.issue3321@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:09:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:09:52 +0000
Subject: [issue3323] Clarify __slots__ behaviour when inheriting
In-Reply-To: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za>
Message-ID: <1216472992.76.0.115623039231.issue3323@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a note in r65136, thanks.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3323>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:11:37 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 19 Jul 2008 13:11:37 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1216473098.0.0.189533698321.issue3311@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller, roudkerk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:12:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:12:55 +0000
Subject: [issue3330] webbrowser module doesn't correctly handle '|' character.
In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za>
Message-ID: <1216473174.97.0.288769982369.issue3330@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as invalid.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3330>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:20:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:20:16 +0000
Subject: [issue3331] Possible inconsistency in behavior of list comprehensions
	vs. generator expressions
In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za>
Message-ID: <1216473615.76.0.338438509401.issue3331@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is not a bug, see this thread:
http://mail.python.org/pipermail/python-3000/2008-July/014328.html

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3331>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:25:01 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 19 Jul 2008 13:25:01 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1216473901.58.0.0321756118247.issue3399@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ok, so for the moment, let's set aside the connection refused messages: 
that may be a case of not cleaning up a socket correctly (which is still 
bad, but not memory corruption).

Of note from the buildbot failure:
Assertion failed: (bp != NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 746.
test test_multiprocessing failed -- errors occurred; run in verbose mode 
for details

I don't know enough about obmalloc.c to state if this is a problem with 
it not being multithreaded

Here's another failure (from my own buildbot to boot):

test_multiprocessing
/Users/buildbot/buildarea/trunk.noller-
osx86/build/Lib/multiprocessing/__init__.py:82: ImportWarning: Not 
importing directory '/Users/buildbot/buildarea/trunk.noller-
osx86/build/Modules/_multiprocessing': missing __init__.py
  import _multiprocessing
Fatal Python error: Objects/tupleobject.c:169 object at 0x539d538 has 
negative ref count -606348326
make: *** [buildbottest] Abort trap
program finished with exit code 2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:33:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:33:25 +0000
Subject: [issue3334] 2to3 looses indentation on import fix
In-Reply-To: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za>
Message-ID: <1216474405.92.0.984128512064.issue3334@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Your patch works, so I applied it and added a test in sandbox r65137.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3334>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:34:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jul 2008 13:34:15 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216474455.32.0.979680861171.issue3322@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

I wrote that I'm unable to fix the bug correctly, but I wrote a patch 
to avoid the crash:
- replace begin by end in error messages: is it correct?
- use "end < 0 || len <= end" test to check scanstring() second 
argument => raise a ValueError if end value is invalid

----------
keywords: +patch
Added file: http://bugs.python.org/file10947/_json.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:34:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:34:43 +0000
Subject: [issue2894] 2to3 discards comments before import statements
In-Reply-To: <1210952262.85.0.552260999958.issue2894@psf.upfronthosting.co.za>
Message-ID: <1216474483.25.0.132199268178.issue2894@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Duplicate of #3334.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2894>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:42:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:42:52 +0000
Subject: [issue3416] Wrong inherit in PickleHTMLBuilder
In-Reply-To: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za>
Message-ID: <1216474971.98.0.298882105814.issue3416@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65138.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3416>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:47:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 19 Jul 2008 13:47:34 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1216475254.64.0.318428334093.issue2523@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't understand the second loop (where n is given). If n is given,
there should be only a single read operation, using

  max(buffer_size, n-avail)

(i.e. the way it is in patch 2). In particular, if the stream is
unbuffered, it shouldn't ever end up with buffered data.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:48:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:48:52 +0000
Subject: [issue3384] Documentation for re.findall and re.finditer lacks
	"ordering" information
In-Reply-To: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>
Message-ID: <1216475332.73.0.847041559168.issue3384@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added info in r65139.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3384>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:50:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:50:13 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216475413.01.0.967042167516.issue3359@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

At least the 2.6 docs say

"The default is to use text mode, which may convert ``'\n'`` characters
to a platform-specific representation on writing and back on reading."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:51:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 13:51:59 +0000
Subject: [issue3417] make the fix_dict fixer explicit
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin.peterson at usfamily.net>:

Can we make the part of fix_dict that converts d.items/values/keys to
list(d.items) explicit? Most of the time, it's fine if the method
returns a view and can be a bit of a performance hit to convert it to a
list.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70031
nosy: benjamin.peterson, collinwinter
severity: normal
status: open
title: make the fix_dict fixer explicit
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:52:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:52:20 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216475540.73.0.0481329743165.issue3379@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, the results are displayed on stdout like they are if sys.exit is
used. As the first post explains, the use-case is running the tests from
an interactive interpreter.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Sat Jul 19 15:54:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 13:54:08 +0000
Subject: [issue2913] idlelib/EditorWindow.py uses xrange()
In-Reply-To: <1211197785.96.0.212094869578.issue2913@psf.upfronthosting.co.za>
Message-ID: <1216475648.27.0.304637202465.issue2913@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65140.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2913>
_______________________________________

From report at bugs.python.org  Sat Jul 19 16:02:50 2008
From: report at bugs.python.org (mgogoulos)
Date: Sat, 19 Jul 2008 14:02:50 +0000
Subject: [issue3418] heavy resource usage with string functions
In-Reply-To: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>
Message-ID: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>


New submission from mgogoulos <mgogoulos at abiss.gr>:

Not sure if this is a bug, however the following string functions when
called with very big numbers as the padding arguments consume great
system resources. My estimation is that it would help to exist a limit
on what can be specified as width.

Check (center, ljust, rjust, zfill)

eg.

import string
string.center('..', 2147483647)

Tested on python versions: 2.5.1 and 2.5.2

----------
components: Library (Lib)
messages: 70034
nosy: mgogoulos
severity: normal
status: open
title: heavy resource usage with string functions
type: resource usage
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3418>
_______________________________________

From report at bugs.python.org  Sat Jul 19 16:03:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 14:03:24 +0000
Subject: [issue3417] make the fix_dict fixer explicit
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216476204.87.0.494133212969.issue3417@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Rather, the list of special contexts in which it is ok to not use list()
should be extended.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sat Jul 19 16:08:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 14:08:17 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216476497.54.0.75575236403.issue3417@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Exactly! For example, if the .items call is in a for loop, list()
doesn't need to be called.

----------
title: make the fix_dict fixer explicit -> make the fix_dict fixer smarter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sat Jul 19 16:51:38 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 19 Jul 2008 14:51:38 +0000
Subject: [issue3418] heavy resource usage with string functions
In-Reply-To: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>
Message-ID: <1216479098.15.0.609162911521.issue3418@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

The issue is that you're creating a string of 2GB. It's expectable that
it'll use a lot of resources.

Test this, for example: 

>>> a = "." * 2147483647

----------
nosy: +facundobatista
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3418>
_______________________________________

From report at bugs.python.org  Sat Jul 19 17:29:55 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 19 Jul 2008 15:29:55 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216481395.91.0.262308859204.issue3379@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I still think a different method would be better for the no-exit
functionality.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Sat Jul 19 17:31:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 19 Jul 2008 15:31:52 +0000
Subject: [issue3418] heavy resource usage with string functions
In-Reply-To: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za>
Message-ID: <1216481512.46.0.731295416856.issue3418@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for the possibility of rejecting the request: Python should
absolutely not do so. If the user/applications wants to compute the
result, and the system has enough virtual memory, then Python should
provide the result.

If you want to limit how much memory Python can consume, use the
operating system's resource management functions (such as ulimit).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3418>
_______________________________________

From report at bugs.python.org  Sat Jul 19 17:33:10 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 19 Jul 2008 15:33:10 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1216481590.78.0.152878375784.issue3405@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Actually, it could be the "detail" field too according to
http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24
And this field may not exist, so I'm checking for that now.

New patch added.

Added file: http://bugs.python.org/file10948/event_generate__data2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Sat Jul 19 17:51:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jul 2008 15:51:47 +0000
Subject: [issue3113] Document exception chaining
In-Reply-To: <1213475513.28.0.247169838861.issue3113@psf.upfronthosting.co.za>
Message-ID: <1216482706.95.0.762845329691.issue3113@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documented in r65144.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3113>
_______________________________________

From report at bugs.python.org  Sat Jul 19 18:17:30 2008
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sat, 19 Jul 2008 16:17:30 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1216484250.49.0.974559816758.issue1697943@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

Small improvement of the patch: Instead of hardcoding the BOM as
'\xef\xbb\xbf', we should use codecs.BOM_UTF8.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Sat Jul 19 18:35:41 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 19 Jul 2008 16:35:41 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1216485341.72.0.0757644593469.issue3405@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file10934/event_generate__data.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Sat Jul 19 19:39:16 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 19 Jul 2008 17:39:16 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216489156.39.0.465321265848.issue3299@psf.upfronthosting.co.za>


Changes by Adam Olsen <rhamph at gmail.com>:


----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sat Jul 19 19:57:59 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 19 Jul 2008 17:57:59 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1216490279.79.0.19809877234.issue3299@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Reducing priority to normal; this bug has been around since Python 2.2,
and only affects code that doesn't work anyway when running on debug builds.

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sat Jul 19 20:32:38 2008
From: report at bugs.python.org (Joshua Kugler)
Date: Sat, 19 Jul 2008 18:32:38 +0000
Subject: [issue3384] Documentation for re.findall and re.finditer lacks
	"ordering" information
In-Reply-To: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za>
Message-ID: <1216492358.06.0.193766377154.issue3384@psf.upfronthosting.co.za>


Joshua Kugler <jkugler at bigfoot.com> added the comment:

That looks good.  Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3384>
_______________________________________

From report at bugs.python.org  Sat Jul 19 20:39:09 2008
From: report at bugs.python.org (nicodotti)
Date: Sat, 19 Jul 2008 18:39:09 +0000
Subject: [issue2951] ElementTree parsing bus error (but only from mod_python)
In-Reply-To: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
Message-ID: <1216492748.96.0.664335488483.issue2951@psf.upfronthosting.co.za>


nicodotti <nicodotti2 at gmail.com> added the comment:

Thanks for logging this bug Kathy I had the same problem for 2 days! I
used the cElementTree as you mentioned and it worked fine

----------
nosy: +nicodotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2951>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:02:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 19:02:11 +0000
Subject: [issue2951] ElementTree parsing bus error (but only from mod_python)
In-Reply-To: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
Message-ID: <1216494130.96.0.635245245375.issue2951@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

This is probably a mod_python problem.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2951>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:07:54 2008
From: report at bugs.python.org (Kathy Van Stone)
Date: Sat, 19 Jul 2008 19:07:54 +0000
Subject: [issue2951] ElementTree parsing bus error (but only from mod_python)
In-Reply-To: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
Message-ID: <1216494474.66.0.533359268192.issue2951@psf.upfronthosting.co.za>


Kathy Van Stone <kvs at acm.org> added the comment:

Does ElementTree do anything unusual in importing? That is one area
where mod_python is different from standard python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2951>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:08:29 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 19:08:29 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216494509.77.0.356618053194.issue2960@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

python 2.6b1+, bdb 4.7.25 on x86 ubuntu linux.


% ../../../../python/trunk/python bsddb3/tests/test_replication.py -v
test01_basic_replication (__main__.DBReplicationManager) ... zsh:
segmentation fault  ../../../../python/trunk/python
bsddb3/tests/test_replication.py -v


% ../../../../python/trunk/python bsddb3/tests/test_replication.py -v
test01_basic_replication (__main__.DBReplicationManager) ... FAIL
test01_basic_replication (__main__.DBBaseReplication) ... ERROR
test02_test_request (__main__.DBBaseReplication) ... ERROR
test03_master_election (__main__.DBBaseReplication) ... ERROR

======================================================================
ERROR: test01_basic_replication (__main__.DBBaseReplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "bsddb3/tests/test_replication.py", line 228, in setUp
    self.dbenvMaster.rep_set_transport(13,m2c)
AttributeError: rep_set_transport

======================================================================
ERROR: test02_test_request (__main__.DBBaseReplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "bsddb3/tests/test_replication.py", line 228, in setUp
    self.dbenvMaster.rep_set_transport(13,m2c)
AttributeError: rep_set_transport

======================================================================
ERROR: test03_master_election (__main__.DBBaseReplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "bsddb3/tests/test_replication.py", line 228, in setUp
    self.dbenvMaster.rep_set_transport(13,m2c)
AttributeError: rep_set_transport

======================================================================
FAIL: test01_basic_replication (__main__.DBReplicationManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "bsddb3/tests/test_replication.py", line 134, in
test01_basic_replication
    self.assertTrue(time.time()<timeout)
AssertionError

----------------------------------------------------------------------
Ran 4 tests in 2.198s

FAILED (failures=1, errors=3)
[27429 refs]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:08:55 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 19:08:55 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216494535.67.0.0445308183211.issue2960@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

(that last comment was using pybsddb svn r529)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:13:24 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 19:13:24 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216494803.71.0.056807924559.issue2960@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

hmm.  nevermind.

those last results clearly used the wrong bsddb library.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:17:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 19:17:08 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216495028.0.0.715663753222.issue3417@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

Here's a patch that doesn't add the enclosing list call in a for loop.

----------
keywords: +patch
Added file: http://bugs.python.org/file10949/smarter_fix_dict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sat Jul 19 21:58:59 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jul 2008 19:58:59 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216497539.45.0.139225356311.issue3417@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

for k in d.keys():
   return k   # needs to return a list

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sat Jul 19 22:00:42 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 19 Jul 2008 20:00:42 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Tested on MacOSX 10.5.4, running test_multiprocessing in a tight loop :

[~/Sources/py3k]> while true;do ./python ./Lib/test/regrtest.py 
test_multiprocessing;done
test_multiprocessing
1 test OK.
test_multiprocessing
1 test OK.
test_multiprocessing
1 test OK.
test_multiprocessing
Process Process-48:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 720, in _callmethod
    conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 232, in _bootstrap
    self.run()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", 
line 601, in f
    cond.acquire()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 949, in acquire
    return self._callmethod('acquire', (blocking,))
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 724, in _callmethod
    self._connect()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 711, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", 
line 133, in Client
    c = SocketClient(address)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", 
line 254, in SocketClient
    s.connect(address)
socket.error: [Errno 61] Connection refused
Exception in thread Thread-58:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 720, in _callmethod
    conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/threading.py", line 492, in 
_bootstrap_inner
    self.run()
  File "/Users/cartman/Sources/py3k/Lib/threading.py", line 447, in run
    self._target(*self._args, **self._kwargs)
  File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", 
line 601, in f
    cond.acquire()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 949, in acquire
    return self._callmethod('acquire', (blocking,))
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 724, in _callmethod
    self._connect()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 711, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", 
line 133, in Client
    c = SocketClient(address)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", 
line 254, in SocketClient
    s.connect(address)
socket.error: [Errno 61] Connection refused

----------
components: Tests
messages: 70053
nosy: cartman
severity: normal
status: open
title: multiprocessing module is racy
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Jul 19 22:08:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 20:08:48 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216498128.22.0.535954050989.issue2960@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Okay, now i've run the correct test suite on the correct modules with
pybsddb r530:

The problems still happen.  Sometimes it passes.  Other times it raises
an assertion error.

test01_basic_replication DBReplicationManger error:

File
"/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6-pydebug/bsddb3/tests/test_replication.py",
line 134, in test01_basic_replication
    self.assertTrue(time.time()<timeout)

test01_basic_replication DBBaseReplication error:

File
"/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6-pydebug/bsddb3/tests/test_replication.py",
line 342, in test01_basic_replication
    self.assertEquals("123", v)


and some others.

i haven't seen it segfault anymore though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Sat Jul 19 22:51:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 20:51:32 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216500692.9.0.45012123787.issue3120@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i believe this patch will fix it.  but i don't have a windows build
environment setup yet to even try it.

Exposing pointers to data structures as a number to Python is very gross
to begin with.  It'd be safer to define a tiny type to wrap them in.

Review at:  http://codereview.appspot.com/2608

----------
keywords: +patch
Added file: http://bugs.python.org/file10950/windows-amd64-subprocess-handle-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sat Jul 19 23:01:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Jul 2008 21:01:32 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1216501292.06.0.638768170762.issue3419@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin.peterson at usfamily.net> added the comment:

When running test_multiprocessing in a loop, I see:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/temp/python/trunk/Lib/test/test_multiprocessing.py", line 1157,
in test_remote
    queue = manager2.get_queue()
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 635,
in temp
    authkey=self._authkey, exposed=exp
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 887,
in AutoProxy
    incref=incref)
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 696,
in __init__
    self._incref()
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 743,
in _incref
    dispatch(conn, None, 'incref', (self._id,))
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 79, in
dispatch
    raise convert_to_error(kind, result)
RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 181,
in handle_request
    result = func(c, *args, **kwds)
  File "/temp/python/trunk/Lib/multiprocessing/managers.py", line 397,
in incref
    self.id_to_refcount[ident] += 1
KeyError: '1033760'
---------------------------------------------------------------------------

----------
assignee:  -> jnoller
nosy: +benjamin.peterson, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Jul 19 23:24:41 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 19 Jul 2008 21:24:41 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216502681.05.0.809079246196.issue3322@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

Am I to understand that the bug here is that the C extension doesn't
validate input properly if you call into it directly? Without a test I'm
not entirely sure exactly how you could possibly get negative values
into those functions using the json module as-is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sat Jul 19 23:48:14 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 19 Jul 2008 21:48:14 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216504094.85.0.840205476712.issue3322@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I've audited the patch, while it does fix the input range it looks like
it regresses other things (at least the error messages). "begin" was
intentionally used. The patch is not suitable for use, I'll create a
minimal patch that just fixes input validation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sun Jul 20 00:00:39 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 19 Jul 2008 22:00:39 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216504839.26.0.679491428229.issue3322@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I just committed a fix to trunk in r65147, needs port to py3k?

----------
assignee: bob.ippolito -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sun Jul 20 00:13:24 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 19 Jul 2008 22:13:24 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1216505604.86.7.15269653734e-05.issue3419@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This also happens under trunk

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sun Jul 20 01:17:53 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 23:17:53 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1216509473.48.0.302648939033.issue2620@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

diff up for review on http://codereview.appspot.com/2599

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Sun Jul 20 02:16:18 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Jul 2008 00:16:18 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216512978.78.0.220632995561.issue3120@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file10951/windows-amd64-subprocess-handle-gps02.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sun Jul 20 02:16:23 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Jul 2008 00:16:23 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216512983.58.0.843567647872.issue3120@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Removed file: http://bugs.python.org/file10950/windows-amd64-subprocess-handle-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sun Jul 20 02:23:59 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Jul 2008 00:23:59 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216513439.81.0.67400432493.issue3120@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r65151 (in theory).

I don't have amd64 to test with.

Roger, would you please test an AMD64 build from that revision or later
to confirm that it is fixed?

Once confirmed, this should be backported to release25-maint.

----------
keywords: +64bit, easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sun Jul 20 09:26:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 07:26:13 +0000
Subject: [issue3322] bugs in scanstring_str() and scanstring_unicode() of
	_json module
In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za>
Message-ID: <1216538773.15.0.881851279698.issue3322@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Was merged in r65148.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3322>
_______________________________________

From report at bugs.python.org  Sun Jul 20 09:41:36 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 20 Jul 2008 07:41:36 +0000
Subject: [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1216539696.48.0.195942364344.issue3216@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for "how to use the module": what do you want to use the module for,
and what kind of information would you need for that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3216>
_______________________________________

From report at bugs.python.org  Sun Jul 20 10:07:07 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 20 Jul 2008 08:07:07 +0000
Subject: [issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
In-Reply-To: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>
Message-ID: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165
$ python3.0
Python 3.0b2 (r30b2:65080, Jul 20 2008, 08:46:13) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

$ /Library/Frameworks/Python.framework//Versions/3.0/bin/2to3 a.py
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework//Versions/3.0/bin/2to3",
line 5, in <module>
    sys.exit(refactor.main("lib2to3/fixes"))
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 81, in main
    rt = RefactoringTool(fixer_dir, options)
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 160, in __init__
    self.pre_order, self.post_order = self.get_fixers()
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 182, in get_fixers
    fix_names = get_all_fix_names(self.fixer_dir)
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 95, in get_all_fix_names
    names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70065
nosy: barry-scott, collinwinter
severity: normal
status: open
title: 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3420>
_______________________________________

From report at bugs.python.org  Sun Jul 20 10:20:33 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 20 Jul 2008 08:20:33 +0000
Subject: [issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
In-Reply-To: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>
Message-ID: <1216542033.07.0.226535498903.issue3420@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Fixing 2to3 with the full path to the fixes folder gets this traceback:
 $ ./2to3 /dev/null
Traceback (most recent call last):
  File "./2to3", line 5, in <module>
   
sys.exit(refactor.main("/Library/Frameworks/Python.framework//Versions/3.0/lib/python3.0/lib2to3/fixes"))
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 81, in main
    rt = RefactoringTool(fixer_dir, options)
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 160, in __init__
    self.pre_order, self.post_order = self.get_fixers()
  File
"/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py",
line 185, in get_fixers
    mod = __import__(fixer_pkg + ".fix_" + fix_name, {}, {}, ["*"])
ValueError: Empty module name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3420>
_______________________________________

From report at bugs.python.org  Sun Jul 20 10:41:48 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 20 Jul 2008 08:41:48 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216543308.49.0.160470545631.issue3120@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

This fixes the problem I had on 64-bit Vista, and all of python's own 
tests still pass.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sun Jul 20 11:09:52 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Jul 2008 09:09:52 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216544992.24.0.862362553616.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That's fine with me. I just need a 'rbU' mode to know in which format
should I write the output file if I want to preserve proper line endings
regardless of platform.

As for Python 2.6 note - I would replace "may convert" with "converts".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Sun Jul 20 12:03:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 10:03:10 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216548190.59.0.0981120085814.issue3359@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you want to write your own line endings, read with "rU" and write
with "rb".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:14:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:14:07 +0000
Subject: [issue1905] PythonLauncher not working correctly on OS X 10.5/Leopad
In-Reply-To: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za>
Message-ID: <1216552447.82.0.198496850257.issue1905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No complaints were voiced, so I'm closing this.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1905>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:15:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:15:02 +0000
Subject: [issue2641] setuptools gets site-packages wrong on Mac
In-Reply-To: <1208291676.15.0.165300999847.issue2641@psf.upfronthosting.co.za>
Message-ID: <1216552502.71.0.335538950471.issue2641@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2641>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:15:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:15:20 +0000
Subject: [issue3104] overzealous garbage collector (dict)
In-Reply-To: <1213349018.67.0.856453652888.issue3104@psf.upfronthosting.co.za>
Message-ID: <1216552520.79.0.759394035734.issue3104@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No complaints were voiced, so I'm closing this.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3104>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:16:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:16:14 +0000
Subject: [issue3181] ConfigParsers are classic classes
In-Reply-To: <1214239689.68.0.615869985575.issue3181@psf.upfronthosting.co.za>
Message-ID: <1216552574.64.0.989316484967.issue3181@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

When creating your own subclass, you can always inherit from object too
to create a new-style class.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3181>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:16:54 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:16:54 +0000
Subject: [issue1711] socket functions that should return unsigned int return
	signed int
In-Reply-To: <1199050245.75.0.972014457431.issue1711@psf.upfronthosting.co.za>
Message-ID: <1216552614.02.0.675920297048.issue1711@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:17:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:17:15 +0000
Subject: [issue1619130] 64-bit Universal Binary build broken
Message-ID: <1216552635.59.0.245594538508.issue1619130@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No complaints were voiced, so I'm closing this.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1619130>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:19:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:19:35 +0000
Subject: [issue1391872] floating point literals don't work in non-US locale in
	2.5
Message-ID: <1216552775.71.0.150170475206.issue1391872@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It seems it has been fixed.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1391872>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:20:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:20:11 +0000
Subject: [issue1197207] Add proxies arg to urllib.urlretrieve
Message-ID: <1216552811.31.0.995486215723.issue1197207@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No response, closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1197207>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:20:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:20:30 +0000
Subject: [issue1363] python 2.4.4 fails on solaris (sun4u sparc SUNW,
	Sun-Fire-880)
In-Reply-To: <1193768290.81.0.981284051139.issue1363@psf.upfronthosting.co.za>
Message-ID: <1216552830.45.0.363505951568.issue1363@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No response, closing.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1363>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:21:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:21:34 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1216552894.33.0.896524650158.issue1481296@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It seems backporting this is not useful.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:22:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:22:01 +0000
Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X
In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za>
Message-ID: <1216552921.06.0.814148042956.issue1471@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Something else to do here?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:22:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:22:58 +0000
Subject: [issue1666952] terminalcommand doesn't work under Darwin
Message-ID: <1216552978.14.0.520205677038.issue1666952@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666952>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:23:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:23:24 +0000
Subject: [issue1733134] sqlite3.dll cannot be relocated
Message-ID: <1216553004.52.0.450357427169.issue1733134@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1733134>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:24:06 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:24:06 +0000
Subject: [issue756093] complex pow() crash on Alpha
Message-ID: <1216553046.87.0.736409851967.issue756093@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Did you get some results?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue756093>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:25:59 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:25:59 +0000
Subject: [issue1092962] Make Generators Pickle-able
Message-ID: <1216553159.04.0.111872035008.issue1092962@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

A patch can open a new issue, then.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092962>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:26:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:26:39 +0000
Subject: [issue839496] SimpleHTTPServer reports wrong content-length for text
	files
Message-ID: <1216553199.43.0.304829002635.issue839496@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Better not to backport it then.

----------
nosy: +georg.brandl
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue839496>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:30:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:30:13 +0000
Subject: [issue628258] pydoc.Helper.topics not based on docs
Message-ID: <1216553413.72.0.0366291660237.issue628258@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Since the mapping now uses section labels instead of file names, which
should be fairly stable, I'm going to declare this as "works for me".

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue628258>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:32:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:32:05 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1216553525.95.0.573039882467.issue670664@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Adding test suite patch from #674449; closed that as a duplicate.

----------
nosy: +georg.brandl
Added file: http://bugs.python.org/file10952/patch-test-cdata.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:32:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:32:16 +0000
Subject: [issue674449] test_htmlparser -- more robust SCRIPT tag handling
Message-ID: <1216553536.07.0.694200708951.issue674449@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Both patches are now in #670664.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue674449>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:35:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:35:35 +0000
Subject: [issue787077] copy_reg globals in cPickle
Message-ID: <1216553734.86.0.832410764275.issue787077@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'll declare this is not a bug; reload() isn't very safe in many contexts.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue787077>
_______________________________________

From report at bugs.python.org  Sun Jul 20 13:50:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 11:50:37 +0000
Subject: [issue926501] (ref-manual) position docstrings in source not
	documented
Message-ID: <1216554637.04.0.315406383753.issue926501@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added info in r65155.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue926501>
_______________________________________

From report at bugs.python.org  Sun Jul 20 14:01:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 12:01:48 +0000
Subject: [issue980092] tp_subclasses grow without bounds
Message-ID: <1216555308.77.0.485280883603.issue980092@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

After all this time, it should be safe to close this.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue980092>
_______________________________________

From report at bugs.python.org  Sun Jul 20 15:44:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 20 Jul 2008 13:44:52 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216561492.25.0.172689070579.issue3385@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Sun Jul 20 16:57:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Jul 2008 14:57:42 +0000
Subject: [issue756093] complex pow() crash on Alpha
Message-ID: <1216565862.18.0.139828297633.issue756093@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue756093>
_______________________________________

From report at bugs.python.org  Sun Jul 20 20:03:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Jul 2008 18:03:34 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1216577014.92.0.515305671263.issue3120@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Sun Jul 20 20:08:21 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Jul 2008 18:08:21 +0000
Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X
In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za>
Message-ID: <1216577301.06.0.155469846343.issue1471@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i believe this is fixed by the two changes mentioned above, i was
waiting for fbvortex to confirm the fix on his 64-bit OpenBSD system.

these changes need backporting to release25-maint.

----------
status: pending -> open
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471>
_______________________________________

From report at bugs.python.org  Sun Jul 20 21:23:43 2008
From: report at bugs.python.org (Nicholas Marriott)
Date: Sun, 20 Jul 2008 19:23:43 +0000
Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X
In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za>
Message-ID: <1216581823.56.0.927290368134.issue1471@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

I was going to test this on sparc64 (I no longer have access to amd64)
but I've been busy/on holiday, I'll try to do it this week.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471>
_______________________________________

From report at bugs.python.org  Sun Jul 20 22:45:04 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 20:45:04 +0000
Subject: [issue3303] invalid ref count on locale.strcoll() error
In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za>
Message-ID: <1216586704.79.0.872643277472.issue3303@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65134.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3303>
_______________________________________

From report at bugs.python.org  Sun Jul 20 22:49:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 20:49:05 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216586945.86.0.893484902744.issue3396@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Sun Jul 20 23:05:07 2008
From: report at bugs.python.org (engelbert gruber)
Date: Sun, 20 Jul 2008 21:05:07 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1216587907.35.0.775422162282.issue2532@psf.upfronthosting.co.za>


engelbert gruber <grubert at users.sourceforge.net> added the comment:

Truncating the file to 2448 lines helps, seams to be a size not content 
problem.

All fixes work exept fix_next.py .

And removing the lines ::

  |
  mod=file_input< any+ >

makes even this run through.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2532>
_______________________________________

From report at bugs.python.org  Sun Jul 20 23:39:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 21:39:34 +0000
Subject: [issue3400] dis module: undocumented new bytecodes
In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za>
Message-ID: <1216589974.48.0.294129702662.issue3400@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

MAKE_BYTES is no longer in opcode.h; removed it in r65160.
Documented the other three, which are new in 3k, in r65161. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3400>
_______________________________________

From report at bugs.python.org  Sun Jul 20 23:44:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 21:44:40 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1216590280.82.0.378092253399.issue1242657@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The problem is in _PyObject_LengthHint which calls len(o) and masks all
exceptions from it. Its comments says "This function never fails.
Accordingly, it will mask exceptions raised in either method."

Would it be better to at least not mask BaseExceptions?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Mon Jul 21 00:36:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jul 2008 22:36:53 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

In Py3k, but not in trunk:

======================================================================
FAIL: testSum (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 769, in
testSum
    self.assertEqual(math.sum(vals), s)
OverflowError: math range error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 772, in
testSum
    "for math.sum(%.100r)" % (i, s, vals))
AssertionError: test 13 failed: got OverflowError, expected
1.7976931348623157e+308 for math.sum([1.7976931348623157e+308,
9.979201547673598e+291])

System info: linux x86, glibc 2.8

----------
assignee: marketdickinson
components: Extension Modules, Tests
messages: 70094
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Test failure in test_math::testSum
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Mon Jul 21 00:39:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Jul 2008 22:39:26 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216593566.49.0.158153642881.issue3417@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

>for k in d.keys():
>   return k   # needs to return a list

Could you explain this a bit more?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Mon Jul 21 01:08:35 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 20 Jul 2008 23:08:35 +0000
Subject: [issue3422] sphinx.doc.autodoc: Hook for changing argspec
In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
Message-ID: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

It would be useful if the 

    autodoc-process-docstring

event from sphinx.ext.autodoc allowed to change the argspec of the 
function being documented. Some other hook for changing the function 
signature would also do.

We are using Sphinx for generating a reference guide for Numpy, where 
many of the functions are from extension modules for which 
inspect.getargspec does not work. Instead, the function signature is 
contained within the object's docstring. Right now I'm simply 
monkeypatching sphinx.ext.autodoc.format_signature, but a cleaner 
approach would be better.

It seems that this would be fairly easy to implement in generate_rst. 
Perhaps a .signature attribute to the Options passed to the hook would 
be an acceptable solution?

I can write a patch doing this, if someone doesn't do this faster.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70096
nosy: georg.brandl, pv
severity: normal
status: open
title: sphinx.doc.autodoc: Hook for changing argspec
type: feature request
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3422>
_______________________________________

From report at bugs.python.org  Mon Jul 21 04:44:15 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Jul 2008 02:44:15 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216608255.47.0.794185130315.issue3417@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The example was mucked-up :(  The question is that when for-looping 
over d.keys/items etc, how you know that the body of the loop isn't 
going to mutate the dict?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Mon Jul 21 08:13:02 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 21 Jul 2008 06:13:02 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216620781.96.0.630919385123.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

If lineends are mixed I would like to leave them as is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Mon Jul 21 11:23:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 09:23:56 +0000
Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside
	execfile
In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
Message-ID: <1216632236.7.0.263075525156.issue2378@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file10953/localstofast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2378>
_______________________________________

From report at bugs.python.org  Mon Jul 21 11:24:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 09:24:04 +0000
Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside
	execfile
In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
Message-ID: <1216632244.4.0.840638050595.issue2378@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file10707/localstofast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2378>
_______________________________________

From report at bugs.python.org  Mon Jul 21 11:27:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 09:27:05 +0000
Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside
	execfile
In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
Message-ID: <1216632425.32.0.00635925972567.issue2378@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2378>
_______________________________________

From report at bugs.python.org  Mon Jul 21 11:29:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 09:29:44 +0000
Subject: [issue3415] Interpreter error when running a script under debugger
	control
In-Reply-To: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za>
Message-ID: <1216632584.3.0.0645045072685.issue3415@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This issue is a duplicate of issue2378; the patch attached there
corrects this problem. I will commit it tonight.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> UnboundLocalError when trying to raise exceptions inside execfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3415>
_______________________________________

From report at bugs.python.org  Mon Jul 21 11:30:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jul 2008 09:30:18 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1216475254.64.0.318428334093.issue2523@psf.upfronthosting.co.za>
Message-ID: <1216632612.48845724ee88b@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon "Martin v. L??wis" <report at bugs.python.org>:
>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> I don't understand the second loop (where n is given). If n is given,
> there should be only a single read operation, using
>
>   max(buffer_size, n-avail)

I mimicked the original logic rather than rethink the algorithm. I'm not totally
sure what motivates the original logic but the purpose seems to be that
non-blocking streams can return at least a few bytes rather than an empty string
when less than N bytes are ready at OS level.

> (i.e. the way it is in patch 2). In particular, if the stream is
> unbuffered, it shouldn't ever end up with buffered data.

Hmm, what do you mean by "if the stream is unbuffered"? Unbuffered streams
should use the raw unbuffered objects (e.g. FileIO) rather than wrap them with
BufferedReader.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Mon Jul 21 12:00:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 10:00:40 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216634440.7.0.0482716008789.issue3353@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO the "struct tok_state" should not be part of the API, it contains
too many implementation details. Or maybe as an opaque structure.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Mon Jul 21 12:03:46 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Mon, 21 Jul 2008 10:03:46 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216634625.96.0.177063367596.issue3353@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

There are a few things in the struct that needs to be public, but that's
nothing that cannot be handled by documentation.  No need to complicate
the API just in case.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Mon Jul 21 13:52:03 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jul 2008 11:52:03 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1216641123.1.0.504783146543.issue2620@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The patch looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Mon Jul 21 14:15:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 12:15:56 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216642556.51.0.406059118598.issue3208@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyCFunctionObject has indeed no way to store annotations. This could be
useful for extension module writers. 

The PyMethodDef structure could grow a "ml_annotations" member. A patch
is welcome!

----------
nosy: +amaury.forgeotdarc
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Mon Jul 21 15:04:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 13:04:25 +0000
Subject: [issue3387] undefined array passed to CryptGenRandomBytes
In-Reply-To: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>
Message-ID: <1216645465.76.0.045015378027.issue3387@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3387>
_______________________________________

From report at bugs.python.org  Mon Jul 21 15:07:53 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 21 Jul 2008 13:07:53 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216645673.17.0.725614222528.issue3396@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I don't understand.

I tried the following:

Python 2.6b2+ (trunk:65167M, Jul 21 2008, 09:51:48) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rlcompleter
>>> import readline
>>> readline.parse_and_bind("tab: complete")

Then I wrote "int". Then I pressed TAB. Nothing happened. I pressed TAB
again, and the following appeared:

>>> int
int(     intern(  

To me this is the expected behaviour: if the system has two alternatives
(in this case it does not if it should follow with "(" or "e"), don't
continue with the first tab, and then show all the options with the
second tab (I'm used to this in bash).

Is this wrong according to you?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Mon Jul 21 15:10:36 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Mon, 21 Jul 2008 13:10:36 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216645836.62.0.59473696163.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

here is an attempt to make erf, erfc, lgamma and tgamma
accessible from math module.
erf and erfc are crude translation of the code pointed
out by Daniel Stutbach.
lgamma is also taken from sourceware.org, but doesn't
use the reentrant call for the sign.

i tested only on gcc-4.3.1/linux-2.6.26.
i'll write a testsuite soon.

some results:

Python 3.0b2 (r30b2:65080, Jul 21 2008, 13:13:13) 
[GCC 4.3.1] on linux2

>>> print(math.tgamma(0.5))
1.77245385091
>>> print(math.sqrt(math.pi))
1.77245385091
>>> print(math.tgamma(1.5))
0.886226925453
>>> print(math.sqrt(math.pi)/2)
0.886226925453
>>> print(math.sqrt(math.pi)*3/4)
1.32934038818
>>> print(math.tgamma(2.5))
1.32934038818
>>> for i in range(14):
	print(i, math.lgamma(i), math.tgamma(i))
	
0 inf inf
1 0.0 1.0
2 0.0 1.0
3 0.69314718056 2.0
4 1.79175946923 6.0
5 3.17805383035 24.0
6 4.78749174278 120.0
7 6.57925121201 720.0
8 8.52516136107 5040.0
9 10.6046029027 40320.0
10 12.8018274801 362880.0
11 15.1044125731 3628800.0
12 17.5023078459 39916800.0
13 19.9872144957 479001600.0

>>> for i in range(-14,0):
	print(i/5, math.lgamma(i/5), math.tgamma(i/5))
	
-2.8 0.129801291662 -1.13860211111
-2.6 -0.118011632805 -0.888685714647
-2.4 0.102583615968 -1.10802994703
-2.2 0.790718673676 -2.20498051842
-2.0 inf inf
-1.8 1.15942070884 3.18808591111
-1.6 0.837499812222 2.31058285808
-1.4 0.978052353322 2.65927187288
-1.2 1.57917603404 4.85095714052
-1.0 inf -inf
-0.8 1.74720737374 -5.73855464
-0.6 1.30750344147 -3.69693257293
-0.4 1.31452458994 -3.72298062203
-0.2 1.76149759083 -5.82114856863

>>> math.erf(INF)
1.0
>>> math.erf(-INF)
-1.0
>>> math.erfc(INF)
0.0
>>> math.erfc(-INF)
2.0
>>> math.erf(0.6174)
0.61741074841139409

----------
keywords: +patch
nosy: +nirinA
Added file: http://bugs.python.org/file10954/mathmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Jul 21 15:11:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jul 2008 13:11:48 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216645673.17.0.725614222528.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216645834.48848aca9b275@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Facundo Batista <report at bugs.python.org>:
>
> Then I wrote "int". Then I pressed TAB. Nothing happened. I pressed TAB
> again, and the following appeared:
>
> >>> int
> int(     intern(

This is not the point. The problem is when you type "int.", then press TAB twice
and it doesn't show the list of int members.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Mon Jul 21 15:16:05 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Mon, 21 Jul 2008 13:16:05 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216646165.36.0.525405717898.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

and this is the header.
it is stolen from glibc.

Added file: http://bugs.python.org/file10955/math_private.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Jul 21 16:02:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 14:02:40 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1216648960.73.0.010453334682.issue3373@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Mon Jul 21 16:03:29 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 21 Jul 2008 14:03:29 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216649009.93.0.669858379886.issue1758146@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I know the discussions more or less says this, but I want to add some 
additional information.

For the record, the reason that mod_python crashes with 'Invalid thread state 
for this thread' when Py_DEBUG is defined in part relates to:

  http://issues.apache.org/jira/browse/MODPYTHON-217

Also, that Py_DEBUG check effectively says that if you use simplified GIL API 
for a particular thread against the first interpreter, you are prohibited from 
creating additional thread states for that thread. I haven't checked the 
documentation lately, but I am not sure it is really clear on that specific 
point and so in some respects the documentation may be at fault here. Someone 
might like to point to exact part of documentation which states this 
requirement.

The problem thus is that code which worked prior to Python 2.3 would still work 
with Python 2.3 and later, up to the point that some code decided to use the 
simplified GIL API. At that point Python would create its own internal thread 
state for that thread even if user code had already created one. Conversely, if 
the simplified GIL API was used against the thread first and then user code 
tried to create an additional thread state for that thread against first 
interpreter.

With Py_DEBUG defined, this scenario causes the assertion failure and the above 
error. Without Py_DEBUG defined, the code can quite happily run fine, at least 
until the point where code which left Python using a user thread state object 
attempts to reenter Python by using simplified GIL API. At that point it would 
deadlock.

Now, as I said, that one was effectively forced to use simplified GIL API for 
first interpreter with Python 2.3 probably wasn't at all clear and so 
mod_python was never updated to meet that requirement. As per the JIRA issue 
referenced above it is a known problem that code isn't meeting this 
requirement, but not much development has been done on mod_python for quite a 
while.

I have though recently made changes to personal copy of mod_python code such 
that it uses simplified GIL API for all access against first interpreter and it 
no longer suffers that assertion failure when Py_DEBUG defined. The code also 
should work for any modules which use simplified GIL API, such as SWIG 
generated bindings for Xapian. You do have to force the application using such 
modules to run under first interpreter.

The code for mod_wsgi uses simplified GIL API for first interpreter as well and 
works with SWIG generated bindings, but it is possible that it may still fail 
that assertion when Py_DEBUG is defined. This is because in order to allow 
mod_python and mod_wsgi to be used in Apache at the same time, mod_wsgi had to 
incorporate some hacks to workaround the fact that mod_python was not using 
simplified GIL API for first interpreter, but also because mod_python wasn't 
releasing the GIL for a critical section between when it was initialised and 
Apache child processes were created. It was in this section that mod_wsgi has 
to initialise itself and so it had to fiddle the thread states to be able to do 
its things. This workaround may have been enough to create additional thread 
state of a thread for first interpreter, thus later triggering the assertion.

It would have been nice to have mod_wsgi do the correct thing from the start, 
but that would have barred it being used at same time as mod_python and so 
people may have baulked at trying mod_wsgi as a result. Now that mod_wsgi has 
got some traction, in mod_wsgi version 3.0 it will be changed to remove the 
mod_python fiddle. This will mean that mod_wsgi 3.0 will not be usable at same 
time as current mod_python versions and would only be usable with the 
mod_python version (maybe 3.4) which I have made modifications for to also use 
simplified GIL APIs properly.

So that is the state of play as I see and understand it.

As to Adam's comments about use cases for multiple interpreters, we have had 
that discussion before and despite that many people rely on that feature in 
both mod_python and mod_wsgi he still continues to dismiss it outright and 
instead calls for complete removal of the feature.

Also Adam's comments that multiple interpreters were used in mod_wsgi only to 
support buggy third party software, that is untrue. Multiple interpreter 
support exists in mod_wsgi because mod_python provided a similar feature and 
mod_python existed before many of the Python web applications which are claimed 
to be the reason that sub interpreters are used in the first place. So, 
mod_python and use of sub interpreters came first, and not really the other way 
around. Where Python web applications do rely on os.environ it is historically 
because that is how things were done in CGI. Many such as Trac may still 
support that means of configuration as a fall back, but Trac now also supports 
other ways which are thread safe.

All up, use of distinct sub interpreters in mod_python and mod_wsgi is a valid 
concept in web hosting, one reason being because of the fact that it is simpler 
to use one Apache instance than many. Despite claims that sub interpreter 
support is completely broken it works fine for that use case because of the 
nature of web applications and the transient nature of individual requests and 
how sub interpreters persist for the life of the process and are not destroyed 
within the lifetime of the process.

Unfortunately some are quite blinkered to this and haven't taken the time to 
understand how it is being used. This is quite unfortunate, and rather than 
ripping out multiple interpreters, time might be better spent on improving it 
to work better as necessary if certain areas are still a problem.

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Mon Jul 21 16:28:45 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 21 Jul 2008 14:28:45 +0000
Subject: [issue3396] rlcompleter can't autocomplete members of callable objects
In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za>
Message-ID: <1216650525.47.0.958695757732.issue3396@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Ah, sorry, missed that point.

Ok, I included this change and now it works ok.

Also worked a little that code (change the name of the variable
"object", used extend() for a list instead of adding to itself, and
removed a comparison from a loop).

Commited in r65168.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3396>
_______________________________________

From report at bugs.python.org  Mon Jul 21 17:39:24 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Mon, 21 Jul 2008 15:39:24 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216654764.26.0.314159538552.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

"Also, that Py_DEBUG check effectively says that if you use simplified 
GIL API for a particular thread against the first interpreter, you are 
prohibited from creating additional thread states for that thread."

I found that you cannot create additional thread states against the 
first interpreter and swap between them w/o this assertion occurring.  
I didn't use the GIL functions at all and had this issue in debug.  
PyInitialize initializes the GIL and hijacks the main interpreter.  We 
always call PyInitialize so does that mean we can only use the GIL 
functions with the main interpreter and nothing else when 
locking/unlocking the global lock as you seem to infer?  Does that mean 
there is a backward compatibility issue here with those who used the 
main interpreter only and created thread states from it to handle multi-
threading, like I did (thru the use of PyEval_Acquire/Release & 
PyThreadState_Swap)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Mon Jul 21 17:42:10 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Mon, 21 Jul 2008 15:42:10 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216654929.98.0.137565237681.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

By the way.  I switched to using the GIL functions on the main 
interpreter and everything works great now.  It is a better solution to 
use the GIL functions because I also had my own code that prevented 
dead lock from occuring when a python script calls back into the 
extension module that ends up calling PyEval_Acquire again (deadlock) 
even though it is the same thread.  Now with the GIL functions I don't 
need that code.  It is a good feature but it broke my previous 
implementation and it is not obvious why.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Mon Jul 21 18:40:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 16:40:38 +0000
Subject: [issue3409] ElementPath.Path.findall problem with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1216658438.72.0.909245132665.issue3409@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> effbot
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________

From report at bugs.python.org  Mon Jul 21 19:23:50 2008
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 21 Jul 2008 17:23:50 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216661030.67.0.342595358341.issue1758146@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Graham, I appreciate the history of sub-interpreters and how entrenched
they are.  Changing those practises requires a significant investment. 
This is an important factor to consider.

The other factor is the continuing maintenance and development cost. 
Subinterpreters add substantial complexity, which I can personally vouch
for.  This is exhibited in the GIL API not supporting them properly and
in the various bugs that have been found over the years.

Imagine, for a moment, that the situation were reversed; that everything
were built on threading.  Would you consider even for a moment adding
sub-interpreters?  How could you justify it?

It's not a decision to be taken lightly, but my preference is clear:
bite the bullet, make the change.  It's easier in the long run.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Mon Jul 21 20:16:12 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 21 Jul 2008 18:16:12 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216664172.34.0.974985769228.issue3381@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

This bug should be re-opened. The patch to configure.in wasn't quite
right. I'm attaching a slight fix. `autoconf`ing removes one level of
square brackets in the 'sed' command to create $tgt.

(Q about the issue tracker: I'm unable to change the "Status" field on
this bug. I'm guessing that is "by design", right? I.e., only certain
people have the privs to change bug status?)

----------
keywords: +patch
type:  -> compile error
Added file: http://bugs.python.org/file10956/issue3381_configure_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Mon Jul 21 20:29:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Jul 2008 18:29:40 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216664980.01.0.281891331104.issue3381@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reopening. Yes, "Status" is settable only by Developers, but as a
committer, you should certainly have that privilege.

----------
nosy: +georg.brandl
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Mon Jul 21 20:36:02 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 21 Jul 2008 18:36:02 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216665362.04.0.135091009608.issue2960@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Are you using a python pydebug version?. Can you reproduce the issue
with a no "pydebug" python interpreter?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Mon Jul 21 20:59:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 21 Jul 2008 18:59:20 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1216666760.29.0.290124512357.issue2960@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

using a python trunk optimized (non-debug) build and pybsddb r530:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Berkeley DB 4.7.25: (May 15, 2008)
bsddb.db.version():   (4, 7, 25)
bsddb.db.__version__: 4.7.2devel3
bsddb.db.cvsid:       $Id: _bsddb.c 527 2008-07-19 09:06:38Z jcea $
py module:           
/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/__init__.py
extension module:    
/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/_pybsddb.so
python version:       2.6b2+ (trunk:65173M, Jul 21 2008, 11:46:04)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
My pid:               9144
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Failure in test test01_basic_replication
(bsddb3.tests.test_replication.DBReplicationManager)
Traceback (most recent call last):
  File "/home/greg/sandbox/python/trunk/Lib/unittest.py", line 279, in run
    testMethod()
  File
"/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/tests/test_replication.py",
line 134, in test01_basic_replication
    self.assertTrue(time.time()<timeout)
  File "/home/greg/sandbox/python/trunk/Lib/unittest.py", line 325, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError

Failure in test test01_basic_replication
(bsddb3.tests.test_replication.DBBaseReplication)
Traceback (most recent call last):
  File "/home/greg/sandbox/python/trunk/Lib/unittest.py", line 279, in run
    testMethod()
  File
"/home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/tests/test_replication.py",
line 352, in test01_basic_replication
    self.assertEquals(None, v)
  File "/home/greg/sandbox/python/trunk/Lib/unittest.py", line 350, in
failUnlessEqual
    (msg or '%r != %r' % (first, second))
AssertionError: None != '123'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Mon Jul 21 23:14:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 21:14:58 +0000
Subject: [issue3387] undefined array passed to CryptGenRandomBytes
In-Reply-To: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za>
Message-ID: <1216674898.54.0.459205174023.issue3387@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r65174 and r65175. 
(for trunk, I had to change PyBytes_AS_STRING into PyString_AS_STRING)
Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3387>
_______________________________________

From report at bugs.python.org  Mon Jul 21 23:18:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 21 Jul 2008 21:18:52 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1216632612.48845724ee88b@imp.free.fr>
Message-ID: <4884FD38.4020206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>   max(buffer_size, n-avail)
> 
> I mimicked the original logic rather than rethink the algorithm. I'm not totally
> sure what motivates the original logic but the purpose seems to be that
> non-blocking streams can return at least a few bytes rather than an empty string
> when less than N bytes are ready at OS level.

IIUC, a read of the full requested size would achieve exactly that: on a
non-blocking stream (IIUC), a read will always return
min(bytes_available, bytes_requested).

> Hmm, what do you mean by "if the stream is unbuffered"? Unbuffered streams
> should use the raw unbuffered objects (e.g. FileIO) rather than wrap them with
> BufferedReader.

IIUC, io.open will always return a BufferedReader, potentially with
buffer_size=0 for unbuffered IO. This case must be supported.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Mon Jul 21 23:24:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jul 2008 21:24:09 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216675449.18.0.755229346011.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch!  I probably won't get to this properly until after 
2.6 final, but it won't get lost.  It seems like there's pretty good 
support for adding these functions.

By the way, there's already a setup in Python 2.6 (ad 3.0) for substitutes 
for missing math functions:  take a look at the file Python/pymath.c, 
which provides inverse hyperbolic functions for those platforms that need 
them, as well as the bits in configure.in that check for these functions.  
This is the really the right place for the tgamma/lgamma/erf/erfc code.

So a full patch for this should touch at least Python/pymath.c, 
Modules/mathmodule.c, configure.in, Lib/test/test_math.py, and 
Doc/Library/math.rst.  If you have time to fill in any of these pieces, it 
would be greatly appreciated.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Jul 21 23:56:37 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jul 2008 21:56:37 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1216677397.28.0.783529375377.issue1481296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I still think this is the wrong solution, and should be fixed before 2.6; 
long(float('nan')) should raise ValueError.  As Alexander points out, 
this fits much better with the IEEE 754 standard, and also with the C99 
standard.  It also just "feels right", to me; an attempt to convert a nan 
to an integer should not pass silently.

Here's a patch, based on Ronald's original patch.

Christian, what was the motivation for returning 0 here?

(One could also argue on the basis of IEEE 754 and C99 that 
long(float('inf')) should raise ValueError instead of OverflowError;  
personally, I'm content that long(float('inf')) raises an exception---I'm 
not too bothered which one.)

I agree that there doesn't seem much value in backporting the fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file10957/issue1481296.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:01:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 22:01:20 +0000
Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside
	execfile
In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za>
Message-ID: <1216677680.57.0.61939078158.issue2378@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r65177.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2378>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:02:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Jul 2008 22:02:19 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1216677739.28.0.837710856408.issue1481296@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> critical
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:23:50 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jul 2008 22:23:50 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1216679030.93.0.916875318711.issue1481296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Assigning to me;  I'd like to check in the new fix for 2.6/3.0, but I'll 
give it a couple of weeks for any objections to surface first.

----------
assignee:  -> marketdickinson
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:28:56 2008
From: report at bugs.python.org (Mark Harrison)
Date: Mon, 21 Jul 2008 22:28:56 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1216679336.64.0.950144040628.issue1767370@psf.upfronthosting.co.za>


Mark Harrison <marhar at users.sourceforge.net> added the comment:

There's a one-line change necessary in BaseHTTPServer.py.
s/socketserver/SocketServer/ on this line:

+        socketserver.StreamRequestHandler.__init__(self, request,
client_address, parent)

+        SocketServer.StreamRequestHandler.__init__(self, request,
client_address, parent)

Other than that it seems to work well.  The client side xmlrpc
code even does the right thing with an apache-based server.

I copied just the patched files to a standalone directory and
it works for Python 2.4 as well, if sys.path picks up that
directory first.

----------
nosy: +marhar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:34:44 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Jul 2008 22:34:44 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216679684.4.0.943072620014.issue3366@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Since we're not in a hurry for Py2.7 and 3.1, I would like to this 
kicked around a bit on the newsgroup and in numpy forums (personally, I 
would also post a pure python equivalent to the ASPN cookbook for 
further commentary).

There are several different approximations to choose from.  Each of 
them has their own implications for speed and accuracy.  IIRC, the one 
I used in test.test_random.gamma() was accompanied by a proof that its 
maximum error never exceeded a certain amount.  I think there were some 
formulas that made guarantees only over a certain interval and others 
that had nice properties in the first and second derivatives (one that 
don't have those properties can throw newtonian solvers wildly off the 
mark). 

Let's let the community use its collective wisdom to select the best 
approach and not immediately commit ourselves to the one in this patch.

At one point, Tim was reluctant to add any of these functions because 
it is non-trivial to do well and because it would open a can of worms 
about why python gets a different answer (possibly not as close to 
true) and some other favorite tool (matlab, excel, numpy, and 
engineering calculator, etc).

FWIW, I changed the 2.6 version of test_random.gamma() to take 
advantage of msum() to increase its accuracy when some of the summands 
have nearly cancelling values.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:52:21 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jul 2008 22:52:21 +0000
Subject: [issue3369] memory leak in floatobject.c
In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za>
Message-ID: <1216680741.81.0.0981349859594.issue3369@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r65179.  I modified the patch slightly to include the "infinity" 
check, and to change "if(s_buffer)" to the slightly more explicit "if 
(s_buffer != NULL)".

Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3369>
_______________________________________

From report at bugs.python.org  Tue Jul 22 00:59:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jul 2008 22:59:13 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <4884FD38.4020206@v.loewis.de>
Message-ID: <1216681149.6227.9.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 21 juillet 2008 ? 21:18 +0000, Martin v. L?wis a ?crit :
> IIUC, a read of the full requested size would achieve exactly that: on a
> non-blocking stream (IIUC), a read will always return
> min(bytes_available, bytes_requested).

Hmm, it seems logical indeed... Alexandre, do you have other information
on the subject?

> IIUC, io.open will always return a BufferedReader, potentially with
> buffer_size=0 for unbuffered IO. This case must be supported.

No, io.open returns the raw object without wrapping it:

    if buffering == 0:
        if binary:
            raw._name = file
            raw._mode = mode
            return raw
        raise ValueError("can't have unbuffered text I/O")

We could even decide to raise a ValueError when trying to construct a
BufferedReader with a buffer_size < 1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Tue Jul 22 01:03:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 23:03:56 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1216681436.85.0.382824254408.issue3344@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Tue Jul 22 01:20:44 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 21 Jul 2008 23:20:44 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216679684.4.0.943072620014.issue3366@psf.upfronthosting.co.za>
Message-ID: <eae285400807211620i3b3ef19h4a62097bb821b4d3@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Mon, Jul 21, 2008 at 5:34 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
> There are several different approximations to choose from.  Each of
> them has their own implications for speed and accuracy.

FWIW, the current patch dynamically selects one of a few different
approximation methods based on the input value.

+1 on kicking it around and comparing the output with that from other
mathematics tools.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Jul 22 02:40:42 2008
From: report at bugs.python.org (Greg Hazel)
Date: Tue, 22 Jul 2008 00:40:42 +0000
Subject: [issue3423] DeprecationWarning message applies to wrong context with
	exec()
In-Reply-To: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>
Message-ID: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>


New submission from Greg Hazel <ghazel at users.sourceforge.net>:

exec()ing a line which causes a DeprecationWarning causes the warning 
to quote the file exec() occurs in instead of the string.

Demonstration of the issue:
http://codepad.org/aMTYQgN5

----------
components: None
messages: 70129
nosy: ghazel
severity: normal
status: open
title: DeprecationWarning message applies to wrong context with exec()
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3423>
_______________________________________

From report at bugs.python.org  Tue Jul 22 03:10:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Jul 2008 01:10:41 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216689041.41.0.626367739134.issue3359@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you look at the io.open() function?
It's a new module in python2.6, but also the builtin "open" in py3k!

"""
    * On input, if newline is None, universal newlines mode is
      enabled. Lines in the input can end in '\n', '\r', or '\r\n', and
      these are translated into '\n' before being returned to the
      caller. If it is '', universal newline mode is enabled, but line
      endings are returned to the caller untranslated. If it has any of
      the other legal values, input lines are only terminated by the given
      string, and the line ending is returned to the caller untranslated.
"""

I suggest to try
    io.open(filename, newline="")

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Tue Jul 22 03:12:42 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Jul 2008 01:12:42 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216689162.13.0.0879432512185.issue3366@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It would be nice if we knew the error bounds for each of the 
approximation methods. Do we know how the coefficients were generated?

When switching from one method to another, it might be nice to have a 
range where the results slowly blend from one method to another:
  if x < a: return f1(x)
  if x > b: return f2(x)
  t = (x - a) / (b - a)
  return (1-t)*f1(x) + t*f2(x)
This minimizes discontinuities in the first and second derivatives.

The lowword/highword macros look to be tightly tied to the internal 
processor representation for floats.  It would be more portable and 
maintainable to replace that bit twiddling with something based on frexp
().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Tue Jul 22 04:58:27 2008
From: report at bugs.python.org (lorph)
Date: Tue, 22 Jul 2008 02:58:27 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1216695507.75.0.165413452927.issue672115@psf.upfronthosting.co.za>


lorph <lorph1 at gmail.com> added the comment:

Is anyone still working on this? It seems like an oddity of python that
has been a stumbling block for me to create a super reload.

I've found that i am able to bypass this problem by creating the
following definition:

class object(object):pass

However, this feels like an ugly hack.

----------
nosy: +lorph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Tue Jul 22 05:11:19 2008
From: report at bugs.python.org (Michael Hudson)
Date: Tue, 22 Jul 2008 03:11:19 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1216696279.19.0.857244084013.issue672115@psf.upfronthosting.co.za>


Michael Hudson <mwh at users.sourceforge.net> added the comment:

Another 3 and a bit years on <wink> I still think my comment
http://bugs.python.org/msg14169 is the crux of the issue.  It's even
relevant to your class object(object): pass hack!

I'm not at all likely to work on this any time soon myself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Tue Jul 22 06:04:39 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 22 Jul 2008 04:04:39 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216699479.86.0.830949462679.issue3417@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I think the proper way to address this is via the confidence levels that
Rodrigo Bernardo Pimentel is adding for his Summer of Code project. The
idea is that you'll be able to say "let me inspect any changes where the
fixer is less than X% confident". fix_dict and for loops would be one
such place.

Until that mechanism is in place, I agree with Raymond that we should
err on the side of correctness.

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Tue Jul 22 06:21:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 22 Jul 2008 04:21:35 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1216700495.25.0.41435710668.issue1767370@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

We would need the copyright holder of the patch to submit a contributor
form. Would that be possible?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Tue Jul 22 06:44:38 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 22 Jul 2008 04:44:38 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1216701878.78.0.739411581756.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Sorry for the delay and my miss in further communication on this issue.
I would like to take this issue in two fronts for its closure.

1) Issue with headers .capitalize() vs .title()
2) Documenting the Interface

With respect to point 1), I assume that we all agree upon that headers
should stored in Titled-Format instead of Capitalized-format. 

So I went ahead with the implementation of Titled format with a
CaseInsensitive Lookup so that previous code using Capitalize format
would also return values from the headers dict.

John: I agree with your point that these changes would break the
.header_items() that returns a list of Titled() key-value pairs, whereas
the previous existing code would be expecting Capitalized key-value
pairs. CaseInsensitive Dict lookup would not solve it.

I had assumed that new code will be confirming to it and changed the
tests. Even though I thought about it, I did not bring it up for
discussion for backward compatibility header_items() method.

- I don't have a solution for how to make header_items() backward
compatible if we go for headers title() change. I shall try to come up
by today.

Now, if we go for a Case Normalization at the much later stage, will the
headers be stored still in capitalize() format? ( In that case, this bug
requests it be stored in .titled() format confirming to many practices)
Would you like to explain a bit more on that?


We can address the documentation of interface later to coming upon
conclusion on the first one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Jul 22 06:47:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 22 Jul 2008 04:47:47 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1216702067.43.0.0854891752275.issue2620@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Commited to trunk.  r65182.

This still needs backporting to release25-maint.  (and release24-maint
if anyone is maintaining that)

----------
keywords: +patch
versions: +Python 3.0 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Tue Jul 22 09:07:21 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jul 2008 07:07:21 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216710441.34.0.351905061359.issue3381@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r65183.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Tue Jul 22 09:11:20 2008
From: report at bugs.python.org (Trent Mick)
Date: Tue, 22 Jul 2008 07:11:20 +0000
Subject: [issue3381] `./configure --enable-framework --enable-universalsdk`
	fails because of change in r63997
In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za>
Message-ID: <1216710680.08.0.558336700109.issue3381@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Thanks Ronald.

Any comment on http://bugs.python.org/msg69936

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3381>
_______________________________________

From report at bugs.python.org  Tue Jul 22 10:46:14 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Tue, 22 Jul 2008 08:46:14 +0000
Subject: [issue3409] ElementPath.Path.findall problem with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1216716374.02.0.883270466202.issue3409@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Hmm.  That's embarrassing.  What was I thinking?

Guess it's time to update the 2.X codebase to ET 1.2.8.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________

From report at bugs.python.org  Tue Jul 22 11:04:08 2008
From: report at bugs.python.org (Aurelien Jarno)
Date: Tue, 22 Jul 2008 09:04:08 +0000
Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using
	marshal
Message-ID: <1216717448.7.0.41011111107.issue1762561@psf.upfronthosting.co.za>


Aurelien Jarno <aurel32 at debian.org> added the comment:

AFAIK, this "mixed-endian" format is only used on little endian ARM 
(old-ABI only). 

That is true that IEEE 754 does not specify any format. I used the big 
and little endian code as a template to add the "ARM format", hence 
IEEE in the name. "mixed-endian" is the term usually used to describe 
this format in the ARM community. I am not opposed to any other name.

OTOH, if you consider that IEEE does not specify any format, "IEEE, 
little-endian" and "IEEE, big-endian" are also not correct.

----------
nosy: +aurel32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762561>
_______________________________________

From report at bugs.python.org  Tue Jul 22 11:30:39 2008
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Tue, 22 Jul 2008 09:30:39 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>


New submission from Ilpo Nyyss?nen <iny at iki.fi>:

The order of tests in imghdr makes it slow in common cases. Even without
any statistics it is quite easy to see that jpeg is the most common
format. In imghdr only bmp and png are after it. Also, should png really
be the last one?

Nearly all digital cameras produce jpegs and handling such images is one
big use case for this module.

Changing the test order should be easy and have big effect in common use
cases.

----------
components: Library (Lib)
messages: 70142
nosy: biny
severity: normal
status: open
title: imghdr test order makes it slow
type: performance
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Tue Jul 22 12:18:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2008 10:18:59 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1216721938.93.0.874940799203.issue1481296@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It also just "feels right", to me; an attempt to convert a nan 
> to an integer should not pass silently.

I have the same gut feeling.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Tue Jul 22 12:22:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 22 Jul 2008 10:22:45 +0000
Subject: [issue616013] cPickle documentation incomplete
Message-ID: <1216722165.78.0.570654793354.issue616013@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No need for gratuitous breakage of cPickle in Python 2.6.

Alexandre, if you can add the list of changes to the documentation, that
would be great.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue616013>
_______________________________________

From report at bugs.python.org  Tue Jul 22 14:32:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jul 2008 12:32:29 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1216729949.75.0.515247255174.issue3417@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I'll mark this as something to do for 2.7/3.1.

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Tue Jul 22 14:36:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jul 2008 12:36:40 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1216730200.55.0.919481559364.issue3424@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Do you have any benchmarks to prove this with? IMO, the difference would
be extremely insignificant.

----------
nosy: +benjamin.peterson
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Tue Jul 22 15:47:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2008 13:47:29 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216734449.9.0.432669903591.issue3348@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 15:56:33 2008
From: report at bugs.python.org (Oskar Andersson)
Date: Tue, 22 Jul 2008 13:56:33 +0000
Subject: [issue3425] posixmodule.c always using res = utime(path, NULL)
In-Reply-To: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za>
Message-ID: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za>


New submission from Oskar Andersson <oskar.andersson at gmail.com>:

I'm porting, embedding and extending Python in a very limited environment.

This environment does not have utime.h and have not defined the
following function:

int utime(const char *, const struct utimbuf *);

Although the function called utimes, defined in sys/time.h exist.

int utimes(const char *path, const struct timeval times[2]);


In the method, in posixmodule.c:

static PyObject *
posix_utime(PyObject *self, PyObject *args);

usage of these methods are used. If a time is specified in args, a
define determines which of the two methods to use, utime or utimes
depending if these exist or not.

If Py_None is sent instead utime is always used, the solution to solve
this is to use #ifdef with HAVE_UTIMES.

Line number 2835 in
http://svn.python.org/projects/python/trunk/Modules/posixmodule.c

I have not checked if this is solved in future versions.

----------
components: Extension Modules
messages: 70147
nosy: oskar86
severity: normal
status: open
title: posixmodule.c always using res = utime(path, NULL)
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3425>
_______________________________________

From report at bugs.python.org  Tue Jul 22 16:21:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jul 2008 14:21:11 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216736471.7.0.0425334732179.issue3348@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> pje
nosy: +pje
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 16:32:13 2008
From: report at bugs.python.org (=?utf-8?q?Christian_H=C3=A4ggstr=C3=B6m?=)
Date: Tue, 22 Jul 2008 14:32:13 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>


New submission from Christian H?ggstr?m <chn at virtutech.com>:

If current working directory contains non-ascii characters, calling
os.path.abspath(u".") will result in an error. I expect it to call the
underlying os.getcwdu() in this case.

>>> import os
>>> os.path.abspath(u".")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line
403, in abspath
    path = join(os.getcwd(), path)
  File
"/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line
65, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 29:
ordinal not in range(128)

It works if I do it manually, using os.getcwdu():

>>> os.path.join(os.getcwdu(), u".")
u'/disk1/chn_local/work/test/sk\xe4rg\xe5rds\xf6-latin1/.'

----------
components: Unicode
messages: 70148
nosy: saturn_mimas
severity: normal
status: open
title: os.path.abspath with unicode argument should call os.getcwdu
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Tue Jul 22 17:14:03 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 22 Jul 2008 15:14:03 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216739643.74.0.924647748267.issue3348@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

The encoding must be latin-1, not utf-8, and the stream must be binary
mode, not text.

I have no idea how to deal with the test suite, and don't have time at
the moment to investigate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 17:20:41 2008
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 22 Jul 2008 15:20:41 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216740041.91.0.323562934322.issue3348@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Are you saying the stream passed to _write SHOULD always be a binary
stream, and hence the test case is wrong, because it opens a text stream?

(I'm not sure where the stream comes from, but we should guarantee it's
a binary stream).

Also, why Latin-1?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 17:52:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Jul 2008 15:52:33 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1216741953.51.0.609453348596.issue3426@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, os.path.supports_unicode_filenames is False on posix platforms.
So os.path.abspath is not supposed to work with unicode values.

I was about to close the issue, but python 3.0 also defines
supports_unicode_filenames to False! In addition, os.getcwd() fails when
the current dir has non-ascii characters. Should we drop its
implementation, and use os.getcwdu instead?

----------
nosy: +amaury.forgeotdarc
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Tue Jul 22 17:58:41 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 22 Jul 2008 15:58:41 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1216740041.91.0.323562934322.issue3348@psf.upfronthosting. co.za>
Message-ID: <20080722155838.13AB73A40B0@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

For the "why Latin-1", read the WSGI spec's explanation of how 
strings should be handled in Python implementations where 'str' is unicode.

I suppose that you *could* make it a text stream with Latin-1 
encoding; I'm just not clear on whether there are any other ramifications.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 18:01:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2008 16:01:41 +0000
Subject: [issue3293] incorrect comments for PyObject_ReleaseBuffer
In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za>
Message-ID: <1216742501.57.0.6797217812.issue3293@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +teoliphant
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3293>
_______________________________________

From report at bugs.python.org  Tue Jul 22 18:12:20 2008
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 22 Jul 2008 16:12:20 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216743140.73.0.476717155968.issue3348@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Wow, I read the WSGI spec. That seems very strange that it says "HTTP
does not directly support Unicode, and neither does this interface."
Clearly HTTP *does* support Unicode, because it allows you to specify an
encoding.

I assume then that the ISO-8859-1 characters the WSGI functions receive
will be treated as byte values. (That's rather silly; it's just dodging
the issue of Unicode rather than supporting it).

But in any event, the PEP has spoken, so we stick with Latin-1.

With respect to the text/binary stream, I think it would be best if it's
a binary stream, and we explicitly convert those str objects (which WSGI
says must only contain Latin-1 range characters) into bytes objects
(simply treating code points as bytes; in other words calling
.encode('latin-1')) and writing them to the binary stream. (Since the
WSGI spec is so adamant we deal in bytes).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:05:35 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:05:35 +0000
Subject: [issue3427] urllib documentation: urlopen().info() return type
In-Reply-To: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za>
Message-ID: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

http://docs.python.org/lib/module-urllib.html
The page says that the return type of urlopen().info() is a
mimetools.Message object, which is not quite true; it is a
httplib.HTTPMessage object, which is a class derived from
mimetools.Message, but with additional features.

The httplib.HTTPMessage class is not documented at all, for which I will
file a separate bug.

----------
assignee: georg.brandl
components: Documentation
messages: 70154
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: urllib documentation: urlopen().info() return type
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3427>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:09:01 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:09:01 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

The httplib.HTTPMessage class needs documentation; it is missing from
the package documentation entirely. Instances of this class are e.g.
returned by the urllib.urlopen().info() method.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70155
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: httplib.HTTPMessage undocumented
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:17:09 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:17:09 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
Message-ID: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

The file-like object returned by urllib.urlopen() should be documented
like a proper class. The textual description under the urlopen() method
is less approachable and breaks the usual format of a class documentation.

Maybe the return type should be changed to be a httplib.HTTPResponse
object (but that's a separate issue).

----------
assignee: georg.brandl
components: Documentation
messages: 70156
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: urllib.urlopen() return type
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:24:09 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 22 Jul 2008 17:24:09 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1216743140.73.0.476717155968.issue3348@psf.upfronthosting. co.za>
Message-ID: <20080722172405.2DF123A40B2@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

HTTP is defined as a stream of bytes; the fact that you can specify 
encodings for headers and content is a different level of the 
spec.  WSGI wants to basically be as transparent a mapping as 
possible between HTTP and Python data structures, without imposing 
any *new* higher-level structures or conventions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:31:20 2008
From: report at bugs.python.org (ThomasH)
Date: Tue, 22 Jul 2008 17:31:20 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>


New submission from ThomasH <thomas.bugzilla at gmx.net>:

The library reference documentation of httplib.HTTPResponse does not
match up with the online help documentation, or with the dir()
information of a particular instance.

E.g. the list of public features in the library reference
(http://docs.python.org/lib/httpresponse-objects.html) is:
- read
- getheader
- getheaders
- msg
- version
- status
- reason

>From the online documentation (with 'help(httplib.HTTPResponse)'):
- begin
- close
- getheader
- getheaders
- isclosed
- read

And from a class instance (via 'dir(httpResponseInstance)'):
- 'begin',
- 'chunk_left',
- 'chunked',
- 'close',
- 'debuglevel',
- 'fp',
- 'getheader',
- 'getheaders',
- 'isclosed',
- 'length',
- 'msg',
- 'read',
- 'reason',
- 'status',
- 'strict',
- 'version',
- 'will_close'

----------
assignee: georg.brandl
components: Documentation
messages: 70158
nosy: ThomasH, georg.brandl
severity: normal
status: open
title: httplib.HTTPResponse documentations inconsistent
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:34:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jul 2008 17:34:41 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
Message-ID: <1216748081.24.0.64984603754.issue3429@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'll let Georg make the final determination about this, but IMO this is
unneeded. File-like objects are so common in Python code, that just
telling what methods are supported should be fine.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Tue Jul 22 19:54:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2008 17:54:32 +0000
Subject: [issue3231] re.compile fails with some bytes patterns
In-Reply-To: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>
Message-ID: <1216749272.34.0.547890355696.issue3231@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the fix is trivial enough. Committed in r65185.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3231>
_______________________________________

From report at bugs.python.org  Tue Jul 22 20:03:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2008 18:03:24 +0000
Subject: [issue3092] Wrong unicode size detection in pybench
In-Reply-To: <1213300200.75.0.77296570553.issue3092@psf.upfronthosting.co.za>
Message-ID: <1216749804.76.0.973999595718.issue3092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65186

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3092>
_______________________________________

From report at bugs.python.org  Tue Jul 22 21:04:43 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 22 Jul 2008 19:04:43 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1216753483.22.0.691442273843.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

> With respect to point 1), I assume that we all agree upon that headers
> should stored in Titled-Format instead of Capitalized-format. 

I would probably choose to store the headers in Capitalized-form,
because that makes implementing .headers trivial.

[...]
> Now, if we go for a Case Normalization at the much later stage, will the
> headers be stored still in capitalize() format? ( In that case, this bug
> requests it be stored in .titled() format confirming to many practices)
> Would you like to explain a bit more on that?

Implement .get_header() and friends using .headers, along the lines of:

    def get_header(self, header_name, default=None):
        return self.headers.get(
            header_name,
            self.unredirected_hdrs.get(header_name, default)).title()

And then ensure that the headers actually passed to httplib also get
.title()-cased.  This also has the benefit, compared with your patch, of
leaving the behaviour of non-HTTP URL schemes unchanged.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Jul 22 21:07:03 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 22 Jul 2008 19:07:03 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1216753623.64.0.252273577467.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Of course, that "along the lines of" suggestion isn't quite right: None
does not have a .title() method.

(and, to spell it out, I'm assuming in that suggestion that .headers is
the dict of headers with .capitalize()d keys, i.e. unchanged from Python
2.5)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Jul 22 23:41:43 2008
From: report at bugs.python.org (cfr)
Date: Tue, 22 Jul 2008 21:41:43 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1216762903.72.0.96298065844.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Altering ~/.CFUserTextEncoding so it has the contents "0:0" and then
rebooting seems to prevent the crash for GUI applications, too.

Would like to know how to fix this properly, of course, since I suspect
that the value on my machine was probably not "0:0" for a reason!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Jul 23 04:12:53 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 23 Jul 2008 02:12:53 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216779172.85.0.0825450435588.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Just in case you are wondering why I haven't submitted a patch yet, I 
want to let you know that my home computer is currently broken. So, I 
won't be able to work on this until I get my computer fixed (which 
unfortunately could take a few weeks).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Wed Jul 23 05:02:31 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 23 Jul 2008 03:02:31 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1216782150.94.0.927313067142.issue2523@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Antoine wrote:
> Le lundi 21 juillet 2008 ? 21:18 +0000, Martin v. L?wis a ?crit :
> > IIUC, a read of the full requested size would achieve exactly that: 
on a
> > non-blocking stream (IIUC), a read will always return
> > min(bytes_available, bytes_requested).
>
> Hmm, it seems logical indeed... Alexandre, do you have other 
information
> on the subject?

Martin is right. However, I don't how Python handle the case where 
bytes_available is zero (in C, an error value is returned and errno is 
set to EWOULDBLOCK).

When I revised the patch I had a weak understanding of nonblocking I/O. 
I thought the "exponential" reads were for nonblocking I/O, but I see 
now that is non-sense.

I am not sure, but I think Martin is also right about the second loop. 
The max() call should be changed back to "max(self.buffer_size, n))", 
like in the 2nd patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Wed Jul 23 07:16:51 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Wed, 23 Jul 2008 05:16:51 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216790211.63.0.793008157352.issue3208@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

By considering the implementing, some problems emerged. 

First of all, as we know, all CFunctionObject and their attributes are 
imutable, but the __annotations__ attribute should be a dict, and dict 
is mutable. So how to solve this?

Secondly, the annotation value can be abitrary expression, and then, 
for extension module, would it be reasonable to restrict these value to 
string?

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Wed Jul 23 07:38:19 2008
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Wed, 23 Jul 2008 05:38:19 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1216791499.12.0.297041734408.issue3424@psf.upfronthosting.co.za>


Ilpo Nyyss?nen <iny at iki.fi> added the comment:

Naturally it requires a big amount of files. Getting big amount of jpegs
is easy. Getting big amount of pbms or rgbs is not so easy.

I'll attach two profiling runs showing some difference when test_jpeg
and test_exif are moved to be the first tests. The beginnings those
outputs show the return value counts.

Added file: http://bugs.python.org/file10958/current

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Wed Jul 23 07:38:56 2008
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Wed, 23 Jul 2008 05:38:56 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1216791536.25.0.893459353385.issue3424@psf.upfronthosting.co.za>


Changes by Ilpo Nyyss?nen <iny at iki.fi>:


Added file: http://bugs.python.org/file10959/optimized

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Wed Jul 23 08:44:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Jul 2008 06:44:41 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1216795480.97.0.158423065422.issue3385@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A use case:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/572213
shows how code can use the Pickler.dispatch dict, but also some
Pickler.save_xxx function which should be exposed as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Wed Jul 23 09:14:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Jul 2008 07:14:00 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216797240.22.0.475085412819.issue3208@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- A immmutable object may contain mutable members. Try with a tuple
containing a list.
Then, I don't think that something says that CFunctionObjects are
immutable. They don't have any modifiable attribute, until today!

- (Did I say "string"?) The new PyMethodDef::ml_annotations would not be
a char*, but a PyObject* member. If it is not possible to set it in the
static array, one could update the array in the module init function.

Anyway, for a SWIG module I think the best is to set the __annotations__
in the shadow python file. It seems more practical to build the dict there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Wed Jul 23 11:19:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jul 2008 09:19:57 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1216782150.94.0.927313067142.issue2523@psf.upfronthosting.co.za>
Message-ID: <1216804783.4886f7af1cba1@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When I revised the patch I had a weak understanding of nonblocking I/O.
> I thought the "exponential" reads were for nonblocking I/O, but I see
> now that is non-sense.

Fine, so it will make the patch simpler.

As for non-blocking IO, I think we should raise the general issue on
python-3000. There is no real support for it right now, by which I mean (1) no
easy and portable way of enable non-blocking IO on a file object and (2) no test
cases of non-blocking IO in real-world conditions (rather than with mock
objects). This shouldn't stop us from fixing the present bug though.

> I am not sure, but I think Martin is also right about the second loop.
> The max() call should be changed back to "max(self.buffer_size, n))",
> like in the 2nd patch.

Ok. Could you produce an updated patch? :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Wed Jul 23 15:17:37 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 23 Jul 2008 13:17:37 +0000
Subject: [issue3379] Option to not-exit on test
In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za>
Message-ID: <1216819057.03.0.298044566649.issue3379@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

What about always returning the results. Granted, when sys.exit is run
there will be no results returned, but then nothing to get the results.
If we divided in two functions, would one be unittest.main and the other
unittest.nonExitingMain? Sounds ugly, but OK if no other better way is
possible.

I personally believe that main should not hijack the current interpreter
with sys.exit at all, but I understand that behavior is not changeable
at the moment (is it?).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3379>
_______________________________________

From report at bugs.python.org  Wed Jul 23 16:57:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jul 2008 14:57:29 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1216825049.63.0.105139435894.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would someone object to committing this before beta3?
For clarity I would first commit the rewrite of test_locale to use
unittest, and then the fix for the thousands separator bug.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:11:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jul 2008 15:11:05 +0000
Subject: [issue2417] [py3k] Integer floor division (//): small int check
	omitted
In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
Message-ID: <1216825865.25.0.0811773591193.issue2417@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2417>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:29:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jul 2008 15:29:26 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1216826966.42.0.816470343614.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Greg, I'm not sure your improvement patch is right, since some code may
be holding a reference to the former _MainThread instance and expecting
it to still be part of the active threads container.

On the other hand there are things in the Thread class that may need
reinitializing after a fork (e.g. self.__block = Condition(Lock()), and
self.__ident = _get_ident() :-))... so perhaps your patch is a good
enough approximation of what is needed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:33:27 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 23 Jul 2008 15:33:27 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216827207.31.0.801737173906.issue3256@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file10848/multiprocessing.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:34:05 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 23 Jul 2008 15:34:05 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216827245.65.0.5298539045.issue3256@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Added file: http://bugs.python.org/file10960/issue3256.multiprocessing.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:43:44 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 23 Jul 2008 15:43:44 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216827823.78.0.0537068732092.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Here is the updated version of multiprocessing.rst patch. Not much has
changes, as you can see (if you've seen the previous version, of course
;) ).
I have only one question left about multiprocessing.rst, it's about
'allow_connection_pickling' function -- should documentation cover this
function or just leave it as it is?
The only issue I still have is mp_distributing.py example, which is not
properly documented.
Jesse, I think you should review both patches and leave this issue open
until mp_distributing.py is documented. If you have any questions --
ping me on #python-dev.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Wed Jul 23 17:48:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Jul 2008 15:48:19 +0000
Subject: [issue3431] multiprocessing uses Pickler.dispatch which isn't in 3.0
	_pickle
In-Reply-To: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za>
Message-ID: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

multiprocessing's new ForkingPickler uses Pickler's dispatch attribute
which is only present in the Python version, not the C one. As a result,
a straightforward merge isn't possible.

----------
assignee: jnoller
components: Library (Lib)
messages: 70176
nosy: alexandre.vassalotti, georg.brandl, jnoller
severity: normal
status: open
title: multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3431>
_______________________________________

From report at bugs.python.org  Wed Jul 23 18:47:54 2008
From: report at bugs.python.org (qiang)
Date: Wed, 23 Jul 2008 16:47:54 +0000
Subject: [issue1524] os.system() fails for commands with multiple quoted file
	names
In-Reply-To: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za>
Message-ID: <1216831674.08.0.22267667073.issue1524@psf.upfronthosting.co.za>


qiang <interchange at 126.com> added the comment:

in subprocess.py , 
change line 788: args = comspec + " /c " + args
             to: args = comspec + args
it will be ok.

----------
nosy: +likes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524>
_______________________________________

From report at bugs.python.org  Wed Jul 23 19:35:01 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Wed, 23 Jul 2008 17:35:01 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216834500.93.0.299217947817.issue3208@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

I think there is reason that CFunctionObjects are immutable: single 
CFunctionObject is shared by mutiple Python interpreters, so any change 
of CFunctionObject would affect other Python interpreters. Is that 
right?

If it should be immutable, then we should use something like static 
array to assign annotations to CFunctionObject, and the value also 
should be immutable, that means the value couldn't be abitrary 
PyObject. (by value I mean the value of every __annotations__ dict 
items.)

For SWIG, there's a way to bypass the Python side proxy, eg. for a 
simple C function, in the shadow module we directly 
let 'func=_cmod.func', where _cmod is the C DLL module. So the 
annotation information would be lost if we can't directly assign 
annotation to C function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Wed Jul 23 19:37:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Jul 2008 17:37:24 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216834644.6.0.267658718192.issue3208@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There never should be multiple Python interpreters running in the same
process, though.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Wed Jul 23 20:14:19 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 23 Jul 2008 18:14:19 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216836859.62.0.214597160411.issue3359@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

As I indicated in msg69679 if you want to see the line endings just open
the file in binary mode ('rb').

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 24 00:53:09 2008
From: report at bugs.python.org (Andy)
Date: Wed, 23 Jul 2008 22:53:09 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216853589.42.0.0072259585625.issue3353@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

Sorry for the terribly dumb question about this.

Are you meaning that, at this stage, all that is required is:

 1. the application of the PyAPI_FUNC macro
 2. move the file to the Include directory
 3. update Makefile.pre.in to point to the new location

Just I have read this now 10 times or so and keep thinking more must be
involved :-) [certainly given my embarrassing start to the Python dev
community re:asynchronous thread exceptions :-| ]

I have attached a patch that does this. Though at this time it is
lacking any documentation that will state what parts of "struct
tok_state" are private and public. I will need to trawl the code some
more to do that.

I have executed:

 - ./configure
 - make
 - make test

And all proceed well.

----------
keywords: +patch
nosy: +kirkshorts
Added file: http://bugs.python.org/file10961/issue3353.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Thu Jul 24 00:55:07 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Wed, 23 Jul 2008 22:55:07 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1216853707.37.0.861873291728.issue2975@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Any new thoughts on this?

I had to patch my local copy again after a reinstall.
It would be nice to fix it upstream.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2975>
_______________________________________

From report at bugs.python.org  Thu Jul 24 01:15:50 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Wed, 23 Jul 2008 23:15:50 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1216854950.9.0.593770431713.issue2975@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Sorry, posted too quickly.

Actually, the problem was a little different.
There was an environment variable with '=' characters in it.

Here is a patch to deal with that:

--- msvc9compiler.py.orig	2008-07-23 16:13:25.248438400 -0700
+++ msvc9compiler.py	2008-07-23 16:13:54.059867200 -0700
@@ -252,7 +252,9 @@
         if '=' not in line:
             continue
         line = line.strip()
-        key, value = line.split('=')
+        i = line.index('=')
+        key   = line[0:i]
+        value = line[i:]
         key = key.lower()
         if key in interesting:
             if value.endswith(os.pathsep):

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2975>
_______________________________________

From report at bugs.python.org  Thu Jul 24 01:46:40 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 23 Jul 2008 23:46:40 +0000
Subject: [issue3431] multiprocessing uses Pickler.dispatch which isn't in 3.0
	_pickle
In-Reply-To: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za>
Message-ID: <1216856800.17.0.934341597516.issue3431@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Duplicate of issue3385

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> cPickle to pickle conversion in py3k missing methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3431>
_______________________________________

From report at bugs.python.org  Thu Jul 24 03:09:13 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 24 Jul 2008 01:09:13 +0000
Subject: [issue2417] [py3k] Integer floor division (//): small int check
	omitted
In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
Message-ID: <1216861753.15.0.667693222882.issue2417@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Alexander, tried the issue2417a.diff patch against 65210, and does not
apply cleanly, could you please submit an updated one?

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2417>
_______________________________________

From report at bugs.python.org  Thu Jul 24 03:44:16 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 24 Jul 2008 01:44:16 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216863856.75.0.803561149888.issue3208@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

As I understand, at least C extension modules, which built as shared 
library, would be shared among Python interpreter in different process 
space. Is that correct?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:15:04 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 24 Jul 2008 02:15:04 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216865704.29.0.607622627113.issue1758146@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Franco, you said 'I found that you cannot create additional thread 
states against the  first interpreter and swap between them w/o this 
assertion occurring. ...'

Since the Py_DEBUG check is checking against the simplified GIL state 
API thread state object, then technically you could have a thread with 
multiple thread states, that thread just can't ever use/have used 
simplified GIL state API.

Take for example a system where threads are actually foreign threads and 
not created within Python. In this case simplified GIL state API thread 
state object would never have been created for that thread. For those 
you could have multiple thread states and not trip the test.

In other words, multiple thread states only blocked if one of them is 
the internal one created by simplified GIL state AP. This is getting 
hard to avoid though.

In summary, the simplified GIL state API is basically viral in nature.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:26:53 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jul 2008 02:26:53 +0000
Subject: [issue2417] [py3k] Integer floor division (//): small int check
	omitted
In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
Message-ID: <1216866413.23.0.849515156187.issue2417@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like e-mail submission did not work.  Uploading updated patch as issue2417b.diff .

Added file: http://bugs.python.org/file10962/issue2417b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2417>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:42:54 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:42:54 +0000
Subject: [issue3432] Mac, 2.6 framework install error
In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>
Message-ID: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

OSX Leopard (10.5.4)
Python-2.6b2 tarball

./configure --enable-universalsdk --enable-framework 
make
sudo make install 

Ends with this error:

cd Mac && make installmacsubtree DESTDIR=""
Creating directory
/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386
../python.exe ./scripts/cachersrc.py -v
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac
/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
Traceback (most recent call last):
  File "./scripts/cachersrc.py", line 7, in <module>
    import macresource
  File "/projects/Python-2.6b2/Lib/plat-mac/macresource.py", line 6, in
<module>
    from Carbon import Res
  File "/projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py", line 4, in
<module>
    from _Res import *
ImportError: No module named _Res
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2


Since by this time in the install process the _Res module has already
been installed I was able to work around this issue by hacking the
generated Mac/Makefile and setting RUNSHARED to nothing.  The same
problem happens in Mac/IDLE/Makefile as well.

----------
components: Macintosh
messages: 70189
nosy: robind
severity: normal
status: open
title: Mac, 2.6 framework install error
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3432>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:43:30 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:43:30 +0000
Subject: [issue3433] Mac, 3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

OSX Leopard (10.5.4)
Python-3.0b2 tarball 

./configure --enable-universalsdk --enable-framework 
make
sudo make install 

Ends with this error:
cd PythonLauncher && make install DESTDIR=
test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0"
test -d "/Applications/Python 3.0/Python Launcher.app" && rm -r
"/Applications/Python 3.0/Python Launcher.app"
cp -r "Python Launcher.app" "/Applications/Python 3.0"
touch "/Applications/Python 3.0/Python Launcher.app"
test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0"
test -d "/Applications/Python 3.0/IDLE.app" && rm -r
"/Applications/Python 3.0/IDLE.app"
make[1]: [install_IDLE] Error 1 (ignored)
cp -PR IDLE/IDLE.app "/Applications/Python 3.0"
cp: Warning: the meaning of `-P' will change in the future to conform to
POSIX.
Use `--parents' for the old meaning, and `--no-dereference' for the new one.
ln -sf
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python
"/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python"
ln: creating symbolic link `/Applications/Python
3.0/IDLE.app/Contents/MacOS/Python' to
`/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python':
No such file or directory
make[1]: *** [install_IDLE] Error 1
make: *** [frameworkinstallapps] Error 2


It looks like this is due to fink's cp being found first on the PATH. 
Temporarily disabling /sw/bin/cp so /bin/cp would be found first then
the install finished.

----------
components: Macintosh
messages: 70190
nosy: robind
severity: normal
status: open
title: Mac, 3.0 framework install error with fink cp
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:45:34 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 02:45:34 +0000
Subject: [issue3434] Mac, 3.0 framework install, Python.app not created
In-Reply-To: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>
Message-ID: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

OS X Leopard (10.5.4)
Python-3.0b2 tarball

./configure --enable-universalsdk --enable-framework 
make
sudo make install 

/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app
is not created by the install step, but it is needed for running python3.0:

$ python3.0
python3.0: execv:
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python:
No such file or directory

----------
components: Macintosh
messages: 70191
nosy: robind
severity: normal
status: open
title: Mac, 3.0 framework install, Python.app not created
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3434>
_______________________________________

From report at bugs.python.org  Thu Jul 24 04:48:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Jul 2008 02:48:14 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1216863856.75.0.803561149888.issue3208@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807231948o10965a7epc5bcb39887b906c6@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Wed, Jul 23, 2008 at 8:44 PM, Haoyu Bai <report at bugs.python.org> wrote:

>
> Haoyu Bai <divinekid at gmail.com> added the comment:
>
> As I understand, at least C extension modules, which built as shared
> library, would be shared among Python interpreter in different process
> space. Is that correct?

The operating system should provide memory protection between processes.

>
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3208>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080724/5e2da93d/attachment.txt>

From report at bugs.python.org  Thu Jul 24 05:19:33 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 03:19:33 +0000
Subject: [issue3434] Mac, 3.0 framework install, Python.app not created
In-Reply-To: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>
Message-ID: <1216869573.09.0.558775665353.issue3434@psf.upfronthosting.co.za>


Robin Dunn <robin at alldunn.com> added the comment:

This appears to already be fixed in the current py3k branch, so this can
be closed.  Sorry for the noise.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3434>
_______________________________________

From report at bugs.python.org  Thu Jul 24 08:21:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 06:21:59 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216880519.95.0.814531649786.issue3208@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file10963/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Thu Jul 24 08:31:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 06:31:19 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216881079.45.0.605579980102.issue3208@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Shared libraries share code, not memory.

But were you talking about sub-interpreters?
http://docs.python.org/dev/c-api/init.html#Py_NewInterpreter
mod_python uses them, but see the "Caveats" section of the doc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Thu Jul 24 08:46:05 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 24 Jul 2008 06:46:05 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216881965.34.0.361210909464.issue3208@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

I found the explanation of why buitl-ins are immutable:

For the curious: there are two reasons why changing built-in classes is 
disallowed. First, it would be too easy to break an invariant of a 
built-in type that is relied upon elsewhere, either by the standard 
library, or by the run-time code. Second, when Python is embedded in 
another application that creates multiple Python interpreters, the 
built-in class objects (being statically allocated data structures) are 
shared between all interpreters; thus, code running in one interpreter 
might wreak havoc on another interpreter, which is a no-no.

(From http://www.python.org/download/releases/2.2.3/descrintro/)

Is the statement still valid for current version of Python?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Thu Jul 24 09:00:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 07:00:02 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1216882802.16.0.956981664574.issue3208@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The "First" argument does not apply here, we could just say "annotations
are not a function invariant", but the "Second" argument is valid to me. 

A solution would be a global (or interpreter-local if we really want to
support sub-interpreters) registry that stores annotations. The index
could not be the PyCFunctionObject (since it is different for every
bound method), but the address of the PyMethodDef entry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Thu Jul 24 09:04:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 24 Jul 2008 07:04:49 +0000
Subject: [issue3434] Mac, 3.0 framework install, Python.app not created
In-Reply-To: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za>
Message-ID: <1216883089.93.0.881636680056.issue3434@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3434>
_______________________________________

From report at bugs.python.org  Thu Jul 24 12:39:01 2008
From: report at bugs.python.org (Gustavo Narea)
Date: Thu, 24 Jul 2008 10:39:01 +0000
Subject: [issue3435] trace.py tries to get coverage data from non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>


New submission from Gustavo Narea <me at gustavonarea.net>:

trace.py tries to get coverage information from non Python files, which raises a
SyntaxError because the file doesn't contain valid Python code.

I've attached a path that fixes this problem in Python 2.5.

----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 70197
nosy: Gustavo
severity: normal
status: open
title: trace.py tries to get coverage data from non Python files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10964/trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________

From report at bugs.python.org  Thu Jul 24 13:08:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 11:08:08 +0000
Subject: [issue3435] trace.py tries to get coverage data from non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1216897688.3.0.876305017526.issue3435@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your remark is certainly valid, but where does this occur? Some tool
that generate python code on the fly?
Do you have an example, a use case?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________

From report at bugs.python.org  Thu Jul 24 13:19:24 2008
From: report at bugs.python.org (Gustavo Narea)
Date: Thu, 24 Jul 2008 11:19:24 +0000
Subject: [issue3435] trace.py tries to get coverage data from non Python files
In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za>
Message-ID: <1216898364.43.0.951333910691.issue3435@psf.upfronthosting.co.za>


Gustavo Narea <me at gustavonarea.net> added the comment:

Hi, Amaury.

I found this problem using the Bitten continuous integration system
(http://bitten.edgewall.org/ticket/304).

I'm using the TurboGears framework with Genshi, and therefore
mypackage.templates module should contain non-Python files. Here you'll find
its contents:
https://tracker.gnulinuxmatters.org/browser/animador/trunk/animador/template

This is the only situation where the problem occurs, AFAIK.

If you want to reproduce it, you can:
 1.- Install Bitten:
easy_install http://svn.edgewall.org/repos/bitten/trunk/
 2.- Install my package:
svn co https://svn.gnulinuxmatters.org:81/animador/trunk/ animador
cd animador
./setup.py develop
 3.- Run Bitten's "unittest" extension for setuptools under my package with the
following options:
./setup.py unittest --xml-output build/test-results.xml --coverage-summary
build/test-coverage.txt --coverage-dir build/coverage

Then you'll get a SyntaxError if the patch I attached is not applied.

Cheers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3435>
_______________________________________

From report at bugs.python.org  Thu Jul 24 14:08:38 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Jul 2008 12:08:38 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1216901318.59.0.777148577824.issue2983@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've added it to PyPi (http://pypi.python.org/pypi/pyttk) yesterday to
facilitate the process of installing the module (without needing to
checkout the repo) in the hope that people will use it, and contribute
to make it better and possibly even support its inclusion into python
(given the chances of getting this into 2.6 and 3.0 are near zero now).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Thu Jul 24 14:30:50 2008
From: report at bugs.python.org (Franco DiRosa)
Date: Thu, 24 Jul 2008 12:30:50 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216902649.89.0.610240495349.issue1758146@psf.upfronthosting.co.za>


Franco DiRosa <fdirosa at stny.rr.com> added the comment:

I'm unsure if you are understanding what I'm doing so here is the 
story...

I stepped through Py_Initialize and this function takes the main 
interpreter and it's initial thread state and makes that the GIL thread 
state.

The following code in Py_Initialize hijacks the main interpreter and 
thread state for GIL use...

/* auto-thread-state API, if available */
#ifdef WITH_THREAD
    _PyGILState_Init(interp, tstate);
#endif /* WITH_THREAD */

WITH_THREAD is defined since I'm using multithreading in my application.

So now if you create thread states from the main interpeter and use the 
PyEval_Acquire/Release and PyThreadState_Swap you will get the 
assertion when compiled with the DEBUG option. If you use the 
PyGILState_Ensure and PyGILState_Release functions you don't. 

What I'm doing is that I have a Windows application with embedded 
python.  The application spawns multiple threads each running a python 
script.  Each application thread has its own unique PyThreadState 
created from the main interpreter because I wanted all the modules 
loaded only once for resource conservation purposes (thus use only one 
interpreter). I used PyEval_Acquire/Release and PyThreadState_Swap to 
handle swapping in each application thread's thread state when each one 
uses the python API.  This worked great in RELEASE compilation but in 
DEBUG it asserted.  Now that I use the GIL functions it works well and 
not only that, I removed the code I had put in myself to handle python 
callback's into the application and avoiding deadlocks by calling 
PyEval_Acquire onto itself (since it uses mutexes which doesn't do 
reference counting so it could deadlock waiting on itself to complete)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Thu Jul 24 14:39:00 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 24 Jul 2008 12:39:00 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1216903140.68.0.200769799306.issue2834@psf.upfronthosting.co.za>


Changes by Mark Summerfield <mark at qtrac.eu>:


----------
nosy: +mark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Thu Jul 24 14:39:17 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 24 Jul 2008 12:39:17 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216903157.59.0.674778603781.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for the hints. It appeared that "universal text mode" is not for
crossplatform but for platform-specific programming. =)

So I gave it up and ended with my own 'rb' newlines counter and 'wb'
writer which inserts lines in required format.

As for 2.6 io.open()
http://docs.python.org/dev/library/io.html#module-io
- can anybody point what's the difference between text mode with
newlines='' and binary mode?
- the comment about newline=<string>
"If it is '', universal newline mode is enabled, but line endings are
returned to the caller untranslated. If it has any of the other legal
values, input lines are only terminated by the given string, and the
line ending is returned to the caller untranslated."
does it mean that if newline='\r\n' is specified all single '\n'
characters are returned inline?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 24 15:41:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Jul 2008 13:41:37 +0000
Subject: [issue3433] Mac, 3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1216906897.35.0.66334612833.issue3433@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Isn't this a Fink problem then?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Thu Jul 24 16:20:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 14:20:18 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216909218.77.0.531823284376.issue3359@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> does it mean that if newline='\r\n' is specified all single '\n'
> characters are returned inline?
Yes.

Let's take a file with mixed newlines:
>>> io.open("c:/temp/t", "rb").read()
'a\rb\r\nc\nd\n'

rb mode splits only on '\r\n' (I'm on Windows)
>>> io.open("c:/temp/t", "rb").readlines()
['a\rb\r\n', 'c\n', 'd\n']

rU mode splits on every newline, and converts everything to \n
>>> io.open("c:/temp/t", "rU").readlines()
[u'a\n', u'b\n', u'c\n', u'd\n']

newline='' splits like rU, but does not translate newlines:
>>> io.open("c:/temp/t", newline='').readlines()
[u'a\r', u'b\r\n', u'c\n', u'd\n']

newline='\r\n' only splits on the specified string:
>>> io.open("c:/temp/t", newline='\r\n').readlines()
[u'a\rb\r\n', u'c\nd\n']

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 24 16:29:32 2008
From: report at bugs.python.org (Robin Dunn)
Date: Thu, 24 Jul 2008 14:29:32 +0000
Subject: [issue3433] Mac, 3.0 framework install error with fink cp
In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za>
Message-ID: <1216909772.13.0.414558265351.issue3433@psf.upfronthosting.co.za>


Robin Dunn <robin at alldunn.com> added the comment:

Maybe, but I think that a more proper approach would be one of the
following:

* Decide that features specific to Apple's cp are required and change
the Makefile to use /bin/cp instead of just cp.

* Use configure to determine if a GNU cp is present and if so adjust the
command-line parameters used.

* Just use the $(INSTALL) value already set by configure as already used
in the main Makefile.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3433>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:07:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jul 2008 15:07:53 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1216912073.55.0.407150169426.issue2834@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:11:57 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 24 Jul 2008 15:11:57 +0000
Subject: [issue1758146] Crash in PyObject_Malloc
Message-ID: <1216912317.57.0.32356859179.issue1758146@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

I do understand.

The initial thread, which is effectively a foreign thread to Python to 
begin with, when used to initialise Python, ie., call Py_Initialize(), 
is treated in a special way in as much as as a side effect it does that 
initialisation of GIL internal thread state. This is as you say. But, 
this is the only foreign thread this implicitly occurs for and why the 
main thread is a bit special.

If you were to create additional foreign threads outside of Python, ie., 
in addition to main thread which initialised it, those later threads 
should not fail the Py_DEBUG test unless the code they execute 
explicitly calls the simplified API and by doing so implicitly causes 
internal threadstate for that thread to be created.

Hope this makes sense. Sorry, in a bit of a hurry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758146>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:26:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jul 2008 15:26:33 +0000
Subject: [issue2832] Line numbers reported by extract_stack are offset by the
	#-*- encoding line
In-Reply-To: <1210567925.19.0.359554733284.issue2832@psf.upfronthosting.co.za>
Message-ID: <1216913193.42.0.371884454854.issue2832@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2832>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:30:36 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:30:36 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

I had to use csv module recently and ran into a "problem" with
DictReader. I had to get headers of CSV file and only after that iterate
throgh each row. But AFAIU there is no way to do it, other then
subclassing. So, basically, right now we have this:

Python 3.0b2+ (unknown, Jul 24 2008, 12:15:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
>>> next(r)
{'baz': '13', 'foo': '42', 'bar': '27'}
>>> r.fieldnames
['foo', 'bar', 'baz']

I think it would be much more useful, if DictReader got 'fieldnames' on
calling __init__ method, so this would look like this:
>>> r = csv.DictReader(open('test.csv'))
>>> r.fieldnames
['foo', 'bar', 'baz']

The easy way to do this is to subclass csv.DictReader.
The hard way to do this is to apply the patches I'm attaching. :)
These patches also remove redundant check for self.fieldnames being None
for each next()/__next__() call

----------
files: py3k.csv.py.diff
keywords: patch
messages: 70207
nosy: mishok13
severity: normal
status: open
title: csv.DictReader inconsistency
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10965/py3k.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:31:51 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:31:51 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913511.86.0.582162352803.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Added file: http://bugs.python.org/file10966/trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:32:53 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:32:53 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913573.18.0.450553761098.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file10966/trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:33:22 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:33:22 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913602.17.0.865670574111.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Added file: http://bugs.python.org/file10967/trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:33:38 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 15:33:38 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216913618.09.0.635430502188.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:34:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jul 2008 15:34:16 +0000
Subject: [issue2566] Py3.0a4 wsgiref simple_server failed to start
In-Reply-To: <1207538995.31.0.628770173127.issue2566@psf.upfronthosting.co.za>
Message-ID: <1216913656.64.0.908105957918.issue2566@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The same bug is being discussed in #3348

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Cannot start wsgiref simple server in Py3k

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2566>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:35:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jul 2008 15:35:04 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1216913705.0.0.804269791011.issue3348@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +delimy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:50:26 2008
From: report at bugs.python.org (mARK)
Date: Thu, 24 Jul 2008 15:50:26 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>


New submission from mARK <python.mbloore at xoxy.net>:

RobotFileParser.parse() contains the lines

                elif line[0] == "disallow":
                    if state != 0:
                        entry.rulelines.append(RuleLine(line[1], False))
                        state = 2
                elif line[0] == "allow":
                    if state != 0:
                        entry.rulelines.append(RuleLine(line[1], True))

with no 'state = 2' in the 'allow' part.
This causes different behaviour depending on whether the file ends with
'allow' or 'disallow', or an empty line.

Those lines were taken from revision 65118.  My Python 2.5 sources are
similar.  I have not checked others.

----------
components: Library (Lib)
messages: 70209
nosy: mbloore
severity: normal
status: open
title: robotparser.py missing one line
type: behavior
versions: Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:52:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Jul 2008 15:52:49 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216914769.26.0.642813632224.issue3437@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Thu Jul 24 17:59:00 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Jul 2008 15:59:00 +0000
Subject: [issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with
	statement
In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
Message-ID: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Yesterday I read at a maillist about IDLE being able to use the "with"
statement in python 2.5 without needing to explicitly doing "from
__future__ import with_statement", then today I started tracing the
origin of this. It starts at the use of the InteractiveInterpreter from
the code module (so this report affects any custom shells based on it),
which uses the codeop module to compile lines.

The Compile class of the codeop module, innocently compiles the passed
source with a PyCF_DONT_IMPLY_DEDENT flag by default (I'm not going to
enter in the other details done by Compile). 
This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at
parsetok.py with a value of 0x0002) by a PARSER_FLAGS macro at
pythonrun.c. Later on the function parsertok at Parser/parsetok.c is
called and it performs this check "if (flags &
PyPARSE_WITH_IS_KEYWORD)", but PyPARSE_WITH_IS_KEYWORD right now has a
value of 0x0003, so this check ends up working for both
PyPARSE_WITH_IS_KEYWORD and PyPARSE_DONT_IMPLY_DEDENT, causing the
with_statement to be enabled if the PyCF_DONT_IMPLY_DEDENT flag is
passed to the compile builtin.

To test this, start the interpreter (python 2.5) and:

>>> a = compile('with open("something") as x: pass\n', '-', 'single', 0x200)
>>> import __future__
>>> a = compile('with open("something") as x: pass\n', '-', 'single',
__future__.with_statement.compiler_flag)

Notice how it works in both cases. 

The patch added is deadly (!) simple (make clean is needed).

----------
components: Interpreter Core
files: new_PyPARSE_WITH_IS_KEYWORD.diff
keywords: patch
messages: 70210
nosy: gpolo
severity: normal
status: open
title: PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement
versions: Python 2.5
Added file: http://bugs.python.org/file10968/new_PyPARSE_WITH_IS_KEYWORD.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3438>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:01:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Jul 2008 16:01:37 +0000
Subject: [issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with
	statement
In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
Message-ID: <1216915297.88.0.555799439902.issue3438@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

"This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at
parsetok.py with a value of 0x0002"

Sorry, it is defined at "parsetok.h" of course.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3438>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:04:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Jul 2008 16:04:03 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1216915443.2.0.218456409846.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch adding the s* format, and changing files, sockets, and
fileio to use it. For bz2, the immediate effect is that you get a type
error (as an object providing bf_releasebuffer cannot be converted
through s#/w# anymore); it would be possible to fix bz2 also to use
s*/w* instead.

I'd like reviewers to focus on flaws in the approach and bugs in the
implementation; existing code should be converted to the new API
afterwards (or not converted at all for 2.6/3.0, but only as patches get
contributed).

If this is accepted in principle, I'll forward-port it to 3.0.

Added file: http://bugs.python.org/file10969/s_star.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:18:50 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Jul 2008 16:18:50 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216916330.53.0.532232313598.issue3436@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think this is the wrong approach.  It would be better to have a 
separate getheader() method.  Having __init__ do the deed is at odds 
with other uses of __init__ that only do setup but don't start reading.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:30:00 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 16:30:00 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216917000.18.0.220198805235.issue3436@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

And how this method should look?
Something like this, I suppose:
def getheader(self):
    if self.fieldnames is None:
        try:
            self.fieldnames = self.reader.next()
        except StopIteration:
            pass
     return self.fieldnames

Well, adding new API after beta2 is a "no-no" as I understand, so this
getheader() method can be added only in 2.7/3.1 releases. Should I post
updated patches or just live with it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:41:04 2008
From: report at bugs.python.org (Dylan Grose)
Date: Thu, 24 Jul 2008 16:41:04 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216917664.79.0.400105457696.issue3394@psf.upfronthosting.co.za>


Changes by Dylan Grose <dgrose at gmail.com>:


----------
nosy: +dkbg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Thu Jul 24 18:57:26 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 16:57:26 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216918646.21.0.38449463741.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

btw, some of the docstrings are also outdated, e.g. Pool.imap, Pool.map,
etc. Should I handle this one too?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Thu Jul 24 19:20:44 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Thu, 24 Jul 2008 17:20:44 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>


New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:

Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.frexp(10**100)
(0.5714936956411375, 333)
>>> math.frexp(10**1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C double
>>>

(Same behavior in Python 2.5.2, and presumably 2.6 although I haven't
checked the latter.)

I think it should be easy to make frexp work for large integers by
calling PyLong_AsScaledDouble and adding the exponents. It would be
logical to fix this since math.log(n) already works for large integers.

My reason for requesting this change is that math.frexp is the fastest
way I know of to accurately count the number of bits in a Python integer
(it is more robust than math.log(n,2) and makes it easy to verify that
the computed size is exact) and this is something I need to do a lot.

Actually, it would be even more useful to have a standard function to
directly obtain the bit size of an integer. If I'm not mistaken,
PyLong_NumBits does precisely this, and would just have to be wrapped.
Aside from my own needs (which don't reflect those of the Python
community), there is at least one place in the standard library where
this would be useful: decimal.py contains an inefficient implementation
(_nbits) that could removed.

----------
components: Library (Lib)
messages: 70216
nosy: fredrikj
severity: normal
status: open
title: math.frexp and obtaining the bit size of a large integer
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Jul 24 19:23:44 2008
From: report at bugs.python.org (Roger Demetrescu)
Date: Thu, 24 Jul 2008 17:23:44 +0000
Subject: [issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with
	statement
In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
Message-ID: <1216920224.49.0.850157717747.issue3438@psf.upfronthosting.co.za>


Changes by Roger Demetrescu <roger.demetrescu at gmail.com>:


----------
nosy: +rdemetrescu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3438>
_______________________________________

From report at bugs.python.org  Thu Jul 24 19:26:33 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 24 Jul 2008 17:26:33 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216920393.9.0.169085819436.issue3256@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

that's your call Andrii

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Thu Jul 24 19:32:58 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 24 Jul 2008 17:32:58 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216920778.3.0.864381429815.issue3359@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This '\r' makes things worse. I am also on Windows and didn't thought
that "rb" processes '\r\n' linefeeds as a side-effect of '\n' being the
last character. Thanks.

newline='' is just what I need. I guess there is no alternative to it in
2.5 series except splitting lines returned from binary read manually.
What about file.newlines attribute - is it preserved in 2.6/Py3k?

BTW, it would be nice to have this example in manual.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 24 20:51:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jul 2008 18:51:46 +0000
Subject: [issue3359] add 'rbU' mode to open()
In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za>
Message-ID: <1216925506.04.0.897256888779.issue3359@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please read
http://docs.python.org/dev/library/io.html#io.TextIOBase.newlines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3359>
_______________________________________

From report at bugs.python.org  Thu Jul 24 20:57:37 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 24 Jul 2008 18:57:37 +0000
Subject: [issue2417] [py3k] Integer floor division (//): small int check
	omitted
In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za>
Message-ID: <1216925857.15.0.411497569946.issue2417@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in r65220.

Thank you everybody!!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2417>
_______________________________________

From report at bugs.python.org  Thu Jul 24 21:14:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 24 Jul 2008 19:14:55 +0000
Subject: [issue2916] urlgrabber.grabber calls setdefaulttimeout
In-Reply-To: <1211212331.88.0.0515887247336.issue2916@psf.upfronthosting.co.za>
Message-ID: <1216926895.19.0.96982615186.issue2916@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2916>
_______________________________________

From report at bugs.python.org  Thu Jul 24 21:41:58 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Jul 2008 19:41:58 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216928518.96.0.535888935041.issue3439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to work on a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Jul 24 21:46:32 2008
From: report at bugs.python.org (Donovan Baarda)
Date: Thu, 24 Jul 2008 19:46:32 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
In-Reply-To: <1216700495.25.0.41435710668.issue1767370@psf.upfronthosting.co.za>
Message-ID: <11697.88.101.207.173.1216928721.squirrel@minkirri.apana.org.au>


Donovan Baarda <abo at users.sourceforge.net> added the comment:

On Tue, July 22, 2008 05:21, Martin v. L??wis wrote:
>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> We would need the copyright holder of the patch to submit a contributor
> form. Would that be possible?

he works for Google (krabbe at google.com), and so do I (abo at google.com)... I
think Google has some sort of company wide contributor agreement, and I
faintly recall signing something before I started working at Google...

krabbe also has a more recent version of this patch that we both keep
failing to submit..

Please let me know if he still needs to sign something, and I'll try to
get him to submit his most recent version of this...

> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1767370>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Thu Jul 24 21:47:10 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Jul 2008 19:47:10 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216928830.49.0.566908809198.issue3439@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I prefer your idea to expose PyLong_Numbits().  IMO, frexp() is very 
much a floating point concept and should probably remain that way.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Jul 24 22:48:30 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 24 Jul 2008 20:48:30 +0000
Subject: [issue3256] Multiprocessing docs are not 3.0-ready
In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za>
Message-ID: <1216932510.92.0.276073304506.issue3256@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

OK, I'll work on this too. :) Patch should be ready by Monday.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3256>
_______________________________________

From report at bugs.python.org  Thu Jul 24 22:58:55 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 24 Jul 2008 20:58:55 +0000
Subject: [issue3440] Starting Python as a subprocess fails when
	subprocess.Popen has env argument
In-Reply-To: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za>
Message-ID: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

Python 2.6b2 (r26b2:65106, Jul 18 2008, 18:22:27) [MSC v.1500 32 bit
(Intel)] on win32

Windows XP Professional, SP 2

Library class subprocess.Popen


When subprocess.Popen is used to start the python interpreter as a
subprocess with a custom environment, env is set to a mapping, the
subprocess terminates with the following pop-up error dialog:

"The application failed to initialize properly (0xc0150004). Click on OK
to terminate the application."

The attached fail.py program reproduces the bug. It should print "ABCDE"
if successful. It does for Pythons 2.4 and 2.5.

The reason is that Python 2.6 on Windows requires the environment
variable SystemRoot, which it cannot find. This is demonstrated by
modifying fail.py to include SystemRoot in the environment. This works:

import sys
import os
import subprocess

command = ('''%s -c "import os; print os.environ['YAHOO']"''' %
           sys.executable)

env = {"YAHOO": "ABCDE", "SystemRoot": os.environ["SystemRoot"]}
subprocess.Popen(command, env=env).wait()

----------
components: Library (Lib), Windows
files: fail.py
messages: 70225
nosy: kermode
severity: normal
status: open
title: Starting Python as a subprocess fails when subprocess.Popen has env argument
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file10970/fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3440>
_______________________________________

From report at bugs.python.org  Thu Jul 24 23:11:09 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 24 Jul 2008 21:11:09 +0000
Subject: [issue3422] sphinx.doc.autodoc: Hook for changing argspec
In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
Message-ID: <1216933869.53.0.367137904907.issue3422@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Suggested patch attached. Tested on Numpy documentation.

It adds a new signal,

    autodoc-process-signature(app, what, name, obj, options,
                              signature, return_annotation)

which is assumed to return either None or a 
new (signature, return_annotation) tuple. Warnings are raised
only if introspection fails and none of the event handlers returns
a new signature.

----------
keywords: +patch
Added file: http://bugs.python.org/file10971/autodoc-process-signature.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3422>
_______________________________________

From report at bugs.python.org  Thu Jul 24 23:25:37 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 24 Jul 2008 21:25:37 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1216934737.45.0.156614124307.issue3353@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

That's should be all that's needed to expose the existing API, as is. 
If you want to verify the build, you can grab the pytoken.c and setup.py
files from this directory, and try building the module.

http://svn.effbot.org/public/stuff/sandbox/pytoken/

Make sure you remove the local copy of "tokenizer.h" that's present in
that directory before you build.  If that module builds, all's well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Thu Jul 24 23:39:58 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Jul 2008 21:39:58 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216935598.26.0.118628105023.issue3439@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Another reason to leave frexp() untouched  is that it is tightly 
coupled to ldexp() as its inverse, for a lossless roundtrip:

  assert ldexp(*frexp(pi)) == pi

This relationship is bound to get mucked-up or confused if frexp starts 
accepting large integers that are no exactly representable as floats 
(i.e. 2**100+1).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Jul 24 23:55:51 2008
From: report at bugs.python.org (=?utf-8?q?Mart=C3=ADn_Conte_Mac_Donell?=)
Date: Thu, 24 Jul 2008 21:55:51 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1216936551.24.0.583515004646.issue1767370@psf.upfronthosting.co.za>


Mart?n Conte Mac Donell <Reflejo at gmail.com> added the comment:

I've signed and faxed the form. Just in case.

Martin.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Fri Jul 25 01:12:22 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Thu, 24 Jul 2008 23:12:22 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216941142.42.0.493323507872.issue3439@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

Raymond, yes, I think that a separate numbits function would better,
although exposing this functionality would not prevent also changing the
behavior of frexp. As I said, math.log already knows about long
integers, so handling long integers similarly in frexp would not be all
that unnatural. (On the other hand, it is true that math.sqrt, math.pow,
math.cos, etc could all theoretically be "fixed" to work with
larger-than-double input, and that slippery slope is probably better
avoided.)

Good point about roundtripping, but the problem with that argument is
that frexp already accepts integers that cannot be represented exactly,
e.g.:

>>> ldexp(*frexp(10**100)) == 10**100
False

Anyway, if there is support for exposing _PyLong_Numbits, should it be a
method or a function? (And if a function, placed where? Should it accept
floating-point input?)

I'm attaching a patch (for the trunk) that adds a numbits method to the
int and long types. My C-fu is limited, and I've never hacked on Python
before, so the code is probably broken or otherwise bad in several ways
(but in that case you can tell me about it and I will learn something
:-). I did not bother to optimize the implementation for int, and the
tests may be redundant/incomplete/placed wrongly.

A slight problem is that _PyLong_NumBits is restricted to a size_t, so
it raises an OverflowError on 32-bit platforms for some easily
physically representable numbers:

>>> (1<<3*10**9).numbits()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

This would need to be fixed somehow.

If numbits becomes a method, should it also be added to the Integral
ABC? GMPY's mpz type, by the way, defines a method numdigits(self,
base). This generalization would possibly be overkill, but it's worth
considering.

If it's too late to add this method/function for 2.6 and 3.0, please
update the issue version field as appropriate.

----------
keywords: +patch
Added file: http://bugs.python.org/file10972/numbits.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:11:07 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 00:11:07 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1216944667.62.0.268421571631.issue3439@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

numbers.Integral is already way too fat of an API.  Am -1 on expanding 
it further.  Recommend sticking with the simplest, least invasive, 
least pervasive version of your request, a numbits() method for ints.

FWIW, in Py2.6 you can already write:

  def numbits(x):
      return len(bin(abs(x))) - 2

----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:30:31 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:30:31 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216945831.47.0.901789397931.issue3366@psf.upfronthosting.co.za>


Changes by nirinA raseliarison <nirina at mail.blueline.mg>:


Removed file: http://bugs.python.org/file10954/mathmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:31:19 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:31:19 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216945879.51.0.895164012985.issue3366@psf.upfronthosting.co.za>


Changes by nirinA raseliarison <nirina at mail.blueline.mg>:


Added file: http://bugs.python.org/file10973/pymath.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:31:54 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:31:54 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216945914.44.0.626736449552.issue3366@psf.upfronthosting.co.za>


Changes by nirinA raseliarison <nirina at mail.blueline.mg>:


Added file: http://bugs.python.org/file10974/mathmodule.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:32:26 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:32:26 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216945946.77.0.201103445579.issue3366@psf.upfronthosting.co.za>


Changes by nirinA raseliarison <nirina at mail.blueline.mg>:


Added file: http://bugs.python.org/file10975/pymath.h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:32:46 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:32:46 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216945966.81.0.327951357805.issue3366@psf.upfronthosting.co.za>


Changes by nirinA raseliarison <nirina at mail.blueline.mg>:


Added file: http://bugs.python.org/file10976/test_math.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 02:33:29 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 00:33:29 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216946009.02.0.844421366462.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

Mark Dickinson :
> So a full patch for this should touch at least Python/pymath.c, 
> Modules/mathmodule.c, configure.in, Lib/test/test_math.py, and 
> Doc/Library/math.rst.
here are patches for Python/pymath.c, Modules/mathmodule.c,
Lib/test/test_math.py, Doc/Library/math.rst and also Include/pymath.h.
i haven't touched configure.in as i've erf, erfc, lgamma and tgamma
on my platform, so the patches can be tested.
the doc may need better wording and test_math.py some additionnal tests.

Raymond Hettinger:
> It would be nice if we knew the error bounds for each of the 
> approximation methods. Do we know how the coefficients were generated?
it will be really great if we're able to regenerate all these
coefficients. this may be done by following the comments in
the original codes, but not that easy and not sure one will obtain
the same things.

> The lowword/highword macros look to be tightly tied to the internal 
> processor representation for floats.  It would be more portable and 
> maintainable to replace that bit twiddling with something based on frexp
it seems possible to avoid the use of these macros.
i'll try to find time to dig up these possibilities.

Added file: http://bugs.python.org/file10977/math.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:05:48 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 02:05:48 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216951548.75.0.623320711335.issue3366@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Why isn't tgamma() simply named gamma()?  The t prefix does nothing for 
me except raise questions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:13:05 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:13:05 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216951985.3.0.349626477103.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Do you have a concrete robots.txt file I can use in a test case?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:19:11 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:19:11 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216952351.64.0.193872976533.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Perhaps more important than a test case, can you explain what states 0, 1 
and 2 are (maybe give them some symbolic names I can at least put in a 
comment)?  This is not my code.  Though I wrote the first version of the 
robotparser module and I served as the person who checked this version 
into the repo, as I recall this is a complete rewrite.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:26:56 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:26:56 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216952816.65.0.0218292310845.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

*sigh* there are no test cases with Allow: lines in test_robotparser.py.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:29:53 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:29:53 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216952993.34.0.665746543275.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

*sigh* there are no test cases in the current code with Allow: lines in 
test_robotparser.py.

----------
priority:  -> normal
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:30:02 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:30:02 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1216953002.46.0.695528362836.issue3437@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:41:18 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 25 Jul 2008 02:41:18 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1216953677.99.0.0463693105921.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

That would be a fairly easy change to the DictReader class (see
the attached patch) but probably can't be applied at this point
in the 2.6 release cycle even though all csv module tests pass
with it.

----------
nosy: +skip.montanaro
Added file: http://bugs.python.org/file10978/csv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Jul 25 04:51:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Jul 2008 02:51:46 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1216954306.65.0.113433638356.issue1767370@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If this is under the Google agreement, then it's fine (I think). It's
just that we can't accept anonymous contributions (even if made through
a known middleman).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_______________________________________

From report at bugs.python.org  Fri Jul 25 06:09:07 2008
From: report at bugs.python.org (Richard Jones)
Date: Fri, 25 Jul 2008 04:09:07 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>


New submission from Richard Jones <richardjones at optushome.com.au>:

The Python 2.5 "-m" command-line option allowed execution of a package
directly, by invoking the __init__.py module.

Python 2.6 no longer allows this.

This is a quite unfortunate regression, and I would urge the decision to
hobble it to be reconsidered.

----------
messages: 70240
nosy: richard
severity: normal
status: open
title: Regression in "module as a script" command-line option
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Fri Jul 25 06:10:58 2008
From: report at bugs.python.org (Richard Jones)
Date: Fri, 25 Jul 2008 04:10:58 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1216959058.69.0.15626497335.issue3441@psf.upfronthosting.co.za>


Changes by Richard Jones <richardjones at optushome.com.au>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Fri Jul 25 06:29:44 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 25 Jul 2008 04:29:44 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1216960184.2.0.135864899275.issue3366@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I think he just carried the names over from C, where:

tgamma() is the "true gamma function"
lgamma() is the log of the gamma function

and gamma() might be tgamma() or lgamma() depending on which C library
you use (sigh).

I'm +1 on making gamma() be the true gamma function and not carrying
over this brain-damage to Python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 07:26:05 2008
From: report at bugs.python.org (Collin Winter)
Date: Fri, 25 Jul 2008 05:26:05 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1216963565.08.0.288621699731.issue3358@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Yeah, benchmarking this change against the unmodified HEAD, the
iterative version runs the test suite much slower. Let's file this under
the "didn't work out" category. It was a good idea that you obviated
with the fix_imports improvements.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Fri Jul 25 09:09:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Jul 2008 07:09:02 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1216969742.37.0.291337121351.issue3441@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Fri Jul 25 11:16:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 09:16:11 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1216977371.14.0.264260457721.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't yet studied the patch in detail but I have a few questions:

(1) are you sure it is safe not to INCREF the obj pointer in the
Py_buffer? in the cases handled by your patch we still hold a reference
to the original args tuple and dict before calling PyBuffer_Release(),
but some functions may want to store the Py_buffer object somewhere to
re-use it later. It would seem more logical for PyBuffer_FillInfo to
INCREF the obj, and for PyBuffer_Release to DECREF it and set it to NULL.

(2) is it necessary to call directly bf_getbuffer & the like or is there
a higher-level API to do it?

(3) didn't you forget to convert "PyArg_ParseTuple(args, "s#iO:sendto",
[...])" in sock_sendto?

(4) is it really necessary to do a special case with PyString_Check()
rather than rely on the string type's getbuffer method?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Jul 25 11:46:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 09:46:48 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1216979208.2.0.591372846629.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Travis, it would be really nice to have your input on this.

----------
nosy: +teoliphant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Jul 25 11:57:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 09:57:32 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216979852.7.0.690496971134.issue3394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agree with using 0600 as default permissions.

----------
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Fri Jul 25 12:26:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 25 Jul 2008 10:26:31 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1216981591.87.0.525229110025.issue3394@psf.upfronthosting.co.za>


Changes by Mark Summerfield <mark at qtrac.eu>:


----------
nosy: +mark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Fri Jul 25 12:42:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 10:42:58 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1216982578.15.0.814987769415.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hirokazu, does replacing the following line (rather than changing the
type of the `ch` variable):
         ch = *s;
with
         ch = (unsigned char) *s;

fix the crash as well?

----------
keywords: +patch
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 13:10:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 25 Jul 2008 11:10:21 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1216984221.46.0.54900259188.issue2242@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

With this patch? Yes, it fixed crash.

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c	(revision 65223)
+++ Objects/unicodeobject.c	(working copy)
@@ -1523,7 +1523,7 @@
     while (s < e) {
         Py_UNICODE ch;
         restart:
-        ch = *s;
+        ch = (unsigned char)*s;
 
         if (inShift) {
             if ((ch == '-') || !B64CHAR(ch)) {


>>> '+\xc1'.decode("utf7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "e:\python-dev\trunk\lib\encodings\utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-1:
unexpected

# But I don't know whether this behavior is right or not....

I confirmed test_unicode, test_codecs, test_codeccallbacks passed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 13:38:07 2008
From: report at bugs.python.org (Pavel Strashkin)
Date: Fri, 25 Jul 2008 11:38:07 +0000
Subject: [issue3442] wsgiref.validate.InputWrapper.readline does not accept
	optional "length" argument
In-Reply-To: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>
Message-ID: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>


New submission from Pavel Strashkin <xaka2004 at gmail.com>:

All file/stream-like objects in Python have "readline" method with
optional "length" argument, but wsgiref.validate.InputWrapper doest not
have. Some 3rd party modules/packages use this argument. As result there
is exception:
<type 'exceptions.TypeError'>: readline() takes exactly 1 argument (2 given)

I think wsgiref.validate.InputWrapper.readline must be implemented same
to wsgiref.validate.InputWrapper.read:

def readline(self, *args, **kwargs):
    v = self.input.readline(*args, **kwargs)
    assert_(type(v) is type(""))
    return v

----------
components: Library (Lib)
messages: 70248
nosy: xaka
severity: normal
status: open
title: wsgiref.validate.InputWrapper.readline does not accept optional "length" argument
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3442>
_______________________________________

From report at bugs.python.org  Fri Jul 25 13:43:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Jul 2008 11:43:01 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1216986180.89.0.259897516638.issue2242@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

VS8 and VS9 are immune to the crash, even if the exception message
differ between release and debug builds.

VC6 crashes, and the proposed patch fixes the problem there as well.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:11:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 12:11:38 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1216984221.46.0.54900259188.issue2242@psf.upfronthosting.co.za>
Message-ID: <1216987889.4889c2f15a132@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Hirokazu Yamamoto <report at bugs.python.org>:
>
> With this patch? Yes, it fixed crash.

Thanks!

> # But I don't know whether this behavior is right or not....

As the name implies, utf7 is a 7-bit coding of Unicode... bytes >= 0x80 must
raise an exception. The error message could be better though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:33:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 12:33:08 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1216989188.4.0.818378953744.issue3441@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Please see #2751.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:41:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 12:41:28 +0000
Subject: [issue1734234] Fast path for unicodedata.normalize()
Message-ID: <1216989688.11.0.274933286933.issue1734234@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734234>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:42:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 12:42:54 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1216989774.61.0.998545488368.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch also has a test in it.

Added file: http://bugs.python.org/file10979/2242.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:53:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 12:53:39 +0000
Subject: [issue3442] wsgiref.validate.InputWrapper.readline does not accept
	optional "length" argument
In-Reply-To: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>
Message-ID: <1216990419.28.0.407782993351.issue3442@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> pje
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3442>
_______________________________________

From report at bugs.python.org  Fri Jul 25 14:55:50 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 25 Jul 2008 12:55:50 +0000
Subject: [issue3443] crash on badly initialised AttributeError
In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
Message-ID: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

I get a reproducible crash under Linux when running the test cases of
lxml's trunk in Py3b2. As usual with these things, it's not reproducible
when running the crashing test by itself, only when it hits the test
during the usual test run (which makes it look like somethings's leaking
between tests here).

Here is what gdb gives me so far.

----------------------
[...]
test_namespace_lookup (lxml.tests.test_classlookup.ClassLookupTestCase)
... ok
test_parser_based_lookup
(lxml.tests.test_classlookup.ClassLookupTestCase) ... ok
Doctest: test_css_select.txt ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210656576 (LWP 938)]
0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88
88          switch (PyTuple_GET_SIZE(self->args)) {
(gdb) pyo self
object  : AttributeError<NULL>
type    : AttributeError
refcount: 10
address : 0x8d747d4
$1 = void
(gdb) print self->args
$2 = (PyObject *) 0x0
(gdb) bt
#0  0x080f3b89 in BaseException_str (self=0x8d747d4) at
Objects/exceptions.c:88
#1  0x0805b158 in PyObject_Str (v=0x8d747d4) at Objects/object.c:414
#2  0x0807951a in unicode_new (type=0x81523a0, args=0x8de77ac, kwds=0x0)
at Objects/unicodeobject.c:9247
#3  0x0806068d in type_call (type=0x81523a0, args=0x8de77ac, kwds=0x0)
at Objects/typeobject.c:636
#4  0x080d83a9 in PyObject_Call (func=0x81523a0, arg=0x8de77ac, kw=0x0)
at Objects/abstract.c:2178
#5  0x0808de50 in PyEval_EvalFrameEx (f=0x8e2d07c, throwflag=0) at
Python/ceval.c:3606
#6  0x0808fccd in PyEval_EvalFrameEx (f=0x8e2bf14, throwflag=0) at
Python/ceval.c:3481
#7  0x0808fccd in PyEval_EvalFrameEx (f=0x8e2cef4, throwflag=0) at
Python/ceval.c:3481
#8  0x0808fccd in PyEval_EvalFrameEx (f=0x8e2d4ec, throwflag=0) at
Python/ceval.c:3481
#9  0x08090f6b in PyEval_EvalCodeEx (co=0x8268458, globals=0xb7b772d4,
locals=0x0, args=0x8e2cea4, argcount=3, kws=0x8e2ceb0, kwcount=1,
defs=0x826c678, defcount=3, kwdefs=0x0,
    closure=0x0) at Python/ceval.c:2830
#10 0x0808f63e in PyEval_EvalFrameEx (f=0x8e2cd54, throwflag=0) at
Python/ceval.c:3491
#11 0x0808fccd in PyEval_EvalFrameEx (f=0x8dc37a4, throwflag=0) at
Python/ceval.c:3481
#12 0x0808fccd in PyEval_EvalFrameEx (f=0x8da1d7c, throwflag=0) at
Python/ceval.c:3481
#13 0x08090f6b in PyEval_EvalCodeEx (co=0x84b21d0, globals=0x847d79c,
locals=0x0, args=0x8da0dbc, argcount=2, kws=0x8da0dc4, kwcount=2,
defs=0x8591b78, defcount=3, kwdefs=0x0,
    closure=0x0) at Python/ceval.c:2830
#14 0x0808f63e in PyEval_EvalFrameEx (f=0x8da0c64, throwflag=0) at
Python/ceval.c:3491
#15 0x0808fccd in PyEval_EvalFrameEx (f=0x8da00ec, throwflag=0) at
Python/ceval.c:3481
#16 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80410, globals=0xb7b75824,
locals=0x0, args=0x8d6ee98, argcount=2, kws=0x89e8058, kwcount=0,
defs=0x826a518, defcount=1,
    kwdefs=0x0, closure=0x0) at Python/ceval.c:2830
#17 0x080fe855 in function_call (func=0x8267e6c, arg=0x8d6ee8c,
kw=0x8ccee84) at Objects/funcobject.c:628
#18 0x080d83a9 in PyObject_Call (func=0x8267e6c, arg=0x8d6ee8c,
kw=0x8ccee84) at Objects/abstract.c:2178
#19 0x0808d73f in PyEval_EvalFrameEx (f=0x8d9ff84, throwflag=0) at
Python/ceval.c:3694
#20 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80458, globals=0xb7b75824,
locals=0x0, args=0x8d7f078, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0,
    closure=0x0) at Python/ceval.c:2830
[...]
(gdb) pyo 0x8268458
object  : <code object print_exception at 0x8268458, file
"/usr/local/python3.0b2/lib/python3.0/traceback.py", line 136>
type    : code
refcount: 2
address : 0x8268458
$3 = void
----------------------

When I call "pystack", gdb seems to lock up using 100% CPU, so I'm not
sure what else I can provide. The crash happening in a non-trivial
doctest makes is somewhat tricky to figure out what gets executed here.
At least, there is no anticipated AttributeError in the doctest, and it
doesn't seem to get raised when I run the test just by itself.

----------
components: Interpreter Core
messages: 70253
nosy: scoder
severity: normal
status: open
title: crash on badly initialised AttributeError
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3443>
_______________________________________

From report at bugs.python.org  Fri Jul 25 16:48:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 14:48:11 +0000
Subject: [issue3444] add warnings for intra-package imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Non-absolute or relative imports in 2.6 should give a Py3k warning.

----------
components: Interpreter Core
messages: 70254
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: add warnings for intra-package imports
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3444>
_______________________________________

From report at bugs.python.org  Fri Jul 25 16:55:48 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 25 Jul 2008 14:55:48 +0000
Subject: [issue3442] wsgiref.validate.InputWrapper.readline does not accept
	optional "length" argument
In-Reply-To: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za>
Message-ID: <1216997748.47.0.994655349443.issue3442@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Any package which is using the length argument to readline() is in
violation of PEP 333 and should be fixed.  The argument is intentionally
not supported by wsgiref.validate, since its purpose is to catch
incorrect programs that are violating the spec by using it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3442>
_______________________________________

From report at bugs.python.org  Fri Jul 25 17:26:55 2008
From: report at bugs.python.org (Antoine d'Otreppe)
Date: Fri, 25 Jul 2008 15:26:55 +0000
Subject: [issue3445] functools.update_wrapper bug
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>


New submission from Antoine d'Otreppe <a.dotreppe at gmail.com>:

When trying to do something like
"functools.update_wrapper(myWrapper, str.split)"

I got this error message:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Aspyct.py", line 175, in beforeCall
    _stickAdvice(function, theAdvice)
  File "Aspyct.py", line 90, in _stickAdvice
    functools.update_wrapper(theAdvice, function)
  File "/usr/lib/python2.5/functools.py", line 33, in update_wrapper
    setattr(wrapper, attr, getattr(wrapped, attr))
AttributeError: 'method_descriptor' object has no attribute '__module__'

----------
components: Library (Lib)
messages: 70256
nosy: Antoine d'Otreppe
severity: normal
status: open
title: functools.update_wrapper bug
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Fri Jul 25 17:36:54 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 25 Jul 2008 15:36:54 +0000
Subject: [issue1592] operations on closed shelves fail cryptically
In-Reply-To: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>
Message-ID: <1217000214.66.0.06840538047.issue1592@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Any reason this is not in trunk yet?

----------
nosy: +tebeka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
_______________________________________

From report at bugs.python.org  Fri Jul 25 17:59:23 2008
From: report at bugs.python.org (=?utf-8?q?Ignas_Mikalaj=C5=ABnas?=)
Date: Fri, 25 Jul 2008 15:59:23 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>


New submission from Ignas Mikalaj?nas <ignas at pov.lt>:

Not all combinations of unicode/non-unicode parameters work for ljust,
center and rjust. Passing a unicode character to them as a parameter
when the string is ascii fails with an error.

This doctest fails in 3 places. Though I would expect it to be passing.

def doctest_strings():
    """

      >>> uni = u"a"
      >>> ascii = "a"

      >>> uni.center(5, ascii)
      u'aaaaa'

      >>> uni.center(5, uni)
      u'aaaaa'

      >>> ascii.center(5, ascii)
      'aaaaa'

      >>> ascii.center(5, uni)
      u'aaaaa'

      >>> uni.ljust(5, ascii)
      u'aaaaa'

      >>> uni.ljust(5, uni)
      u'aaaaa'

      >>> ascii.ljust(5, ascii)
      'aaaaa'

      >>> ascii.ljust(5, uni)
      u'aaaaa'

      >>> uni.rjust(5, ascii)
      u'aaaaa'

      >>> uni.rjust(5, uni)
      u'aaaaa'

      >>> ascii.rjust(5, ascii)
      'aaaaa'

      >>> ascii.rjust(5, uni)
      u'aaaaa'

    """

----------
components: Library (Lib), Unicode
messages: 70258
nosy: ignas
severity: normal
status: open
title: center, ljust and rjust are inconsistent with unicode parameters
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3446>
_______________________________________

From report at bugs.python.org  Fri Jul 25 18:09:17 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 16:09:17 +0000
Subject: [issue1592] operations on closed shelves fail cryptically
In-Reply-To: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>
Message-ID: <1217002157.23.0.441767884051.issue1592@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
_______________________________________

From report at bugs.python.org  Fri Jul 25 18:51:15 2008
From: report at bugs.python.org (Alejandro J. Cura)
Date: Fri, 25 Jul 2008 16:51:15 +0000
Subject: [issue3447] itertools.izip_longest docs don't specify default
	fillvalue
In-Reply-To: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za>
Message-ID: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za>


New submission from Alejandro J. Cura <alecu at vortech.com.ar>:

izip_longest default fillvalue is None, but the docs don't specify it.
I'm attaching a diff that fixes this.

----------
assignee: georg.brandl
components: Documentation
files: itertools.izip_longest-default-fillvalue.diff
keywords: patch
messages: 70259
nosy: alecu, georg.brandl
severity: normal
status: open
title: itertools.izip_longest docs don't specify default fillvalue
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10980/itertools.izip_longest-default-fillvalue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3447>
_______________________________________

From report at bugs.python.org  Fri Jul 25 19:03:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 17:03:24 +0000
Subject: [issue3447] itertools.izip_longest docs don't specify default
	fillvalue
In-Reply-To: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za>
Message-ID: <1217005404.38.0.303721491616.issue3447@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks. Fixed in r65226.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3447>
_______________________________________

From report at bugs.python.org  Fri Jul 25 19:45:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Jul 2008 17:45:11 +0000
Subject: [issue1592] operations on closed shelves fail cryptically
In-Reply-To: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>
Message-ID: <1217007911.59.0.629112152337.issue1592@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The usual reasons, probably: nobody had time to work on it, as there are
so many other things to do.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
_______________________________________

From report at bugs.python.org  Fri Jul 25 19:47:01 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jul 2008 17:47:01 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1217008021.46.0.928551189492.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm +1 on making gamma() be the true gamma function and not carrying
> over this brain-damage to Python.

+1 from me, too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 19:53:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 17:53:16 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217008396.08.0.680137049949.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed in r65227. Please reopen if there's still a problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 19:59:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 17:59:48 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217008787.97.0.0699970496117.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On second thought, perhaps it should also be backported to 2.5, so I'm
leaving the bug open.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 20:01:35 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 18:01:35 +0000
Subject: [issue1592] operations on closed shelves fail cryptically
In-Reply-To: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>
Message-ID: <1217008895.67.0.39283880801.issue1592@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm working on this one.  Alternate patch attached.

The problem with the old one is that it slows down every access to the 
shelf and it prevents assignment to self.dict which has always been 
allowed.

The new patch improves error reporting without changing performance or 
semantics for shelves prior to closing.

----------
keywords: +patch
Added file: http://bugs.python.org/file10981/shelve.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
_______________________________________

From report at bugs.python.org  Fri Jul 25 20:06:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 18:06:06 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217009166.21.0.642467772505.issue2242@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> accepted
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 20:33:21 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Fri, 25 Jul 2008 18:33:21 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1217010801.63.0.162048786953.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

ouch!
i was asleep, at 3AM, when i edited the issue
and didn't really know what i was doing.
i just see that i removed, instead of edited the
mathmodule.diff and didn't check after.
so here it is again, with the url for original code
added.

if you want to test the erf, erfc, lgamma and gamma
please use this mathmodule.diff and the math_private.h header

the other diffs are incomplete and don't work, unless you have
erfs and gammas functions implemented in your platform.
i'll try to work on these files this weekend and
will rename tgamma to gamma.

Added file: http://bugs.python.org/file10982/mathmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 20:37:28 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 18:37:28 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1217011048.29.0.444693833704.issue3366@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can you also implement blending of approximations:  (1-t)*f1(x) + t*f2
(x)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Fri Jul 25 20:45:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2008 18:45:02 +0000
Subject: [issue1592] operations on closed shelves fail cryptically
In-Reply-To: <1197398296.88.0.878837711853.issue1592@psf.upfronthosting.co.za>
Message-ID: <1217011502.11.0.567453037409.issue1592@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r65233

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592>
_______________________________________

From report at bugs.python.org  Fri Jul 25 21:04:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 19:04:22 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217012662.12.0.397761512222.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the fix for 2.5 in r65234, can somebody try it out with
the failing MSVC version?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 21:12:28 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 25 Jul 2008 19:12:28 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1217011048.29.0.444693833704.issue3366@psf.upfronthosting.co.za>
Message-ID: <eae285400807251212t76515dc0kd5409aa609100238@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Fri, Jul 25, 2008 at 1:37 PM, Raymond Hettinger
<report at bugs.python.org>wrote:

> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> Can you also implement blending of approximations:  (1-t)*f1(x) + t*f2
> (x)
>

Is this necessary?  Are the approximations significantly different near the
transition points?

(Haven't had a chance to download the patch and try it myself as a I'm
getting on a plane in the morning--sorry)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080725/0ef99291/attachment.txt>

From report at bugs.python.org  Fri Jul 25 21:44:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 19:44:32 +0000
Subject: [issue3394] zipfile.writestr doesn't set external attributes,
	so files are extracted mode 000 on Unix
In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za>
Message-ID: <1217015072.31.0.245659284221.issue3394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r65235. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3394>
_______________________________________

From report at bugs.python.org  Fri Jul 25 22:01:50 2008
From: report at bugs.python.org (Eric Smith)
Date: Fri, 25 Jul 2008 20:01:50 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1217016110.91.0.428833459548.issue1222@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'd recommend breaking the patch into the 3 parts mentioned in msg61929,
then committing the first 2 parts.  That should make the 3rd part much
easier to evaluate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Jul 25 22:55:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 20:55:08 +0000
Subject: [issue1864] test_locale doesn't use unittest
In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
Message-ID: <1217019308.7.0.478825903391.issue1864@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in r65237. Hopefully it won't break in weird ways on some platforms...

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1864>
_______________________________________

From report at bugs.python.org  Fri Jul 25 22:55:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 20:55:46 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1217019346.95.0.499068121433.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The first 2 parts have been committed in r65237. I'll soon provide a
patch for the third part.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:02:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 21:02:41 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1217019761.62.0.0548360529813.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the patch for the third part.

Added file: http://bugs.python.org/file10984/thousands_sep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:02:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 21:02:46 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1217019766.83.0.948728223903.issue1222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10128/bug1222.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:02:50 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 21:02:50 +0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1217019770.89.0.054123142033.issue1222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file10041/1222.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:03:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Jul 2008 21:03:49 +0000
Subject: [issue3443] crash on badly initialised AttributeError
In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
Message-ID: <1217019829.87.0.80979010518.issue3443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduced the problem on Windows.
The exception shown is the AttributeError('next') raised and caught in
lxml._elementpath.find().
The "args" atribute is cleared in the BaseException_clear, during a call
to gc.collect() (in some tearDown() method).
Unfortunately this exception is still shomehow stored in the thread
state structure...

After some researches, I think that the problem is in Cython. Cython
tries to simulate a python frame without using the interpreter loop.
But at least an invariant is not respected: when a frame exits without
an exception set, the tstate->exc_type (and friends) should be NULL.
For example, at the end of the PyInit_etree() function (called by an
"import lxml.etree"), the tstate->exc_value contains an
AttributeError('module' object has no attribute 'unicode').

Now, the consequence may be that all these exceptions are "implicitely
chained" together. And there may be a subtle refcounting bug that shows
up only if this invariant is not respected.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3443>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:06:38 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 25 Jul 2008 21:06:38 +0000
Subject: [issue3448] Multi-process 2to3
In-Reply-To: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za>
Message-ID: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

Here is a working, multiprocess version of 2to3 with a few caveats.
First, you need to already have the processing module installed for this
to work. If we don't want to include processing in some way, I think I
can modify this to only import processing and use the Process method if
the user wants to run it with more than one process. Also, I know that
logger is supposed to be thread safe, so I am correct in assuming that
this means it is also multi-process safe? This fix delegates the fixing
of files to a designated number of processes, so on a multi-core
machine, it is significantly faster. It may be appropriate to add a test
suite for it, but I have not yet done so. I've tested it on my dual-core
laptop running Ubuntu and a quad-core mac and it appears to be working
fine. I don't know if the use of tempfile was the right choice, but it
seemed reasonable. Another possibility is to instead using a processing
Queue and pass it the output, filename, and input rather than calling
write_file. Also, the join timeout I used is completely arbitrary
because I don't really have a sense of what a reasonable value for it
should be.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: multiProcess.diff
keywords: patch
messages: 70277
nosy: collinwinter, nedds
severity: normal
status: open
title: Multi-process 2to3
type: performance
Added file: http://bugs.python.org/file10985/multiProcess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3448>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:10:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jul 2008 21:10:30 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217020230.65.0.0657847856065.issue3358@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Maybe this is a bad idea, but would it be possible/reasonable to provide
recursive and iterative implementations and use the iterative one on
large files?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:19:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Jul 2008 21:19:23 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217020763.7.0.59921835421.issue2242@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I confirm that r65234 for 2.5 corrects the crash.
(Windows XP, Visual Studio 6)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:20:32 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 25 Jul 2008 21:20:32 +0000
Subject: [issue3448] Multi-process 2to3
In-Reply-To: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za>
Message-ID: <1217020832.87.0.205022547886.issue3448@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Here is a version that only imports processing if the multi-process
option is specified. I don't know if this is the most efficient way it
can be done, and I think there's a better way to do it, but this works.

Added file: http://bugs.python.org/file10986/multiProcess2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3448>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:21:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 21:21:37 +0000
Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on
	Windows Vista
In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za>
Message-ID: <1217020897.03.0.929739819581.issue2242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks Amaury!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2242>
_______________________________________

From report at bugs.python.org  Fri Jul 25 23:22:13 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 25 Jul 2008 21:22:13 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217020933.16.0.129953315588.issue3358@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I don't think it would be hard to implement, I just need a good, fast
metric to determine if a file should be processed iteratively or
recursively. What do you think would be the best way to do this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Jul 26 00:15:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jul 2008 22:15:08 +0000
Subject: [issue1819] Speed hack for function calls with named parameters
In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za>
Message-ID: <1217024108.31.0.166602068793.issue1819@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r65240 (new pybench test) and r65241 (speedup patch).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1819>
_______________________________________

From report at bugs.python.org  Sat Jul 26 00:16:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jul 2008 22:16:13 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The IBM General Decimal Arithmetic Specification, on which the decimal 
module is based, has recently been updated to version 1.68;  the 
testcases from IBM have also been updated.

The comments in the decimal module clearly state that the decimal module 
should be kept in sync with the IBM specification, and that deviation 
from the spec is considered a bug.  So it seems to me that the decimal 
module should be updated, preferably before 2.6 and 3.0 come out.

As far as I can tell the required changes should be minimal:  max-
magnitude and min-magnitude definitely need changing, and there may be 
other minor changes necessary to make the new tests pass; I haven't 
looked properly yet.  I'll try to get to this in the next few days.

----------
assignee: marketdickinson
components: Library (Lib)
messages: 70284
nosy: facundobatista, marketdickinson, rhettinger
priority: critical
severity: normal
status: open
title: Update decimal module to version 1.68 of the IBM specification
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 00:20:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jul 2008 22:20:52 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217024452.33.0.0239945845536.issue3449@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One change from v1.66 to v1.68 of the spec:

"""The normalize operation has been renamed reduce to avoid confusion with 
normal numbers."""

The decimal module is not under any obligation to use the same names as in 
the IBM specification, so I don't think we're required to rename 
Decimal.normalize to Decimal.reduce.  Does anyone think that we should 
rename this method?  I'm inclined not to rename.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 01:34:47 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 25 Jul 2008 23:34:47 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217028887.78.0.252588176129.issue3449@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

-0 to rename it, specially considering that we had a reduce builtin in
our history... better to not confuse it. But we'd need to convert the
name in the tests...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 02:07:15 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jul 2008 00:07:15 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217030835.56.0.915023096223.issue3449@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on renaming.  I concur with Mark that we are under no obligation to 
match the names used in the spec -- only the functionality matters -- 
also we're already got a history of at least slightly different names.  
I also see no reason to break existing code relying on the existing 
name.  I also agree with Facundo that the "reduce" name has a 
completely unrelated association in the Python langauge.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 02:09:44 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jul 2008 00:09:44 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217030984.43.0.368582909911.issue3449@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

P.S. I also agree with Mark that the 1.68 update should be treated as a 
bugfix and go into the next beta, preferably as soon as possible.  
Facundo and I should both agree to give it a quick and thorough review 
so that the beta is as solid as possible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 08:40:11 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Jul 2008 06:40:11 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1217054410.64.0.652667795386.issue3441@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Now, if someone was to provide a 2.7 rfe with associated patch that
implements this feature properly, and includes an explanation for why it
doesn't subtly break imports the way 2.5 does, that would be a
completely different story.

But it isn't as simple as just getting rid of the explicit check that
prevents packages from being executed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Sat Jul 26 08:48:32 2008
From: report at bugs.python.org (Richard Jones)
Date: Sat, 26 Jul 2008 06:48:32 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1217054912.86.0.20067072804.issue3441@psf.upfronthosting.co.za>


Richard Jones <richardjones at optushome.com.au> added the comment:

I'm afraid it's all a bit opaque to an outsider like me. I've no idea 
what subtle breakage the feature was causing. I just saw it working 
quite nicely for me in 2.5 :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Sat Jul 26 09:10:37 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Jul 2008 07:10:37 +0000
Subject: [issue3441] Regression in "module as a script" command-line option
In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za>
Message-ID: <1217056237.72.0.910007059965.issue3441@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If I recall correctly (it's been a while), the breakages were tied in
with relative imports - probably something like explicit relative
imports not working at all, and implicit relative imports appearing to
work, but resulting in incorrect module names and sys.modules entries
(similar to running a file from inside a package directly).

Doing "python -m package.__init__" instead of "python -m package" is
actually better behaved (although still a little odd - the
__init__ module code gets run once on the actual package import, and
then again as __main__).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3441>
_______________________________________

From report at bugs.python.org  Sat Jul 26 10:46:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 08:46:18 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217061978.31.0.856819336511.issue3449@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like the changes needed here are even more minor than I thought.

The decimal module already does the right thing with respect to
the new specification and the new tests.  So all that needs doing is
to replace the old tests with the new ones.  No changes to decimal.py
or test_decimal.py are necessary.

Here's a patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 10:47:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 08:47:29 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217062049.68.0.178726681559.issue3449@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file10987/issue3449.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sat Jul 26 12:03:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 10:03:10 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217066590.91.0.392238513019.issue3421@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sadly, this is not the only problem with math.sum on x86 hardware right 
now.  I'd guess that this is another problem related to double-rounding 
and the use of 80-bit floating-point registers on x86.  Raymond and I 
are still actively looking for ways to fix math.sum up, including the 
possibility of a complete rewrite using a totally different algorithm.

With the current algorithm, behaviour at or near the boundary of the 
floating-point range should really be considered undefined;  so the 
quick fix is to update the tests and docs to reflect this.  The 
particular test that causes test.math to fail would just be removed.

I am intrigued that py3k and the trunk give different results, though;  
I'd very much like to know where the difference comes from.

Georg, *only if you have time*, could you please tell me what results 
the linux box gives for the following two Python sums, in both py3k and 
the trunk:

>>> 1e16 + 2.9999
10000000000000002.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
1.7976931348623157e+308

(The results shown are the ones I get on OS X 10.5.4;  I don't have 
access to a linux box for testing at the moment.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sat Jul 26 12:14:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 10:14:23 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217067263.19.0.605752487713.issue3421@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 2819 for ongoing discussion, and issue 2937, which is the 
likely root cause of the current difficulties with math.sum.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sat Jul 26 12:38:41 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 10:38:41 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217068721.62.0.551524870004.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch giving an alternative implementation of math.fsum; it's 
based on Tim Peter's suggestions, works mostly with integer arithmetic, 
and so bypasses problems with double rounding and extended precision 
floats.

The patch is experimental:  it doesn't have sufficient tests, has no 
documentation, and it adds math.fsum alongside the current math.sum, to 
make it easy to compare the two implementations.

On my MacBook, math.fsum is a factor of 2-3 times slower than math.sum.
It's also longer and distinctly less elegant.  So its only real 
advantage is that it should fix the difficulties on x86 hardware.

We *really* need to sort math.sum out, one way or another, before the 
next beta.  Georg recently discovered another problem on x86/Linux:  see 
issue 3421.

Some options:

 (1) leave math.sum as it is, skip all tests on x86/Linux, and document
     the current behaviour.

 (2) investigate a version of math.sum that plays with the FPU control 
word to force 53-bit rounding (and round-half-even)

 (3) replace math.sum with the slower but (presumably) less erratic 
math.fsum, possibly just as a temporary measure.  This would at least 
get all tests passing.

Jean, Raymond:  what do you think?

Added file: http://bugs.python.org/file10988/fsum7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Sat Jul 26 13:18:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Jul 2008 11:18:37 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217071117.79.0.631193258008.issue3421@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Both trunk and 3k give this:

>>> 1e16 + 2.9999
10000000000000004.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
inf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sat Jul 26 13:40:21 2008
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 26 Jul 2008 11:40:21 +0000
Subject: [issue3450] Buy stocks now to make money
In-Reply-To: <000601c8ef14$6216e0b0$fdfea37a@San>
Message-ID: <000601c8ef14$6216e0b0$fdfea37a@San>


New submission from Nobody/Anonymous:

Your wife says his bed skills are better than yours http://kwhgs.ca/topnews.html

----------
files: unnamed
messages: 70297
nosy: nobody
severity: normal
status: open
title: Buy stocks now to make money
Added file: http://bugs.python.org/file10989/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3450>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080726/8f9e9f76/attachment.txt>

From report at bugs.python.org  Sat Jul 26 13:48:49 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 26 Jul 2008 11:48:49 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1217072929.29.0.0712384459218.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Attached is a patch against 2.6 which adds the missing line (state = 2), a 
comment describing the three states the parser can be in and expands the 
test cases to cover this change (fail without it, pass with it).  In the 
process I snagged some broken example robots.txt files from Google's 
Googlebot help pages and turned them into test cases, both before and 
after fixing the examples.  I think this can probably go into the 
repository as a bug fix and get merged to the py3k branch.  If nobody 
complains in the next day or two I'll apply it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Sat Jul 26 13:53:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jul 2008 11:53:56 +0000
Subject: [issue3450] Buy stocks now to make money
In-Reply-To: <000601c8ef14$6216e0b0$fdfea37a@San>
Message-ID: <1217073236.29.0.475779078841.issue3450@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file10989/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3450>
_______________________________________

From report at bugs.python.org  Sat Jul 26 13:54:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jul 2008 11:54:00 +0000
Subject: [issue3450] Buy stocks now to make money
Message-ID: <1217073240.19.0.737859533087.issue3450@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3450>
_______________________________________

From report at bugs.python.org  Sat Jul 26 13:54:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jul 2008 11:54:15 +0000
Subject: [issue3450] Buy stocks now to make money
Message-ID: <1217073255.99.0.990513065696.issue3450@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3450>
_______________________________________

From report at bugs.python.org  Sat Jul 26 14:37:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Jul 2008 12:37:09 +0000
Subject: [issue3356] some tests fail with Py_DEBUG (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1217075829.32.0.899703595301.issue3356@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, ok. I was using `make EXTRA_CFLAGS="-DPy_DEBUG"`, but it wouldn't
undefine NDEBUG so the assert() macro wouldn't be enabled.
By using `make EXTRA_CFLAGS="-DPy_DEBUG -UNDEBUG"` instead it's fine.

But that makes test_c_api in setobject.c bogus, because it relies on the
execution of assert() statements to modify the refcount of certain
objects - which doesn't happen when assert() is optimized out. The only
reason it doesn't crash in non-debug mode is that the deallocated
objects are still intact in memory, and Py_REFCNT simply drops their
refcount field to -1 without bothering.

It also means the following statement in Misc/SpecialBuilds.txt is
misleading:

? Py_DEBUG implies LLTRACE, Py_REF_DEBUG, Py_TRACE_REFS, and
PYMALLOC_DEBUG (if WITH_PYMALLOC is enabled).  In addition, C
assert()s are enabled (via the C way: by not defining NDEBUG) ?

I haven't looked at the distutils problem yet.

----------
assignee:  -> georg.brandl
components: +Documentation -Tests
nosy: +georg.brandl
priority:  -> high
title: some tests fail in debug mode (test_distutils, test_set) -> some tests fail with Py_DEBUG (test_distutils, test_set)
type: crash -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Sat Jul 26 14:39:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Jul 2008 12:39:58 +0000
Subject: [issue3356] some tests fail with Py_DEBUG (test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1217075997.96.0.884314220107.issue3356@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Py_REFCNT simply drops their refcount field to -1 without bothering.

I meant Py_DECREF.

----------
components: +Tests
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Sat Jul 26 15:07:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Jul 2008 13:07:34 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1216977371.14.0.264260457721.issue3139@psf.upfronthosting.co.za>
Message-ID: <488B2192.3040605@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> (1) are you sure it is safe not to INCREF the obj pointer in the
> Py_buffer?

Yes, that's the semantics of the current buffer interface, and I cannot
see a flaw in it. When you call getbuffer, you certainly hold a
reference, and it is your obligation to hold onto this reference
somehow. So it is definitely safe (if properly documented).

> It would seem more logical for PyBuffer_FillInfo to
> INCREF the obj, and for PyBuffer_Release to DECREF it and set it to NULL.

Perhaps. I cannot quite see what undesirable consequences that might
have - feel free to develop and test an alternative patch that takes
that approach.

> (2) is it necessary to call directly bf_getbuffer & the like or is there
> a higher-level API to do it?

There is PyObject_GetBuffer and PyObject_ReleaseBuffer, but it is not
higher-level. I need to check the function pointers, anyway (to
determine whether the object supports getbuffer and requires
releasebuffer or not), so calling them directly is the right level
of abstraction (IMO).

> (3) didn't you forget to convert "PyArg_ParseTuple(args, "s#iO:sendto",
> [...])" in sock_sendto?

True.

> (4) is it really necessary to do a special case with PyString_Check()
> rather than rely on the string type's getbuffer method?

That's what the code always did (for s#). It would be possible to
eliminate that case, yes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Jul 26 15:52:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Jul 2008 13:52:40 +0000
Subject: [issue1446] Link to call me for free
In-Reply-To: <1195165602.64.0.122223209254.issue1446@psf.upfronthosting.co.za>
Message-ID: <1217080360.82.0.819395747217.issue1446@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446>
_______________________________________

From report at bugs.python.org  Sat Jul 26 16:14:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jul 2008 14:14:57 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217081697.36.0.49155108503.issue3421@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  Those are the results I'd expect on x86.  So here's the puzzle:

On lines 658-9 of Lib/test/test_math.py, in revision 65248 of the py3k 
branch, there's a pair of lines that looks like:

        if 1e16+2.999 != 1e16+2.9999:
            return

These lines are supposed to bail out of testSum on IEEE 754 hardware 
that doesn't do correct rounding.  So on your machine, I'd expect:

1e16+2.999  to evaluate to 10000000000000002.0
1e16+2.9999 to evaluate to 10000000000000004.0

so the condition in the if statement ought to be True, and the rest of 
the tests should be skipped.

It looks like this bailout is working as intended in the trunk, but not 
in Py3k.  Any ideas why there's a difference?  Is there some sort of 
constant folding going on in py3k but not in the trunk?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sat Jul 26 17:43:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Jul 2008 15:43:23 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217087003.74.0.258812078659.issue3421@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Strangely, it seems to work now with 3k too -- both in a debug and
release build. I've no idea what changed, but I'll close this for now.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sat Jul 26 17:59:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Jul 2008 15:59:43 +0000
Subject: [issue1064] Test issue
In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za>
Message-ID: <1217087983.05.0.605780325275.issue1064@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A new message for spambayes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
_______________________________________

From report at bugs.python.org  Sat Jul 26 22:59:59 2008
From: report at bugs.python.org (Andy)
Date: Sat, 26 Jul 2008 20:59:59 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1217105999.45.0.12839603524.issue3353@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

Did that and it builds fine.

So my test procedure was:

 - checkout clean source
 - apply patch as per guidelines
 - remove the file Psrser/tokenizer.h (*)
 - ./configure
 - make
 - ./python setup.py install

Build platform: Ubuntu , gcc 4.2.3

All works fine.

thanks for the extra test files.

* - one question though. I removed the file using 'svn remove' but the
diff makes it an empty file not removed why is that? (and is it correct?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3353>
_______________________________________

From report at bugs.python.org  Sat Jul 26 23:29:03 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jul 2008 21:29:03 +0000
Subject: [issue3421] Test failure in test_math::testSum
In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za>
Message-ID: <1217107743.33.0.559376867259.issue3421@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The tests at floating point boundaries should probably be removed and 
their behavior should be left undefined.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3421>
_______________________________________

From report at bugs.python.org  Sun Jul 27 02:49:49 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 27 Jul 2008 00:49:49 +0000
Subject: [issue3437] robotparser.py missing one line
In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za>
Message-ID: <1217119789.65.0.876467996528.issue3437@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

committed as r 65255.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3437>
_______________________________________

From report at bugs.python.org  Sun Jul 27 02:53:23 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 27 Jul 2008 00:53:23 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217120003.72.0.672129617946.issue3449@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

The patch looks great, feel free to apply it and commit.

For the record: the name issue that Mark talked about is not in this
last change, it was before, and we handled it the way we now decide
(hey, at least we're coherent with ourselves, ;) ).

Thank you Mark!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sun Jul 27 03:11:05 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Sun, 27 Jul 2008 01:11:05 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>


New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:

A few weeks ago, I blogged about taking advantage of Karatsuba
multiplication and Newton's method to divide big integers quickly (some
of you may have read it, as it was posted to Daily Python-URL among
other places):

http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html

To summarize, this method blows the builtin division out of the water 
already at ~(2000 digits)/(1000 digits).

The primary catch is that the result of the Newton division may be
slightly wrong (typically 1 ulp). However, a single extra multiplication
and a subtraction at the end allows one to compute a remainder, and
since the remainder must satisfy 0 <= r < q, the error is easily
corrected. From a quick test, the cost of the extra multiplication seems
to move the break-even point with the builtin division up to around
5000/2500 digits.

A pure Python implementation of divmod, with error correction based on
the remainder, can be found in this file:

http://www.dd.chalmers.se/~frejohl/code/libarith/libarith.py

(See the function idivmod)

Of particular note is that fast divmod gives a fast way to do radix
conversion, by recursively splitting the number in half. The function
numeral (see same .py file) does this, e.g:

>>> from time import clock
>>> a = 2**1257787-1
>>> t1=clock(); s1=str(a); t2=clock(); t2-t1
109.08065159119386
>>> t1=clock(); s2=numeral(a); t2=clock(); t2-t1
7.1394886780303182
>>> s1 == s2
True

(This recursive algorithm, by the way, is actually faster than str()
even with the slow builtin divmod.)

Would there be any interest in porting these algorithms to C and using
them in the standard Python long implementation?

There are likely some problems that I have overlooked. A critical review
will be most welcome.

----------
components: Interpreter Core
messages: 70309
nosy: fredrikj
severity: normal
status: open
title: Asymptotically faster divmod and str(long)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 03:13:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 27 Jul 2008 01:13:09 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217121189.99.0.309156910206.issue3451@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 05:23:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 27 Jul 2008 03:23:45 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217129025.38.0.66833746732.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I should also point out that I've generally used this technique to 
populate the fieldnames attribute from the file:

    f = open("somefile.csv", "rb")
    rdr = csv.DictReader(f, fieldnames=csv.reader(f).next())

So it is fairly trivial to set the fieldnames attribute before actually
reading any data rows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Sun Jul 27 06:15:48 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jul 2008 04:15:48 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217132148.42.0.233271510487.issue3436@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Like Raymond, I have issues with the idea of implicitly reading the
headers in __init__, but would be fine with the idea of a separate
method in 2.7/3.1.

As far as working around the absence of such a method goes, I personally
use itertools.chain if I happen to need the headers before I start
iterating:

r = csv.DictReader(open('test.csv'))
first = next(r)
# Do something with r.fieldnames
for row in chain(first, r):
    # Do something with each row

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Sun Jul 27 08:29:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jul 2008 06:29:54 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1217140194.36.0.25702853053.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd also be interested in having _PyLong_NumBits exposed to Python in some 
way or another.  It's something I've needed many times before, and it's 
used in the decimal module, for example.

My favorite workaround uses hex instead of bin:

4*len('%x'%x) - correction_dictionary[first_hexdigit_of_x]

but this is still O(log x) rather than O(1).

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Sun Jul 27 08:34:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jul 2008 06:34:29 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217140469.09.0.526536943031.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Would there be any interest in porting these algorithms to C and using
> them in the standard Python long implementation?

Yes, definitely!  Though it depends a little bit how much complication 
is involved.

A subquadratic algorithm for converting strings to longs might also fit 
well here.

Now I'm just waiting for you to propose an implementation of integer 
square root  :-).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 08:40:19 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jul 2008 06:40:19 +0000
Subject: [issue3449] Update decimal module to version 1.68 of the IBM
	specification
In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za>
Message-ID: <1217140819.86.0.56459948981.issue3449@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed, r65257.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3449>
_______________________________________

From report at bugs.python.org  Sun Jul 27 09:04:35 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 27 Jul 2008 07:04:35 +0000
Subject: [issue3443] crash on badly initialised AttributeError
In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
Message-ID: <1217142275.69.0.66685803625.issue3443@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Thanks a lot for the analysis. I was considering that this was a problem
with Cython, but since this was the first time I got a crash on this
(even Py3.0b1 didn't expose this), I wanted to ask here first.

Your explanation sounds like the right thing to do would be to clear the
exception state when a function exists cleanly but an exception was
raised and caught during its execution. So the exception state would
only stay available within the function itself. We could also try to
emulate the Py3 behaviour as outlined in PEP 3110. But we'll have to
discuss that on the Cython mailing list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3443>
_______________________________________

From report at bugs.python.org  Sun Jul 27 09:07:40 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Sun, 27 Jul 2008 07:07:40 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217142460.01.0.34073634951.issue3451@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

> Yes, definitely!  Though it depends a little bit how much complication
is involved.

Not that much, I think, the pure Python version being just a few lines
of code (plus a few more lines of boilerplate). But I'm not too familiar
with converting Python to C myself, so I may underestimate the
difficulties. It might get a little more complicated if you want to
minimize temporary allocations, for example.

> Now I'm just waiting for you to propose an implementation of integer
square root  :-).

Yes, there is also code for fast (O(M(n)) integer square roots in
libarith.py. This function would be much less useful overall as a
builtin, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 09:19:31 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jul 2008 07:19:31 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217143171.67.0.464138874526.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tests related to overflow, special-values, intermediate overflow, and
results at or near the boundary of the floating-point range have been
removed in r65258.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Sun Jul 27 09:47:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jul 2008 07:47:32 +0000
Subject: [issue3445] functools.update_wrapper bug
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217144852.01.0.746440066951.issue3445@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sun Jul 27 09:56:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Jul 2008 07:56:31 +0000
Subject: [issue3443] crash on badly initialised AttributeError
In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za>
Message-ID: <1217145391.88.0.259247432075.issue3443@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> So the exception state would only stay available 
> within the function itself.
AFAIK That's what python does for caught exceptions.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3443>
_______________________________________

From report at bugs.python.org  Sun Jul 27 10:38:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Jul 2008 08:38:04 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217147884.43.0.470053411689.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With the patch the following script crashes the 2.6 interpreter on Windows:

import sys, io, threading
stdout2 = io.open(sys.stdout.fileno(), mode="w")
def f(i):
    for i in range(10):
        stdout2.write(unicode((x, i)) + '\n')
for x in range(10):
    t = threading.Thread(target=f, args=(x,))
    t.start()

(with py3k, replace "stdout2.write" with a simple "print")

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Jul 27 15:05:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Jul 2008 13:05:12 +0000
Subject: [issue3445] functools.update_wrapper bug
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217163912.72.0.915789919487.issue3445@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think what you want is

functools.update_wrapper(myWrapper, str.split, ('__name__', '__doc__'))

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sun Jul 27 16:39:39 2008
From: report at bugs.python.org (lregebro)
Date: Sun, 27 Jul 2008 14:39:39 +0000
Subject: [issue3452] subprocess.Popen description unclear.
In-Reply-To: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>
Message-ID: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>


New submission from lregebro <regebro at gmail.com>:

In the documentation of subprocess.Popen the docs say:

"args should be a string, or a sequence of program arguments. The
program to execute is normally the first item in the args sequence or
string, but can be explicitly set by using the executable argument. "

The statement that the program to exectute is the "first item in the
args sequence or string" indicates that the first item in a string like
"ls -l", i.e. the "ls" will be the program. The next paragraph however
makes it clear that this is not the case, but by then the damage is
done, and you think that passing in "ls -l" will work.

Rewording this, perhaps by saying "The program to execute is normally
the first item in the args sequence, or the string if a string a given",
would make this clear.

----------
assignee: georg.brandl
components: Documentation
messages: 70321
nosy: georg.brandl, lregebro
severity: normal
status: open
title: subprocess.Popen description unclear.
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3452>
_______________________________________

From report at bugs.python.org  Sun Jul 27 17:14:05 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 27 Jul 2008 15:14:05 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

If a type's tp_base has not been initialized yet, PyType_Ready calls 
itself for tp_base.  However, it doesn't do the same for members of 
tp_bases.  The inheritance determinations assume that all bases are 
ready, in particular that tp_mro is not null.

----------
components: Interpreter Core
messages: 70322
nosy: rupole
severity: normal
status: open
title: PyType_Ready doesn't ensure that all bases are ready
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Sun Jul 27 17:22:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Jul 2008 15:22:37 +0000
Subject: [issue3452] subprocess.Popen description unclear.
In-Reply-To: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>
Message-ID: <1217172157.26.0.426440530882.issue3452@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the report. Fixed in r65259.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3452>
_______________________________________

From report at bugs.python.org  Sun Jul 27 17:22:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Jul 2008 15:22:47 +0000
Subject: [issue3452] subprocess.Popen description unclear.
In-Reply-To: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za>
Message-ID: <1217172167.22.0.0619415198415.issue3452@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3452>
_______________________________________

From report at bugs.python.org  Sun Jul 27 17:24:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Jul 2008 15:24:50 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217172290.03.0.178504025679.issue3453@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I believe that's because the bases are supposed to be ready at the time
a subclass is created.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Sun Jul 27 18:04:55 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Sun, 27 Jul 2008 16:04:55 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217174695.83.0.942691912705.issue3451@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

For your convenience, I have split the division and numeral code off to
a standalone .py file which I'm attaching here.

I also updated the remainder logic to use the default divmod instead of
repeated subtraction, which ensures worst-case performance similar to
the builtin divmod in the very unlikely case that div_newton would
return junk.

Added file: http://bugs.python.org/file10990/div.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 18:17:47 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Sun, 27 Jul 2008 16:17:47 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217175467.98.0.404517126151.issue3451@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

And here some timings on my laptop.

Both int->str and balanced division become faster somewhere between 1000
and 2000 digits. This is after editing the division benchmark to use
random numbers instead of exact powers of ten (interestingly causing a
bit of slowdown). String conversion might be a little slower for lengths
that aren't close to powers of two.

Added file: http://bugs.python.org/file10991/div_timings.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Sun Jul 27 19:54:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 27 Jul 2008 17:54:37 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1217181277.27.0.0572027678775.issue2771@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Testing authorage

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Jul 27 20:12:08 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jul 2008 18:12:08 +0000
Subject: [issue3445] functools.update_wrapper bug
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217182328.89.0.102404821949.issue3445@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The problem actually has to do with trying to use update_wrapper on a
method instead of a function - bound and unbound methods don't have all
the same attributes that actual functions do.

>>> import functools
>>> functools.WRAPPER_ASSIGNMENTS
('__module__', '__name__', '__doc__')
>>> functools.WRAPPER_UPDATES
('__dict__',)
>>> def f(): pass
...
>>> class C:
...   def m(): pass
...
>>> set(dir(f)) - set(dir(C.m))
set(['func_closure', 'func_dict', '__module__', 'func_name',
'func_defaults', '__dict__', '__name__', 'func_code', 'func_doc',
'func_globals'])

Is an exception the right response when encountering a missing
attribute? Given that the error can be explicitly silenced by writing
"functools.update_wrapper(g, str.split,
set(functools.WRAPPER_ASSIGNMENTS) & set(dir(str.split)))", I'm inclined
to think the current behaviour is the correct option.

Since this is an issue that doesn't come up with the main intended use
case for update_wrapper (writing decorators), and since it can be
handled easily by limiting the set of attributes copied to those the
object actually has, I'm converting this tracker item to an enhancement
request asking for a shorter way of spelling "ignore missing attributes"
(e.g. a keyword-only flag).

----------
assignee: ncoghlan -> 
priority:  -> normal
type: behavior -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sun Jul 27 20:13:32 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jul 2008 18:13:32 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217182412.71.0.275336949127.issue3445@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: functools.update_wrapper bug -> Ignore missing attributes in functools.update_wrapper

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sun Jul 27 21:58:01 2008
From: report at bugs.python.org (John Firestone)
Date: Sun, 27 Jul 2008 19:58:01 +0000
Subject: [issue3454] __getitem__() doesn't capture all slices if class
	inherits from list, tuple or str
Message-ID: <1217188681.81.0.529319728995.issue3454@psf.upfronthosting.co.za>


Changes by John Firestone <johnf at freenet.de>:


----------
components: Interpreter Core
files: getitem_problem.py
nosy: johnf
severity: normal
status: open
title: __getitem__() doesn't capture all slices if class inherits from list, tuple or str
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10992/getitem_problem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3454>
_______________________________________

From report at bugs.python.org  Sun Jul 27 23:17:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Jul 2008 21:17:58 +0000
Subject: [issue3454] __getitem__() doesn't capture all slices if class
	inherits from list, tuple or str
In-Reply-To: <1217193478.72.0.669277922436.issue3454@psf.upfronthosting.co.za>
Message-ID: <1217193478.72.0.669277922436.issue3454@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When executing self[i:j], the __getslice__(self,i,j) method is called
first, if it exists. See
http://docs.python.org/ref/sequence-methods.html

Yes, the __(get|set|del)slice__ methods are deprecated since 2.0, but
for compatibility the built-in types must keep defining them. You may
want to override them as well if your class inherit from such a type.

With python 3.0 the __getslice__ slots were removed, and __getitem__ is
called in all cases.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3454>
_______________________________________

From report at bugs.python.org  Mon Jul 28 01:07:18 2008
From: report at bugs.python.org (Collin Winter)
Date: Sun, 27 Jul 2008 23:07:18 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217200038.96.0.371577192939.issue3358@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

One option would be to use the faster recursive version, falling back to
the iterative version if you hit a "RuntimeError: maximum recursion
depth exceeded" error. This would keep the speed for most files, but
would allow 2to3 to parse files like the one in issue 2532.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Mon Jul 28 02:05:33 2008
From: report at bugs.python.org (Antoine d'Otreppe)
Date: Mon, 28 Jul 2008 00:05:33 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217203533.92.0.0291369054114.issue3445@psf.upfronthosting.co.za>


Antoine d'Otreppe <a.dotreppe at gmail.com> added the comment:

Thank you for considering this report :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Mon Jul 28 02:13:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 00:13:04 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1217200038.96.0.371577192939.issue3358@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807271713p29654b3fy2ae971cf3b2a8b38@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Sun, Jul 27, 2008 at 6:07 PM, Collin Winter <report at bugs.python.org> wrote:
>
> Collin Winter <collinw at gmail.com> added the comment:
>
> One option would be to use the faster recursive version, falling back to
> the iterative version if you hit a "RuntimeError: maximum recursion
> depth exceeded" error. This would keep the speed for most files, but
> would allow 2to3 to parse files like the one in issue 2532.

Sounds fine to me. I think we should provide a command line switch, too

>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3358>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Mon Jul 28 02:15:57 2008
From: report at bugs.python.org (Collin Winter)
Date: Mon, 28 Jul 2008 00:15:57 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217204157.08.0.214482832374.issue3358@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Why include a command-line flag? Would you know when to use it? In what
cases would you want to second-guess the app like that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Mon Jul 28 02:40:09 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 00:40:09 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>


New submission from ??? <zkfarmer at gmail.com>:

in Python 2.5 document, os.remove() explain: On Windows, attempting to
remove a file that is in use causes an exception to be raised. but, i
run it in IDLE.it deletes my file that in use without any exception.

----------
assignee: georg.brandl
components: Documentation
messages: 70334
nosy: georg.brandl, zkfarmer
severity: normal
status: open
title: os.remove()method document error
type: performance
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 02:41:46 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 00:41:46 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217205706.19.0.680587909331.issue3455@psf.upfronthosting.co.za>


Changes by ??? <zkfarmer at gmail.com>:


----------
type: performance -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 03:35:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 01:35:48 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217208948.96.0.706626932531.issue3455@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What do you mean by "in use"?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 03:50:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 01:50:51 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217209851.89.0.225518542945.issue3358@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Never mind. I had thought it would take a while for the RuntimeError to
be generated, but it only took about 7 seconds; I have no need for a
command line switch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Mon Jul 28 07:26:54 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 28 Jul 2008 05:26:54 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1217222814.78.0.516088199969.issue2620@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Committed revision 65261 for 2.5
Committed revision 65262 for 2.4.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Mon Jul 28 09:46:48 2008
From: report at bugs.python.org (Xue Can)
Date: Mon, 28 Jul 2008 07:46:48 +0000
Subject: [issue3456] compile python using MinGW
In-Reply-To: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>
Message-ID: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>


New submission from Xue Can <xuecan at gmail.com>:

I hope the official source release can add support for MinGW
to compile python under Win32 platform. And layout built files
like python in Unix-like paltforms.

----------
components: Build
messages: 70338
nosy: xuecan
severity: normal
status: open
title: compile python using MinGW
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3456>
_______________________________________

From report at bugs.python.org  Mon Jul 28 11:55:37 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 09:55:37 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217208948.96.0.706626932531.issue3455@psf.upfronthosting.co.za>
Message-ID: <83794ac50807280255xd332d9bgca4b284b34e726f7@mail.gmail.com>


??? <zkfarmer at gmail.com> added the comment:

yes, i use this method,but actually the result don't agree with the Python's
manual. my OS is windows xp and version is simplified chinese!

2008/7/28 Benjamin Peterson <report at bugs.python.org>

>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> What do you mean by "in use"?
>
> ----------
> nosy: +benjamin.peterson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3455>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080728/0dc9c676/attachment.txt>

From report at bugs.python.org  Mon Jul 28 12:02:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Jul 2008 10:02:55 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217239375.78.0.306043758798.issue3455@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There seems to be some misunderstanding.

zkfarmer, you said: "it deletes my file that in use without any exception."
Can you explain this sentence? How is your file "in use"?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 12:59:33 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 28 Jul 2008 10:59:33 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217242773.93.0.840708260571.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The consensus seems to be that __init__ shouldn't "magically" read the
header row, even though by not specifying a fieldnames arg that's
exactly what you're telling the DictReader where to find the column
headers.  Given that case, my argument is that we not make any changes
(no getheaders method, etc) since there are at least a couple different
ways mentioned already to do what you want.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Mon Jul 28 13:03:09 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Mon, 28 Jul 2008 11:03:09 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217242989.44.0.273984227256.issue3436@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

I'm ok with that. :)
Looks like you can close this one as "won't fix".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Mon Jul 28 13:17:41 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 28 Jul 2008 11:17:41 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217243861.77.0.89086774551.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Done...

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Mon Jul 28 14:15:13 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 28 Jul 2008 12:15:13 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217247313.38.0.584279691246.issue3455@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

zkfarmer, please try the following from your IDLE:

>>> myfilename = r"c:\tmp\test.txt"
>>> fh = open(myfilename, "w")
>>> fh.write("test\n")
>>> fh.close()
>>> fh = open(myfilename)
>>> import os
>>> os.remove(myfilename)

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    os.remove(myfilename)
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process: 'c:\\tmp\\test.txt'
>>> 

...and copy here what happened.

Thanks!

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 14:49:40 2008
From: report at bugs.python.org (Cliff Dyer)
Date: Mon, 28 Jul 2008 12:49:40 +0000
Subject: [issue3457] Release notes for 2.6b2 call it an alpha release
In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
Message-ID: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>


New submission from Cliff Dyer <jcd at sdf.lonestar.org>:

The release notes for python 2.6b2 at
http://www.python.org/download/releases/2.6/ identify the release as an
alpha release.  I'm not sure, but the disclaimer regarding who should
use it might need changing too.

alpha != beta

----------
assignee: georg.brandl
components: Documentation
messages: 70345
nosy: georg.brandl, jcd
severity: normal
status: open
title: Release notes for 2.6b2 call it an alpha release
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3457>
_______________________________________

From report at bugs.python.org  Mon Jul 28 14:51:59 2008
From: report at bugs.python.org (Cliff Dyer)
Date: Mon, 28 Jul 2008 12:51:59 +0000
Subject: [issue3457] Release notes for 2.6b2 call it an alpha release
In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
Message-ID: <1217249519.44.0.352903775132.issue3457@psf.upfronthosting.co.za>


Cliff Dyer <jcd at sdf.lonestar.org> added the comment:

The same issue applies to 3.0b2.  The release is identified as alpha. 
Also, there's a bit about who the alphas are aimed at (developers), but
nothing about the role of the betas.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3457>
_______________________________________

From report at bugs.python.org  Mon Jul 28 15:03:35 2008
From: report at bugs.python.org (reiko)
Date: Mon, 28 Jul 2008 13:03:35 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1217250215.83.0.395397705376.issue2475@psf.upfronthosting.co.za>


reiko <j.k.langridge at gmail.com> added the comment:

I have also run into this problem.  If you only use p.poll() and never
p.wait(), returncode will always remain None.

roudkerk's workaround doesn't seem to work with the new Popen objects,
at least in python 2.4.  ("unexpected keyword argument '_deadstate'") 
Does anyone have a workaround for subprocess.Popen?  Do I have to switch
to the deprecated popen function(s)?

----------
nosy: +reiko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2475>
_______________________________________

From report at bugs.python.org  Mon Jul 28 15:35:37 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 13:35:37 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217247313.38.0.584279691246.issue3455@psf.upfronthosting.co.za>
Message-ID: <83794ac50807280635i6aa6e070vf0727b337911ec35@mail.gmail.com>


??? <zkfarmer at gmail.com> added the comment:

Thank you for your reply.I mean I used gvim to open a file. the Python
manual did not specify how to use a file, but said that if a file is to be
used, the deletion of the file will be exception to be raise.so when I use
gvim to open a file, then run os.remove () method to remove the file, the
file is deleted, and no exception to be raise.

2008/7/28 Facundo Batista <report at bugs.python.org>

>
> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
>
> zkfarmer, please try the following from your IDLE:
>
> >>> myfilename = r"c:\tmp\test.txt"
> >>> fh = open(myfilename, "w")
> >>> fh.write("test\n")
> >>> fh.close()
> >>> fh = open(myfilename)
> >>> import os
> >>> os.remove(myfilename)
>
> Traceback (most recent call last):
>  File "<pyshell#6>", line 1, in <module>
>    os.remove(myfilename)
> WindowsError: [Error 32] The process cannot access the file because it
> is being used by another process: 'c:\\tmp\\test.txt'
> >>>
>
> ...and copy here what happened.
>
> Thanks!
>
> ----------
> nosy: +facundobatista
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3455>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080728/e121a43c/attachment-0001.txt>

From report at bugs.python.org  Mon Jul 28 15:52:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 13:52:57 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217253177.73.0.353986823363.issue3455@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Editors usually don't cause the file to be "in use." "In use" would 
mean that the file was being held open by a program. Editors only do 
that when they are opening or saving a file.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 15:53:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 13:53:56 +0000
Subject: [issue3457] Release notes for 2.6b2 call it an alpha release
In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
Message-ID: <1217253236.59.0.877301441597.issue3457@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: georg.brandl -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3457>
_______________________________________

From report at bugs.python.org  Mon Jul 28 16:07:11 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 28 Jul 2008 14:07:11 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217253177.73.0.353986823363.issue3455@psf.upfronthosting.co.za>
Message-ID: <83794ac50807280707i7ee17b17r69366a6afcba0ea9@mail.gmail.com>


??? <zkfarmer at gmail.com> added the comment:

Thanks, you are right, I am wrong, I think that is the use of editing, so I
made a mistake.

2008/7/28 Benjamin Peterson <report at bugs.python.org>

>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Editors usually don't cause the file to be "in use." "In use" would
> mean that the file was being held open by a program. Editors only do
> that when they are opening or saving a file.
>
> ----------
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3455>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080728/5fefadd1/attachment.txt>

From report at bugs.python.org  Mon Jul 28 17:05:52 2008
From: report at bugs.python.org (Oleksiy Golovko)
Date: Mon, 28 Jul 2008 15:05:52 +0000
Subject: [issue1540529] cgi.py error on parsing/handling content-disposition
Message-ID: <1217257552.35.0.512689597423.issue1540529@psf.upfronthosting.co.za>


Oleksiy Golovko <zindel at gamma.dn.ua> added the comment:

Here is the another patch for this issue.

----------
nosy: +zindel
title: cgi.py error on parsing/handling content-disposition  -> cgi.py error on parsing/handling content-disposition
Added file: http://bugs.python.org/file10996/cgtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540529>
_______________________________________

From report at bugs.python.org  Mon Jul 28 17:29:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 15:29:59 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1217258999.79.0.899982372207.issue3445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another possibility would be for methods to also get the __name__ and
__module__ attributes. I don't see any counter-indication to it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Mon Jul 28 18:24:27 2008
From: report at bugs.python.org (David Farrar)
Date: Mon, 28 Jul 2008 16:24:27 +0000
Subject: [issue3458] dict.update() optimisation gives unexpected/invalid
	results when passed a subclass of DictType
In-Reply-To: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>
Message-ID: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>


New submission from David Farrar <pythonbugs at spam.decafbad.co.uk>:

Using a python module that expected me to pass a dictionary as a
parameter to a function, I found that I was getting unexpected results
when using a class which inherits from types.DictType.

The module was passing the instance I had supplied as a parameter to
update() on a newly created dictionary. I wanted my class to present its
methods as items of the dictionary it was pretending to be. Even though
I could see that __getattribute__ had been called to get 'keys', keys()
was not called and I ended up with an empty dictionary.

Trying to find the cause of the problem, I downloaded the python source
package and found that in PyDict_Merge (in Objects/dictobject.c, line
1359), there is an optimisation that is run if PyDict_Check determines
that the parameter we passed is itself a dictionary. The optimisation
takes advantage of the fact that we know how data is stored in the
dictionary and accesses whatever it needs directly.

I had overridden keys() to provide the result I wanted but this
optimisation prevented the code from ever being run, leading to code
that seems like it should work failing with no apparent cause. The only
way I could find around this was to raise AttributeError in
__getattribute__ when getting 'keys', causing dict_update_common to call
PyDict_MergeFromSeq2 in place of PyDict_Merge.

Should the call to PyDict_Check in PyDict_Merge not be replaced with
PyDict_CheckExact ? This would keep the optimisation in place in most
cases, where we know that it is safe, still allowing keys() to be
overridden as you expect.

----------
components: Interpreter Core
files: dictionary.patch
keywords: patch
messages: 70353
nosy: david
severity: normal
status: open
title: dict.update() optimisation gives unexpected/invalid results when passed a subclass of DictType
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10997/dictionary.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3458>
_______________________________________

From report at bugs.python.org  Mon Jul 28 18:39:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 16:39:31 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1217263171.82.0.496263450938.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Final patch adding the (?a) inline flag (equivalent to re.ASCII). Please
review:
http://codereview.appspot.com/2439

Added file: http://bugs.python.org/file10998/reunicode5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Mon Jul 28 18:59:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 16:59:03 +0000
Subject: [issue2491] io.open() handles errors differently on different
	platforms
In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
Message-ID: <1217264343.84.0.551092428876.issue2491@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What's the status of this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2491>
_______________________________________

From report at bugs.python.org  Mon Jul 28 18:59:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 16:59:36 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1217264376.75.0.821970687547.issue2777@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What's the status of this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2777>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:00:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:00:11 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1217264411.37.0.908691563524.issue2538@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

How's this coming?

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2538>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:02:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:02:03 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1217264523.57.0.257835607002.issue2534@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can this patch go in?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:02:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:02:50 +0000
Subject: [issue1967] Backport dictviews to 2.6
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1217264570.86.0.99259772663.issue1967@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm going to defer this to 2.7.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:03:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:03:20 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1217264600.59.0.3252237458.issue1745@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This will probably have to be deferred to 2.7.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:04:20 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Mon, 28 Jul 2008 17:04:20 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1217264660.12.0.780048947724.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

i wrote pure Python equivalent of the patch and will
post it to the ASPN cookbook as suggested. i'm wondering
if i have to upload the code here too, or just the link
will suffice?

Raymond Hettinger:
> Can you also implement blending of approximations:
> (1-t)*f1(x) + t*f2(x)

i do this with the Python code for now, and my question is:
how to choose the values for the borders?

with erf, for example, one has typically 5 domains
of approximation and one can write something like:

    def erf(x):
        f = float(x)
        if (f == inf):
            return 1.0
        elif (f == -inf):
            return -1.0
        elif (f == nan):
            return nan
        else:
            if (abs(x)<0.84375):
                return erf1(x)
            elif (0.84375<=abs(x)<1.25):
                return erf2(x)
            elif (1.25<=abs(x)<2.857142):
                return erf3(x)
            elif (2.857142<=abs(x)<6):
                return erf4(x)
            elif (abs(x)>=6):
                return erf5(x)

implementing the blending of approximations,
one may write:

    def blend(x, a, b, f1, f2):
        if x < a:
            return f1(x)
        if x > b:
            return f2(x)
        return (((b-x)*f1(x))-((a-x)*f2(x)))/(b-a)

and the definition becomes:

    def erf(x):
	f=float(x)
	if (abs(x)<0.83):
		return erf1(x)
	elif (0.83<=abs(x)<0.85):
		return blend(x,0.83,0.85,erf1,erf2)
	elif (0.85<=abs(x)<1.24):
		return erf2(x)
	elif (1.24<=abs(x)<1.26):
		return blend(x,1.24,1.26,erf2,erf3)
	elif (1.26<=abs(x)<2.84):
		return erf3(x)
	elif (2.84<=abs(x)<2.86):
		return blend(x,2.84,2.86,erf3,erf4)
	elif (2.86<=abs(x)<5.99):
		return erf4(x)
	elif (5.99<=abs(x)<6.01):
		return blend(x,5.99,6.01,erf4,erf5)
	elif (abs(x)>=6.01):
		return erf5(x)

but the choice of these values is somewhat arbitrary.
or i completely misunderstood what you mean by "blending of approximations"!

for erf functions, blending of approximations, as i understand it,
may be implemented easily as the functions are monotonics.
for gammas, this will be a bit complicated, especially for
negative values, where there are extremums for half integers and
discontinuities for integers.
in the other hand, i'm wondering if these coefficients had been chosen
with optimization of discontinuities already taken into account.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:04:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:04:30 +0000
Subject: [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1217264670.68.0.698515516483.issue2222@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

How's this coming along?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:05:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:05:42 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1217264742.49.0.868634581539.issue2542@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:06:18 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Jul 2008 17:06:18 +0000
Subject: [issue3458] dict.update() optimisation gives unexpected/invalid
	results when passed a subclass of DictType
In-Reply-To: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>
Message-ID: <1217264778.42.0.0727225631112.issue3458@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will look back in my notes.  I believe this was previously discussed 
and rejected.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3458>
_______________________________________

From report at bugs.python.org  Mon Jul 28 19:08:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jul 2008 17:08:17 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1217264897.83.0.0803038288864.issue1242657@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Raymond, can you comment?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Mon Jul 28 20:51:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 18:51:27 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When the separator is empty and the sequence only contains one non-empty
item, it is possible to optimize b"".join([...]) by simply returning the
non-empty item.

Since b"".join() is the recommended idiom to join large strings
together, I think it can be useful. I encountered this when trying to
optimize io.BufferedReader.

./python -m timeit -s "l=[b'', b'a' * 10000]" "b''.join(l)"

before the patch:
100000 loops, best of 3: 2.35 usec per loop
after the patch:
1000000 loops, best of 3: 0.335 usec per loop

----------
components: Interpreter Core
files: bytesjoin.patch
keywords: patch
messages: 70365
nosy: pitrou
severity: normal
status: open
title: optimize bytes.join()
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file10999/bytesjoin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Mon Jul 28 20:56:08 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Jul 2008 18:56:08 +0000
Subject: [issue1242657] list(obj) can swallow KeyboardInterrupt
Message-ID: <1217271368.23.0.502242793185.issue1242657@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg's suggestion seems reasonable.  Alternatively, you can just catch 
AttributeError or TypeError.

Lowering the priority to normal and marking as unresolved.  At some 
point, it would be nice to review the whole code base to see if other 
calls to PyErr_Clear() are too aggressive.  In that review, perhaps a 
more clean and general solution with present itself.

----------
assignee: rhettinger -> georg.brandl
priority: critical -> normal
resolution: fixed -> 
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242657>
_______________________________________

From report at bugs.python.org  Mon Jul 28 21:04:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 19:04:38 +0000
Subject: [issue3460] PyUnicode_Join could perhaps be simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In py3k, PyUnicode_Join inherits some complexity from the 2.x days.
However, it seems some of the precautions taken there may not be needed
anymore. Witness the following comment:

    /* Grrrr.  A codec may be invoked to convert str objects to
     * Unicode, and so it's possible to call back into Python code
     * during PyUnicode_FromObject(), and so it's possible for a sick
     * codec to change the size of fseq (if seq is a list).  Therefore
     * we have to keep refetching the size -- can't assume seqlen
     * is invariant.
     */

Perhaps it would also allow to preallocate the target buffer all at once
(like bytes.join does) rather than resize it incrementally.
Marc-Andre, what do you think?

----------
components: Unicode
messages: 70367
nosy: lemburg, pitrou
priority: normal
severity: normal
status: open
title: PyUnicode_Join could perhaps be simpler
type: performance
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________

From report at bugs.python.org  Mon Jul 28 21:42:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Jul 2008 19:42:55 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217274175.27.0.163167367727.issue3455@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can a file be "in use" other than being opened? If not, wouldn't be
"opened" be a better wording?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Jul 28 21:49:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 19:49:19 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1217274559.28.0.872066234299.issue2523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Following our discussion and Guido's answer on python-3000 (*), I
committed a modified fix in r65264.

(*) http://mail.python.org/pipermail/python-3000/2008-July/014466.html

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2523>
_______________________________________

From report at bugs.python.org  Mon Jul 28 22:41:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Jul 2008 20:41:57 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1217277717.21.0.860514510098.issue2834@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are all those re.ASCII flags mandatory, or are they here just for
theoretical correctness?
For example, the output of "gcc -dumpversion" is certainly plain ASCII.
I don't mind that \d also matches some exotic digit - it just won't happen.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Mon Jul 28 22:49:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jul 2008 20:49:17 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1217277717.21.0.860514510098.issue2834@psf.upfronthosting.co.za>
Message-ID: <1217278150.12857.22.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 28 juillet 2008 ? 20:41 +0000, Amaury Forgeot d'Arc a ?crit :
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Are all those re.ASCII flags mandatory, or are they here just for
> theoretical correctness?

For theoretical correctness. I just don't want to analyze each case
individually and I'm probably not competent for many of them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Tue Jul 29 00:08:45 2008
From: report at bugs.python.org (Derek Morr)
Date: Mon, 28 Jul 2008 22:08:45 +0000
Subject: [issue3461] smtplib does not fully support IPv6 in EHLO
In-Reply-To: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za>
Message-ID: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za>


New submission from Derek Morr <derekmorr at psu.edu>:

On an IPv6-only machine, smtplib does not send an IPv6 address in the 
EHLO. It sends "EHLO [0.0.0.0]" instead. For example, on a v6-only 
network with stateless autoconfiguration enabled (a common 
configuration), smtplib will show this error.

Further, SMTP's __init__() method tries to determine the value of EHLO 
parameter before the socket is established. But it can't know what 
value to use before the socket is setup (e.g., should it use a 
hostname, a v4 address literal, or a v6 address literal).

The attached patch moves the self.local_hostname processing into the 
connect() method, and updates it to use IPv6-aware resolver interfaces.

----------
components: Library (Lib)
files: python_smtplib.patch
keywords: patch
messages: 70372
nosy: dmorr
severity: normal
status: open
title: smtplib does not fully support IPv6 in EHLO
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file11000/python_smtplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3461>
_______________________________________

From report at bugs.python.org  Tue Jul 29 02:17:51 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jul 2008 00:17:51 +0000
Subject: [issue3458] dict.update() optimisation gives unexpected/invalid
	results when passed a subclass of DictType
In-Reply-To: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za>
Message-ID: <1217290671.71.0.271370755425.issue3458@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is duplicate of http://bugs.python.org/issue1615701 .  The 
check_exact solution was attempted once but it broke code in a subtle 
and hard to find way so it had to be reverted.  For your use case, try 
UserDict instead of subclassing dict.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3458>
_______________________________________

From report at bugs.python.org  Tue Jul 29 04:06:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 02:06:35 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

In Py3k:

$ ./python Lib/test/regrtest.py test_decimal test_builtin
test_decimal
test_builtin
test test_builtin failed -- Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 603, in runtest_inner
    indirect_test()
  File "/temp/python/py3k/Lib/test/test_builtin.py", line 1252, in test_main
    run_unittest(*test_classes)
  File "/temp/python/py3k/Lib/test/support.py", line 717, in run_unittest
    _run_suite(suite)
  File "/temp/python/py3k/Lib/test/support.py", line 700, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_builtin.py", line 390, in
test_general_eval
    self.assertEqual(eval('globals()', g, m), g)
AssertionError: {'unittest': <module 'unittest' from
'/temp/python/py3k/Lib/unittest.py'>, 'random': <module 'random' from
'/temp/python/py3k/Lib/random.py'>, 'test_conv_no_sign': [('0', 0),
('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314),
(' 314', 314), ('314 ', 314), ('  \t\t  314  \t\t  ', 314),
('2147483647', 2147483647), ('  1x', <class 'ValueError'>), ('  1  ',
1), ('  1\x02  ', <class 'ValueError'>), ('', <class 'ValueError'>), ('
', <class 'ValueError'>), ('  \t\t  ', <class 'ValueError'>),
('\u0663\u0661\u0664 ', 314), ('\u0200', <class 'ValueError'>)],
'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99),
('100', 100), ('314', 314), (' 314', <class 'ValueError'>), ('314 ',
314), ('  \t\t  314  \t\t  ', <class 'ValueError'>), ('2147483647',
2147483647), ('  1x', <class 'ValueError'>), ('  1  ', <class
'ValueError'>), ('  1\x02  ', <class 'ValueError'>), ('', <class
'ValueError'>), (' ', <class 'ValueError'>), ('  \t\t  ', <class
'ValueError'>), ('\u0663\u0661\u0664 ', 314), ('\u0200', <class
'ValueError'>)], 'run_with_locale': <function run_with_locale at
0x10b0390>, 'io': <module 'io' from '/temp/python/py3k/Lib/io.py'>,
'Squares': <class 'test.test_builtin.Squares'>, 'neg': <built-in
function neg>, '__package__': None, 'collections': <module 'collections'
from '/temp/python/py3k/Lib/collections.py'>, 'TestFailingIter': <class
'test.test_builtin.TestFailingIter'>, 'run_unittest': <function
run_unittest at 0x10b0540>, '__doc__': None, 'test_main': <function
test_main at 0x1474390>, 'fractions': <module 'fractions' from
'/temp/python/py3k/Lib/fractions.py'>, 'StrSquares': <class
'test.test_builtin.StrSquares'>, 'warnings': <module 'warnings' from
'/temp/python/py3k/Lib/warnings.py'>, '__builtins__': {'bytearray':
<class 'bytearray'>, 'IndexError': <class 'IndexError'>, 'all':
<built-in function all>, 'help': Type help() for interactive help, or
help(object) for help about object., 'vars': <built-in function vars>,
'SyntaxError': <class 'SyntaxError'>, 'UnicodeDecodeError': <class
'UnicodeDecodeError'>, 'memoryview': <class 'memoryview'>, 'isinstance':
<built-in function isinstance>, '__build_class__': <built-in function
__build_class__>, 'copyright': Copyright (c) 2001-2008 Python Software
Foundation.
All Rights Reserved.

Copyright (c) 2000 BeOpen.com.
All Rights Reserved.

Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved., 'NameError': <class 'NameError'>, 'BytesWarning':
<class 'BytesWarning'>, 'dict': <class 'dict'>, 'IOError': <class
'IOError'>, 'oct': <built-in function oct>, 'bin': <built-in function
bin>, 'SystemExit': <class 'SystemExit'>, 'format': <built-in function
format>, 'repr': <built-in function repr>, 'sorted': <built-in function
sorted>, 'False': False, 'RuntimeWarning': <class 'RuntimeWarning'>,
'list': <class 'list'>, 'iter': <built-in function iter>, 'Warning':
<class 'Warning'>, '__package__': None, 'round': <built-in function
round>, 'dir': <built-in function dir>, 'cmp': <built-in function cmp>,
'set': <class 'set'>, 'bytes': <class 'bytes'>, 'UnicodeTranslateError':
<class 'UnicodeTranslateError'>, 'issubclass': <built-in function
issubclass>, 'EOFError': <class 'EOFError'>, 'locals': <built-in
function locals>, 'BufferError': <class 'BufferError'>, 'slice': <class
'slice'>, 'FloatingPointError': <class 'FloatingPointError'>, 'sum':
<built-in function sum>, 'getattr': <built-in function getattr>, 'abs':
<built-in function abs>, 'exit': Use exit() or Ctrl-D (i.e. EOF) to
exit, 'print': <built-in function print>, 'True': True, 'FutureWarning':
<class 'FutureWarning'>, 'ImportWarning': <class 'ImportWarning'>,
'None': None, 'hash': <built-in function hash>, 'ReferenceError': <class
'ReferenceError'>, 'len': <built-in function len>, 'credits':     Thanks
to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands
    for supporting Python development.  See www.python.org for more
information., 'frozenset': <class 'frozenset'>, '__name__': 'builtins',
'ord': <built-in function ord>, 'super': <class 'super'>, '_':
Decimal('NaN123'), 'TypeError': <class 'TypeError'>, 'license': Type
license() to see the full license text, 'KeyboardInterrupt': <class
'KeyboardInterrupt'>, 'UserWarning': <class 'UserWarning'>, 'filter':
<class 'filter'>, 'range': <class 'range'>, 'staticmethod': <class
'staticmethod'>, 'SystemError': <class 'SystemError'>, 'BaseException':
<class 'BaseException'>, 'pow': <built-in function pow>, 'RuntimeError':
<class 'RuntimeError'>, 'float': <class 'float'>, 'MemoryError': <class
'MemoryError'>, 'StopIteration': <class 'StopIteration'>, 'globals':
<built-in function globals>, 'divmod': <built-in function divmod>,
'enumerate': <class 'enumerate'>, 'Ellipsis': Ellipsis, 'LookupError':
<class 'LookupError'>, 'open': <class 'io.OpenWrapper'>, 'quit': Use
quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': <class
'UnicodeError'>, 'zip': <class 'zip'>, 'hex': <built-in function hex>,
'next': <built-in function next>, 'ImportError': <class 'ImportError'>,
'chr': <built-in function chr>, 'type': <class 'type'>, '__doc__':
"Built-in functions, exceptions, and other objects.\n\nNoteworthy: None
is the `nil' object; Ellipsis represents `...' in slices.", 'Exception':
<class 'Exception'>, 'tuple': <class 'tuple'>, 'reversed': <class
'reversed'>, 'UnicodeEncodeError': <class 'UnicodeEncodeError'>,
'input': <built-in function input>, 'hasattr': <built-in function
hasattr>, 'delattr': <built-in function delattr>, 'setattr': <built-in
function setattr>, 'SyntaxWarning': <class 'SyntaxWarning'>, 'compile':
<built-in function compile>, 'ArithmeticError': <class
'ArithmeticError'>, 'str': <class 'str'>, 'property': <class
'property'>, 'GeneratorExit': <class 'GeneratorExit'>, 'int': <class
'int'>, '__import__': <built-in function __import__>, 'KeyError': <class
'KeyError'>, 'PendingDeprecationWarning': <class
'PendingDeprecationWarning'>, 'EnvironmentError': <class
'EnvironmentError'>, 'ascii': <built-in function ascii>, 'id': <built-in
function id>, 'OSError': <class 'OSError'>, 'DeprecationWarning': <class
'DeprecationWarning'>, 'min': <built-in function min>, 'UnicodeWarning':
<class 'UnicodeWarning'>, 'any': <built-in function any>, 'complex':
<class 'complex'>, 'bool': <class 'bool'>, 'ValueError': <class
'ValueError'>, 'NotImplemented': NotImplemented, 'map': <class 'map'>,
'exec': <built-in function exec>, 'max': <built-in function max>,
'object': <class 'object'>, 'TabError': <class 'TabError'>,
'ZeroDivisionError': <class 'ZeroDivisionError'>, 'eval': <built-in
function eval>, '__debug__': True, 'IndentationError': <class
'IndentationError'>, 'AssertionError': <class 'AssertionError'>,
'classmethod': <class 'classmethod'>, 'UnboundLocalError': <class
'UnboundLocalError'>, 'NotImplementedError': <class
'NotImplementedError'>, 'AttributeError': <class 'AttributeError'>,
'OverflowError': <class 'OverflowError'>}, '__file__':
'/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': <class
'test.test_builtin.BuiltinTest'>, 'TestFailingBool': <class
'test.test_builtin.TestFailingBool'>, 'sys': <module 'sys' (built-in)>,
'test': <module 'test' from '/temp/python/py3k/Lib/test/__init__.py'>,
'__name__': 'test.test_builtin', 'unlink': <function unlink at
0x7a5540>, 'TESTFN': '@test', 'TestSorted': <class
'test.test_builtin.TestSorted'>, 'BitBucket': <class
'test.test_builtin.BitBucket'>, 'fcmp': <function fcmp at 0x7ad540>} !=
{'unittest': <module 'unittest' from
'/temp/python/py3k/Lib/unittest.py'>, 'random': <module 'random' from
'/temp/python/py3k/Lib/random.py'>, 'test_conv_no_sign': [('0', 0),
('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314),
(' 314', 314), ('314 ', 314), ('  \t\t  314  \t\t  ', 314),
('2147483647', 2147483647), ('  1x', <class 'ValueError'>), ('  1  ',
1), ('  1\x02  ', <class 'ValueError'>), ('', <class 'ValueError'>), ('
', <class 'ValueError'>), ('  \t\t  ', <class 'ValueError'>),
('\u0663\u0661\u0664 ', 314), ('\u0200', <class 'ValueError'>)],
'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99),
('100', 100), ('314', 314), (' 314', <class 'ValueError'>), ('314 ',
314), ('  \t\t  314  \t\t  ', <class 'ValueError'>), ('2147483647',
2147483647), ('  1x', <class 'ValueError'>), ('  1  ', <class
'ValueError'>), ('  1\x02  ', <class 'ValueError'>), ('', <class
'ValueError'>), (' ', <class 'ValueError'>), ('  \t\t  ', <class
'ValueError'>), ('\u0663\u0661\u0664 ', 314), ('\u0200', <class
'ValueError'>)], 'run_with_locale': <function run_with_locale at
0x10b0390>, 'io': <module 'io' from '/temp/python/py3k/Lib/io.py'>,
'Squares': <class 'test.test_builtin.Squares'>, 'neg': <built-in
function neg>, '__package__': None, 'collections': <module 'collections'
from '/temp/python/py3k/Lib/collections.py'>, 'TestFailingIter': <class
'test.test_builtin.TestFailingIter'>, 'run_unittest': <function
run_unittest at 0x10b0540>, '__doc__': None, 'test_main': <function
test_main at 0x1474390>, 'fractions': <module 'fractions' from
'/temp/python/py3k/Lib/fractions.py'>, 'StrSquares': <class
'test.test_builtin.StrSquares'>, 'warnings': <module 'warnings' from
'/temp/python/py3k/Lib/warnings.py'>, '__builtins__': {'bytearray':
<class 'bytearray'>, 'IndexError': <class 'IndexError'>, 'all':
<built-in function all>, 'help': Type help() for interactive help, or
help(object) for help about object., 'vars': <built-in function vars>,
'SyntaxError': <class 'SyntaxError'>, 'UnicodeDecodeError': <class
'UnicodeDecodeError'>, 'memoryview': <class 'memoryview'>, 'isinstance':
<built-in function isinstance>, '__build_class__': <built-in function
__build_class__>, 'copyright': Copyright (c) 2001-2008 Python Software
Foundation.
All Rights Reserved.

Copyright (c) 2000 BeOpen.com.
All Rights Reserved.

Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved., 'NameError': <class 'NameError'>, 'BytesWarning':
<class 'BytesWarning'>, 'dict': <class 'dict'>, 'IOError': <class
'IOError'>, 'oct': <built-in function oct>, 'bin': <built-in function
bin>, 'SystemExit': <class 'SystemExit'>, 'format': <built-in function
format>, 'repr': <built-in function repr>, 'sorted': <built-in function
sorted>, 'False': False, 'RuntimeWarning': <class 'RuntimeWarning'>,
'list': <class 'list'>, 'iter': <built-in function iter>, 'Warning':
<class 'Warning'>, '__package__': None, 'round': <built-in function
round>, 'dir': <built-in function dir>, 'cmp': <built-in function cmp>,
'set': <class 'set'>, 'bytes': <class 'bytes'>, 'UnicodeTranslateError':
<class 'UnicodeTranslateError'>, 'issubclass': <built-in function
issubclass>, 'EOFError': <class 'EOFError'>, 'locals': <built-in
function locals>, 'BufferError': <class 'BufferError'>, 'slice': <class
'slice'>, 'FloatingPointError': <class 'FloatingPointError'>, 'sum':
<built-in function sum>, 'getattr': <built-in function getattr>, 'abs':
<built-in function abs>, 'exit': Use exit() or Ctrl-D (i.e. EOF) to
exit, 'print': <built-in function print>, 'True': True, 'FutureWarning':
<class 'FutureWarning'>, 'ImportWarning': <class 'ImportWarning'>,
'None': None, 'hash': <built-in function hash>, 'ReferenceError': <class
'ReferenceError'>, 'len': <built-in function len>, 'credits':     Thanks
to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands
    for supporting Python development.  See www.python.org for more
information., 'frozenset': <class 'frozenset'>, '__name__': 'builtins',
'ord': <built-in function ord>, 'super': <class 'super'>, '_':
Decimal('NaN123'), 'TypeError': <class 'TypeError'>, 'license': Type
license() to see the full license text, 'KeyboardInterrupt': <class
'KeyboardInterrupt'>, 'UserWarning': <class 'UserWarning'>, 'filter':
<class 'filter'>, 'range': <class 'range'>, 'staticmethod': <class
'staticmethod'>, 'SystemError': <class 'SystemError'>, 'BaseException':
<class 'BaseException'>, 'pow': <built-in function pow>, 'RuntimeError':
<class 'RuntimeError'>, 'float': <class 'float'>, 'MemoryError': <class
'MemoryError'>, 'StopIteration': <class 'StopIteration'>, 'globals':
<built-in function globals>, 'divmod': <built-in function divmod>,
'enumerate': <class 'enumerate'>, 'Ellipsis': Ellipsis, 'LookupError':
<class 'LookupError'>, 'open': <class 'io.OpenWrapper'>, 'quit': Use
quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': <class
'UnicodeError'>, 'zip': <class 'zip'>, 'hex': <built-in function hex>,
'next': <built-in function next>, 'ImportError': <class 'ImportError'>,
'chr': <built-in function chr>, 'type': <class 'type'>, '__doc__':
"Built-in functions, exceptions, and other objects.\n\nNoteworthy: None
is the `nil' object; Ellipsis represents `...' in slices.", 'Exception':
<class 'Exception'>, 'tuple': <class 'tuple'>, 'reversed': <class
'reversed'>, 'UnicodeEncodeError': <class 'UnicodeEncodeError'>,
'input': <built-in function input>, 'hasattr': <built-in function
hasattr>, 'delattr': <built-in function delattr>, 'setattr': <built-in
function setattr>, 'SyntaxWarning': <class 'SyntaxWarning'>, 'compile':
<built-in function compile>, 'ArithmeticError': <class
'ArithmeticError'>, 'str': <class 'str'>, 'property': <class
'property'>, 'GeneratorExit': <class 'GeneratorExit'>, 'int': <class
'int'>, '__import__': <built-in function __import__>, 'KeyError': <class
'KeyError'>, 'PendingDeprecationWarning': <class
'PendingDeprecationWarning'>, 'EnvironmentError': <class
'EnvironmentError'>, 'ascii': <built-in function ascii>, 'id': <built-in
function id>, 'OSError': <class 'OSError'>, 'DeprecationWarning': <class
'DeprecationWarning'>, 'min': <built-in function min>, 'UnicodeWarning':
<class 'UnicodeWarning'>, 'any': <built-in function any>, 'complex':
<class 'complex'>, 'bool': <class 'bool'>, 'ValueError': <class
'ValueError'>, 'NotImplemented': NotImplemented, 'map': <class 'map'>,
'exec': <built-in function exec>, 'max': <built-in function max>,
'object': <class 'object'>, 'TabError': <class 'TabError'>,
'ZeroDivisionError': <class 'ZeroDivisionError'>, 'eval': <built-in
function eval>, '__debug__': True, 'IndentationError': <class
'IndentationError'>, 'AssertionError': <class 'AssertionError'>,
'classmethod': <class 'classmethod'>, 'UnboundLocalError': <class
'UnboundLocalError'>, 'NotImplementedError': <class
'NotImplementedError'>, 'AttributeError': <class 'AttributeError'>,
'OverflowError': <class 'OverflowError'>}, '__file__':
'/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': <class
'test.test_builtin.BuiltinTest'>, 'TestFailingBool': <class
'test.test_builtin.TestFailingBool'>, 'sys': <module 'sys' (built-in)>,
'test': <module 'test' from '/temp/python/py3k/Lib/test/__init__.py'>,
'__name__': 'test.test_builtin', 'unlink': <function unlink at
0x7a5540>, 'TESTFN': '@test', 'TestSorted': <class
'test.test_builtin.TestSorted'>, 'BitBucket': <class
'test.test_builtin.BitBucket'>, 'fcmp': <function fcmp at 0x7ad540>}


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1197, in <module>
    main()
  File "Lib/test/regrtest.py", line 411, in main
    testdir, huntrleaks)
  File "Lib/test/regrtest.py", line 570, in runtest
    testdir, huntrleaks)
  File "Lib/test/regrtest.py", line 623, in runtest_inner
    print("test", test, "failed --", msg)
  File "/temp/python/py3k/Lib/io.py", line 1459, in write
    b = encoder.encode(s)
  File "/temp/python/py3k/Lib/encodings/ascii.py", line 22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode characters in position
697-699: ordinal not in range(128)

----------
messages: 70374
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: test_builtin fails after test_decimal
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 04:29:34 2008
From: report at bugs.python.org (mvngu)
Date: Tue, 29 Jul 2008 02:29:34 +0000
Subject: [issue3463] make life.py use more rendering characters
In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
Message-ID: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>


New submission from mvngu <nguyenminh2 at gmail.com>:

Allows life.py to use other characters for rendering (alphanumeric plus
punctuation characters), apart from the default asterisk "*". The
rendering character can be specified from the command line.

----------
components: Demos and Tools
files: life.py.diff
keywords: patch
messages: 70375
nosy: mvngu
severity: normal
status: open
title: make life.py use more rendering characters
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11001/life.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3463>
_______________________________________

From report at bugs.python.org  Tue Jul 29 04:55:55 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 29 Jul 2008 02:55:55 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217300155.17.0.558264462583.issue3453@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

If that were the case, it wouldn't need to call PyType_Ready for 
tp_base either.  From stepping thru the code, there are several places 
in the interpreter core that PyType_Ready is called for types whose 
tp_base has not been initialized yet.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Tue Jul 29 08:49:56 2008
From: report at bugs.python.org (nandhakumar)
Date: Tue, 29 Jul 2008 06:49:56 +0000
Subject: [issue3464] Python & NCURSES
In-Reply-To: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za>
Message-ID: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za>


New submission from nandhakumar <nandhakumar at inteleants.com>:

i have installed python 2.4 and ncurses 5.4 in my linux server.
 
Python script is working fine but when i tried using thread function in
my script(which also uses ncurses) it gives the following error: 

 
Traceback (most recent call last):
  File "xxxx.py", line 199, in ?
    curses.wrapper(AnDoRun)
  File "/usr/local/lib/python2.4/curses/wrapper.py", line 44, in wrapper
    return func(stdscr, *args, **kwds)
  File "xxxx.py", line 182, in AnDoRun
    ando.start()
  File "xxxx.py", line 136, in start
    self.proxyManagerThread.start()
  File "/usr/local/lib/python2.4/threading.py", line 416, in start
    _start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread

help me how can i solve this problem ASAP

----------
components: None
messages: 70377
nosy: nandha
severity: normal
status: open
title: Python & NCURSES
type: compile error
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3464>
_______________________________________

From report at bugs.python.org  Tue Jul 29 09:20:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 07:20:02 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217316002.02.0.716468740219.issue3453@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyType_Ready is called for each class in tp_bases.
This is done in typeobject.c::best_base()
Isn't it the case in your program?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Tue Jul 29 09:29:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 07:29:14 +0000
Subject: [issue3464] Python & NCURSES
In-Reply-To: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za>
Message-ID: <1217316554.94.0.484163882839.issue3464@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The python issue tracker is not the correct place to get this kind of
help. Please ask on the comp.lang.python newsgroup:
http://www.python.org/community/lists

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3464>
_______________________________________

From report at bugs.python.org  Tue Jul 29 10:40:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 08:40:38 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1217320838.25.0.839866876122.issue3453@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Forget my last remark: it applies to heap types (created with
type_new()) and not to static types.

However, it seems that a non-ready class in tp_bases can happen only
when an extension type inherits from another extension type.
It is good practice to call PyType_Ready() on every type you define
(otherwise tp_methods doesn't work); doesn't this answer the initial
problem?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Tue Jul 29 11:06:29 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jul 2008 09:06:29 +0000
Subject: [issue3460] PyUnicode_Join could perhaps be simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1217322389.19.0.197006026422.issue3460@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The comment gives a wrong impression: The problem is not (only) that a
codec might by evil, it's the fact that a codec may well execute Python
code and thus allow the list to be changed by other threads during the
operation.

Now, since in Python 3.x codecs are no longer being invoked, it is
probably safe to assume that Python code is not being executed while
PyUnicode_Join() is running, but please double-check.

It's also wise to apply a sanity check at the end of the loop to check
whether the sequence length has indeed not changed (as assert maybe).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________

From report at bugs.python.org  Tue Jul 29 11:24:53 2008
From: report at bugs.python.org (Piotr Wysocki)
Date: Tue, 29 Jul 2008 09:24:53 +0000
Subject: [issue3465] doctest unable to use '...' for unicode literals
In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
Message-ID: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>


New submission from Piotr Wysocki <piotr.wysocki at gmail.com>:

Might be related to 2811

----------
components: Library (Lib)
files: doctest_problem.py
messages: 70382
nosy: wysek
severity: normal
status: open
title: doctest unable to use '...' for unicode literals
versions: Python 2.5
Added file: http://bugs.python.org/file11002/doctest_problem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3465>
_______________________________________

From report at bugs.python.org  Tue Jul 29 11:27:22 2008
From: report at bugs.python.org (Piotr Wysocki)
Date: Tue, 29 Jul 2008 09:27:22 +0000
Subject: [issue3465] doctest unable to use '...' for unicode literals
In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
Message-ID: <1217323642.06.0.547591782386.issue3465@psf.upfronthosting.co.za>


Piotr Wysocki <piotr.wysocki at gmail.com> added the comment:

As I would like to use '...' in order not to care about some part of a
unicode string containing unicode literals (using ELLIPSIS).
The unicode string is inside the value of a dict returned by a function.

It is working on Python 2.4.4 and not working on Python 2.5.2.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3465>
_______________________________________

From report at bugs.python.org  Tue Jul 29 12:30:53 2008
From: report at bugs.python.org (Piotr Wysocki)
Date: Tue, 29 Jul 2008 10:30:53 +0000
Subject: [issue3465] doctest unable to use '...' for unicode literals
In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
Message-ID: <1217327453.13.0.858427726125.issue3465@psf.upfronthosting.co.za>


Piotr Wysocki <piotr.wysocki at gmail.com> added the comment:

I am attaching the output of doctest_problem.py on Python 2.5.2
in case it is necessary.

At the moment I haven't a clue where to look for a bug. Anybody? ;)

----------
components: +Tests, Unicode
Added file: http://bugs.python.org/file11003/doctest_problem_output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3465>
_______________________________________

From report at bugs.python.org  Tue Jul 29 12:41:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 10:41:13 +0000
Subject: [issue3460] PyUnicode_Join could perhaps be simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1217328073.03.0.569741164216.issue3460@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well the potentially dangerous function would have been
PyUnicode_FromObject, but in py3k it only accepts unicode instances
(either exact or subclasses), and since we are only interested in the
underlying buffer we can replace those calls with PyUnicode_Check.
I'll work on a patch and keep you updated.

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________

From report at bugs.python.org  Tue Jul 29 13:19:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 11:19:49 +0000
Subject: [issue3465] doctest unable to use '...' for unicode literals
In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za>
Message-ID: <1217330389.38.0.562598560595.issue3465@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This has nothing to do with doctest. Starting with your script, I get:

>>> a = f()
>>> b = repr(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0105' in
position 4: ordinal not in range(128)

__repr__() is supposed to return a str object. In your case, I suggest
to use %r instead of "%s":
    def __repr__(self):
        return '<%s %r>' % (self.__class__.__name__, self.x)

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3465>
_______________________________________

From report at bugs.python.org  Tue Jul 29 14:42:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 12:42:38 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217335358.52.0.257105613293.issue3462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

My wild uneducated guess is that it's due to a nan-like value being in
the globals, and comparing unequal to itself:

>>> d = {1: float('nan')}
>>> d
{1: nan}
>>> d == d
False
>>> import decimal
>>> nan = decimal.Decimal('nan')
>>> d = {1: nan}
>>> d == d
False

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 14:50:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 12:50:13 +0000
Subject: [issue3460] PyUnicode_Join could perhaps be simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1217335813.15.0.404048276415.issue3460@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. On my measurements it makes str.join() 30% to 50%
faster on non-trivial input.

----------
keywords: +patch
Added file: http://bugs.python.org/file11004/strjoin3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:00:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 13:00:03 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217336403.65.0.779782305984.issue3459@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Raymond, Martin, any opinion on this?

----------
nosy: +loewis, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:13:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 13:13:00 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1217337180.96.0.614734551404.issue2538@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should probably come with a test :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2538>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:30:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 13:30:17 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217338217.45.0.494421902789.issue3462@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Bingo! doctest sets the __builtins__._ variable,
and the last doctest in decimal.py (in lexicographic order) is
Decimal.__round__, which ends with
        >>> round(Decimal('sNaN123'), 0)
        Decimal('NaN123')
This is the value you see in Benjamin's output.

Here is a trivial patch:

Index: Lib/test/regrtest.py
===================================================================
--- Lib/test/regrtest.py        (revision 65283)
+++ Lib/test/regrtest.py        (working copy)
@@ -647,6 +647,8 @@
 def cleanup_test_droppings(testname, verbose):
     import shutil

+    __builtins__._ = None
+
     # Try to clean up junk commonly left behind.  While tests shouldn't
leave
     # any files or directories behind, when a test fails that can be
tedious
     # for it to arrange.  The consequences can be especially nasty on
Windows,

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:32:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 13:32:12 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217338217.45.0.494421902789.issue3462@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807290632o58bf4efcx636da8acf3d7384d@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Tue, Jul 29, 2008 at 8:30 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Bingo! doctest sets the __builtins__._ variable,
> and the last doctest in decimal.py (in lexicographic order) is
> Decimal.__round__, which ends with
>        >>> round(Decimal('sNaN123'), 0)
>        Decimal('NaN123')
> This is the value you see in Benjamin's output.
>
> Here is a trivial patch:

Shouldn't this be fixed in test_decimal so it cleans properly after it's self?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:45:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 13:45:34 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217339134.93.0.0100983544716.issue3462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the cleanup should either be in regrtest.py as Amaury proposes,
or in doctest itself. There's nothing wrong in decimal and its test suite.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:45:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 13:45:57 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217339157.85.0.844440695693.issue3462@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I was leaning towards the "doctest should not pollute the __builtins__
module" side. 
test_decimal might not be the only test that leaks one object outside
the module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 15:47:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 13:47:04 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217339224.19.0.72887146484.issue3462@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I vote for fixing doctest then!

----------
components: +Library (Lib), Tests
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 16:28:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 14:28:06 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217341686.78.0.389401874456.issue3462@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is another patch that modifies doctest itself.
Note that the _ is cleared only if "clear_globs" is True, which makes
sense IMO.

Index: Lib/doctest.py
===================================================================
--- Lib/doctest.py      (revision 65283)
+++ Lib/doctest.py      (working copy)
@@ -1360,6 +1360,7 @@
             linecache.getlines = self.save_linecache_getlines
             if clear_globs:
                 test.globs.clear()
+                __builtins__['_'] = None

     #/////////////////////////////////////////////////////////////////
     # Summarization

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 16:53:35 2008
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Tue, 29 Jul 2008 14:53:35 +0000
Subject: [issue3466] urllib2 should support HTTPS connections with client keys
In-Reply-To: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>
Message-ID: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>


New submission from Marcelo Fern?ndez <fernandezm22 at yahoo.com.ar>:

Despite httplib does have support for HTTPS with client keys[1], urllib2
should support them too, because of the added value that urllib2 has,
like cookielib automatic handling.

[1]: http://code.activestate.com/recipes/117004/

However, I made a workaround:

#-*- coding: utf-8 -*-

import httplib 
import urllib2

key_file = None
cert_file = None

class HTTPSClientAuthConnection(httplib.HTTPSConnection):
    def __init__(self, host):
        httplib.HTTPSConnection.__init__(self, host, key_file=key_file,
cert_file=cert_file)

class HTTPSClientAuthHandler(urllib2.HTTPSHandler):
    def https_open(self, req):
        return self.do_open(HTTPSClientAuthConnection, req)

Regards,
Marcelo

----------
components: Library (Lib)
messages: 70397
nosy: marcelo_fernandez
severity: normal
status: open
title: urllib2 should support HTTPS connections with client keys
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3466>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:15:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 15:15:21 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217344521.14.0.621586534427.issue3462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The doctest patch looks fine to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:29:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 15:29:35 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217345375.97.0.97342825756.issue3462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well except that it would be better spelt as:
    __builtins__._ = None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:35:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 15:35:38 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217345738.0.0.899582773238.issue3462@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Thanks! Applied in r65285.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:39:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jul 2008 15:39:39 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217345375.97.0.97342825756.issue3462@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807290839n6cf370eahf6e2697209419177@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Tue, Jul 29, 2008 at 10:29 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Well except that it would be better spelt as:
>    __builtins__._ = None

__builtins__ is a dict here, though.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3462>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:42:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 15:42:52 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217346172.45.0.174739574599.issue3462@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You know what? It's a mess.
- from the __main__ module, __builtins__ is a module.
- in all other modules, __builtins__ is a dict.

The fix is correct for most modules:
    ./python Lib\test\test_decimal.py
but fails for
    ./python Lib\doctest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:52:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 15:52:37 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217346172.45.0.174739574599.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217346642.488f3c528d433@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Amaury Forgeot d'Arc <report at bugs.python.org>:
>
> You know what? It's a mess.
> - from the __main__ module, __builtins__ is a module.
> - in all other modules, __builtins__ is a dict.

(why is it so? :-O)

Anyway:

    import builtins as b
    b._ = None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 17:59:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jul 2008 15:59:34 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217347174.01.0.827401557066.issue3462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've found it:

? But why is __builtins__ a module in __main__ and a dict elsewhere?
Because in *interactive* mode, printing vars() would include
__builtins__, which would be rather large. Code that incorrectly
assumes it's always one or the other is incorrect and has always been
incorrect; the wart was present when this feature first appeared.
Since this has never been documented AFAIK, it's probably just been
(incorrectly) reverse-engineered and copied around. ?

http://mail.python.org/pipermail/python-3000/2007-March/006170.html

:-S

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 18:02:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 16:02:13 +0000
Subject: [issue3462] test_builtin fails after test_decimal
In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za>
Message-ID: <1217347333.56.0.0325305842935.issue3462@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It is actually documented, at the bottom of
http://docs.python.org/dev/library/__builtin__.html

"import builtin" is the correct thing to do.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3462>
_______________________________________

From report at bugs.python.org  Tue Jul 29 19:46:50 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Jul 2008 17:46:50 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1217353610.1.0.111677563187.issue2394@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Also, the implementation does not follow the revised buffer PEP 3118. It
still calls get/releasebuffer(NULL) to acquire a lock, which is no
longer allowed by the buffer protocol.

I think this should become a release blocker for the last beta.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Jul 29 20:16:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Jul 2008 18:16:32 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1217355392.22.0.290334388215.issue2394@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree, buffer interface should be completed before going into rc phase.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Jul 29 20:31:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Jul 2008 18:31:03 +0000
Subject: [issue3422] sphinx.doc.autodoc: Hook for changing argspec
In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
Message-ID: <1217356263.73.0.258574715395.issue3422@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed the patch with a few changes in r65290. Let me know if
it works!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3422>
_______________________________________

From report at bugs.python.org  Tue Jul 29 20:47:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jul 2008 18:47:18 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217357238.71.0.84476373652.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See r65292 for more updates to the test-suite:  I've replaced the Python
version of msum by a version based on lsum in the original ASPN recipe.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Tue Jul 29 20:53:44 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Tue, 29 Jul 2008 18:53:44 +0000
Subject: [issue3422] sphinx.doc.autodoc: Hook for changing argspec
In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za>
Message-ID: <1217357624.21.0.872087637667.issue3422@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Thanks, works OK.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3422>
_______________________________________

From report at bugs.python.org  Tue Jul 29 22:42:59 2008
From: report at bugs.python.org (Eric L. Frederich)
Date: Tue, 29 Jul 2008 20:42:59 +0000
Subject: [issue3467] sqlite3 path is hard coded in setup.py
In-Reply-To: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>
Message-ID: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>


New submission from Eric L. Frederich <eric.frederich at gmail.com>:

In setup.py, the paths that it searches for sqlite in is hard coded in a
list sqlite_inc_paths.

This should also search any path in either $PATH or $LD_LIBRARY_PATH.

This is necessary for non-default installations of sqlite for users
without root access, or for those with root access that have multiple
versions installed in different locations.

----------
components: Installation
messages: 70411
nosy: ericfrederich
severity: normal
status: open
title: sqlite3 path is hard coded in setup.py
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3467>
_______________________________________

From report at bugs.python.org  Tue Jul 29 22:55:36 2008
From: report at bugs.python.org (nirinA raseliarison)
Date: Tue, 29 Jul 2008 20:55:36 +0000
Subject: [issue3366] Add gamma and error functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1217364936.06.0.5925061521.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

pure Python codes are posted to ASPN:

http://code.activestate.com/recipes/576391/
http://code.activestate.com/recipes/576393/

i also rewrote the patch so that they don't
use the high_word/low_word macros anymore.

Added file: http://bugs.python.org/file11005/pymath.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Wed Jul 30 02:17:29 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 00:17:29 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217377049.0.0.0281967149985.issue3436@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I know this has been closed, but perhaps the fieldnames attribute could
be made into a property that reads the first line of the file if it
hasn't been read yet?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Wed Jul 30 02:43:27 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 00:43:27 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <94BD5636.5B0F346F@aaiworldmarket.com>


New submission from Guido van Rossum <guido at python.org>:

Give your lady only the very best, find out how here http://www.pinehelp.com/

----------
messages: 70414
nosy: gvanrossum
severity: normal
status: open
title: Satisfy her lovemaking desire

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Wed Jul 30 03:04:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 30 Jul 2008 01:04:22 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1217379862.59.0.041575824642.issue3468@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

something going on roundup?

----------
nosy: +gpolo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Wed Jul 30 05:45:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 30 Jul 2008 03:45:55 +0000
Subject: [issue3467] sqlite3 path is hard coded in setup.py
In-Reply-To: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>
Message-ID: <1217389555.37.0.112564486705.issue3467@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

User with non-standard search paths should edit Modules/Setup.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3467>
_______________________________________

From report at bugs.python.org  Wed Jul 30 06:08:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 30 Jul 2008 04:08:06 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1217390886.9.0.665887965841.issue3468@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looking at the message id, this came in through email. I have now
trained this as spam in spambayes (which unfortunately also means that
user:5 gets associated with being spam; we'll have to watch this and
train potential other misclassifications also).

It was a lucky shot of the spambot to guess a valid email address when
sending to the report address. To make this really safe, I can't think
of anything else but require PGP signing of messages (but this really
belongs to tracker-discuss).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Wed Jul 30 06:19:41 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 04:19:41 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1217391581.43.0.0893650903926.issue2542@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Ping? Anyone cares about this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Wed Jul 30 10:30:43 2008
From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=)
Date: Wed, 30 Jul 2008 08:30:43 +0000
Subject: [issue3469] Umlauts make conf.latex_documents fail
In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
Message-ID: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>


New submission from Berthold H?llmann <hoel at users.sourceforge.net>:

For a Project of mine I have set latex_documents to something like

latex_documents = [
  ('index', 'doc.tex', 'Documentation', 'Berthold H?llmann', 'manual'),
]

With this processing fails with:

LANG=C make latex
mkdir -p build/latex build/doctrees
sphinx-build -b latex -d build/doctrees -D latex_paper_size=a4 -N source
build/latex
Sphinx v0.4.2, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 1 changed, 0 removed
reading... index
pickling the env... done
checking consistency...
processing CrossSolverTests.tex... index
resolving references...
writing... Exception occurred:
  File
"/usr/software/gltools/python/Python-2.5/lib/python2.5/site-packages/Sphinx-0.4.2-py2.5.egg/sphinx/latexwriter.py",
line 162, in astext
    '\\renewcommand{\\indexname}{Index}\n' or '') + \
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
206: ordinal not in range(128)
The full traceback has been saved in /tmp/sphinx-err-l_u8H4.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-dev at googlegroups.com. Thanks!
make: *** [latex] Error 1

changing ? to \"o does work.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-err-l_u8H4.log
messages: 70419
nosy: georg.brandl, hoel
severity: normal
status: open
title: Umlauts make conf.latex_documents fail
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11006/sphinx-err-l_u8H4.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3469>
_______________________________________

From report at bugs.python.org  Wed Jul 30 11:38:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Jul 2008 09:38:48 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1217410728.61.0.75760817934.issue2542@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I am working on Thomas' patch, plus tests.

----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Wed Jul 30 12:43:26 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Wed, 30 Jul 2008 10:43:26 +0000
Subject: [issue3470] Wrong name for getrandbits in docstring and documentation
In-Reply-To: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za>
Message-ID: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za>


New submission from Fredrik Johansson <fredrik.johansson at gmail.com>:

The docstring for random.Random mentions a method getrandombits().
Surely this should be getrandbits()?

This ghost method is also mentioned in the Library Reference page for
the random module.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 70421
nosy: fredrikj, georg.brandl
severity: normal
status: open
title: Wrong name for getrandbits in docstring and documentation
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3470>
_______________________________________

From report at bugs.python.org  Wed Jul 30 13:18:47 2008
From: report at bugs.python.org (Richard Boulton)
Date: Wed, 30 Jul 2008 11:18:47 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1217416727.42.0.88680514497.issue3208@psf.upfronthosting.co.za>


Richard Boulton <richard at tartarus.org> added the comment:

I don't think it's reasonable not to support multiple interpreters in a
single process - they're quite widely used by mod_python and mod_wsgi,
and probably by others.  I'm not sure whether that's a problem here or
not, though.

If we need to allow function annotations to be arbitrary PyObjects,
these PyObject pointers can't (in general) refer to statically allocated
python objects, so some extension modules will have to allocate them in
the module initialisation function (and presumably deallocate them again
when the module is unloaded).

I would have thought that any such PyObjects are going to be valid only
from within a single interpreter.  Perhaps I'm wrong.

Certainly it would be unpleasant if a change to one of the objects in
one interpreter was reflected in other interpreters, but if that didn't
risk causing a crash due to the memory allocation going wrong, or
something equally nasty, it might be acceptable.

----------
nosy: +richardb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3208>
_______________________________________

From report at bugs.python.org  Wed Jul 30 13:50:22 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 30 Jul 2008 11:50:22 +0000
Subject: [issue3350] multiprocessing adds built-in types to the global
	copyreg.dispatch_table
In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za>
Message-ID: <1217418622.92.0.108864969625.issue3350@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Alexandre - can you take a look at the solution for issue3125 and tell me 
if this satisfies your concerns? Note that the merge-forward is blocked in 
py3k by issue3385 (which is assigned to you)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3350>
_______________________________________

From report at bugs.python.org  Wed Jul 30 14:02:56 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jul 2008 12:02:56 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217419376.16.0.701966785101.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Minor code cleanups, and fixes to special-value handling in r65299

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Wed Jul 30 14:06:17 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 30 Jul 2008 12:06:17 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1217419577.14.0.722681779255.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

>From Victor:
Ok, here is a patch for test_multiprocessing.py.
- TestClosedFile.test_open() verify that Connection() rejects closed file
descriptor
- TestClosedFile.test_operations() verify that Connection() raises IOError 
for
operations on closed file

I don't know if Connection() is a socket or a pipe. Both should be tested.

Added file: http://bugs.python.org/file11007/test_multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Wed Jul 30 14:41:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Jul 2008 12:41:20 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1217421680.07.0.372056327239.issue3321@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm quite sure that neither the patch nor the new test make sense on
Windows. A file handle is not a file descriptor!

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Wed Jul 30 15:47:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jul 2008 13:47:10 +0000
Subject: [issue3470] Wrong name for getrandbits in docstring and documentation
In-Reply-To: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za>
Message-ID: <1217425630.23.0.342425370711.issue3470@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r65307.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3470>
_______________________________________

From report at bugs.python.org  Wed Jul 30 15:48:30 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 30 Jul 2008 13:48:30 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217425710.08.0.743748196301.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file10967/trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Wed Jul 30 15:48:28 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Wed, 30 Jul 2008 13:48:28 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217425708.95.0.221196586515.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file10965/py3k.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Wed Jul 30 17:40:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jul 2008 15:40:35 +0000
Subject: [issue2491] io.open() handles errors differently on different
	platforms
In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
Message-ID: <1217432435.42.0.0522491243109.issue2491@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the proposal to deprecate os.fdopen should be brought on
python-3000.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2491>
_______________________________________

From report at bugs.python.org  Wed Jul 30 17:48:14 2008
From: report at bugs.python.org (Eric L. Frederich)
Date: Wed, 30 Jul 2008 15:48:14 +0000
Subject: [issue3467] sqlite3 path is hard coded in setup.py
In-Reply-To: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za>
Message-ID: <1217432894.22.0.918555389994.issue3467@psf.upfronthosting.co.za>


Eric L. Frederich <eric.frederich at gmail.com> added the comment:

If we put the following one liner right after sqlite_inc_paths is
defined it will add include directories based on the PATH environment
variable.

sqlite_inc_paths.extend([re.sub('/bin[/]?$', '/include', p) for p in
os.environ.get('PATH', '').split(':')])

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3467>
_______________________________________

From report at bugs.python.org  Wed Jul 30 18:21:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jul 2008 16:21:24 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217434884.47.0.905633988131.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Renamed math.sum to math.fsum (as previously discussed) in r65308.

I think all that's left now is to add a note to the docs about the
problems on x86.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Wed Jul 30 18:38:35 2008
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 30 Jul 2008 16:38:35 +0000
Subject: [issue3471] PyObject_GetAttr() to get special methods
In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>
Message-ID: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

There is a bunch of obscure behavior caused by the use of
PyObject_GetAttr() to get special method from objects.  This is wrong
because special methods should only be looked up in object types, not on
the objects themselves (i.e. with PyType_Lookup()).

Here is one example caused by the PyObject_GetAttr() found in
PyObject_IsInstance():

import abc
>>> isinstance(5, abc.ABCMeta)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a
Python object

This occurs because it ends up trying to call the unbound method
abc.ABCMeta.__instancecheck__(5).  But this first requires checking if
"5" is indeed an instance of abc.ABCMeta... cycle.

Obviously this is just an example; all PyObject_GetAttr() would
potentially need to be reviewed.

----------
messages: 70431
nosy: arigo
severity: normal
status: open
title: PyObject_GetAttr() to get special methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3471>
_______________________________________

From report at bugs.python.org  Wed Jul 30 18:56:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jul 2008 16:56:04 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217436964.0.0.812499008836.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem is that the fix for #3295 was committed in the py3k branch
(in r64751) rather thank on the trunk!
Once PyExc_BufferError is defined properly the crash disappears and
exceptions are printed instead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Jul 30 19:27:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 30 Jul 2008 17:27:26 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1217438846.3.0.0768808589142.issue1068268@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I think this should be resolved in 2.6/3.0 if possible. Especially if 
distributions like Ubuntu are self-patching the fix into place. For 
reference, see: http://mg.pov.lt/blog/subprocess-in-2.4

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Wed Jul 30 19:41:02 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 30 Jul 2008 17:41:02 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1217377049.0.0.0281967149985.issue3436@psf.upfronthosting.co.za>
Message-ID: <18576.42906.403764.882104@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Guido> I know this has been closed, but perhaps the fieldnames attribute
    Guido> could be made into a property that reads the first line of the
    Guido> file if it hasn't been read yet?

It's a nice thought.  I tried the straightforward implementation in my
sandbox and one of the more obscure tests failed.  I have yet to look into
the cause.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Wed Jul 30 19:45:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jul 2008 17:45:44 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217439944.01.0.191806193003.issue3139@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, that was my oversight! I've backported the fix.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Jul 30 19:47:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jul 2008 17:47:08 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1217440028.36.0.377142545396.issue3295@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

... and backported to the trunk in r65310.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Wed Jul 30 20:52:35 2008
From: report at bugs.python.org (Kevin Watters)
Date: Wed, 30 Jul 2008 18:52:35 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1217443955.14.0.0599638040881.issue3006@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Wed Jul 30 21:42:24 2008
From: report at bugs.python.org (Jeff Rodman)
Date: Wed, 30 Jul 2008 19:42:24 +0000
Subject: [issue3472] Updates to "Macintosh Library Modules" Section 1.1
In-Reply-To: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za>
Message-ID: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za>


New submission from Jeff Rodman <jrodman at mindspring.com>:

Change current introduction in 1.1
WAS:
Mac OS X 10.4 comes with Python 2.3 pre-installed by Apple. However, you are 
encouraged to install the most recent version of Python from the Python website 
(http://www.python.org). A ``universal binary'' build of Python 2.5, which runs natively 
on the Mac's new Intel and legacy PPC CPU's, is available there.

IS:
Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple. If you wish, you are 
invited to install the most recent version (currently 2.5.2) of Python from the Python website 
(http://www.python.org). A current "universal binary'' build of Python, which runs natively 
on the Mac's new Intel and legacy PPC CPU's, is available there.

And then, to line:
The Apple-provided build of Python is installed in 
/System/Library/Frameworks/Python.framework and /usr/bin/python, respectively. You 
should never modify or delete these, as they are Apple-controlled and are used by Apple- 
or third-party software.

ADD:
Remember that if you choose to install a newer Python version like this, you will have two 
different but functional Python installations on your computer, so it will be important that 
your paths and usages are consistent with what you want to do.

----------
assignee: georg.brandl
components: Documentation
messages: 70437
nosy: georg.brandl, jrodman
severity: normal
status: open
title: Updates to "Macintosh Library Modules" Section 1.1
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3472>
_______________________________________

From report at bugs.python.org  Wed Jul 30 22:24:35 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jul 2008 20:24:35 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217449475.66.0.386023524009.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added documentation note about x86 problems in r65315.

Jean, Raymond:  is it okay to close this issue now?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Jul 31 00:01:06 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jul 2008 22:01:06 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217455266.35.0.996185797903.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here (fsum8.patch) is a clean version of the alternative fsum algorithm.

I'd like to push for using this in place of the existing algorithm.

Added file: http://bugs.python.org/file11008/fsum8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Jul 31 00:26:26 2008
From: report at bugs.python.org (Tim Peters)
Date: Wed, 30 Jul 2008 22:26:26 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217456786.27.0.804834683693.issue2819@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Mark, I don't currently have a machine with SVN and a compiler
installed, so can't play with patches.  I just want to note here that,
if you're concerned about speed, it would probably pay to eliminate all
library calls except one to frexp().  fmod() in particular is typically
way too expensive, taking time proportional to the difference between
its inputs' exponents (it emulates "long division" one bit at a time). 
While float->integer conversion is also "too expensive" on Pentium
chips, multiply-and-convert-to-integer is probably a substantially
cheaper way to extract bits from the mantissa frexp() delivers; note
that this is how the Cookbook lsum() function gets bits, although it
gets all 53 bits in one gulp while in C you'd probably want to get,
e.g., 30 bits at a time.

Something that's surprised me for decades is how slow platform ldexp()
functions are too, given how little they do.  Whenever you have a fixed
offset E you'd like to add to an exponent, it's almost certainly very
much faster to multiply by 2.0**E (when that's a compile-time constant)
than to call ldexp(whatever, E).

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Jul 31 00:49:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Jul 2008 22:49:12 +0000
Subject: [issue3469] Umlauts make conf.latex_documents fail
In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
Message-ID: <1217458152.47.0.946667060918.issue3469@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Did you try using a Unicode string? IIRC the docs explicitly say that if
you include non-ASCII chars in the config you should use Unicode strings.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3469>
_______________________________________

From report at bugs.python.org  Thu Jul 31 00:58:37 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Jul 2008 22:58:37 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217458717.35.0.0183050490275.issue3436@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Re-opened for consideration of GvR's suggestion.

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 31 01:03:53 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Jul 2008 23:03:53 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217459033.17.0.457242344425.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's indeed better.
Now with when running my previous script I can see the exception ;-)

Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\dev\python\trunk1\lib\threading.py", line 523, in
__bootstrap_inner
    self.run()
  File "C:\dev\python\trunk1\lib\threading.py", line 478, in run
    self.__target(*self.__args, **self.__kwargs)
  File "<stdin>", line 3, in f
  File "C:\dev\python\trunk1\lib\io.py", line 1473, in write
    self.buffer.write(b)
  File "C:\dev\python\trunk1\lib\io.py", line 1041, in write
    self._write_buf.extend(b)
BufferError: Existing exports of data: object cannot be re-sized

Again, I think this is unfortunate for a simple script that prints from
several threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 01:41:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jul 2008 23:41:55 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217459033.17.0.457242344425.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217461312.5780.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 30 juillet 2008 ? 23:03 +0000, Amaury Forgeot d'Arc a
?crit :
> Again, I think this is unfortunate for a simple script that prints from
> several threads.

Yes, but it's an issue with the BufferedWriter implementation, since it
changes the length of its underlying bytearray object. If it was
rewritten to use a fixed-size bytearray, the problem would probably
disappear.

(in the middle term BufferedReader and BufferedWriter should perhaps be
both rewritten in C)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 01:46:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jul 2008 23:46:47 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za>
Message-ID: <1217461607.08.0.0037512475753.issue3295@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

About r65312, BufferError inherits from StandardError, not directly from
Exception :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Thu Jul 31 01:50:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jul 2008 23:50:36 +0000
Subject: [issue3295] PyExc_BufferError is declared but nowhere defined
In-Reply-To: <1217461607.08.0.0037512475753.issue3295@psf.upfronthosting.co.za>
Message-ID: <1afaf6160807301650o6f675f8ak400f0ee358a09d49@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Wed, Jul 30, 2008 at 6:46 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> About r65312, BufferError inherits from StandardError, not directly from
> Exception :)

[ Benjamin slaps his head not for the first time today... ]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3295>
_______________________________________

From report at bugs.python.org  Thu Jul 31 02:00:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 00:00:05 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217462405.17.0.567611973283.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> If it was rewritten to use a fixed-size bytearray
does such an object exist today?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 02:16:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 00:16:35 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217462405.17.0.567611973283.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217463391.7662.12.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 31 juillet 2008 ? 00:00 +0000, Amaury Forgeot d'Arc a ?crit :
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> > If it was rewritten to use a fixed-size bytearray
> does such an object exist today?

Manually, yes :)
Just preallocate your bytearray, e.g.:
    b = bytearray(b" " * 4096)

and then be careful to only do operations (e.g. slice assignments) which
keep the size intact.
In a BufferedWriter implementation, you would have to keep track of the
currently used chunk in the bytearray (offset and size).

Anyway, I'd question the efficiency of the bytearray approach; when
removing the quadratic behaviour in BufferedReader I discovered that
using a bytearray was slower than keeping a list of bytes instances and
joining them when needed (not to mention that the latter is inherently
thread-safe :-)). The reason is that the underlying raw stream expects
and returns bytes, and the public buffered API also does, so using a
bytearray internally means lots of additional memory copies.

(a related problem is that readinto() does not let you specify an offset
inside the given buffer object, it always starts writing at the
beginning of the buffer. Perhaps memoryview() will support creating
subbuffers, I don't know...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:16:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 01:16:31 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

functions with keyword-only arguments have this form:
    def f(x, *args, y):
        pass
parameters can appear after the *arg, they are required to be passed by
keyword.

It would be more consistent to allow this function call:
    f(X, *ARGS, y=Y)
This is invalid syntax, *ARGS is required to be at the end of the
arguments, together with an eventual **KWARGS. This restriction should
be lifted.

See the use case in
http://mail.python.org/pipermail/python-3000/2008-July/014437.html

----------
assignee: amaury.forgeotdarc
messages: 70449
nosy: amaury.forgeotdarc
severity: normal
status: open
title: In function call, keyword arguments could follow *args
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:21:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 01:21:14 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1217467274.18.0.938644705478.issue2542@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r65320 in trunk.
I'll close the issue after it is merged into py3k.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:30:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 01:30:55 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217467855.01.0.813430806299.issue3473@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Should this apply to 2.6 as well? See r65321, I find the last line
easier to read when arguments are in this order.

    def grouper(n, iterable, fillvalue=None):
        args = [iter(iterable)] * n
        return izip_longest(*args, fillvalue=fillvalue)

On the cons side, keyword-only arguments don't exist in 2.6, so the
consistency with function definition syntax does not apply.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:47:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:47:26 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1217468846.19.0.380858454118.issue2542@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I just merged it.

----------
nosy: +benjamin.peterson
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2542>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:51:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:51:24 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1217469084.14.0.272871967087.issue1692335@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

How is this coming? Can we apply this to 2.6?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:51:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:51:57 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1217469117.4.0.421026533352.issue2322@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Hmm. I suppose this is still an issue. Should it be a release blocker yet?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2322>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:52:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:52:31 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1217469151.92.0.752043285763.issue2335@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm going to defer this to 2.7.

----------
nosy: +benjamin.peterson
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:53:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:53:09 +0000
Subject: [issue2336] Backport PEP 3114 (__next__)
In-Reply-To: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za>
Message-ID: <1217469189.02.0.923148095287.issue2336@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has been done.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2336>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:53:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:53:25 +0000
Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking)
In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za>
Message-ID: <1217469205.23.0.576266817296.issue2340@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm deferring this to 2.7

----------
nosy: +benjamin.peterson
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2340>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:53:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:53:47 +0000
Subject: [issue2369] Fixer for new integer literals are needed
In-Reply-To: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za>
Message-ID: <1217469227.74.0.0335248272952.issue2369@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Is this still an issue?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2369>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:56:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:56:02 +0000
Subject: [issue2368] Fixer needed to change __builtin__ -> builtins
In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za>
Message-ID: <1217469362.35.0.577951893881.issue2368@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

We have a fixer for this.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2368>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:56:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:56:35 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1217469395.03.0.613424356324.issue2226@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:57:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:57:34 +0000
Subject: [issue2373] Raise Py3K warnings for comparisons that changed
In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za>
Message-ID: <1217469454.64.0.404766814117.issue2373@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2373>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:57:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:57:57 +0000
Subject: [issue2367] Fixer to handle new places where parentheses are needed
In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za>
Message-ID: <1217469477.53.0.382619853921.issue2367@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

How is this coming?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2367>
_______________________________________

From report at bugs.python.org  Thu Jul 31 03:59:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 01:59:32 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1217469572.12.0.920880138139.issue2366@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:00:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:00:17 +0000
Subject: [issue1581] xmlrpclib.ServerProxy() doesn't use x509 data
In-Reply-To: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za>
Message-ID: <1217469617.81.0.0921556007863.issue1581@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I assume you wanted to close this too.

----------
nosy: +benjamin.peterson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:00:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:00:50 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1217469650.63.0.594148417283.issue1616@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Is this still a problem?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:02:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:02:08 +0000
Subject: [issue2357] sys.exc_{type, values,
	traceback} should raise a Py3K warning
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1217469728.93.0.711053912512.issue2357@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Collin, can you review the 2to3 patch?

----------
assignee:  -> collinwinter
components: +2to3 (2.x to 3.0 conversion tool) -Interpreter Core
nosy: +benjamin.peterson, collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:02:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:02:39 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1217469759.18.0.894066688378.issue2470@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What's the status of this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:03:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:03:23 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1217469803.17.0.789645472958.issue1518@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:03:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:03:53 +0000
Subject: [issue2443] uninitialized access to va_list
In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
Message-ID: <1217469833.95.0.50131099717.issue2443@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What's the status of this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2443>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:04:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:04:34 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1217469874.45.0.517413983822.issue2375@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What's the status of this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2375>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:06:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:06:09 +0000
Subject: [issue2458] Allow Python code to change Py3k warning flag
In-Reply-To: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za>
Message-ID: <1217469969.92.0.176863318733.issue2458@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I guess this isn't going anywhere...

----------
resolution:  -> rejected
status: open -> closed
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2458>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:06:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:06:39 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1217469999.04.0.252770041861.issue1731717@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Any more information on this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:06:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:06:56 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1217470016.75.0.446855057267.issue1717@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:07:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:07:41 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1217470061.3.0.844142741697.issue2389@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:08:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:08:14 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217470094.82.0.808913285838.issue1563@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Any progress?

----------
assignee:  -> josiahcarlson
nosy: +benjamin.peterson, josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:09:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:09:18 +0000
Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za>
Message-ID: <1217470158.92.0.332020397182.issue2370@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Collin, can you review?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2370>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:10:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:10:04 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1217470204.99.0.69246333309.issue1179@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Does anybody still care about this for 2.6?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:11:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:11:05 +0000
Subject: [issue1685] linecache .updatecache fails on utf8 encoded files
In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>
Message-ID: <1217470265.12.0.0280860477076.issue1685@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

re now handles bytes, so what's next?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:12:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:12:10 +0000
Subject: [issue2902] tkinter uses MacOS
In-Reply-To: <1211072203.77.0.284787779391.issue2902@psf.upfronthosting.co.za>
Message-ID: <1217470330.17.0.453720267333.issue2902@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

[ccing people who might now if this should still be an issue.]

----------
nosy: +gpolo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2902>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:13:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:13:19 +0000
Subject: [issue2853] *** glibc detected *** python: double free or corruption
In-Reply-To: <1210784892.85.0.853831073509.issue2853@psf.upfronthosting.co.za>
Message-ID: <1217470399.85.0.455736871655.issue2853@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On lack of response from the OP, I'm going to mark this closed.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2853>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:13:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:13:59 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1217470439.23.0.727617629544.issue2965@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What needs to happen here?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2965>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:15:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:15:11 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1217470511.51.0.730933946666.issue2384@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:15:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:15:35 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1217470535.48.0.179702741525.issue2744@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Alexandre, are you still computerless?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:16:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:16:26 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1217470586.85.0.366203683597.issue2548@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:16:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:16:40 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1217470600.03.0.691297429792.issue2919@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:17:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:17:13 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1217470633.41.0.804966652244.issue3132@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu Jul 31 04:18:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 02:18:14 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1217470694.95.0.229801371425.issue1878@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping

----------
nosy: +benjamin.peterson
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Thu Jul 31 05:40:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 31 Jul 2008 03:40:55 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

It turns out that functools.reduce() is simply __builtins__.reduce().
That does not stop the DeprecationWarning from using reduce() from being
raised even though the message says to use functools.reduce()!

Easiest solution is to create a wrapper for __builtin__.reduce() that
silences the warning when called.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 70484
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Using functools.reduce() does not stop DeprecationWarning when using -3
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Thu Jul 31 08:31:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jul 2008 06:31:29 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217485889.24.0.650226405666.issue3473@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for applying to 2.6.  

izip_longest() is a perfect example of where it's important.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 08:32:38 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jul 2008 06:32:38 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1217485958.12.0.296210159573.issue3474@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can't this be handled by 2-to-3 instead of a -3 warning?

----------
components: +2to3 (2.x to 3.0 conversion tool) -Library (Lib)
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Thu Jul 31 08:47:54 2008
From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=)
Date: Thu, 31 Jul 2008 06:47:54 +0000
Subject: [issue3469] Umlauts make conf.latex_documents fail
In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
Message-ID: <1217486874.82.0.765891231146.issue3469@psf.upfronthosting.co.za>


Berthold H?llmann <hoel at users.sourceforge.net> added the comment:

OK, using Unicode strings in conf.py does work, so make this a Bug in
sphinx-quickstart. My conf.py was generated by sphinx-quickstart, When
asked for the author(s) name I gave my name and conf.py was generated
with a simple string for the name information instead of a Unicode string.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3469>
_______________________________________

From report at bugs.python.org  Thu Jul 31 09:13:10 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Thu, 31 Jul 2008 07:13:10 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>


New submission from Matteo Bertini <matteob at naufraghi.net>:

Playing with PyInstaller I have found that the final part of 
_elementtree.c:

Index: Modules/_elementtree.c
===================================================================
--- Modules/_elementtree.c      (revisione 59540)
+++ Modules/_elementtree.c      (copia locale)
@@ -2780,7 +2780,10 @@

       );

-    PyRun_String(bootstrap, Py_file_input, g, NULL);
+    if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL)
+        return;

    elementpath_obj = PyDict_GetItemString(g, "ElementPath");

execute a bit of python code without checking the return value.
That can lead to weird things playing with import hooks,
for example an assert like this can fail:

Index: Lib/test/test_elemettree.py
===================================================================
--- Lib/test/test_elemettree.py (revisione 0)
+++ Lib/test/test_elemettree.py (revisione 0)
@@ -0,0 +1,21 @@
+#! /usr/bin/env python
+
+def importHook(*args, **kwargs):
+    if 'xml.etree' in args:
+        raise ImportError
+    else:
+        return __real__import__(*args, **kwargs)
+
+import os
+import __builtin__
+__real__import__ = __builtin__.__import__
+__builtin__.__import__ = importHook
+
+try:
+    import xml.etree.cElementTree as cET
+except ImportError:
+    pass
+else:
+    out = os.popen("python -c 'import xml.etree.cElementTree as cET; 
print dir(cET)'").read().strip()
+    assert str(dir(cET)) == out, (str(dir(cET)), out)
+

----------
components: XML
messages: 70488
nosy: naufraghi
severity: normal
status: open
title: _elementtree.c import can fail silently
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Thu Jul 31 09:51:56 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 31 Jul 2008 07:51:56 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1217490716.53.0.598365240116.issue3475@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Fredrik, can you take a look?

----------
assignee:  -> effbot
nosy: +effbot, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Thu Jul 31 09:57:46 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jul 2008 07:57:46 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1217491066.3.0.103565490879.issue1878@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido, what say you, live with it, revert it, or apply 
Py_TPFLAGS_HAVE_VERSION_TAG to all core types?

----------
assignee: arigo -> gvanrossum
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Thu Jul 31 10:06:11 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jul 2008 08:06:11 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1217491571.18.0.672143636458.issue2389@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

At this point, I think it better to wait until Py2.7/3.1.  Changing it 
now would just complicate efforts to port from 2.5 to 2.6 to 3.0.  

Guido, do you agree?

----------
assignee:  -> gvanrossum
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Thu Jul 31 10:37:02 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 08:37:02 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1217493422.47.0.949355829609.issue2965@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it ok that the keys/values/items return iterators rather than views?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2965>
_______________________________________

From report at bugs.python.org  Thu Jul 31 10:38:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 08:38:52 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1217493532.76.0.607166759303.issue2965@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, code like:
         items1 = list(dict.items())
         items1.sort()

could be simplified into:
         items1 = sorted(dict.items())

(same for reversed() instead of list.reverse())

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2965>
_______________________________________

From report at bugs.python.org  Thu Jul 31 11:03:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 09:03:12 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As discovered in #3139, io.BufferedWriter mutates the size of its
internal bytearray object. Consequently, invocations of write() from
multiple threads can produce exceptions when one thread gets a buffer to
the bytearray while the other thread tries to resize it. This especially
affects calling print() from multiple threads.

A solution is to use a fixed-size (preallocated) bytearray object.
Another solution is to get rid of the bytearray approach and replace it
with a growing list of immutable bytes objects.

Here is the test script provided by Amaury:

import sys, io, threading
stdout2 = io.open(sys.stdout.fileno(), mode="w")
def f(i):
    for i in range(10):
        stdout2.write(unicode((x, i)) + '\n')
for x in range(10):
    t = threading.Thread(target=f, args=(x,))
    t.start()

(with py3k, replace "stdout2.write" with a simple "print")

----------
components: Library (Lib)
messages: 70494
nosy: amaury.forgeotdarc, pitrou
priority: high
severity: normal
status: open
title: BufferedWriter not thread-safe
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Jul 31 11:09:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 09:09:46 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217495386.15.0.867740663515.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Martin, sorry for noticing this now but on python-dev you had proposed
the following:

? I propose that new codes s*, t*, w* are added, and that s#,t#,w#
refuses objects which implement a releasebuffer procedure
(alternatively, s# etc might be removed altogether right away) ?

I don't see any changes to s# and t# in your patch. Do you plan to do it
later or do you think this part should be dropped?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 12:38:33 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 31 Jul 2008 10:38:33 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217500713.43.0.107764195004.issue1563@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Now that the major bugs have been fixed I think this patch needs to be
re-adapted to the new asynchat.py currently available in the trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Thu Jul 31 13:27:37 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 31 Jul 2008 11:27:37 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1217503657.06.0.212871069563.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK after a long discussion on the mailing list, Guido gave this the OK,
with the provision that there are str->bytes and bytes->str versions of
these functions as well. So I've written those.

http://mail.python.org/pipermail/python-dev/2008-July/081601.html

quote itself now accepts either a str or a bytes. quote_from_bytes is a
new function which is just an alias for quote. (Is this acceptable?)

unquote is still str->str. I've added a totally separate function
unquote_to_bytes which is str->bytes.

Note there is a slight issue here: I didn't quite know what to do with
unescaped non-ASCII characters in the input to unquote_to_bytes - they
need to somehow be converted to bytes. I chose to encode them using
UTF-8, on the basis that they technically shouldn't be in a URI anyway.

Note that my new unquote doesn't have this problem; it's carefully
written to preserve the Unicode characters, even if they aren't
expressible in the given encoding (which explains some of the code bloat).

This makes unquote(s, encoding=e) necessarily more robust than
unquote_to_bytes(s).decode(e) in terms of unescaped non-ASCII characters
in the input.

I've also added new test cases and documentation for these two new
functions (included in patch6).

On an entirely personal note, can whoever checks this in please mention
my name in the commit log - I've put in at least 30 hours researching
and writing this patch, and I'd like for this not to go uncredited :)

Commit log for patch6:

Fix for issue 3300.

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets.
As per RFC 3986, default is "utf-8" (previously implicitly decoded as
ISO-8859-1).

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded. Default is "utf-8" (previously characters
in range(128, 256) were encoded as ISO-8859-1, and characters above that
as UTF-8). Also characters/bytes above 128 are no longer allowed to be
"safe". Also now allows either bytes or strings.

Added functions urllib.parse.quote_from_bytes,
urllib.parse.unquote_to_bytes.

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface, added quote_from_bytes and unquote_to_bytes.

Lib/test/test_urllib.py: Added several new test cases testing encoding
and decoding Unicode strings with various encodings, as well as testing
the new functions.

Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py,
Lib/test/test_wsgiref.py: Updated and added test cases to deal with
UTF-8-encoded URIs.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file11009/parse.py.patch6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Jul 31 13:37:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 11:37:55 +0000
Subject: [issue3477] grammar productionlist are not properly indented
In-Reply-To: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za>
Message-ID: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

See http://docs.python.org/dev/reference/expressions.html#id9
the production rule for "argument_list" is not properly indented.

It seems that the first line is indented up to the widest name of the
list, but subsequent lines only add 6 to the length of the defined name.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70498
nosy: amaury.forgeotdarc, georg.brandl
severity: normal
status: open
title: grammar productionlist are not properly indented
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3477>
_______________________________________

From report at bugs.python.org  Thu Jul 31 15:12:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 13:12:44 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217509964.64.0.0743586408572.issue3473@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file11010/kwargs30.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 15:13:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 13:13:29 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217510009.59.0.845079638458.issue3473@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Patches for both versions are attached.

Added file: http://bugs.python.org/file11011/kwargs26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 15:16:00 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Thu, 31 Jul 2008 13:16:00 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217510160.32.0.598147869882.issue1563@psf.upfronthosting.co.za>


Daniel Arbuckle <djarb at highenergymagic.org> added the comment:

I'll update the patch and post it again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Thu Jul 31 15:23:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jul 2008 13:23:22 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217510602.33.0.0791967385804.issue3436@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I personally like the idea of making fieldnames a property - while
having merely reading an attribute cause disk I/O is slightly
questionable, it seems like a better option than returning a misleading
value for that property and also a better option than reading the first
line of the file in __init__.

Hopefully Skip can track down that obscure failure and this change can
be made at some point in the future.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 31 15:54:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 13:54:31 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217512471.66.0.11652661176.issue3473@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patches look good to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:20:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 14:20:46 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217514046.95.0.948227194743.issue3476@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a sample implementation (using a fixed-size bytearray) with test.
Amaury, would you like to take a look?

I'm a bit puzzled by the shady BufferedRandom semantics: though the
tests do pass, it's hard to say why e.g. BufferedRandom.tell() was
implemented like that.

----------
keywords: +patch
Added file: http://bugs.python.org/file11012/bufferedwriter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:22:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 14:22:09 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217514129.14.0.722344092021.issue3476@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It seems that as with the quadratic binary buffered reading, the best
solution is the list of bytes which should be especially helped by your
bytes joining optimization.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:22:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 31 Jul 2008 14:22:55 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217495386.15.0.867740663515.issue3139@psf.upfronthosting.co.za>
Message-ID: <4891CABC.2090105@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't see any changes to s# and t# in your patch. Do you plan to do it
> later or do you think this part should be dropped?

It's implemented. When bf_releasebuffer is not NULL, convertbuffer will
complain "string or read-only buffer".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:26:31 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 31 Jul 2008 14:26:31 +0000
Subject: [issue3478] Documentation for struct module is out of date in 3.0
In-Reply-To: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>
Message-ID: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The documentation for the "struct" module still uses the term "string"
even though the struct module itself deals entirely in bytes objects in
Python 3.0.

I propose updating the documentation to reflect the 3.0 terminology.

I've attached a patch for the Docs/library/struct.rst file. It mostly
renames "string" to "bytes". It also notes that pack for 'c', 's' and
'p' accepts either string or bytes, but unpack spits out a bytes.

One important point: If you pass a str to 'c', 's' or 'p', it will get
encoded with UTF-8 before being packed. I've described this behaviour in
the documentation. I'm not sure if this should be described as the
"official" behaviour, or just informatively.

I've traced this behaviour to Modules/_struct.c lines 607, 1650 and 1676
(for 'c', 's' and 'p' respectively), which calls
_PyUnicode_AsDefaultEncodedString. This is found in
Object/unicodeobject.c:1410, which directly calls PyUnicode_EncodeUTF8.

Hence the UTF-8 encoding is not system or locale specific - it will
always happen. However, perhaps we should loosen the documentation to
say "which are encoded using a default encoding scheme".

It would be good if the authors of the struct module read over these
changes first, to make sure I am describing it correctly.

I have also updated Modules/_struct.c's doc strings and exception
messages to reflect this new terminology. (I've changed nothing besides
the contents of these strings - test case passes, just to be safe).

Patch is for /python/branches/py3k/, revision 65324.

Commit Log:

Docs/library/struct.rst: Updated documentation to Python 3.0 terminology
(bytes instead of strings). Added note that packing 'c', 's' or 'p'
accepts either str or bytes.

Modules/_struct.c: Updated doc strings and exception messages to the same.

----------
assignee: georg.brandl
components: Documentation
files: struct-doc.patch
keywords: patch
messages: 70506
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: Documentation for struct module is out of date in 3.0
versions: Python 3.0
Added file: http://bugs.python.org/file11013/struct-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3478>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:27:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 14:27:30 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1217514450.47.0.74995144779.issue3424@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Would you like to propose an alternate order?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:28:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Jul 2008 14:28:02 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217514482.57.0.921732228816.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]
> if you're concerned about speed, it would probably pay to eliminate all
> library calls except one to frexp().

Indeed it would!  Here's a revised patch that avoids use of fmod.  Speed is comparable with the current 
version.  Here are some timings for summing random values on OS X/Core 2 Duo, on a non-debug build of the 
trunk. lsum is the patched version, msum is the version in the current trunk; timings are in seconds.

                                                |  lsum    |  msum
------------------------------------------------+----------+---------
50000 random values in [0, 1)                   | 0.003091 | 0.002540
50000 random values in [0, 1), sorted           | 0.003202 | 0.003043
50000 random values in [0, 1), reverse order    | 0.003201 | 0.002587
50000 random values in [-1, 1)                  | 0.003229 | 0.002829
50000 random values in [-1, 1), sorted          | 0.003183 | 0.002629
50000 random values in [-1, 1), reverse order   | 0.003195 | 0.002731
50000 random exponential values                 | 0.003994 | 0.006178
50000 random exponential values, sorted         | 0.003713 | 0.007933
50000 random exponential values, reverse order  | 0.003714 | 0.002849

Note that lsum doesn't suffer from the 'fragmentation of partials' problem that slows down msum for sorted 
datasets.

I'll do some timings on Linux/x86 as well.

Added file: http://bugs.python.org/file11014/fsum10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:36:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jul 2008 14:36:17 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217514129.14.0.722344092021.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217514969.4891cdd9403bb@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Benjamin Peterson <report at bugs.python.org>:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> It seems that as with the quadratic binary buffered reading, the best
> solution is the list of bytes which should be especially helped by your
> bytes joining optimization.

I don't really know. The logic is quite different (and harder to get right) than
in BufferedReader. I might try to write a list-of-bytes version and do some
timings, but it's not trivial... I should first compare against the current
version.

Also, an advantage of using a fixed-size bytearray is that it more closely
mimicks what will have to be written for an efficient C implementation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:38:14 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jul 2008 14:38:14 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217515095.0.0.468834270637.issue3473@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll have a look at this in the next day or two.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:39:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 14:39:21 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217514969.4891cdd9403bb@imp.free.fr>
Message-ID: <1afaf6160807310739r578c864er4cf39ed9f4b9e5f5@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Jul 31, 2008 at 9:36 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> I don't really know. The logic is quite different (and harder to get right) than
> in BufferedReader. I might try to write a list-of-bytes version and do some
> timings, but it's not trivial... I should first compare against the current
> version.
>
> Also, an advantage of using a fixed-size bytearray is that it more closely
> mimicks what will have to be written for an efficient C implementation.

You are correct that this should probably be rewritten in C at some
point, so let's go with this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:49:51 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 31 Jul 2008 14:49:51 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1217515791.95.0.0710825913962.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Hmm ... seems patch 6 I just checked in fails a test case! Sorry! (It's
minor, gives a harmless BytesWarning if you run with -b, which "make
test" does, so I only picked it up after submitting).

I've slightly changed the code in quote so it doesn't do that any more
(it normalises all "safe" arguments to bytes).

Please review patch 7, not 6. Same commit log as above.

(Also .. someone let me know if I'm not submitting patches properly,
like perhaps I should be deleting the old ones not keeping them around?)

Added file: http://bugs.python.org/file11015/parse.py.patch7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Jul 31 16:53:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 31 Jul 2008 14:53:45 +0000
Subject: [issue3479] unichr integer overflow
In-Reply-To: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>
Message-ID: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

unichr(2**32) results in a unicode string containing a 0 byte:

{{{
~/mwlib.hg/tests/ python                                            
Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(2**32)
u'\x00'
>>> unichr(2**32+1)
u'\x01'
>>> unichr(2**32+2)
u'\x02'
}}}

2.6 shows the same behaviour.

----------
components: Unicode
messages: 70513
nosy: schmir
severity: normal
status: open
title: unichr integer overflow
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3479>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:04:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 15:04:00 +0000
Subject: [issue3478] Documentation for struct module is out of date in 3.0
In-Reply-To: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>
Message-ID: <1217516640.5.0.0343146221055.issue3478@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! Done in r65327.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3478>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:04:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 15:04:32 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217516672.31.0.492306652616.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ok for s#. 
But t# uses bf_getcharbuffer(), which does not seem to lock anything.
I wonder if this can lead to the same kind of problems, for example when
calling file_write with a binary file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:09:42 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 31 Jul 2008 15:09:42 +0000
Subject: [issue3478] Documentation for struct module is out of date in 3.0
In-Reply-To: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za>
Message-ID: <1217516982.48.0.939766358801.issue3478@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Thanks for the props!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3478>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:13:43 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 31 Jul 2008 15:13:43 +0000
Subject: [issue2902] tkinter uses MacOS
In-Reply-To: <1211072203.77.0.284787779391.issue2902@psf.upfronthosting.co.za>
Message-ID: <1217517223.61.0.651030519914.issue2902@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

as I understand, MacOS.SchedParams is gone for more than 4 years now
(that is why you see this hasattr check everywhere). I doubt removing
this MacOS usage will do anything.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2902>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:13:53 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 31 Jul 2008 15:13:53 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217517233.63.0.184708399519.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Added file: http://bugs.python.org/file11016/issue3436.py3k.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:14:16 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 31 Jul 2008 15:14:16 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217517256.79.0.103469842441.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Added file: http://bugs.python.org/file11017/issue3436.trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:16:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 15:16:45 +0000
Subject: [issue2902] tkinter uses MacOS
In-Reply-To: <1211072203.77.0.284787779391.issue2902@psf.upfronthosting.co.za>
Message-ID: <1217517405.01.0.0386656246721.issue2902@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Great! It's gone in r65328.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2902>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:20:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 15:20:51 +0000
Subject: [issue3479] unichr integer overflow
In-Reply-To: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>
Message-ID: <1217517651.72.0.674867067904.issue3479@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed. 
This happens on architectures where sizeof(long) > sizeof(int):
builtin_unichr() converts its argument to a long, but calls
PyUnicode_FromOrdinal() which accepts an int.

----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3479>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:22:10 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 31 Jul 2008 15:22:10 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1217510160.32.0.598147869882.issue1563@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0807310821vfad6f43i6e2f5972c44c08de@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Thanks.  I'll read it.

Bill

On Thu, Jul 31, 2008 at 6:16 AM, Daniel Arbuckle <report at bugs.python.org>wrote:

>
> Daniel Arbuckle <djarb at highenergymagic.org> added the comment:
>
> I'll update the patch and post it again.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1563>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080731/26abb732/attachment.txt>

From report at bugs.python.org  Thu Jul 31 17:25:01 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 31 Jul 2008 15:25:01 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217517901.13.0.0161064849276.issue3436@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

I like the idea of fieldnames attribute being a property, so i've
uploaded patches that implement them as such.
Both patches ran through make test without problems.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Thu Jul 31 17:55:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Jul 2008 15:55:23 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217519723.22.0.97208848367.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Timings on x86/Linux are similar:  the lsum-based version is around
10% slower on average, 25% slower in the worst case, and significantly 
faster for the msum worst cases.

There's probably still some snot left to optimize out, though.  Some
tempting ideas are:

  (1) to try using doubles instead of longs for the accumulator digits
      (with 51 or 52 bits of precision), and
  (2) to split each mantissa into (nearest_integer, fraction) instead
      of (next_smallest_integer, fraction), using rint or lrint.

Anything else?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Jul 31 18:07:44 2008
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 31 Jul 2008 16:07:44 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1217520464.98.0.14781167983.issue1878@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Maybe there is a better solution along the following line: conditionally
define Py_TPFLAGS_DEFAULT so that when compiling the Python core it
includes the Py_TPFLAGS_HAVE_VERSION_TAG, but when compiling extension
modules it does not.  This should ensure compatibility with many
existing extension modules.  (It would still break if they play tricks
like modifying the tp_dict of types other than their own.)

In addition, to support the method cache in newer C extension modules:

* C types defined by C extension modules can include the
Py_TPFLAGS_HAVE_VERSION_TAG explicitly to enable the cache;

* new C API functions should be introduced to give an official way to
access the tp_dict of a type, e.g. PyType_{Get,Set,Del}DictItemString().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Thu Jul 31 19:25:58 2008
From: report at bugs.python.org (Jack Diederich)
Date: Thu, 31 Jul 2008 17:25:58 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1217525158.26.0.971357696322.issue2366@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Thanks for the ping.  I just rewrote the patch from scratch and it
handles corner cases (of which there are many in the parse tree) better.
 I'll upload/checkin sometime today.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Thu Jul 31 19:39:32 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jul 2008 17:39:32 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1217525972.27.0.749783626275.issue2690@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

On the issue of whether len(range()) should be allowed to be >
sys.maxsize, I think this should be allowed.  I think in the future we
should change the __len__ protocol to allow unbounded lengths.  Even
today, I think range(10**100).__len__() should return 10**100 rather
than raising an OverflowError, even if len(range(10**100)) raises
OverflowError.

I also think ranges should be introspectable, exposing their start, stop
and step values just like slice objects.

Probably all those changes are for post 3.0.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Thu Jul 31 19:43:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 31 Jul 2008 17:43:59 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217485958.12.0.296210159573.issue3474@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807311043t3e199185v85c270b495285c61@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Jul 30, 2008 at 11:32 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> Can't this be handled by 2-to-3 instead of a -3 warning?
>

Well, there is the problem of someone having a function already named
reduce() and the import. Since 2to3 can't go back and add an import,
every found use of reduce() would need to have an import inserted
somewhere. That won't work if reduce() is being used in a expression
context instead of a statement context, etc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Thu Jul 31 20:56:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Jul 2008 18:56:14 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1217530574.17.0.656215776787.issue3474@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Alternatively, you could move reduce to functools and have the builtin
module issue a warning and call it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Thu Jul 31 22:00:05 2008
From: report at bugs.python.org (Nick Edds)
Date: Thu, 31 Jul 2008 20:00:05 +0000
Subject: [issue3480] Fix_imports pattern optimization
In-Reply-To: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za>
Message-ID: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

Here is a substantial improvement to the pattern for fix_imports. It
significantly reduces the size of the previous pattern and represents it
in a more reasonable way. It still passes all of the tests and it also
makes 2to3 roughly two to three times as fast based on the results of
some basic testing.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_imports_pattern.diff
keywords: patch
messages: 70528
nosy: collinwinter, nedds
severity: normal
status: open
title: Fix_imports pattern optimization
type: performance
Added file: http://bugs.python.org/file11019/fix_imports_pattern.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3480>
_______________________________________

From report at bugs.python.org  Thu Jul 31 22:14:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 31 Jul 2008 20:14:55 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217516672.31.0.492306652616.issue3139@psf.upfronthosting.co.za>
Message-ID: <48921D3B.8070301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> But t# uses bf_getcharbuffer(), which does not seem to lock anything.

Indeed. I think we can safely drop support for passing buffer objects
into t# which have getbuffer/releasebuffer, so the check for
releasebuffer being NULL should be added to t#.

I think the bytearray object should refuse to implement getcharbuffer,
anyway.

> I wonder if this can lead to the same kind of problems, for example when
> calling file_write with a binary file.

It should be a text file to cause problems, right?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Jul 31 22:46:57 2008
From: report at bugs.python.org (Jack Diederich)
Date: Thu, 31 Jul 2008 20:46:57 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1217537217.45.0.599770909246.issue2366@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

The new patch works and handles all the corner cases I could think of. 
I tried to comment the heck out of it because it does a lot of manual
walking and manipulation of the syntax tree.

This only handles __metaclass__ inside classes.  I wasn't sure what to
do with __metaclass__ at the module level (which is now a NOP, I think).

Added file: http://bugs.python.org/file11020/fix_metaclass.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Thu Jul 31 23:30:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 21:30:38 +0000
Subject: [issue3479] unichr integer overflow
In-Reply-To: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za>
Message-ID: <1217539838.41.0.333573463402.issue3479@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r65339.
Will not backport to 2.5: code that used to (approximately) work would
break.

Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3479>
_______________________________________