[issue5099] subprocess.POpen.__del__() AttributeError (os module == None!)

[Gregory P. Smith]

Gregory P. Smith  added the comment:

i don't see your attachment brett.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue8436] set.__init__ accepts keyword args

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
keywords: +easy

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
keywords: +easy
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 3.3

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Victor, please leave that to David. He will fix it.

--

___
Python tracker 

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

[issue8436] set.__init__ accepts keyword args

[Raymond Hettinger]

Raymond Hettinger  added the comment:

If you submit a patch, be sure to include a test that covers both 
set.__init__() and frozenset.__init__().  Model the code are the equivalent 
checks in Modules/itertoolsmodule.c

--
priority:  -> low
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.2

___
Python tracker 

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

[issue6095] os.curdir as the default argument for os.listdir

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
versions:  -Python 2.7

___
Python tracker 

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

[issue8424] buildbots: test_itimer_virtual failures

[Guilherme Polo]

Guilherme Polo  added the comment:

To make the situation worse, this Ubuntu buildbot passed all signal tests on 
the next run.

--

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Nir Aides]

Nir Aides  added the comment:

Yet another update to bfs.patch.

I upload a variation on Florent's write test which prints progress of 
background CPU bound threads as: thread-name timestamp progress

Here are some numbers from Windows XP 32bit with Intel q9400 (4 cores). Builds 
produced with VS express (alas - no optimizations, so official builds may 
behave differently).

BFS - 
33% CPU, 37,000 context switches per second

z:\bfs\PCbuild\python.exe y:\writes.py
t1 2.34400010109 0
t2 2.4213134 0
t1 4.6713134 1
t2 4.7963134 1
t1 7.0163242 2
t2 7.2036866 2
t1 9.375 3
t2 9.625 3
t1 11.703962 4
t2 12.0309998989 4
t1 14.046313 5
t2 14.421313 5
t1 16.407648 6
t2 16.7809998989 6
t1 18.782648 7
t2 19.125 7
t1 21.157648 8
t2 21.483676 8
t1 23.5 9
t2 23.858676 9
t1 25.858951 10
t2 26.233676 10
t1 28.2349998951 11
28.2189998627

gilinter - starves both bg threads and high rate of context switches.
45% CPU, 203,000 context switches per second

z:\gilinter\PCbuild\python.exe y:\writes.py
t1 13.0939998627 0
t1 26.421313 1
t1 39.812638 2
t1 53.1559998989 3
57.5470001698

PyCON - starves one bg thread and slow IO thread 
Py32 - starves IO thread as expected.

Note, PyCON, gilinter and py32 starve the bg thread with Dave's original 
buffered write test as well - http://bugs.python.org/issue7946#msg101116

--
Added file: http://bugs.python.org/file16968/writes.py

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Nir Aides]

Changes by Nir Aides :


Added file: http://bugs.python.org/file16967/bfs.patch

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Nir Aides]

Changes by Nir Aides :


Removed file: http://bugs.python.org/file16947/bfs.patch

___
Python tracker 

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

[issue8391] os.execvpe() doesn't support surrogates in env

[STINNER Victor]

STINNER Victor  added the comment:

Current code of execve() has a bug: it uses the length of the environment 
variable value in *characters* and not in *bytes* to allocate the "p" buffer. I 
remember that someone wrote a comment somewhere about that... The result is 
that the environment variable value is truncated by 1 byte.

Example (copy of http://dpaste.com/184803/):
---
$ cat test.py
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os

env = {"VAR": "ćd"}
os.execve("test.sh", [], env)
$ cat test.sh
#!/bin/bash

declare -p VAR
$ python2.6 test.py
declare -x VAR="ćd"
$ python3.1 test.py
declare -x VAR="ć"
---

--

___
Python tracker 

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

[issue8394] ctypes.dlopen() doesn't support surrogates

[STINNER Victor]

STINNER Victor  added the comment:

Fixed: r80159 (py3k), r80160 (3.1). I commited a different version of my patch 
to support None.

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

___
Python tracker 

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

[issue850728] Semaphore.acquire() timeout parameter

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Modified patch committed in r80157 (py3k). Thank you!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8424] buildbots: test_itimer_virtual failures

[R. David Murray]

R. David Murray  added the comment:

i486 Ubuntu also showed the test_itimer_virtual failure (but not the other 
one...FreeBSD didn't show the other one either) here:

http://www.python.org/dev/buildbot/builders/i386 Ubuntu 
trunk/builds/949/steps/test/logs/stdio

--
title: tiger/FreeBSD7.2 buildbots: test_itimer_virtual failures -> buildbots: 
test_itimer_virtual failures

___
Python tracker 

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

[issue8432] build: test_send_signal of test_subprocess failure

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #8263.

--

___
Python tracker 

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

[issue8263] regrtest stops prematurately on FreeBSD buildbot, with "success" result.

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #8432.

--
nosy: +haypo

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[STINNER Victor]

STINNER Victor  added the comment:

The commit creating methods "function", "select" were added the 24th february 
2010, whereas gdb 7.1 was released around the 18th february 2010.
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-frame.c?cvsroot=src

I guess that the author (Dave Malcolm?) of the is_evalframeex() method in 
Tools/gdb/libpython.py uses the HEAD version of GDB.

About the select() method, Dave added the following comment to its Frame 
wrapper:
---

def select(self):
'''If supported, select this frame and return True; return False if 
unsupported

Not all builds have a gdb.Frame.select method; seems to be present on 
Fedora 12
onwards, but absent on Ubuntu buildbot'''
---

gdb in Fedora 12 is based on 7.0.1 plus a lot of patches. But I don't see a 
patch added the select() method to the Python API:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/

--

___
Python tracker 

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

[issue5099] subprocess.POpen.__del__() AttributeError (os module == None!)

[R. David Murray]

Changes by R. David Murray :


--
nosy: +brian.curtin

___
Python tracker 

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

[issue8263] regrtest stops prematurately on FreeBSD buildbot, with "success" result.

[R. David Murray]

R. David Murray  added the comment:

The test_break unit test is now skipped for freebsd6 on trunk in r80155.  I 
suspect this affects py3k as well on freebsd6.

--

___
Python tracker 

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

[issue8435] It is possible to observe a mutating frozenset

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm not sure that I care about this one.  The only way to pull it off it is to 
intentionally try to mutate the frozenset.  Will look at it along with the 
others though.

--
priority:  -> low

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Darryl Miles]

Darryl Miles  added the comment:

With regards to create test cases for certain situations, sure this would be 
possible but not with "pure python" since your APIs deny/inhibit the particular 
things required to force a situation for a test case.

With regards to SSL_peek() blocking, you'd need to explain yourself better on 
that one.  The patch has been tested with the test cases from Python SVN enough 
to be happy they run ok.  Maybe you have some offline not yet checked in SSL 
test cases you are referring to.  To clarify why this is being done, if there 
is unread data then SSL_shutdown() will never return 1.  Maybe you can simulate 
this situation by using SSL_write() with 1 byte payloads and a 10ms delay 
between each SSL_write() of the "QUIT response message" (you are trying to 
simulate network propagation delay).  Then you have a client that tries to do 
unwrap() right after having sent the quit command, but makes no attempt to 
receive the response.

I'll leave you guys too it about how you want to handle things with python 
(i.e. to make the design choice trade offs).  I think all the points have been 
covered.

--

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
status: pending -> closed

___
Python tracker 

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

[issue8431] buildbot: hung on ARM Debian

[STINNER Victor]

STINNER Victor  added the comment:

It would help if regrtest.py added a timestamp to messages (at least "test_xxx" 
lines). Eg. "18:08:34.750933: test_io".

--

___
Python tracker 

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

[issue8436] set.__init__ accepts keyword args

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thx, will look at it when I get a chance.

--

___
Python tracker 

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

[issue8431] buildbot: hung on ARM Debian

[STINNER Victor]

STINNER Victor  added the comment:

On ARMv7Thumb Ubuntu trunk, build 47 hung after the following tests:
---
test_wait3
test_genericpath
test_uuid
test_zipimport_support
test_slice
test_decorators
---

build 48 hung after the following tests:
---
test_memoryio
test_robotparser
test_charmapcodec
test_ast
---

build 49 hung after the following tests:
---
test_grp
test_binascii
test_uu
test_zlib
test_unpack
test_array
test_list
test_cmd_line
test_traceback
test_global
test_index
test_cd
test_cd skipped -- No module named cd
test_bz2
test_fnmatch
test_posixpath
test_random
test_code
test_gc
test_dict
test_threading_local
test_eof
test_codecmaps_hk
test_aifc
test_descr
---

test_tokenize and test_io were not yet executed.

--

___
Python tracker 

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

[issue8431] buildbot: hung on ARM Debian

[Stefan Krah]

Stefan Krah  added the comment:

Antoine is right: On a fast machine (3.16GHz) test_io.py takes 810s
on debian-arm/qemu. All tests pass, so perhaps the limit is just too
restrictive on slow machines.

--
nosy: +skrah

___
Python tracker 

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

[issue8279] python-gdb PyListTests fail

[STINNER Victor]

STINNER Victor  added the comment:

> In GDB 7.1, a gdb.frame object has no more function method (...)

Missing function method is not related to gdb version: see #8437 (msg103444).

As Martin wrote: let's continue the discussion in issue #8437 ;-)

--

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[STINNER Victor]

STINNER Victor  added the comment:

According to documentation of the Python API of gdb, a frame has a function 
method. I read gdb 7.0, 7.0.1 and 7.1 (downloaded from 
http://ftp.gnu.org/gnu/gdb): there is not "function" method, but a "name" 
method.

On my Debiand Sid (gdb 7.1), gdb has the name method, but not the function 
method.

Can we use frame.name() instead of frame.function().name on any OS and all gdb 
7.x versions?

--

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[STINNER Victor]

STINNER Victor  added the comment:

See my msg103440 of issue #8279.

--

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[Martin v . Löwis]

New submission from Martin v. Löwis :

I get a number of failures in test_gdb with gdb 7.0.1 about gdb.Frame, e.g.

FAIL: test_basic_command (test.test_gdb.PyListTests)  
Verify that the "py-list" command works   
--
Traceback (most recent call last):
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 538, in 
test_basic_command
cmds_after_breakpoint=['py-list'])  
   
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in 
get_stack_trace   
self.assertEquals(err, '')  
   
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no 
attribute 'function'\n" != ''

--
assignee: dmalcolm
messages: 103442
nosy: dmalcolm, haypo, loewis, ncoghlan
severity: normal
status: open
title: test_gdb: gdb.Frame has no attribute function

___
Python tracker 

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

[issue8279] python-gdb PyListTests fail

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Thanks for the patch, committed as r80156. As expected, there are still 
complaints about gdb.Frame.

As the original issue is now resolved, I'm closing this issue as fixed, and 
open a new issue for the remaining failures.

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

___
Python tracker 

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

[issue8279] python-gdb PyListTests fail

[STINNER Victor]

STINNER Victor  added the comment:

In GDB 7.1, a gdb.frame object has no more function method: it's replaced by a 
name method. Tools/gdb/libpython.py should be modified:

Add >>GDB_70 = gdb.VERSION.startswith("7.0")<< at the beginning, and replace 
is_evalframeex() by:

def is_evalframeex(self):
'''Is this a PyEval_EvalFrameEx frame?'''
if GDB_70:
func = self._gdbframe.function()
if not func:
return False
func_name = func.name
else:
func_name = self._gdbframe.name()

if func_name != 'PyEval_EvalFrameEx':
return False

# I believe we also need to filter on the inline
# struct frame_id.inline_depth, only regarding frames with
# an inline depth of 0 as actually being this function
#
# So we reject those with type gdb.INLINE_FRAME
return (self._gdbframe.type() == gdb.NORMAL_FRAME)

--

___
Python tracker 

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

[issue8281] test_gdb_sample fails

[STINNER Victor]

STINNER Victor  added the comment:

Oops, my last message (msg103435) was for #8434, not this issue. Anyway, #8434 
is a duplicate of #8279, it doesn't matter.

--

___
Python tracker 

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

[issue8279] python-gdb PyListTests fail

[STINNER Victor]

STINNER Victor  added the comment:

#8434 is a duplicate of this issue.

--
nosy: +haypo

___
Python tracker 

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

[issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk

[STINNER Victor]

STINNER Victor  added the comment:

Oh, this is a duplicate of #8279.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue8404] Set operations don't work for dictionary views

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


Removed file: http://bugs.python.org/file16927/fix_dictviews_as_number.diff

___
Python tracker 

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

[issue8404] Set operations don't work for dictionary views

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

I found the issue. The view types didn't have Py_TPFLAGS_CHECKTYPES set, so the 
types were using the old-style binary operators.

Here's a patch that fixes the issue. Please review.

--
Added file: http://bugs.python.org/file16966/fix_dictviews_set_operations.diff

___
Python tracker 

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

[issue8281] test_gdb_sample fails

[STINNER Victor]

STINNER Victor  added the comment:

test_gdb.py refers to test_gdb_sample.py instead of gdb_sample.py. Attached 
patch fixes that.

But then I get new errors:
---
...
Verify the pretty-printing of unicode values ... ok
test_basic_command (__main__.PyListTests)  
Verify that the "py-list" command works ... FAIL   
test_one_abs_arg (__main__.PyListTests)
Verify the "py-list" command with one absolute argument ... FAIL   
test_two_abs_args (__main__.PyListTests)   
Verify the "py-list" command with two absolute arguments ... FAIL  
test_down_at_bottom (__main__.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... FAIL   
test_pyup_command (__main__.StackNavigationTests)  
Verify that the "py-up" command works ... FAIL 
test_up_at_top (__main__.StackNavigationTests) 
Verify handling of "py-up" at the top of the stack ... FAIL
test_up_then_down (__main__.StackNavigationTests)  
Verify "py-up" followed by "py-down" ... FAIL  
test_basic_command (__main__.PyBtTests)
Verify that the "py-bt" command works ... FAIL 
test_basic_command (__main__.PyPrintTests) 
Verify that the "py-print" command works ... FAIL  
test_print_after_up (__main__.PyPrintTests) ... FAIL   
test_printing_builtin (__main__.PyPrintTests) ... FAIL 
test_printing_global (__main__.PyPrintTests) ... FAIL  
test_basic_command (__main__.PyLocalsTests) ... FAIL   
test_locals_after_up (__main__.PyLocalsTests) ... FAIL 

==
FAIL: test_basic_command (__main__.PyListTests)   
Verify that the "py-list" command works   
--
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 535, in test_basic_command
cmds_after_breakpoint=['py-list'])
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace   
self.assertEquals(err, '')
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no 
attribute 'function'\n" != ''

==
FAIL: test_one_abs_arg (__main__.PyListTests) 
Verify the "py-list" command with one absolute argument   
--
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 552, in test_one_abs_arg  
cmds_after_breakpoint=['py-list 9'])  
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace   
self.assertEquals(err, '')
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no 
attribute 'function'\n" != ''

==
FAIL: test_two_abs_args (__main__.PyListTests)
Verify the "py-list" command with two absolute arguments  
--
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 565, in test_two_abs_args 
cmds_after_breakpoint=['py-list 1,3'])
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace   
self.assertEquals(err, '')
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no 
attribute 'function'\n" != ''

==
FAIL: test_down_at_bottom (__main__.StackNavigationTests) 
Verify handling of "py-down" at the bottom of the stack   
--
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 588, in test_down_at_bottom   
cmds_after_breakpoint=['py-down'])
  File "Lib/test/test_gdb.py", line 111, in get_stack_trace   
self.assertEquals(err, '')
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no 
attribute 'function'\n" != ''

==

[issue5099] subprocess.POpen.__del__() AttributeError (os module == None!)

[Brett Cannon]

Brett Cannon  added the comment:

Attached is a patch I wrote entirely independently of this issue (Mercurial's 
test suite trigger it for me). I go further in terms of caching items than the 
original patch as I still got failures even when I stored just a reference to 
os (might be an OS X thing with the os module).

I just need someone to verify my patch works under Windows. If someone can do 
that I will commit it and Gabriel's test (with Antoine's suggested fixes).

--
nosy: +brett.cannon

___
Python tracker 

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

[issue2302] Uses of SocketServer.BaseServer.shutdown have a race

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a simpler patch. It also fixes the wrong use of a lock instead of an 
event in test_httpservers. With this patch, test_httpservers runs forever 
without freezing.

--
Added file: http://bugs.python.org/file16964/shutdown.patch

___
Python tracker 

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

[issue6789] ftplib storelines does not honor strings returned in fp.readline

[R. David Murray]

Changes by R. David Murray :


--
priority:  -> normal
stage:  -> committed/rejected
superseder:  -> Error calling .storlines from ftplib
type: crash -> behavior

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Mark Dickinson]

Mark Dickinson  added the comment:

That patch works for me, too.  Nice!

> It seems that FreeBSD has problems with the fact that readline.so is
> linked with -lreadline and -lncursesw (why?).

Good question...

--

___
Python tracker 

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

[issue2302] Uses of SocketServer.BaseServer.shutdown have a race

[Antoine Pitrou]

Antoine Pitrou  added the comment:

After a bit of investigation, this issue seems to be exactly why 
test_httpservers sometimes hangs.
The patch looks complicated to me, though; I don't think we really have to 
support the multiple shutdowns case.

--
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

[R. David Murray]

R. David Murray  added the comment:

I don't know how deep you want to get into detecting invalid URIs, but with the 
new patch this one causes a parsing error that is probably worth dealing with:

  http://abc[xyz]jkl

Maybe a reasonable set of checks would be (in hostname) that if the part of the 
netloc after the @ contains a ']' or a '[', then it must start with a [ and 
either end with a ] or contain a ']:'.

I can also mess up your new checks with something like this:

  http://foo[...@baz]

or even:

  http://foo[...@baz:33]

although those don't fail, they just faithfully produce the nonsensical results 
implicit in the invalid urls.  I think the above check logic in hostname would 
catch them, but it wouldn't catch this one:

  http://foo[...@[bar]:33]

That may be OK, though, since as you noted earlier we aren't doing full URI 
validation.

Oh, and I notice that your test only covers the 'fast' path code, it doesn't 
exercise the general URI logic.

(Sorry I didn't review this issue earlier.)

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

It seems that FreeBSD has problems with the fact that readline.so is
linked with -lreadline and -lncursesw (why?).

With issue7384.patch I get no more errors using either Mark's test case
or test_curses.py.

--
Added file: http://bugs.python.org/file16963/issue7384.patch

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple

[Mark Dickinson]

Mark Dickinson  added the comment:

Given the lack of agreement here, I propose that we just leave the current code 
as it is;  it doesn't seem like a big issue to me, and we should resist messing 
with code that isn't clearly broken.

--
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

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

[issue8436] set.__init__ accepts keyword args

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue8435] It is possible to observe a mutating frozenset

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue8436] set.__init__ accepts keyword args

[Eugene Kapun]

New submission from Eugene Kapun :

>>> list().__init__(a=0)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'a' is an invalid keyword argument for this function
>>> set().__init__(a=0)

--
components: Interpreter Core
messages: 103427
nosy: abacabadabacaba
severity: normal
status: open
title: set.__init__ accepts keyword args
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue8420] Objects/setobject.c contains unsafe code

[Eugene Kapun]

Changes by Eugene Kapun :


--
type:  -> crash

___
Python tracker 

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

[issue8435] It is possible to observe a mutating frozenset

[Eugene Kapun]

New submission from Eugene Kapun :

This code shows that frozensets aren't really immutable. The same frozenset is 
printed twice, with different content. Buggy functions are set_contains, 
set_remove and set_discard, all in Objects/setobject.c

class bad:
def __eq__(self, other):
global f2
f2 = other
print_f2()
s1.add("querty")
return self is other
def __hash__(self):
return hash(f1)
def print_f2():
print(id(f2), repr(f2))
f1 = frozenset((1, 2, 3))
s1 = set(f1)
s1 in {bad()}
print_f2()

--
components: Interpreter Core
messages: 103426
nosy: abacabadabacaba
severity: normal
status: open
title: It is possible to observe a mutating frozenset
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue6789] ftplib storelines does not honor strings returned in fp.readline

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Closed as a duplicate of 6822 which provides a patch.

--
nosy: +giampaolo.rodola
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue4814] ftplib does not honour "timeout" parameter for active data connections

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
assignee:  -> giampaolo.rodola
nosy: +r.david.murray

___
Python tracker 

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

[issue8420] Objects/setobject.c contains unsafe code

[Eugene Kapun]

Eugene Kapun  added the comment:

I've found more unsafe code in Objects/setobject.c.
This code makes Python 3.1.2 segfault by using a bug in function set_merge:

class bad:
def __eq__(self, other):
if be_bad:
set2.clear()
raise Exception
return self is other
def __hash__(self):
return 0
be_bad = False
set1 = {bad()}
set2 = {bad() for i in range(2000)}
be_bad = True
set1.update(set2)

Function set_symmetric_difference_update has a similar bug.

Another bug in set_symmetric_difference_update:

class bad:
def __init__(self):
print("Creating", id(self))
def __del__(self):
print("Deleting", id(self))
def __eq__(self, other):
print("Comparing", id(self), "and", id(other))
if be_bad:
dict2.clear()
return self is other
def __hash__(self):
return 0
be_bad = False
set1 = {bad()}
dict2 = {bad(): None}
be_bad = True
set1.symmetric_difference_update(dict2)

--
title: set_lookkey is unsafe -> Objects/setobject.c contains unsafe code

___
Python tracker 

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

[issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +pitrou

___
Python tracker 

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

[issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk

[STINNER Victor]

STINNER Victor  added the comment:

Related issue: #8281 (For gdb7, a python-gdb.py file is added to the build, 
allowing to use advanced gdb features when debugging Python.)

--

___
Python tracker 

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

[issue8431] buildbot: hung on ARM Debian

[STINNER Victor]

STINNER Victor  added the comment:

There are other hung on trunk (output of bbreport):

ARMv4 Debian trunk 80129, 80120, 80101, 80098, 80085,  
 80129: # hung for 30 min: test_ast
 80120: # hung for 30 min: test_descr  
 80101: # hung for 30 min: test_parser 
 80098: # hung for 30 min: test_decorators 
 80085: # hung for 30 min: test_lib2to3

ARMv7Thumb Ubuntu trunk80120, 80098, 80084, 80084,  *** , 80030
 80120: # hung for 30 min: test_descr  
 80098: # hung for 30 min: test_ast
 80084: # hung for 30 min: test_decorators 
 ...
 80030: # hung for 30 min: test_opcodes

--
title: buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x -> 
buildbot: hung on ARM Debian
versions: +Python 2.7

___
Python tracker 

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

[issue8384] Distutils C extension build with MinGW on Windows fails

[anatoly techtonik]

anatoly techtonik  added the comment:

To me a better option would be an ability to specify a path to compiler from 
command line.

--compiler-path=./mingw/bin/gcc.exe

--
nosy: +techtonik

___
Python tracker 

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

[issue8434] buildbot: test_gdb failure on sparc Ubuntu trunk

[STINNER Victor]

New submission from STINNER Victor :

http://www.python.org/dev/buildbot/builders/sparc Ubuntu 
trunk/builds/76/steps/test/logs/stdio

test_gdb
test test_gdb failed -- multiple errors occurred; run in verbose mode for 
details
Re-running test 'test_gdb' in verbose mode
test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled ... ok
test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully ... ok
test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_builtin_function (test.test_gdb.PrettyPrintTests) ... ok
test_builtin_method (test.test_gdb.PrettyPrintTests) ... ok
test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled ... ok
test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances ... ok
test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... ok
test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled ... ok
test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled ... ok
test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries ... ok
test_exceptions (test.test_gdb.PrettyPrintTests) ... ok
test_frames (test.test_gdb.PrettyPrintTests) ... ok
test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets ... ok
test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok
test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values ... ok
test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists ... ok
test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values ... ok
test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances ... ok
test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval ... ok
test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval ... ok
test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets ... ok
test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None ... ok
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings ... ok
test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass ... ok
test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass ... ok
test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated ... ok
test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... ok
test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values ... ok
test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works ... FAIL
test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument ... FAIL
test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments ... FAIL
test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... FAIL
test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works ... FAIL
test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack ... FAIL
test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down" ... FAIL
test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... FAIL
test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works ... FAIL
test_print_after_up (test.test_gdb.PyPrintTests) ... FAIL
test_printing_builtin (test.test_gdb.PyPrintTests) ... FAIL
test_printing_global (test.test_gdb.PyPrintTests) ... FAIL
test_basic_command (test.test_gdb.PyLocalsTests) ... FAIL
test_locals_after_up (test.test_gdb.PyLocalsTests) ... FAIL

==
FAIL: test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works
--
Traceback (most recent call last):
  File 
"/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", 
line 535, in t

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Moving the Bad URL check to a higher level can be detect the bad urls much 
better. Once I the netloc is parsed and obtained, invalid URL can be checked. I 
am attaching an update with the new test included.
If you have any comments, please let me know.

--
Added file: http://bugs.python.org/file16962/issue2987-bad_url_checks.diff

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Changes by Charles-Francois Natali :


Removed file: http://bugs.python.org/file16960/marshal_stack.diff

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If everyone agrees on "error: [Errno 0] Error" being a legitimate alias 
> for a "connection closed event" condition then I'd say the test server 
> looks good, even if I think that expecting a ssl.SSLError derived
> exception would have made more sense, but I understand this is a
> OpenSSL inherited behavior.

Well, it's quite an unfortunate error display, so perhaps we could detect it 
and turn into something more meaningful instead.
However, I think it should remain a socket error or an OS error, because it's 
really the underlying socket which is closed, not the SSL wrapper.

> Anyway, I'd like to improve the SSL test server in future as I'm sure > it 
> hides some other problems but I can do that once pyftpdlib's SSL
> server code is more mature and after 2.7 is released.

Shouldn't it become part of asyncore at some point? It's both useful (well, for 
people using asyncore anyway :-)) and non-trivial.

--

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

Ok, I've done too some trivial benchmarking on my Linux box, and I get this:
right now:
$ time ./python /tmp/test_import.py
real0m1.258s
user0m1.111s
sys 0m0.101s

with mmap:
$ time ./python /tmp/test_import.py
real0m1.262s
user0m1.170s
sys 0m0.090s

with malloc only:
$ time ./python /tmp/test_import.py
real0m1.213s
user0m1.111s
sys 0m0.099s

The test script just imports every module available.
So I'd agree with Antoine, and think we should just use malloc. The attached 
patch marshal_stack.diff just does that.

--
Added file: http://bugs.python.org/file16961/marshal_stack.diff

___
Python tracker 

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

[issue8371] Add a command to download distributions

[anatoly techtonik]

anatoly techtonik  added the comment:

There is a ready-to-use public domain code with a progress bar if you'll need 
it.
http://pypi.python.org/pypi/wget/

--
nosy: +techtonik

___
Python tracker 

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

[issue8433] buildbot: test_curses failure, getmouse() returned ERR

[STINNER Victor]

STINNER Victor  added the comment:

Other example: http://www.python.org/dev/buildbot/builders/alpha Debian 
3.x/builds/63/steps/test/logs/stdio

test_curses
[?1049h(B[?7h[?5h[?5l[?12l[?25habc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- : getmouse() returned 
ERR
Re-running test test_curses in verbose mode
[?1049h[?12l[?25h(B[?7h[?1000h[?5h[?5labc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- : getmouse() returned 
ERR
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 291, in test_main
main(stdscr)
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 275, in main
module_funcs(stdscr)
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 228, in module_funcs
m = curses.getmouse()
_curses.error: getmouse() returned ERR

--

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Nir Aides]

Nir Aides  added the comment:

> the scheduling function bfs_find_task returns the first task that 
> has an expired deadline. since an expired deadline probably means 
> that the scheduler hasn't run for a while, it might be worth it to 
> look for the thread with the oldest deadline and serve it first, 
> instead of stopping at the first one

This is by design of BFS as I understand it. Next thread to run is either first 
expired or oldest deadline:

http://ck.kolivas.org/patches/bfs/sched-BFS.txt
"Once a task is descheduled, it is put back on the queue, and an
O(n) lookup of all queued-but-not-running tasks is done to determine which has
the earliest deadline and that task is chosen to receive CPU next. The one
caveat to this is that if a deadline has already passed (jiffies is greater
than the deadline), the tasks are chosen in FIFO (first in first out) order as
the deadlines are old and their absolute value becomes decreasingly relevant
apart from being a flag that they have been asleep and deserve CPU time ahead
of all later deadlines."

--

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r80151 (trunk), r80154 (py3k).

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8433] buildbot: test_curses failure, getmouse() returned ERR

[STINNER Victor]

Changes by STINNER Victor :


--
title: buildbot: test_curses failure -> buildbot: test_curses failure, 
getmouse() returned ERR

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

If everyone agrees on "error: [Errno 0] Error" being a legitimate alias for a 
"connection closed event" condition then I'd say the test server looks good, 
even if I think that expecting a ssl.SSLError derived exception would have made 
more sense, but I understand this is a OpenSSL inherited behavior.

Anyway, I'd like to improve the SSL test server in future as I'm sure it hides 
some other problems but I can do that once pyftpdlib's SSL server code is more 
mature and after 2.7 is released.

--

___
Python tracker 

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

[issue8433] buildbot: test_curses failure

[STINNER Victor]

New submission from STINNER Victor :

http://www.python.org/dev/buildbot/builders/sparc Debian 
3.x/builds/62/steps/test/logs/stdio

test_curses
[?1049h(B[?7h[?5h[?5l[?12l[?25habc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- : getmouse() returned 
ERR

Re-running test test_curses in verbose mode
[?1049h[?12l[?25h(B[?7h[?1000h[?5h[?5labc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- : getmouse() returned 
ERR
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 291, in test_main
main(stdscr)
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 275, in main
module_funcs(stdscr)
  File 
"/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py",
 line 228, in module_funcs
m = curses.getmouse()
_curses.error: getmouse() returned ERR

--
keywords: buildbot
messages: 103411
nosy: haypo
severity: normal
status: open
title: buildbot: test_curses failure
versions: Python 3.2

___
Python tracker 

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

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

[R. David Murray]

R. David Murray  added the comment:

I posted this to the checkins list, but for reference, the following invalid 
URL should be added to the test cases:

http://[::1/foo/bar]/bad

--
nosy: +r.david.murray

___
Python tracker 

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

[issue8432] build: test_send_signal of test_subprocess failure

[STINNER Victor]

New submission from STINNER Victor :

http://www.python.org/dev/buildbot/builders/x86 FreeBSD 
3.x/builds/211/steps/test/logs/stdio

Example:
==
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase)
--
Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_subprocess.py", 
line 770, in test_send_signal
self.assertIn(b'KeyboardInterrupt', stderr)
AssertionError: b'KeyboardInterrupt' not found in b''

--

--
keywords: buildbot
messages: 103409
nosy: haypo
severity: normal
status: open
title: build: test_send_signal of test_subprocess failure
versions: Python 3.2

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> It looks a bit strange for this bug to happen, though. Does Ubuntu use a 
> small stack size?

There are other possible reasons:
- the programs that crash (or the libraries they're using) use the stack a lot
- somehow, pthread_attr_setstacksize is called and set to a reduced thread 
stack size
- notice that this is reported on x86_64 architectures, and stack usage is 
increased on 64 bits

Since I don't have an Ubuntu box, it would be nice if one of the reporters 
could:
- return the result of "ulimit -s" on their box
- call "ulimit -s unlimited", and see if the bug goes away
- check that the attached patch marshal_stack.diff solves this
- return the result of "ltrace -e pthread_attr_setstacksize "

> A small benchmark shows no difference in startup time when disabling the 
> stack buffer. (this is on Linux: of course, the problem might be that the 
> glibc is heavily optimized)

Yeap, there as some crappy systems out there (no name :-), that's why it would 
be nice to have some feedback and small benchmarks on various platforms. 
Anyway, even if compiled files are small most of the time, I'm not sure that 
this "let's copy the file to the stack/heap" approcah is optimal, and maybe 
mmap would be worth considering if we find that the overhead is not negligible 
(I haven't looked at the code in detail, so maybe it's not possible to use in 
this case).

--
keywords: +patch
Added file: http://bugs.python.org/file16960/marshal_stack.diff

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +dmalcolm

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Antoine Pitrou]

Antoine Pitrou  added the comment:

A small benchmark shows no difference in startup time when disabling the stack 
buffer. (this is on Linux: of course, the problem might be that the glibc is 
heavily optimized)

The benchmark was a simple:
$ time ./python -E -c "import logging, pydoc, xmlrpclib, urllib, urllib2, 
unittest, doctest, profile, smtplib, httplib, fractions, decimal, codecs, 
difflib, argparse, distutils, email, imaplib, idlelib, json, _pyio, poplib, 
ftplib"

--

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Oh, and the record of the original patch conversation (when this optimization 
was added) can be found here:
http://mail.python.org/pipermail/patches/2001-January/003500.html

--
priority: normal -> high
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I agree that we can consider dropping the static buffer and always using 
PyMem_MALLOC().
It looks a bit strange for this bug to happen, though. Does Ubuntu use a small 
stack size?

--
nosy: +pitrou, tim_one

___
Python tracker 

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

[issue5650] Obsolete RFCs should be removed from doc of urllib.urlparse

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Fixed in revision 80146 and merged into other branches
release26-maint: r80147
py3k: r80148
release31-maint: r80149

--
assignee: georg.brandl -> orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8430] test_site failure with non-ASCII directory

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> barry
nosy: +barry

___
Python tracker 

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

[issue8431] buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I don't know about test_tokenize, but test_io is quite heavy and a couple of 
individual tests launch many threads. On a slow CPU with little RAM, the test 
could simply be still running (swapping?) after 1800s...

--
nosy: +doko, pitrou

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +doko

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment

[Eugene Kapun]

Eugene Kapun  added the comment:

-1 on special-casing string without an encoding. Current code does (almost) 
this:
...
if argument_is_a_string:
if not encoding_is_given: # Special case
raise TypeError("string argument without an encoding")
encode_argument()
return
if encoding_is_given:
raise TypeError("encoding or errors without a string argument")
...
IMO, it should do this instead:
...
if encoding_is_given:
if not argument_is_a_string:
raise TypeError("encoding or errors without a string argument")
encode_argument()
return
...
This way, bytearray("") would work without any special cases.

--

___
Python tracker 

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

[issue8431] buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x

[STINNER Victor]

New submission from STINNER Victor :

test_tokenize and test_io does sometimes hung on buildbot ARMv4 Debian 3.x. It 
looks to be related to #8429.

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 
3.x/builds/52/steps/test/logs/stdio
-
...
test_tokenize

command timed out: 1800 seconds without output, killing pid 10998
process killed by signal 9
program finished with exit code -1
elapsedTime=12155.584910
-

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 
3.x/builds/50/steps/test/logs/stdio
--
...
test_io

command timed out: 1800 seconds without output, killing pid 18097
process killed by signal 9
program finished with exit code -1
elapsedTime=3859.149082
--

--
keywords: buildbot
messages: 103401
nosy: haypo
severity: normal
status: open
title: buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x
versions: Python 3.2

___
Python tracker 

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

[issue8430] test_site failure with non-ASCII directory

[STINNER Victor]

New submission from STINNER Victor :

r80137 (PEP 3147) introduced a test in test_site. The test fails on non-ASCII 
directory because stdout uses ASCII whereas the directories contains non-ASCII 
characters.

http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu wide 3.x/builds/848

Attached patch is a workaround to this issue. The path is encoded to ASCII 
using backslashreplace error handler. But the patch is not perfect, it should 
use the reverse operation to get the path as an unicode string. But I don't 
know how to implement the reverse operation of .encode("ascii", 
"backslashreplace").

--
files: test_site.patch
keywords: buildbot, patch
messages: 103400
nosy: haypo
severity: normal
status: open
title: test_site failure with non-ASCII directory
versions: Python 3.2
Added file: http://bugs.python.org/file16959/test_site.patch

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[David Beazley]

David Beazley  added the comment:

As a followup, since I'm not sure anyone actually here actually tried a fair 
GIL on Linux, I incorporated your suggested fairness patch to the 
condition-variable version of the GIL (using this pseudocode you wrote as a 
guide):

with gil.cond:
  if gil.n_waiting or gil.locked:
gil.n_waiting += 1
while True:
  gil.cond.wait() #always wait at least once
  if not gil.locked:
break
gil.n_waiting -= 1
  gil.locked = True

I did some tests on this and it does appear to exhibit fairness. Here are the 
results of running the 'fair.py' test with a fair GIL on my Linux system:

[ Fair GIL Linux ]
Sequential execution
slow: 6.246764 (0 left)
fast: 0.465102 (0 left)
Threaded execution
slow: 7.534725 (0 left)
fast: 7.674448 (0 left)
Treaded, balanced execution:
fast A: 10.415756 (0 left)
fast B: 10.456502 (0 left)
fast C: 10.520457 (0 left)
Treaded, balanced execution, with quickstop:
fast B: 8.423304 (0 left)
fast A: 8.409794 (16016 left)
fast C: 8.381977 (9162 left)
beaz...@ubuntu:~/Desktop/Python-2.6.4$ 

If I switch back to the unfair GIL, this is the result:

[ Unfair GIL, original implementation, Linux]
Sequential execution
slow: 6.164739 (0 left)
fast: 0.422626 (0 left)
Threaded execution
slow: 6.570084 (0 left)
fast: 6.690927 (0 left)
Treaded, balanced execution:
fast A: 1.994143 (0 left)
fast C: 2.014925 (0 left)
fast B: 2.073212 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 1.614533 (0 left)
fast C: 1.607324 (377323 left)
fast B: 1.625987 (111451 left)

Probably the main thing to notice is the huge increase in performance over the 
fair GIL.  For instance, the balance execution test runs about 5 times faster.

Here are the two tests repeated with checkinterval = 1000.

[ Fair GIL, checkinterval = 1000]
Sequential execution
slow: 6.175320 (0 left)
fast: 0.424410 (0 left)
Threaded execution
slow: 6.505094 (0 left)
fast: 6.746649 (0 left)
Treaded, balanced execution:
fast A: 2.243123 (0 left)
fast B: 2.416043 (0 left)
fast C: 2.442475 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 1.565914 (0 left)
fast C: 1.514024 (81254 left)
fast B: 1.531937 (63740 left)

[ Unfair GIL, checkinterval = 1000]

Sequential execution
slow: 6.258882 (0 left)
fast: 0.411590 (0 left)
Threaded execution
slow: 6.255027 (0 left)
fast: 0.409412 (0 left)
Treaded, balanced execution:
fast A: 1.291007 (0 left)
fast C: 1.135373 (0 left)
fast B: 1.437205 (0 left)
Treaded, balanced execution, with quickstop:
fast C: 1.331775 (0 left)
fast A: 1.418670 (54841 left)
fast B: 1.403853 (208732 left)

Here, the unfair GIL is still quite a bit faster on raw performance.  I tried 
kicking the check interval up to 1 and the unfair GIL still won by a pretty 
significant margin on raw speed of completing the different tasks.

I've attached a copy of the thread_pthread.h file I modified for this test.  
It's from Python-2.6.4.

--
Added file: http://bugs.python.org/file16958/thread_pthread.h

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout

[STINNER Victor]

STINNER Victor  added the comment:

Same issue on "sparc solaris10 gcc 3.x":
http://www.python.org/dev/buildbot/builders/sparc solaris10 gcc 
3.x/builds/639/steps/test/logs/stdio

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[David Beazley]

David Beazley  added the comment:

I'm definitely sure that semaphores were being used in my test---I stuck a 
print statement inside the code that creates locks just to make sure it was 
using the semaphore version :-).

Unfortunately, at this point I think most of this discussion is academic since 
no change is likely to be incorporated into Python 2.7.  I can definitely see 
where fairness might help I/O performance if there is only 1 CPU bound thread.  
I just don't know for other situations.  For example, if you have a server 
where it's all I/O-bound threads, but it suddenly comes under extreme load 
(e.g., slashdot effect), does a fair GIL help or hurt with that?  I just don't 
know.

In the big picture, all of the issues raised here should be on the minds of 
people fixing the GIL in py3k though.   It's just one more aspect of why fixing 
the GIL is hard.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

>I'm not trying to be a pain here, but do you have any explanation as to >why, 
>with fair scheduling, the observed execution time of multiple CPU->bound 
>threads is substantially worse than with unfair scheduling?
Yes.  This is because the GIL yield now actually succeeds most of the time, 
every 100 opcodes (the default).  Profiling indicates that on multicore 
machines this causes significant instruction cache misses as the new thread is 
scheduled on the other core.   Try raising the sys.checkinterval to 1000 and 
watch the performance difference fall away.

>If so, why would I want fair locking?   Wouldn't I want the solution >that 
>offers the fastest overall execution time?
Because of IO latency.  Your IO thread, waiting to wake up when somethin happen 
also has to compete unfairly with the CPU threads.

"a fair" lock allows you to balance the cost of switching (on multicore) vs 
thread latency using sys.checkinterval (if we are based on opcodes).  The 
unfair lock all but disables this control.

>One other comment.  Running the modified fair.py file on my Linux >system 
>using Python compiled with semaphores shows they they are >*definitely* not 
>fair.  Here's the relevant part of your test:
Interesting.  let me stress that I am using windows and making assumptions 
about how something like sem_wait() behaves.  And the posix standard does not 
require "fair" behaviour of the semaphore functions according to 
http://www.opengroup.org/onlinepubs/009695399/functions/sem_wait.html.

The kernel-based windows synchronization functions achieve an amount of 
"fairness" through WaitForSingleObject() and friends:
http://msdn.microsoft.com/en-us/magazine/cc163642.aspx#S2

Are you absolutely sure that USE_SEMAPHORES is defined?  There could be a 
latent config problem somewhere.

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

Alas, after installing curses from /usr/ports/devel/ncurses I did not
recompile Modules/_curses_panel.c.

So, after a proper build

  ./python Lib/test/regrtest.py -uall  test_curses

shows no errors.

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

I take that back. With the curses from /usr/ports/devel/ncurses,
Mark's test case is fine, but

  ./python Lib/test/regrtest.py -uall  test_curses

fails again.

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

One oddity: In Mark's test case, the error only shows if readline
is imported _before_ curses. The other way around it's fine.


On FreeBSD 8.0 amd64, with the _default_ libcurses, the Valgrind output
for py3k looks like this:

[...]
==31089== Invalid write of size 8
==31089==at 0x284F1AE: getwin (in /lib/libncursesw.so.8)
==31089==by 0x2AE8532: PyCurses_GetWin (_cursesmodule.c:1903)
==31089==by 0x47FBC7: call_function (ceval.c:3833)
==31089==by 0x47AAC0: PyEval_EvalFrameEx (ceval.c:2645)
==31089==by 0x47DF41: PyEval_EvalCodeEx (ceval.c:3282)
==31089==by 0x47189F: PyEval_EvalCode (ceval.c:721)
==31089==by 0x4B31AA: run_mod (pythonrun.c:1692)
==31089==by 0x4B2FC3: PyRun_FileExFlags (pythonrun.c:1649)
==31089==by 0x4B1734: PyRun_SimpleFileExFlags (pythonrun.c:1177)
==31089==by 0x4B0C75: PyRun_AnyFileExFlags (pythonrun.c:963)
==31089==by 0x4CB029: Py_Main (main.c:650)
==31089==by 0x4150E4: main (python.c:152)
==31089==  Address 0x25c71e0 is 0 bytes after a block of size 112 alloc'd
==31089==at 0x25A8AE: calloc (in 
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==31089==by 0x29C518A: _nc_makenew (in /lib/libncurses.so.8)
==31089==by 0x29C569F: newwin (in /lib/libncurses.so.8)
==31089==by 0x284F2EE: getwin (in /lib/libncursesw.so.8)
==31089==by 0x2AE8532: PyCurses_GetWin (_cursesmodule.c:1903)
==31089==by 0x47FBC7: call_function (ceval.c:3833)
==31089==by 0x47AAC0: PyEval_EvalFrameEx (ceval.c:2645)
==31089==by 0x47DF41: PyEval_EvalCodeEx (ceval.c:3282)
==31089==by 0x47189F: PyEval_EvalCode (ceval.c:721)
==31089==by 0x4B31AA: run_mod (pythonrun.c:1692)
==31089==by 0x4B2FC3: PyRun_FileExFlags (pythonrun.c:1649)
==31089==by 0x4B1734: PyRun_SimpleFileExFlags (pythonrun.c:1177)
==31089==
[...]


Then I installed the curses from /usr/ports/devel/ncurses, and the
error didn't show up any more. I'm inclined to think that the bug is
in the system ncurses. Still, it would be nice to know why the import
order matters.

--

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Changes by Charles-Francois Natali :


--
nosy: +ezio.melotti

___
Python tracker 

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