From report at bugs.python.org  Fri Apr  1 03:00:17 2011
From: report at bugs.python.org (Eli Stevens)
Date: Fri, 01 Apr 2011 01:00:17 +0000
Subject: [New-bugs-announce] [issue11734] Add half-float (16-bit) support to
	struct module
In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>
Message-ID: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za>


New submission from Eli Stevens <wickedgrey at gmail.com>:

Numpy 1.6.0 adds support for a half-float (16-bit) data type, but
cannot currently export a buffer interface to the data since neither PEP 3118 nor the struct module (referenced by PEP 3118) support the data type.

I am proposing that the struct module be extended to support half floats, and will be providing a patch that implements that behavior.

The current numpy implementation (1.6.0b1) uses the 'e' character to indicate half floats; I don't have a vested interest in what character is used.  If consensus between CPython and numpy is reached for using a different character, I will update my patches (but I don't plan on participating in the bike shedding prior to that point).

For reference:

python-ideas thread:
http://mail.python.org/pipermail/python-ideas/2011-March/009650.html

numpy-discussion thread:
http://mail.scipy.org/pipermail/numpy-discussion/2011-March/055667.html

cython-user thread (less relevant to this issue specifically):
http://groups.google.com/group/cython-users/browse_thread/thread/6bf811409cdab89e

----------
components: Library (Lib)
messages: 132722
nosy: Eli.Stevens
priority: normal
severity: normal
status: open
title: Add half-float (16-bit) support to struct module
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  1 05:12:59 2011
From: report at bugs.python.org (mangeletti)
Date: Fri, 01 Apr 2011 03:12:59 +0000
Subject: [New-bugs-announce] [issue11735] Python Crash on strftime with %f
In-Reply-To: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>
Message-ID: <1301627579.13.0.817048852294.issue11735@psf.upfronthosting.co.za>


New submission from mangeletti <michael at angelettigroup.com>:

Win XP 32 bit 2.7.4

>>> import time
>>> time.strftime('%m/%d/%Y %H:%M:%S')
'03/31/2011 20:04:52'
>>> # ^^^ works fine
>>> time.strftime('%m/%d/%Y %H:%M:%S:%f')  # Oops, forgot `time.strftime` doesn't provide microseconds

Python crashes

Error Signature (sorry, didn't get full log):

AppName: python.exe	 AppVer: 0.0.0.0	 ModName: msvcr90.dll
ModVer: 9.0.30729.4148	 Offset: 0005bbac


I've never patched Python, but I might try to give it a whirl.

----------
components: Library (Lib)
messages: 132727
nosy: mangeletti
priority: normal
severity: normal
status: open
title: Python Crash on strftime with %f
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 14:49:56 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 01 Apr 2011 12:49:56 +0000
Subject: [New-bugs-announce] [issue11736] windows installers ssl module /
	openssl broken for some	sites
In-Reply-To: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>
Message-ID: <1301662196.21.0.598409652154.issue11736@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

(Probably the same root cause as issue11725 and using the same test case and analysis, but it seems like it isn't just somebody elses problem.)

Expected behaviour:

C:\Python26>python --version

Python 2.6.4


C:\Python26>python -c "import urllib2; urllib2.urlopen('https://www.finratrace.org')"

Traceback (most recent call last):

  File "<string>", line 1, in <module>

  File "C:\Python26\lib\urllib2.py", line 124, in urlopen

    return _opener.open(url, data, timeout)

  File "C:\Python26\lib\urllib2.py", line 395, in open

    response = meth(req, response)

  File "C:\Python26\lib\urllib2.py", line 508, in http_response

    'http', request, response, code, msg, hdrs)

  File "C:\Python26\lib\urllib2.py", line 433, in error

    return self._call_chain(*args)

  File "C:\Python26\lib\urllib2.py", line 367, in _call_chain

    result = func(*args)

  File "C:\Python26\lib\urllib2.py", line 516, in http_error_default

    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

urllib2.HTTPError: HTTP Error 403: Forbidden



but

	

C:\Python26>python --version

Python 2.6.5



C:\Python26>python -c "import urllib2; urllib2.urlopen('https://www.finratrace.org')"
(hangs...)

the same behaviour is seen on all following versions up to 2.7.1.

I guess the Python windows installer started to contain an openssl that changed something?

I think this has caused a number of strange Mercurial bug reports.

----------
components: Windows
messages: 132736
nosy: kiilerix
priority: normal
severity: normal
status: open
title: windows installers ssl module / openssl broken for some sites
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 16:22:56 2011
From: report at bugs.python.org (Iain Henderson)
Date: Fri, 01 Apr 2011 14:22:56 +0000
Subject: [New-bugs-announce] [issue11737] and is not a logical conjugation
In-Reply-To: <1301667776.1.0.962151448477.issue11737@psf.upfronthosting.co.za>
Message-ID: <1301667776.1.0.962151448477.issue11737@psf.upfronthosting.co.za>


New submission from Iain Henderson <the_iain at mac.com>:

The documentation here: http://docs.python.org/library/stdtypes.html
indicates that and operates as such
{if x:
    return x
else:
    return y}

to be a logical conjugation it should function as
{if x:
    if y:
        return True
return False}

The it is now (False and True) will return True.  Basic logic asserts that this is not the case.

----------
messages: 132740
nosy: the_iain
priority: normal
severity: normal
status: open
title: and is not a logical conjugation
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  1 17:55:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2011 15:55:36 +0000
Subject: [New-bugs-announce] [issue11738] ThreadSignals.test_signals() of
	test_threadsignals hangs	on PPC Tiger 3.x buildbot
In-Reply-To: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>
Message-ID: <1301673336.69.0.136519124397.issue11738@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Thanks to the new faulthandler module (#11393) and regrtest timeout (#11727, timeout of 15 minutes), I finally found why test_threadsignals hangs on PPC Tiger 3.x:
-------------------------------------
...
[ 25/354] test_threadsignals
Thread 0xa000ed88:
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 46 in test_signals
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 442 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1078 in run
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py", line 210 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1103.489396
-------------------------------------
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1685/steps/test/logs/stdio

test_threadsignals hangs at:
----------------
class ThreadSignals(unittest.TestCase):
    def test_signals(self):
        signalled_all.acquire()
        self.spawnSignallingThread()
        signalled_all.acquire() <~~~~ here
        ...
----------------

self.spawnSignallingThread() calls:
----------------
def send_signals():
    os.kill(process_pid, signal.SIGUSR1)
    os.kill(process_pid, signal.SIGUSR2)
    signalled_all.release()
----------------

Before fixing the bug, we can workaroung the hang in the test using a timeout on the second acquire.

This issue may be related to #11223.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh, Tests
keywords: buildbot
messages: 132748
nosy: haypo, pitrou, ronaldoussoren, sable
priority: normal
severity: normal
status: open
title: ThreadSignals.test_signals() of test_threadsignals hangs on PPC Tiger 3.x buildbot
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr  1 18:19:03 2011
From: report at bugs.python.org (Joaquin Sorianello)
Date: Fri, 01 Apr 2011 16:19:03 +0000
Subject: [New-bugs-announce] [issue11739] Python doesn't have a 2011 april
	fools joke
In-Reply-To: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>
Message-ID: <1301674743.91.0.697715232995.issue11739@psf.upfronthosting.co.za>


New submission from Joaquin Sorianello <joac at joac.com.ar>:

I found this bug today, and I am really sad.

We need to create a really good joke.
This languaje takes his name from "Monty Python Flying Circus" and IMHO this makes this languaje more funny.

I hope we can fix this for the next year.

Sorry if you considerate this a lost of time.

Best Regards

----------
components: None
messages: 132750
nosy: joac
priority: normal
severity: normal
status: open
title: Python doesn't have a 2011 april fools joke
type: feature request

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

From report at bugs.python.org  Fri Apr  1 23:25:39 2011
From: report at bugs.python.org (Michael O'Rourke)
Date: Fri, 01 Apr 2011 21:25:39 +0000
Subject: [New-bugs-announce] [issue11740] difflib html diff takes extremely
	long
In-Reply-To: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>
Message-ID: <1301693139.57.0.361562219135.issue11740@psf.upfronthosting.co.za>


New submission from Michael O'Rourke <mkorourk at adobe.com>:

If you try to difference the attached files with difflib and a html difference it take 10 minutes or more. In comparison other differencing tools like windiff and araxis merge will show the diff within a second.

Example code I'm using is:


sourceText = open("source.xml", "rU").readlines()
targetText = open("target.xml", "rU").readlines()

html_diff = difflib.HtmlDiff(tabsize=4)
result = html_diff.make_file(sourceText, targetText, "Source", "Target", context=True, numlines=10)
f = open('c:/libdiff_html.html', 'w')
f.write(result)
finish()

----------
components: None
files: Example.zip
messages: 132767
nosy: mkorourk at adobe.com
priority: normal
severity: normal
status: open
title: difflib html diff takes extremely long
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file21500/Example.zip

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

From report at bugs.python.org  Sat Apr  2 16:25:54 2011
From: report at bugs.python.org (Adam Matan)
Date: Sat, 02 Apr 2011 14:25:54 +0000
Subject: [New-bugs-announce] [issue11741] shutil2.copy fails with
	destination filenames
In-Reply-To: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>
Message-ID: <1301754354.21.0.769652184716.issue11741@psf.upfronthosting.co.za>


New submission from Adam Matan <adam at matan.name>:

shutil.copy2(file, dest) fails when dest has unicode characters:

[2011-04-02 17:19:54 adam at adam-laptop ~/personal :) ]$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import glob
>>> import shutil
>>> files=glob.glob('*.ods')
>>> for file in files:
...     shutil.copy2(file, '?') # This works, but:
...
>>> for file in files:
...     shutil.copy2(file, u'?')
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python2.6/shutil.py", line 98, in copy2
    dst = os.path.join(dst, os.path.basename(src))
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 1: ordinal not in range(128)


See discussion here: http://stackoverflow.com/questions/5523373/python-how-to-move-a-file-with-unicode-filename-to-a-unicode-folder/5523385#5523385

----------
components: Extension Modules
messages: 132799
nosy: Adam.Matan
priority: normal
severity: normal
status: open
title: shutil2.copy fails with destination filenames
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  2 17:42:11 2011
From: report at bugs.python.org (Andrew Sommerville)
Date: Sat, 02 Apr 2011 15:42:11 +0000
Subject: [New-bugs-announce] [issue11742] Possible bug in Python/import.c
In-Reply-To: <1301758931.53.0.147789887182.issue11742@psf.upfronthosting.co.za>
Message-ID: <1301758931.53.0.147789887182.issue11742@psf.upfronthosting.co.za>


New submission from Andrew Sommerville <aksommerville at gmail.com>:

Around line 1509 in Python/import.c, function "find_module", the importer is trying to fail with "No module named...". It is possible for "fp" to be NULL and "fdp" (the return value) to be non-NULL, which callers would see as success.

Solution: add "fdp=NULL;" to this block:
    if (fp == NULL) {
        PyErr_Format(PyExc_ImportError,
                     "No module named %.200s", name);
    }

(my apologies if this is not the correct place to post...)

----------
components: Interpreter Core
messages: 132803
nosy: aksommerville
priority: normal
severity: normal
status: open
title: Possible bug in Python/import.c
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  2 23:33:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Apr 2011 21:33:00 +0000
Subject: [New-bugs-announce] [issue11743] Rewrite PipeConnection and
	Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is a rewrite of multiprocessing.{PipeConnection,Connection} in pure Python, for ease of maintenance and improvement.

----------
components: Library (Lib)
files: mpconn.patch
keywords: patch
messages: 132816
nosy: asksol, brian.curtin, jnoller, pitrou, tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Rewrite PipeConnection and Connection in pure Python
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21506/mpconn.patch

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

From report at bugs.python.org  Sun Apr  3 03:51:12 2011
From: report at bugs.python.org (Vlastimil Brom)
Date: Sun, 03 Apr 2011 01:51:12 +0000
Subject: [New-bugs-announce] [issue11744] re.LOCALE doesn't reflect
	locale.setlocale(...)
In-Reply-To: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>
Message-ID: <1301795472.4.0.896243580236.issue11744@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

Hi,
I just noticed a behaviour of the re.LOCALE flag I can't understand; I first reported this to the new regex implementation, which, however, only mimics the standard lib re in this case:
http://code.google.com/p/mrab-regex-hg/issues/detail?id=6
I also couldn't find anything relevant in the tracker, other than some older, already fixed issues; I'm sorry, if I missed something.
I thought, the search pattern (?L)\w would match any of the respective string.letters according to the current locale (and possibly additionally [0-9_]).

However, the locale doesn't seem to be reflected in an expected way.

>>> unicode_BMP = " " + "".join(unichr(i)for i in range(1, 0x10000))
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> import re
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> locale.setlocale(locale.LC_ALL, "Greek")
'Greek_Greece.1253'
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz?????????????????????????????????????????????????????????????????????????
>>> 

>>> unicode_BMP = " " + "".join(unichr(i)for i in range(1, 0x10000))

>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> print unicode(string.letters, "windows-1250")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> locale.setlocale(locale.LC_ALL, "Greek")
'Greek_Greece.1253'
>>> print unicode(string.letters, "windows-1253")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz???????????????????????????????????????????????????????????????????????
>>> 

It seems that the nearest letter set to the result of the re/regex LOCALE flags migt be ascii or US locale:

>>> locale.setlocale(locale.LC_ALL, "US")
'English_United States.1252'
>>> print unicode(string.letters, "windows-1252")
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz?????????????????????????????????????????????????????????????????????????
>>> 

however, there are some differences too, namely between z? and ?
re (?L)\w : 
Czech
z??????????????????????
Greek
z????????????
string.letters -- US locale
z????????????
(as displayed in tkinter Idle shell)
(in either case, there are some items, one wouldn't consider usual word characters, cf. ?)

I am not sure whether there are no other issues (like some encoding/displaying peculiarities in Tkinter), but the re matching using the LOCALE flag don't reflect the locale.setlocale(...) in a transparent way.

Is it supposed to work this way and is there another possibility to get the expected locale aware matching, as one might expect according to:
http://docs.python.org/library/re.html#re.LOCALE
"""
Make \w, \W, \b, \B, \s and \S dependent on the current locale.
"""


using Python 2.7.1, 32 bit;  win 7 Home Premium 64-bit, Czech.

in Python 3.1.3 as well as 3.2 the result is the same (with the appropriately modified code): ...
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'Czech_Czech Republic.1250'
>>> import re
>>> print("".join(re.findall(r"(?L)\w", unicode_BMP)))
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz??????????????????????????????????????????????????????????????????????????????????
>>> 

However, in Python 3, there is no comparison with string.letters available anymore.

Regards,
    Vlastimil Brom

----------
components: Regular Expressions, Unicode
messages: 132826
nosy: vbr
priority: normal
severity: normal
status: open
title: re.LOCALE doesn't reflect locale.setlocale(...)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Apr  3 04:52:36 2011
From: report at bugs.python.org (Denver Coneybeare)
Date: Sun, 03 Apr 2011 02:52:36 +0000
Subject: [New-bugs-announce] [issue11745] idlelib/PyShell.py: incorrect
	module name reported in	error message: Tkinter should be tkinter
In-Reply-To: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>
Message-ID: <1301799156.61.0.675938234599.issue11745@psf.upfronthosting.co.za>


New submission from Denver Coneybeare <denver.coneybeare at gmail.com>:

Just a very minor bug.  The error message in idlelib/PyShell.py that is printed when importing tkinter fails says that it failed to import "Tkinter", but the actual module name is "tkinter" (with a lowercase t).  

try:
    from tkinter import *
except ImportError:
    print("** IDLE can't import Tkinter.  " \
          "Your Python may not be configured for Tk. **", file=sys.__stderr__)

A patch is attached.

----------
components: IDLE
messages: 132828
nosy: denversc
priority: normal
severity: normal
status: open
title: idlelib/PyShell.py: incorrect module name reported in error message: Tkinter should be tkinter
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 05:20:12 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 03 Apr 2011 03:20:12 +0000
Subject: [New-bugs-announce] [issue11746] ssl library load_cert_chain cannot
	use elliptic curve	type private key
In-Reply-To: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>
Message-ID: <1301800812.36.0.988775171179.issue11746@psf.upfronthosting.co.za>


New submission from umedoblock <umedoblock at gmail.com>:

ssl library load_cert_chain cannot use elliptic curve type private key.

I resolved the problem, I attached patch file

----------
components: Library (Lib)
files: _ssl.c.diff
keywords: patch
messages: 132830
nosy: umedoblock
priority: normal
severity: normal
status: open
title: ssl library load_cert_chain cannot use elliptic curve type private key
versions: Python 3.2
Added file: http://bugs.python.org/file21513/_ssl.c.diff

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

From report at bugs.python.org  Sun Apr  3 06:57:16 2011
From: report at bugs.python.org (Jan Koprowski)
Date: Sun, 03 Apr 2011 04:57:16 +0000
Subject: [New-bugs-announce] [issue11747] unified_diff function product
	incorrect range information
In-Reply-To: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>
Message-ID: <1301806636.68.0.728514553962.issue11747@psf.upfronthosting.co.za>


New submission from Jan Koprowski <jan.koprowski at gmail.com>:

Python:
---------------------------
>>> import difflib
>>> dl = difflib.unified_diff([], ['a\n', 'b\n'])
>>> print ''.join(dl),
---
+++
@@ -1,0 +1,2 @@
+a
+b

Gnu diff:
---------------------------
$diff -uN a b
--- a   1970-01-01 01:00:00.000000000 +0100
+++ b   2011-04-03 06:56:28.330543000 +0200
@@ -0,0 +1,2 @@
+a
+b

----------
components: Library (Lib)
messages: 132832
nosy: jan.koprowski
priority: normal
severity: normal
status: open
title: unified_diff function product incorrect range information
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  3 18:06:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:06:54 +0000
Subject: [New-bugs-announce] [issue11748] test_ftplib failure in test for
	source_address
In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>
Message-ID: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

See http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2475/steps/test/logs/stdio


test test_ftplib failed -- Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 622, in test_source_address_passive_connection
    with self.client.transfercmd('list') as sock:
  File "D:\Buildslave\3.x.moore-windows\build\lib\ftplib.py", line 379, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "D:\Buildslave\3.x.moore-windows\build\lib\ftplib.py", line 344, in ntransfercmd
    source_address=self.source_address)
  File "D:\Buildslave\3.x.moore-windows\build\lib\socket.py", line 407, in create_connection
    raise err
  File "D:\Buildslave\3.x.moore-windows\build\lib\socket.py", line 397, in create_connection
    sock.bind(source_address)
socket.error: [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

----------
assignee: giampaolo.rodola
components: Library (Lib), Tests
messages: 132849
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib failure in test for source_address
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 18:08:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 16:08:33 +0000
Subject: [New-bugs-announce] [issue11749] test_socket failure
In-Reply-To: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>
Message-ID: <1301846913.96.0.368639647794.issue11749@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2473/steps/test/logs/stdio

======================================================================
FAIL: testSmallReadNonBlocking (test.test_socket.UnbufferedFileObjectClassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_socket.py", line 1416, in testSmallReadNonBlocking
    self.assertEqual(n, 3)
AssertionError: None != 3

----------
components: Library (Lib), Tests
messages: 132851
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socket failure
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr  3 20:50:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 18:50:29 +0000
Subject: [New-bugs-announce] [issue11750] Mutualize win32 functions
In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>
Message-ID: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

subprocess and multiprocessing both have their own private modules for wrappers of win32 functions: Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c.

It would be nice to group them in a common module (_win32?) that could be used throughout the stdlib.

----------
components: Extension Modules, Windows
messages: 132868
nosy: asksol, brian.curtin, gregory.p.smith, jnoller, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: Mutualize win32 functions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:07:38 2011
From: report at bugs.python.org (Justin Love)
Date: Sun, 03 Apr 2011 19:07:38 +0000
Subject: [New-bugs-announce] [issue11751] Increase distutils/filelist test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>


New submission from Justin Love <python at JustinLove.name>:

Increase test coverage of distutils/filelist.py from 49% to 100%.  One line was marked as excluded because it was a "this cannot happen" error, and I agreed.

----------
components: Tests
files: increase_distutils_filelist_test_coverage.patch
keywords: patch
messages: 132869
nosy: jlove
priority: normal
severity: normal
status: open
title: Increase distutils/filelist test coverage
type: behavior
Added file: http://bugs.python.org/file21518/increase_distutils_filelist_test_coverage.patch

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

From report at bugs.python.org  Sun Apr  3 21:43:15 2011
From: report at bugs.python.org (gungor)
Date: Sun, 03 Apr 2011 19:43:15 +0000
Subject: [New-bugs-announce] [issue11752] Gungor Basa wants to stay in touch
	on LinkedIn
In-Reply-To: <2042837526.1662080.1301859792311.JavaMail.app@ela4-bed37.prod>
Message-ID: <2042837526.1662080.1301859792311.JavaMail.app@ela4-bed37.prod>


New submission from gungor <gungorbasa at gmail.com>:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Gungor Basa

Gungor Basa
Computer Engineer at CYMSOFT 
Turkey

Confirm that you know Gungor Basa
https://www.linkedin.com/e/-3qcne3-gm2dpgol-1s/isd/2626190363/ywqIa-UZ/

----------
files: unnamed
messages: 132870
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Gungor Basa wants to stay in touch on LinkedIn
Added file: http://bugs.python.org/file21519/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11752>
_______________________________________
-------------- next part --------------

<html>
  <body>

  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>

<div style="font:13px arial, sans-serif; width:540px">  
    
    <p>
      Python,<br/>
<br/>
I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Gungor Basa
    </p>
    
    <table cellpadding="0" cellspacing="0" style="margin-bottom: 10px;">
      <tr>
          <td style="width: 50px;">
              <IMG style="padding: 5px;" src="http://media.linkedin.com/media/p/3/000/052/363/21bbe9e.jpg" class="photo" width="40" height="40">
          </td>
        <td style="font: 13px arial, sans-serif; width: 490px;">
          <div style="padding: 5px 5px 5px 0">
            Gungor Basa<br>
                Computer Engineer at CYMSOFT 
            <br>
                    Turkey
          </div>
          </div>
        </td>
      </tr>
    </table>

    <p>
              <a style="background-color:#ffcc00; display:inline-block; border-right: 1px solid #7a5a20; border-bottom: 1px solid #7a5a20; padding:10px; text-decoration: none; color: #000; text-align: center; white-space:none; font-weight: bold;" href="https://www.linkedin.com/e/-3qcne3-gm2dpgol-1s/isd/2626190363/ywqIa-UZ/EML-invg_59/">Confirm that you know Gungor</a>
    </p>
</div>



  <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">&#169; 2011, LinkedIn Corporation</p>
  
<img src="http://www.linkedin.com/emimp/-3qcne3-gm2dpgol-1s.gif" style="width:1px; height:1px;"/></body>
</html>

From report at bugs.python.org  Sun Apr  3 21:44:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 19:44:53 +0000
Subject: [New-bugs-announce] [issue11753] test_sendall_interrupted() of
	test_socket hangs on	FreeBSD
In-Reply-To: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>
Message-ID: <1301859893.52.0.614181082416.issue11753@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I added a timeout of 30 minutes to regrtest. On "x86 FreeBSD 7.2 3.x" and "x86 FreeBSD 3.x" buildbot, test_sendall_interrupted() of test_socket does timeout after 30 minutes:
----------
...
[201/354] test_socket
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 729 in check_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 740 in test_sendall_interrupted
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 2052 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
----------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1644/steps/test/logs/stdio
another example:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1344/steps/test/logs/stdio

It looks like the test should be done in less than 5 seconds. Extract of the code (with_timeout=False for test_sendall_interrupted):
-------------------------
def check_sendall_interrupted(self, with_timeout):
        # socketpair() is not stricly required, but it makes things easier.
        if not hasattr(signal, 'alarm') or not hasattr(socket, 'socketpair'):
            self.skipTest("signal.alarm and socket.socketpair required for this test")
        # Our signal handlers clobber the C errno by calling a math function
        # with an invalid domain value.
        def ok_handler(*args):
            self.assertRaises(ValueError, math.acosh, 0)
        def raising_handler(*args):
            self.assertRaises(ValueError, math.acosh, 0)
            1 // 0
        c, s = socket.socketpair()
        old_alarm = signal.signal(signal.SIGALRM, raising_handler)
        try:
            if with_timeout:
                # Just above the one second minimum for signal.alarm
                c.settimeout(1.5)
            with self.assertRaises(ZeroDivisionError):
                signal.alarm(1)
                c.sendall(b"x" * (1024**2)) <~~~~ HERE
            if with_timeout:
                signal.signal(signal.SIGALRM, ok_handler)
                signal.alarm(1)
                self.assertRaises(socket.timeout, c.sendall, b"x" * (1024**2))
        finally:
            signal.signal(signal.SIGALRM, old_alarm)
            c.close()
            s.close()
-------------------------
I suppose that sendall() should be interrupted by SIGALRM. sendall() calls PyErr_CheckSignals() after each system call to send(), and exits with an error if PyErr_CheckSignals() returns NULL. If send() fails with EINTR error, sendall() retries calls send() again (in a loop).

I don't know if this hang is new or not, and if it is (or not) a border effect of the timeout feature of regrtest...

But test_signal don't always fail, it looks like a race condition.

----------
components: Library (Lib)
messages: 132871
nosy: haypo
priority: normal
severity: normal
status: open
title: test_sendall_interrupted() of test_socket hangs on FreeBSD
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  3 21:52:27 2011
From: report at bugs.python.org (Lynne Qu)
Date: Sun, 03 Apr 2011 19:52:27 +0000
Subject: [New-bugs-announce] [issue11754] Changed test to check calculated
	constants in	test_string.py
In-Reply-To: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>
Message-ID: <1301860347.11.0.319603986002.issue11754@psf.upfronthosting.co.za>


New submission from Lynne Qu <lynne.qu at gmail.com>:

Changed test to check calculated constants in test_string.py

----------
components: Tests
files: test_calculated_constants.diff
keywords: patch
messages: 132874
nosy: Lynne.Qu
priority: normal
severity: normal
status: open
title: Changed test to check calculated constants in test_string.py
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file21520/test_calculated_constants.diff

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

From report at bugs.python.org  Sun Apr  3 21:56:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2011 19:56:50 +0000
Subject: [New-bugs-announce] [issue11755] test_itimer_real() of test_signal
	hang on FreeBSD
In-Reply-To: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>
Message-ID: <1301860610.2.0.465861463042.issue11755@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_itimer_real() of test_signal hang 30 minutes on FreeBSD "x86 FreeBSD 3.x" and "x86 FreeBSD 7.2 3.x" buildbots. Example:
----------------------------
...
[ 95/354] test_signal
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 436 in test_itimer_real
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_signal.py", line 490 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
*** Error code 1

Stop in /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build.
program finished with exit code 1
elapsedTime=4160.495190
----------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1645/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1345/steps/test/logs/stdio

I don't know if this issue is new or not, and if it is (or not) related to the new regrtest timeout.

See also issue #11753, another signal issue on FreeBSD.

----------
components: Library (Lib)
messages: 132875
nosy: haypo
priority: normal
severity: normal
status: open
title: test_itimer_real() of test_signal hang on FreeBSD
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 00:02:19 2011
From: report at bugs.python.org (David Albert Torpey)
Date: Sun, 03 Apr 2011 22:02:19 +0000
Subject: [New-bugs-announce] [issue11756] bytes.hex()
In-Reply-To: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>
Message-ID: <1301868139.62.0.934615407924.issue11756@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

Floats have fromhex() and hex() to round-trip from and to hexadecimal, but bytes only have fromhex(), so it's hard to reliably round-trip.

----------
messages: 132892
nosy: dtorp
priority: normal
severity: normal
status: open
title: bytes.hex()
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 00:28:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Apr 2011 22:28:25 +0000
Subject: [New-bugs-announce] [issue11757] test_subprocess failure
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/904/steps/test/logs/stdio :

test test_subprocess failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 452, in test_communicate_timeout_large_ouput
    self.assertRaises(subprocess.TimeoutExpired, p.communicate, timeout=0.4)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 574, in assertRaises
    callableObj(*args, **kwargs)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 846, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 1539, in _communicate
    orig_timeout)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/subprocess.py", line 1670, in _communicate_with_select
    self._remaining_time(endtime))
select.error: (22, 'Invalid argument')

Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 32] Broken pipe

----------
components: Library (Lib), Tests
messages: 132898
nosy: gregory.p.smith, pitrou, rnk
priority: normal
severity: normal
stage: needs patch
status: open
title: test_subprocess failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 06:47:14 2011
From: report at bugs.python.org (mdorn)
Date: Mon, 04 Apr 2011 04:47:14 +0000
Subject: [New-bugs-announce] [issue11758] increase xml.dom.minidom test
	coverage
In-Reply-To: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>
Message-ID: <1301892434.54.0.122832391998.issue11758@psf.upfronthosting.co.za>


New submission from mdorn <matt.dorn at gmail.com>:

Added some tests to ensure xml.dom.NotFoundErr where appropriate, and for a handful of previously untested methods.  Increased coverage from 52% to 53%.

----------
components: Tests, XML
files: increase_minidom_test_coverage.patch
keywords: patch
messages: 132915
nosy: mdorn
priority: normal
severity: normal
status: open
title: increase xml.dom.minidom test coverage
versions: Python 3.3
Added file: http://bugs.python.org/file21526/increase_minidom_test_coverage.patch

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

From report at bugs.python.org  Mon Apr  4 08:49:15 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 04 Apr 2011 06:49:15 +0000
Subject: [New-bugs-announce] [issue11759] assert for exception parameters
In-Reply-To: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>
Message-ID: <1301899755.88.0.769835930918.issue11759@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I've just realized that unittest doesn't provide a way to test arguments of exception thrown during assertRaises check.

----------
components: Tests
messages: 132919
nosy: techtonik
priority: normal
severity: normal
status: open
title: assert for exception parameters

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

From report at bugs.python.org  Mon Apr  4 12:15:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Apr 2011 10:15:34 +0000
Subject: [New-bugs-announce] [issue11760] Bus error in test_big_buffer() of
	test_zlib on "AMD64	Snow Leopard 3.x" buildbot
In-Reply-To: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>
Message-ID: <1301912134.97.0.847966944656.issue11760@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Trace:
--------------------
...
[ 79/354] test_time
[ 80/354] test_zlib
Fatal Python error: Bus error

Traceback (most recent call first):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 85 in test_big_buffer
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py", line 611 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Bus error
program finished with exit code 2
elapsedTime=1400.363321
--------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/44/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 132927
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Bus error in test_big_buffer() of test_zlib on "AMD64 Snow Leopard 3.x" buildbot
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 12:54:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 10:54:08 +0000
Subject: [New-bugs-announce] [issue11761] fragile tests in test_gc
In-Reply-To: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>
Message-ID: <1301914448.96.0.658655701177.issue11761@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4329/steps/test/logs/stdio

======================================================================
FAIL: test_collect_generations (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1142, in wrapper
    return func(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_gc.py", line 269, in test_collect_generations
    assertEqual(gc.get_count(), (0, 0, 0))
AssertionError: Tuples differ: (3, 0, 0) != (0, 0, 0)

First differing element 0:
3
0

- (3, 0, 0)
+ (0, 0, 0)

======================================================================
FAIL: test_get_count (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1142, in wrapper
    return func(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_gc.py", line 252, in test_get_count
    assertEqual(gc.get_count(), (0, 0, 0))
AssertionError: (4, 0, 0) != (0, 0, 0)

----------------------------------------------------------------------

----------
components: Tests
messages: 132929
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: fragile tests in test_gc
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 18:16:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2011 16:16:01 +0000
Subject: [New-bugs-announce] [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Two related proposals.

1. Add a warning similar to the one for the dis module. As modified:

"CPython implementation detail: The ast definition is specific to the CPython interpreter! Ast nodes may be added, removed, or changed between versions. Use *ast.__version__* to work across versions."

I omitted " Use of this module should not be considered to work across Python VMs or Python releases." as redundant and too legalistic.
*ast.__version__* should link to its (new) entry).

2. Add a full entry for __version__. Currently (3.2):

"The module defines a string constant __version__ which is the decimal Subversion revision number of the file shown below."

Proposed replacement (with hidden reference point):

ast.__version__         [__version__ in normal entry boldface]
    String constant with version number of abstract grammar file.
    3.1: 67616; 3.2: 82163; 3.3: xxxxxxxxx

----------
assignee: docs at python
components: Documentation
messages: 132951
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Ast doc: warning and version number
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 22:16:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 04 Apr 2011 20:16:04 +0000
Subject: [New-bugs-announce] [issue11763] assertEqual memory issues with
	large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

>>> s = "x" * (2**29)
>>> case.assertEqual(s + "a", s + "b")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 643,
in assertEqual assertion_func(first, second, msg=msg)
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 984,
in assertMultiLineEqual secondlines = [second + '\n']
MemoryError

assertEqual delegates to assertMultilineEqual for comparing text which uses difflib for comparisons. This has performance issues (as well as memory issues) for very large inputs, so should fallback to a simple comparison (or simpler diff generation technique) for very large inputs.

----------
assignee: michael.foord
messages: 132965
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
status: open
title: assertEqual memory issues with large text inputs
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 22:35:22 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 04 Apr 2011 20:35:22 +0000
Subject: [New-bugs-announce] [issue11764] inspect.getattr_static code
	execution w/ class body as	non dict
In-Reply-To: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>
Message-ID: <1301949322.52.0.106729359313.issue11764@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 3 a metclass can create a class __dict__ that is not a true dictionary. This can trigger code execution when accessing __dict__ members. getattr_static should not access them directly but do so using dict methods directly for dict subclasses and skipping classes that have non-dicts for __dict__.

The documentation should mention explicitly that the "no code execution" feature of this function is *not* a security feature and should not be relied on for security purposes.

----------
assignee: michael.foord
components: Library (Lib)
messages: 132967
nosy: michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: inspect.getattr_static code execution w/ class body as non dict
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  4 23:08:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 21:08:57 +0000
Subject: [New-bugs-announce] [issue11765] test_faulthandler failure
In-Reply-To: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>
Message-ID: <1301951337.94.0.471175067329.issue11765@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4334/steps/test/logs/stdio

======================================================================
FAIL: test_dump_tracebacks_later (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 420, in test_dump_tracebacks_later
    self.check_dump_tracebacks_later()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 404, in _check_dump_tracebacks_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>$' not found in 'Thread 0x00000100:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nTraceback (most recent call last):\n  File "<string>", line 27, in <module>\n  File "<string>", line 16, in func\nAssertionError: 0.997999906539917 < 1.125'

======================================================================
FAIL: test_dump_tracebacks_later_cancel (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 426, in test_dump_tracebacks_later_cancel
    self.check_dump_tracebacks_later(cancel=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 406, in _check_dump_tracebacks_later
    self.assertEqual(trace, '')
AssertionError: 'Traceback (most recent call last):\n  File "<string>", line 27, in <module>\n   [truncated]... != ''
- Traceback (most recent call last):
-   File "<string>", line 27, in <module>
-   File "<string>", line 16, in func
- AssertionError: 0.9980001449584961 < 1.125

======================================================================
FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 429, in test_dump_tracebacks_later_file
    self.check_dump_tracebacks_later(file=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 415, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, filename)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 394, in _check_dump_tracebacks_later
    trace, exitcode = self.get_output(code, filename)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 61, in get_output
    self.assertEqual(output, '')
AssertionError: 'Traceback (most recent call last):\n  File "<string>", line 27, in <module>\n   [truncated]... != ''
- Traceback (most recent call last):
-   File "<string>", line 27, in <module>
-   File "<string>", line 16, in func
- AssertionError: 0.9980001449584961 < 1.125
- sys:1: ResourceWarning: unclosed file <_io.BufferedWriter name='c:\\docume~1\\db3l\\locals~1\\temp\\tmph6ch7_'>

======================================================================
FAIL: test_dump_tracebacks_later_repeat (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 423, in test_dump_tracebacks_later_repeat
    self.check_dump_tracebacks_later(repeat=True)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 417, in check_dump_tracebacks_later
    self._check_dump_tracebacks_later(repeat, cancel, None)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_faulthandler.py", line 404, in _check_dump_tracebacks_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Thread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nThread 0x[0-9a-f]+:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>$' not found in 'Thread 0x00000ff4:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nThread 0x00000ff4:\n  File "<string>", line 12 in func\n  File "<string>", line 27 in <module>\nTraceback (most recent call last):\n  File "<string>", line 27, in <module>\n  File "<string>", line 16, in func\nAssertionError: 0.9700000286102295 < 1.125'

----------
assignee: haypo
components: Tests
keywords: buildbot
messages: 132970
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_faulthandler failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  4 23:31:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Apr 2011 21:31:27 +0000
Subject: [New-bugs-announce] [issue11766] test_multiprocessing failure
	(test_pool_worker_lifetime)
In-Reply-To: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>
Message-ID: <1301952687.8.0.704166844851.issue11766@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This sometimes happens on the buildbots:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 1191, in test_pool_worker_lifetime
    self.assertNotIn(None, finalworkerpids)
AssertionError: None unexpectedly found in [1788, 3984, None]

e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4334/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 132974
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
status: open
title: test_multiprocessing failure (test_pool_worker_lifetime)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr  5 01:11:10 2011
From: report at bugs.python.org (Brendan Dolan-Gavitt)
Date: Mon, 04 Apr 2011 23:11:10 +0000
Subject: [New-bugs-announce] [issue11767] Maildir iterator leaks file
	descriptors by default
In-Reply-To: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>
Message-ID: <1301958670.39.0.218079408331.issue11767@psf.upfronthosting.co.za>


New submission from Brendan Dolan-Gavitt <brendandg at gatech.edu>:

The default constructor for Maildir is rfc822.Message. This means that when iterating over a Maildir mailbox instantiated with default settings, the Mailbox class will return self._factory(self.get_file(key)), leaking the file descriptor returned by get_file(). Thus, iterating over any reasonably sized maildir mailbox will cause file descriptors to be leaked, and if a non-refcounting GC is used (as in PyPy), it is very likely that the process will run out of file descriptors.

I see that the default has changed to None, for Py3k, but this still means that using a message factory unavoidably leaks file descriptors. Ideally, I'd like the Mailbox class to close the file descriptor passed into the factory; this would mean that file descriptors are never leaked during iteration.

----------
components: Library (Lib)
messages: 132988
nosy: moyix
priority: normal
severity: normal
status: open
title: Maildir iterator leaks file descriptors by default
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr  5 02:19:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:19:17 +0000
Subject: [New-bugs-announce] [issue11768] test_signals() of
	test_threadsignals failure on Mac OS X	Tiger
In-Reply-To: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>
Message-ID: <1301962757.99.0.598461435574.issue11768@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_threadsignals hangs on "x86 Tiger 3.x" and "PPC Tiger 3.x":
---------------------
[279/354] test_threadsignals
Thread 0xa000d000:
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py", line 46 in test_signals
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 442 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1078 in run
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py", line 210 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=3365.320090
---------------------
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2289/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1700/steps/test/logs/stdio

test_threadsignals hangs at:
----------------
class ThreadSignals(unittest.TestCase):
    def test_signals(self):
        signalled_all.acquire()
        self.spawnSignallingThread()
        signalled_all.acquire() <~~~~ here
----------------

self.spawnSignallingThread() calls:
----------------
def send_signals():
    os.kill(process_pid, signal.SIGUSR1)
    os.kill(process_pid, signal.SIGUSR2)
    signalled_all.release()
----------------

The hang may be related to regrtest timeout: faulthandler had a bug, but the bug is supposed to be fixed (#11753, #11755).

See also issue #11223.

----------
components: Library (Lib)
messages: 132993
nosy: haypo
priority: normal
severity: normal
status: open
title: test_signals() of test_threadsignals failure on Mac OS X Tiger
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 02:45:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 00:45:30 +0000
Subject: [New-bugs-announce] [issue11769] test_notify() of test_threading
	hang on "x86 XP-4 3.x":
In-Reply-To: <1301964330.57.0.512119675756.issue11769@psf.upfronthosting.co.za>
Message-ID: <1301964330.57.0.512119675756.issue11769@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Timeout of 15 minutes on "x86 XP-4 3.x":
----------------------------
...
[334/354] test_threading
Thread 0x0000024c:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x000002d8:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000da4:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line 235 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 392 in f
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 37 in task

Thread 0x00000bb0:
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 16 in _wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 416 in _check_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\lock_tests.py", line 433 in test_notify
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 387 in _executeTestPart
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 442 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 494 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 105 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 67 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1078 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1166 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support.py", line 1192 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_threading.py", line 728 in test_main
  File "../lib/test/regrtest.py", line 1032 in runtest_inner
  File "../lib/test/regrtest.py", line 826 in runtest
  File "../lib/test/regrtest.py", line 650 in main
  File "../lib/test/regrtest.py", line 1607 in <module>
s_push: parser stack overflow
program finished with exit code 1
elapsedTime=2601.059000
----------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4317/steps/test/logs/stdio

Hum, it looks like we have 4 threads, and all threads are waiting.

=> See issue #8799 and maybe also #4188 and #5114.

----------
components: Library (Lib)
messages: 132998
nosy: haypo
priority: normal
severity: normal
status: open
title: test_notify() of test_threading hang on "x86 XP-4 3.x":
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 13:08:55 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 05 Apr 2011 11:08:55 +0000
Subject: [New-bugs-announce] [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

A version of dir that returns all the members that can be seen by getattr_static.

----------
assignee: michael.foord
components: Library (Lib)
messages: 133017
nosy: michael.foord
priority: low
severity: normal
stage: needs patch
status: open
title: inspect.dir_static
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 13:49:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Apr 2011 11:49:42 +0000
Subject: [New-bugs-announce] [issue11771] hashlib object cannot be pickled
In-Reply-To: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>
Message-ID: <1302004182.5.0.155912208324.issue11771@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

$ ./python 
Python 3.3a0 (default:76ed6a061ebe, Apr  5 2011, 12:25:00) 
>>> import hashlib, pickle
>>> hash=hashlib.new('md5')
>>> pickle.dumps(hash)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class '_hashlib.HASH'>: attribute lookup _hashlib.HASH failed

The problem is that _hashlib.HASH is not accessible at Python level. There is a C define to make it accessible, but it is disabled by default: "#if HASH_OBJ_CONSTRUCTOR". This test is as old as the _hashlib module (#1121611, 624918e1c1b2).

----------
components: Library (Lib)
messages: 133021
nosy: haypo
priority: normal
severity: normal
status: open
title: hashlib object cannot be pickled
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  5 15:33:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2011 13:33:13 +0000
Subject: [New-bugs-announce] [issue11772] email header wrapping edge case
	failure
In-Reply-To: <1302010393.33.0.35644236516.issue11772@psf.upfronthosting.co.za>
Message-ID: <1302010393.33.0.35644236516.issue11772@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I discovered the attached failure case in the process of investigating another issue.  The bug (a continuation line with no leading white space) doesn't exist in 2.7, but in 2.7 the extra whitespace is not preserved (that is, the output of the new test looks just like the output of the Face2 test), which is consistent with email4's handling of header whitespace in general.

----------
assignee: r.david.murray
components: Library (Lib)
files: test_email_extra_test.patch
keywords: patch
messages: 133029
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email header wrapping edge case failure
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21542/test_email_extra_test.patch

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

From report at bugs.python.org  Tue Apr  5 17:18:59 2011
From: report at bugs.python.org (Abhijeet Rastogi)
Date: Tue, 05 Apr 2011 15:18:59 +0000
Subject: [New-bugs-announce] [issue11773] Unicode compared using "is"
	results in abnormal behavior
In-Reply-To: <1302016739.97.0.129069075348.issue11773@psf.upfronthosting.co.za>
Message-ID: <1302016739.97.0.129069075348.issue11773@psf.upfronthosting.co.za>


New submission from Abhijeet Rastogi <abhijeet.1989 at gmail.com>:

>>> a = u'0'
>>> a is u'0'
False
>>> a == u'0'
True
>>>

----------
components: Unicode
messages: 133038
nosy: shadyabhi
priority: normal
severity: normal
status: open
title: Unicode compared using "is" results in abnormal behavior
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  5 20:13:46 2011
From: report at bugs.python.org (Carsten Klein)
Date: Tue, 05 Apr 2011 18:13:46 +0000
Subject: [New-bugs-announce] [issue11774] Issue tracker sends notification
	mails twice...
In-Reply-To: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>
Message-ID: <1302027226.99.0.081276499304.issue11774@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

Currently I am receiving duplicates of the notification mails by your issue tracker.

----------
messages: 133062
nosy: carsten.klein at axn-software.de
priority: normal
severity: normal
status: open
title: Issue tracker sends notification mails twice...

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

From report at bugs.python.org  Tue Apr  5 20:57:11 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 05 Apr 2011 18:57:11 +0000
Subject: [New-bugs-announce] [issue11775] `bool(Counter({'a': 0'})) is True`
In-Reply-To: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>
Message-ID: <1302029831.74.0.558006617631.issue11775@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

bool(Counter({'a': 0'})) is True.

Is this wise? I want to be able to do:

    if my_counter:
        whatever

To check whether my counter has any elements. Currently this seems to be impossible because of this bug.

Will we have to keep this weird behavior because of backwards compatibility? If so, perhaps `.elements` could be turned into a smart object so we could at least do `if my_counter.elements():` and get the expected result.

If you want a patch let me know and I'll write one.

----------
components: Library (Lib)
messages: 133076
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `bool(Counter({'a': 0'})) is True`
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  5 22:53:25 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Apr 2011 20:53:25 +0000
Subject: [New-bugs-announce] [issue11776] types.MethodType() params and
	usage is not documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

types.MethodType(function, instance) is used as a replacement for new.instancemethod(function, instance, class), but this usage is not documented.

----------
assignee: docs at python
components: Documentation
messages: 133089
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: types.MethodType() params and usage is not documented
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr  6 03:16:35 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Apr 2011 01:16:35 +0000
Subject: [New-bugs-announce] [issue11777] Executor.map does not submit
	futures until iter.next()	is called
In-Reply-To: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>
Message-ID: <1302052595.78.0.918161508373.issue11777@psf.upfronthosting.co.za>


New submission from Brian Quinlan <brian at sweetapp.com>:

from concurrent import futures

with futures.ThreadPoolExecutor(max_workers=5) as e:
  e.map(print, range(10))

# No output

----------
assignee: bquinlan
components: Library (Lib)
messages: 133104
nosy: bquinlan
priority: normal
severity: normal
status: open
title: Executor.map does not submit futures until iter.next() is called
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 08:33:01 2011
From: report at bugs.python.org (xBrawny)
Date: Wed, 06 Apr 2011 06:33:01 +0000
Subject: [New-bugs-announce] [issue11778] __subclasscheck__ : class P(M):
	__metaclass__=M causes	maximum recursion depth exceeded.
In-Reply-To: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>
Message-ID: <1302071581.19.0.711337712085.issue11778@psf.upfronthosting.co.za>


New submission from xBrawny <andrei at newthot.com>:

I wonder if this is the desired behavior. According to docs, __instancecheck__ should be called,  but it never gets to it. If "return True" is replaced with "raise Exception" the result is the same.
=========================================
class M(type):
    def __instancecheck__(cls,obj):
        return True
    
class P(M):
    __metaclass__=M

isinstance(object,P)
========================================
    isinstance(object,P)
RuntimeError: maximum recursion depth exceeded while calling a Python object

----------
components: Interpreter Core
messages: 133110
nosy: xBrawny
priority: normal
severity: normal
status: open
title: __subclasscheck__ :  class P(M): __metaclass__=M causes maximum recursion depth exceeded.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  6 09:59:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Apr 2011 07:59:22 +0000
Subject: [New-bugs-announce] [issue11779] test_mmap timeout (30 min) on
	"AMD64 Snow Leopard 3.x"	buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The creation of a file of 5.25 GB took more than 30 min on "AMD64 Snow Leopard 3.x" buildbot, and so regrtest exited:
-----------------
[ 27/354] test_mmap
Thread 0x00007fff70439ca0:
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 685 in test_large_offset
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 442 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py", line 494 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 105 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1078 in run
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1166 in _run_suite
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py", line 1192 in run_unittest
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py", line 706 in test_main
  File "./Lib/test/regrtest.py", line 1032 in runtest_inner
  File "./Lib/test/regrtest.py", line 826 in runtest
  File "./Lib/test/regrtest.py", line 650 in main
  File "./Lib/test/regrtest.py", line 1607 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1909.711111
-----------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/46/steps/test/logs/stdio

----------
components: Tests
messages: 133115
nosy: haypo
priority: normal
severity: normal
status: open
title: test_mmap timeout (30 min) on "AMD64 Snow Leopard 3.x" buildbot
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 13:04:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 11:04:58 +0000
Subject: [New-bugs-announce] [issue11780] email.encoders are broken
In-Reply-To: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>
Message-ID: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

This is what one gets if using a BytesParser() generated message:


encoders.encode_7or8bit(msg)
AttributeError: 'list' object has no attribute 'decode'

encoders.encode_base64(msg)
TypeError: expected bytes, not list

encoders.encode_quopri(msg)
TypeError: 'list' does not support the buffer interface


I'll attach a diff against 3.3 test_email.py which adds stupid
tests (there is really no assertNoRaises()).
Maybe they should also be extended so that it is actually tested
wether the generated content is also correct.

----------
components: Library (Lib)
files: test_email.1.diff
keywords: patch
messages: 133120
nosy: sdaoden
priority: normal
severity: normal
status: open
title: email.encoders are broken
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21548/test_email.1.diff

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

From report at bugs.python.org  Wed Apr  6 14:00:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 12:00:12 +0000
Subject: [New-bugs-announce] [issue11781] test/test_email directory does not
	get installed by	'make install'
Message-ID: <1302091212.24.0.8958212578.issue11781@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
components: Installation
nosy: r.david.murray, sdaoden
priority: normal
severity: normal
status: open
title: test/test_email directory does not get installed by 'make install'
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 15:49:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Apr 2011 13:49:45 +0000
Subject: [New-bugs-announce] [issue11782]
	email.generator.Generator.flatten() fails
In-Reply-To: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>
Message-ID: <1302097785.46.0.28701143911.issue11782@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

This snippet (for #11684, but it's simply BytesParser with
headersonly=True in the end)


        with openfile('msg_46.txt', 'rb') as fp:
            msgdata = fp.read()
        parser = email.parser.BytesHeaderParser()
        msg = parser.parsebytes(msgdata)
        out = BytesIO()
        gen = email.generator.BytesGenerator(out)
        gen.flatten(msg)
        self.assertEqual(out.getvalue(), msgdata)


causes this error:


ERROR: test_byte_message_rfc822_only (test_email.TestMessageAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_email/test_email.py", line 200, in test_byte_message_rfc822_only
    gen.flatten(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py", line 304, in _handle_message
    self._fp.write(payload)
TypeError: 'str' does not support the buffer interface

----------
components: Library (Lib)
messages: 133128
nosy: sdaoden
priority: normal
severity: normal
status: open
title: email.generator.Generator.flatten() fails
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr  6 16:12:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2011 14:12:01 +0000
Subject: [New-bugs-announce] [issue11783] email parseaddr and formataddr
	should be IDNA aware
In-Reply-To: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>
Message-ID: <1302099121.47.0.140525796896.issue11783@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The patch for issue 1690608 adds support for unicode in the realname field to formataddr.  To complete the currently-workable internationalization of address specs, both parseaddr and formataddr should be made IDNA aware.  It is probably a good idea to do some research on this to double check, but it seems as though recognizing IDNA during parsing and generating it during formatting when the domain contains non-ASCII characters should be both safe and useful.

See also issue 963906, which contains some test cases that could be adapted.

----------
assignee: r.david.murray
components: Library (Lib)
keywords: easy
messages: 133133
nosy: r.david.murray, torsten.becker
priority: normal
severity: normal
stage: needs patch
status: open
title: email parseaddr and formataddr should be IDNA aware
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  6 17:14:52 2011
From: report at bugs.python.org (Patrick Sabin)
Date: Wed, 06 Apr 2011 15:14:52 +0000
Subject: [New-bugs-announce] [issue11784] multiprocessing.Process.join:
	timeout argument doesn't	specify time unit.
In-Reply-To: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>
Message-ID: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

The documentation of multiprocessing.Process.join doesn't tell the user
of which time unit the timeout argument is. It seems to be seconds.

----------
assignee: docs at python
components: Documentation
files: join-timeout-doc-improvement.patch
keywords: patch
messages: 133142
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: multiprocessing.Process.join: timeout argument doesn't specify time unit.
type: behavior
Added file: http://bugs.python.org/file21551/join-timeout-doc-improvement.patch

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

From report at bugs.python.org  Wed Apr  6 17:57:46 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 06 Apr 2011 15:57:46 +0000
Subject: [New-bugs-announce] [issue11785] email subpackages documentation
	problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>


New submission from ysj.ray <ysj.ray at gmail.com>:

All the module name in the first line of email subpackages' documentation files(Doc/library/email.xxx.rst) are incorrect: all of them are "email" but not "email.xxx"

Besides, the Doc/library/email-examples.rst is not a module and it uses ":mod:`email`: xxx"

----------
assignee: docs at python
components: Documentation
files: email_subpackages_document_problems.diff
keywords: patch
messages: 133143
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: email subpackages documentation problems
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21552/email_subpackages_document_problems.diff

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

From report at bugs.python.org  Wed Apr  6 19:17:57 2011
From: report at bugs.python.org (Adam Groszer)
Date: Wed, 06 Apr 2011 17:17:57 +0000
Subject: [New-bugs-announce] [issue11786] ConfigParser.[Raw]ConfigParser
	optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>


New submission from Adam Groszer <agroszer at gmail.com>:

The documentation http://docs.python.org/library/configparser.html states that optionxform() is used only beginning ConfigParser.ConfigParser, whereas it is ALSO in effect for ConfigParser.RawConfigParser. (As I checked in the source)

----------
assignee: docs at python
components: Documentation
messages: 133148
nosy: Adam.Groszer, docs at python
priority: normal
severity: normal
status: open
title: ConfigParser.[Raw]ConfigParser optionxform()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  6 20:42:55 2011
From: report at bugs.python.org (Pulin Shah)
Date: Wed, 06 Apr 2011 18:42:55 +0000
Subject: [New-bugs-announce] [issue11787] File handle leak in TarFile lib
In-Reply-To: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>
Message-ID: <1302115375.88.0.984018215443.issue11787@psf.upfronthosting.co.za>


New submission from Pulin Shah <shahpr at gmail.com>:

I ran into a problem the other day while trying to extract a slightly corrupted tar file.  I suspect this problem is really only an issue on Windows systems.  I am running Python 2.7.1 r271:86832 win32.

The following code (simplified) snipet

try:
	tar = tarfile.open(args.file)
	tar.extractall(basefolder)
	tar.close()
except tarfile.ReadError:
	shutil.rmtree(basefolder)
except IOError:
	shutil.rmtree(basefolder)

was throwing a WindowsError on the rmtree calls.

This is due to the tarfile library not closing file handles in the case of an exception in the copyfileobj function, and Windows inability to delete open files.  

I was able to patch the issue locally by modifying tarfile's makefile function as follows:

    def makefile(self, tarinfo, targetpath):
        """Make a file called targetpath.
        """
        source = self.extractfile(tarinfo)
        target = bltn_open(targetpath, "wb")
        try:
            copyfileobj(source, target)
        except:
            source.close()
            target.close()
            raise
        source.close()
        target.close()

There is probably a cleaner way of implementing it.

I'm hoping you can integrate this patch into later versions of the lib.

Thanks.

----------
components: Library (Lib)
messages: 133153
nosy: shahpr
priority: normal
severity: normal
status: open
title: File handle leak in TarFile lib
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  6 23:46:54 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 21:46:54 +0000
Subject: [New-bugs-announce] [issue11788] Decorator class with optional
	arguments and a __call__	method gets not called when there
	are no arguments
In-Reply-To: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>
Message-ID: <1302126414.93.0.377099378978.issue11788@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

Scenario:

class deco(object):
  def __init__(self, optional = False):
    self._optional = optional

  def __call__(self, decorated):
    decorated.optional = self._optional
    return decorated

@deco
class y(object):
  pass

will fail decorating the class since y is passed in as the first parameter to deco.__init__, and deco.__call__ will never be called.

@deco(optional = True)
class y(object):
  pass

will succeed.

I wonder why there is a distinction between decorator class w/ arguments and decorator class w/o arguments?

Guessing that one would like to have a decorator class decorating another class and also acting as a kind of proxy by implementing a __call__ method, this could also be achieved by further indirection, provided that it will not break existing code.

A working alternative would be a decorator function like this:

def deco(_decorated = None, optional = False):
  def _wrapped(decorated):
    decorated.optional = optional
    return decorated
  if _decorated is not None:
    return _wrapped(decorated)
  return _wrapped

Is there a chance that the behavior of the decorator class will be fixed in a future release?

Expected behavior for the decorator class would be:

if formal parameter list has optional parameters and actual parameter list is empty and there are no formal mandatory parameters:
   if decorator class is callable:
      deco = decorator class ()
      decor.__call__(decorated)
   else:
      fall back to old behaviour, requiring the decorator class __init__ method to have one mandatory parameter
else:
  deco = decorator class(actual parameters...)
  deco.__call__(decorated)

TIA

----------
components: Interpreter Core
messages: 133171
nosy: carsten.klein
priority: normal
severity: normal
status: open
title: Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr  6 23:55:21 2011
From: report at bugs.python.org (Carsten Klein)
Date: Wed, 06 Apr 2011 21:55:21 +0000
Subject: [New-bugs-announce] [issue11789] Extend upon metaclass/type class
	documentation,
	here: zope.interface and usage of instances of classes as base
	classes
In-Reply-To: <1302126921.15.0.0291977163306.issue11789@psf.upfronthosting.co.za>
Message-ID: <1302126921.15.0.0291977163306.issue11789@psf.upfronthosting.co.za>


New submission from Carsten Klein <carsten.klein at axn-software.de>:

In zope.interface, you have something the following construct:

class InterfaceBase:
  pass

Interface = InterfaceBase()



Using the above Interface as a derivation base for your own classes, will make that instance a type derived class:

class IFoo(Interface):
  pass

type(IFoo)
-> Interface

type(Interface)
-> type


I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there...

----------
assignee: docs at python
components: Documentation
messages: 133173
nosy: carsten.klein, docs at python
priority: normal
severity: normal
status: open
title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 01:04:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Apr 2011 23:04:35 +0000
Subject: [New-bugs-announce] [issue11790] transient failure
	in	test_multiprocessing.WithProcessesTestCondition
In-Reply-To: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>
Message-ID: <1302131075.81.0.79285380131.issue11790@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%202.7/builds/519/steps/test/logs/stdio

======================================================================
FAIL: test_notify_all (test.test_multiprocessing.WithProcessesTestCondition)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 757, in test_notify_all
    self.assertReturnsIfImplemented(6, get_value, woken)
  File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 116, in assertReturnsIfImplemented
    return self.assertEqual(value, res)
AssertionError: 6 != 5

----------
components: Library (Lib), Tests
messages: 133182
nosy: pitrou
priority: normal
severity: normal
status: open
title: transient failure in test_multiprocessing.WithProcessesTestCondition
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  7 09:12:51 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 07 Apr 2011 07:12:51 +0000
Subject: [New-bugs-announce] [issue11791] python -m doctest has a -v flag
	that it ignores
In-Reply-To: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>
Message-ID: <1302160371.62.0.724682728561.issue11791@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

The usage string details a -v option, but python -m doctest doesn't use a -v option.

The attached patch adds that.

----------
files: doctest_verbosity.diff
keywords: patch
messages: 133195
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: python -m doctest has a -v flag that it ignores
versions: Python 3.2
Added file: http://bugs.python.org/file21559/doctest_verbosity.diff

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

From report at bugs.python.org  Thu Apr  7 10:22:27 2011
From: report at bugs.python.org (Samuele Kaplun)
Date: Thu, 07 Apr 2011 08:22:27 +0000
Subject: [New-bugs-announce] [issue11792] asyncore module print to stdout
In-Reply-To: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>
Message-ID: <1302164547.51.0.00796675638599.issue11792@psf.upfronthosting.co.za>


New submission from Samuele Kaplun <Samuele.Kaplun at cern.ch>:

The method "log_info" of the "dispatcher" class of the asyncore.py module, uses print statement to print to stdout.

This lead to conflicts when asyncore is used within e.g. mod_wsgi, as writing to stdout is not supposed to be valid.

----------
components: Library (Lib)
messages: 133198
nosy: kaplun
priority: normal
severity: normal
status: open
title: asyncore module print to stdout
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Apr  7 10:48:34 2011
From: report at bugs.python.org (chaos)
Date: Thu, 07 Apr 2011 08:48:34 +0000
Subject: [New-bugs-announce] [issue11793] raw strings
In-Reply-To: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>
Message-ID: <1302166114.84.0.402815371871.issue11793@psf.upfronthosting.co.za>


New submission from chaos <846909323 at qq.com>:

>>> print(r'\')
      
SyntaxError: EOL while scanning string literal
>>> print(r'\'')
\'
>>>

----------
messages: 133199
nosy: chaos
priority: normal
severity: normal
status: open
title: raw strings
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 10:58:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2011 08:58:02 +0000
Subject: [New-bugs-announce] [issue11794] Backport new logging docs to 2.7
In-Reply-To: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>
Message-ID: <1302166682.89.0.483892888748.issue11794@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Vinay did some great work on the logging documentation for 3.2 (http://docs.python.org/py3k/library/logging).

However, a lot of people will currently miss it, since they land on the existing 2.7 documentation (http://docs.python.org/library/logging) instead.

A backport would update the web site immediately, and then be incorporated in the bundled documentation when 2.7.2 is released (presumably later this year).

Backporting should be relatively straightforward (since logging hasn't changed *that* much between 2.7 and 3.2), but isn't completely trivial (since details of the Python 3 only items will need to be removed and the "changed in" and "added in" notices will need to be updated to reflect the information in the existing 2.x series documentation)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 133200
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Backport new logging docs to 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  7 14:47:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2011 12:47:06 +0000
Subject: [New-bugs-announce] [issue11795] Better core dev guidelines for
	committing submitted	patches
In-Reply-To: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>
Message-ID: <1302180426.35.0.989064957004.issue11795@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Based on a core-mentoring thread, a couple more points for:
http://docs.python.org/devguide/committing.html#handling-other-s-code

Attribution:
- add to Misc/ACKS if they aren't already there (and didn't add themselves in their patch)
- mention "Patch by <x>" in the NEWS entry and the checkin message*
- If I had to substantially change or fix a patch, I'll usually amend the acknowledgement to "Initial patch by <x>"

*(If I forget to say something in the checkin message, I generally don't worry about it - ACKS and NEWS are the important ones)

Contributor Licensing Agreements
- it's unlikely bug fixes will require a CLA unless they touch a *lot* of code
- new features often get into CLA-preferred territory, as the associated comments, docstrings and documentation are far more likely to reach a copyrightable standard
- for sprints, we now just collect CLAs as a matter of course, since there isn't any real inconvenience in doing so

----------
assignee: ncoghlan
components: Devguide
messages: 133212
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Better core dev guidelines for committing submitted patches

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

From report at bugs.python.org  Thu Apr  7 14:55:21 2011
From: report at bugs.python.org (Menno Smits)
Date: Thu, 07 Apr 2011 12:55:21 +0000
Subject: [New-bugs-announce] [issue11796] list and generator expressions in
	a class definition	fail if expression condition refers to a
	class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>


New submission from Menno Smits <menno at freshfoo.com>:

A list comprehension or generator expression in a class definition fails with NameError if it has a condition that refers to another class variable. This doesn't occur if the class variable is used the "in" part of the expression.

The following works:

class Foo:
    x = range(3)
    y = [z for z in x]

but this doesn't:

class Foo:
    x = 3
    y = [z for z in range(5) if z < x]

The error reported is: NameError: global name 'x' is not defined

Both of these examples work in Python 2.

Issue3692 suggests that class variables can't be referred to inside list comprehensions and gen expressions inside class definitions and that this won't be fixed, but these examples show that it is possible to refer to an outside class variable depending on usage. This is inconsistent and confusing.

The Python 2 behaviour makes much more sense. I understand that we don't want list comprehensions to leak internal variables but they should still be able to pull names from outside scopes in a consistent way.

----------
components: Interpreter Core
messages: 133213
nosy: mjs0
priority: normal
severity: normal
status: open
title: list and generator expressions in a class definition fail if expression condition refers to a class variable
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  7 17:57:24 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 07 Apr 2011 15:57:24 +0000
Subject: [New-bugs-announce] [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

The following code is not changed by 2to3::
    
    import os
    reload(os)

reload has moved to the imp module.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 133223
nosy: tebeka
priority: normal
severity: normal
status: open
title: 2to3 does not correct "reload"

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

From report at bugs.python.org  Thu Apr  7 18:15:57 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 07 Apr 2011 16:15:57 +0000
Subject: [New-bugs-announce] [issue11798] Test cases not garbage collected
	after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Right now, when doing a test case, one must clear all the variables created in the test class, and I believe this shouldn't be needed...

E.g.:

class Test(TestCase):
  def setUp(self):
    self.obj1 = MyObject()

  ...

  def tearDown(self):
    del self.obj1

Ideally (in my view), right after running the test, it should be garbage-collected and the explicit tearDown wouldn't be needed (as the test would garbage-collected, that reference would automatically die), because this is currently very error prone... (and probably a source of leaks for any sufficiently big test suite).

If that's accepted, I can provide a patch.

----------
components: Library (Lib)
messages: 133225
nosy: fabioz
priority: normal
severity: normal
status: open
title: Test cases not garbage collected after run
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Apr  7 21:32:50 2011
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 07 Apr 2011 19:32:50 +0000
Subject: [New-bugs-announce] [issue11799] urllib HTTP authentication
	behavior with unrecognized	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

When trying to use urllib to open a page from a server with NTLM authentication python raises urllib.error.HTTPError: HTTP Error 401: Unauthorized

A python 3 code example: http://codepad.org/axPomYHw

This was a bit confusing for me as I had to debug urllib to figure out python doesn't support NTLM. I'd expect python to tell me the authentication method isn't supported in such cases.

I didn't add a test for the attached patch as it doesn't seem test-worthy.

----------
components: Library (Lib)
files: urllib.auth.patch
keywords: patch
messages: 133248
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: urllib HTTP authentication behavior with unrecognized auth method
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file21567/urllib.auth.patch

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

From report at bugs.python.org  Thu Apr  7 23:54:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Apr 2011 21:54:54 +0000
Subject: [New-bugs-announce] [issue11800] regrtest --timeout: apply the
	timeout on a function, not on the whole file
In-Reply-To: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>
Message-ID: <1302213294.05.0.908920520464.issue11800@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I added recently a --timeout option to regrtest.py: dump the traceback of all threads and exit if a test takes more than TIMEOUT seconds (issue #11727). But my implementation was not correct: the timeout is applied on the whole file, not on a single function. Attached patch fixes this issue.

----------
components: Tests
files: regrtest_timeout.patch
keywords: patch
messages: 133262
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest --timeout: apply the timeout on a function, not on the whole file
versions: Python 3.3
Added file: http://bugs.python.org/file21573/regrtest_timeout.patch

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

From report at bugs.python.org  Fri Apr  8 02:17:23 2011
From: report at bugs.python.org (Lane Stevens)
Date: Fri, 08 Apr 2011 00:17:23 +0000
Subject: [New-bugs-announce] [issue11801] difference in comparison behavior
	between 32 bit and 64	bit releases
In-Reply-To: <1302221843.91.0.79714388976.issue11801@psf.upfronthosting.co.za>
Message-ID: <1302221843.91.0.79714388976.issue11801@psf.upfronthosting.co.za>


New submission from Lane Stevens <tiwula at gmail.com>:

I have two systems running 

python-2.6.4-27.fc13.x86_64
and
python-2.6.4-27.fc13.i686

respectively. Given the following statement the 64-bit version returns False and the 32-bit version returns True.

Decimal('1.0') > 0.0

Decimal('1.0') > 0 returns True on both systems.

----------
components: Interpreter Core
messages: 133279
nosy: Lane.Stevens
priority: normal
severity: normal
status: open
title: difference in comparison behavior between 32 bit and 64 bit releases
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  8 05:37:24 2011
From: report at bugs.python.org (jeff deifik)
Date: Fri, 08 Apr 2011 03:37:24 +0000
Subject: [New-bugs-announce] [issue11802] filecmp.cmp needs a documented way
	to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I have a program which calls filecmp.cmp a lot.
It runs out of memory.
I read the source to filecmp, and then I periodically set
filecmp._cache = {}

Without doing this, filecmp's cache uses up all the memory in the computer.

There needs to be a documented interface to clear the cache.

I suggest a function
def clear_cache:
    _cache = {}

Without a documented interface, there is no standard way to clear the
cache. It is possible different versions of python will require
different methods to clear the cache, which will reduce python code
portability and is a bad idea.

Alternatively, one might disable the caching code.

One shouldn't have to look at the source code of a library function
to see why it is consuming memory.

----------
messages: 133290
nosy: lopgok
priority: normal
severity: normal
status: open
title: filecmp.cmp needs a documented way to clear cache
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  8 09:06:50 2011
From: report at bugs.python.org (Swapnil Talekar)
Date: Fri, 08 Apr 2011 07:06:50 +0000
Subject: [New-bugs-announce] [issue11803] Memory leak in sub-interpreters
In-Reply-To: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>
Message-ID: <1302246410.34.0.932869842046.issue11803@psf.upfronthosting.co.za>


New submission from Swapnil Talekar <swapnil.st at gmail.com>:

In the attached program, the total memory consumption of the process, goes up each time a new subinterpreter imports a bunch of modules. When the subinterpreter is shutdown with Py_EndInterpreter, the memory consumed with import of modules is not returned back. Hence the amount of memory consumed keeps increasing with each loop. It goes up from about 8MB to about 11MB after few loops. Strangely it doesn't rise any further.

I have tested this only for Python 2.6.5

----------
components: Interpreter Core
files: test_subinterpreter.c
messages: 133292
nosy: amaury.forgeotdarc, benjamin.peterson, christian.heimes, eric.araujo, grahamd, haypo, loewis, ncoghlan, pitrou, python-dev, swapnil
priority: normal
severity: normal
status: open
title: Memory leak in sub-interpreters
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file21577/test_subinterpreter.c

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

From report at bugs.python.org  Fri Apr  8 11:33:03 2011
From: report at bugs.python.org (Panos Christeas)
Date: Fri, 08 Apr 2011 09:33:03 +0000
Subject: [New-bugs-announce] [issue11804] expat parser not xml 1.1 (breaks
	xmlrpclib)
In-Reply-To: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>
Message-ID: <1302255183.42.0.728288108717.issue11804@psf.upfronthosting.co.za>


New submission from Panos Christeas <xrg at hellug.gr>:

The expat library (in C level) is not xml 1.1 compliant, meaning that
it won't accept characters \x01-\x08,\x0b,\x0c and \x0e-\x1f .
At the same time, ElementTree (or custom XML creation, such as in xmlrpclib.py:694) allow these characters to pass through. They will get blocked on the receiving side.
Since 2.7, the expat library is the default parser for xml-rpc, so it
this is a regression, IMHO. According to the network principal, we should
accept these characters gracefully.

The attached test script demonstrates that we're not xml 1.1 compliant (but instead enforce the more strict 1.0 rule)

References:
http://bugs.python.org/issue5166
http://en.wikipedia.org/wiki/Valid_characters_in_XML

----------
components: XML
files: expat-test.py
messages: 133301
nosy: xrg
priority: normal
severity: normal
status: open
title: expat parser not xml 1.1 (breaks xmlrpclib)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file21580/expat-test.py

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

From report at bugs.python.org  Sat Apr  9 00:23:49 2011
From: report at bugs.python.org (Erik Bray)
Date: Fri, 08 Apr 2011 22:23:49 +0000
Subject: [New-bugs-announce] [issue11805] package_data only allows one glob
	per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

In distutils the package_data option can be supplied a list of glob patterns for each package.  distutils2 currently only supports one glob per package.

This could easily be fixed by simply allowing more than one `package_name = pattern` value in the package_data option.  For example:

package_data =
    mypackage = templates/*.html
    mypackage = static/css/*.css
    mypackage.subpackage = templates/*.html
    ...

----------
assignee: tarek
components: Distutils2
hgrepos: 16
messages: 133346
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
status: open
title: package_data only allows one glob per-package
type: behavior

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

From report at bugs.python.org  Sat Apr  9 10:36:37 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 09 Apr 2011 08:36:37 +0000
Subject: [New-bugs-announce] [issue11806] Missing 2 hyphens in the docs
In-Reply-To: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>
Message-ID: <1302338197.1.0.100311254016.issue11806@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please see  http://docs.python.org/py3k/library/argparse.html#module-argparse  and read the first sentence which goes...

"The argparse module makes it easy to write user friendly command line interfaces."

Please fix this to...

"The argparse module makes it easy to write user-friendly command-line interfaces."

Note: "user friendly" --> "user-friendly"
      "command line" --> "command-line"

----------
assignee: docs at python
components: Documentation
messages: 133377
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Missing 2 hyphens in the docs
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr  9 11:21:12 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 09 Apr 2011 09:21:12 +0000
Subject: [New-bugs-announce] [issue11807] Documentation of add_subparsers
	lacks information about	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

In argparse documentation parametres of add_subparsers are not listed. And yet there are some really useful parametres like parser_class. It would be useful, it they were described there well and one wouldn't have to look into the code to find them :-) I'll be happy to provide documentation patch tomorrow.

----------
assignee: docs at python
components: Documentation
messages: 133379
nosy: docs at python, gruszczy
priority: normal
severity: normal
status: open
title: Documentation of add_subparsers lacks information about parametres
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr  9 16:55:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 14:55:32 +0000
Subject: [New-bugs-announce] [issue11808] $MACOSX_DEPLOYMENT_TARGET mismatch
	... during configure
In-Reply-To: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>
Message-ID: <1302360932.31.0.240480898156.issue11808@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Hello Mac OS X gurus, if i


else
	DEBUG='--with-pydebug'
	echo Using --with-pydebug
fi
./configure --prefix="$HOME/usr/opt/$PREFIX" $DEBUG
make -j2 all


i get this


/usr/bin/gcc -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -O2 -O2  -I. -IInclude -I./Include    -DPy_BUILD_CORE \
	      -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" \
	      -DHGTAG="\"`LC_ALL=C hg id -t .`\"" \
	      -DHGBRANCH="\"`LC_ALL=C hg id -b .`\"" \
	      -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure
Traceback (most recent call last):
  File "/Users/steffen/usr/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/steffen/usr/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/steffen/usr/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/steffen/usr/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/steffen/usr/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure

----------
components: Build
messages: 133395
nosy: ned.deily, ronaldoussoren, sdaoden
priority: normal
severity: normal
status: open
title: $MACOSX_DEPLOYMENT_TARGET mismatch ... during configure
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr  9 20:52:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 09 Apr 2011 18:52:22 +0000
Subject: [New-bugs-announce] [issue11809] Rietveld Code Review Tool can't
	handle well-known	controls
In-Reply-To: <1302375142.87.0.0417169208521.issue11809@psf.upfronthosting.co.za>
Message-ID: <1302375142.87.0.0417169208521.issue11809@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

The file http://bugs.python.org/file21593/11650.termios.diff
cannot be parsed, i guess it's due to ^D, ^Z, ^\ and ^C being
embedded as ASCII control characters.
Maybe this is a feature, though.
Then someone should close this.
Nice weekend all of you.

----------
components: None
messages: 133411
nosy: sdaoden
priority: normal
severity: normal
status: open
title: Rietveld Code Review Tool can't handle well-known controls

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

From report at bugs.python.org  Sat Apr  9 22:49:39 2011
From: report at bugs.python.org (Emile Heitor)
Date: Sat, 09 Apr 2011 20:49:39 +0000
Subject: [New-bugs-announce] [issue11810] _socket fails to build on
	OpenIndiana
In-Reply-To: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>
Message-ID: <1302382179.44.0.700403156795.issue11810@psf.upfronthosting.co.za>


New submission from Emile Heitor <imil at NetBSD.org>:

This issue http://bugs.python.org/issue8852 seems to happen again since python 2.6.6. Same cause, same consequences. Patching Modules/socketmodule.h with the following fixes it:

--- Modules/socketmodule.h.orig 2010-05-09 15:15:40.000000000 +0000             
+++ Modules/socketmodule.h                                                      
@@ -59,6 +59,10 @@ typedef int socklen_t;                                       
 #include <bluetooth.h>                                                         
 #endif                                                                         
                                                                                
+#if defined(__sun)                                                             
+#undef HAVE_NETPACKET_PACKET_H                                                 
+#endif                                                                         
+                                                                               
 #ifdef HAVE_NETPACKET_PACKET_H                                                 
 # include <sys/ioctl.h>                                                        
 # include <net/if.h>

----------
components: Build
messages: 133420
nosy: iMil
priority: normal
severity: normal
status: open
title: _socket fails to build on OpenIndiana
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr  9 23:18:20 2011
From: report at bugs.python.org (Paul Wouters)
Date: Sat, 09 Apr 2011 21:18:20 +0000
Subject: [New-bugs-announce] [issue11811] ssl.get_server_certificate() does
	not work for IPv6	addresses
In-Reply-To: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>
Message-ID: <1302383900.51.0.808943452569.issue11811@psf.upfronthosting.co.za>


New submission from Paul Wouters <paul at xelerance.com>:

ssl.get_server_certificate() does not work for IPv6 addresses:

>>> ssl.get_server_certificate( ("2001:888:2003:1004:c2ff:eeff:fe00:133",443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/ssl.py", line 403, in get_server_certificate
    s.connect(addr)
  File "/usr/lib64/python2.7/ssl.py", line 292, in connect
    socket.connect(self, addr)
  File "/usr/lib64/python2.7/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -9] Address family for hostname not supported

----------
messages: 133422
nosy: pwouters
priority: normal
severity: normal
status: open
title: ssl.get_server_certificate() does not work for IPv6 addresses
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  9 23:56:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 21:56:54 +0000
Subject: [New-bugs-announce] [issue11812] transient test_telnetlib failure
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2920/steps/test/logs/stdio

test test_telnetlib failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_telnetlib.py", line 45, in testBasic
    telnet = telnetlib.Telnet(HOST, self.port)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\telnetlib.py", line 209, in __init__
    self.open(host, port, timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\telnetlib.py", line 225, in open
    self.sock = socket.create_connection((host, port), timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 407, in create_connection
    raise err
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 398, in create_connection
    sock.connect(sa)
socket.error: [Errno 10061] No connection could be made because the target machine actively refused it

----------
components: Library (Lib), Tests
messages: 133429
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: transient test_telnetlib failure
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr 10 00:44:19 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 09 Apr 2011 22:44:19 +0000
Subject: [New-bugs-announce] [issue11813] inspect.getattr_static doesn't get
	module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

My patch for issue #11133 introduced a regression: it is no longer possible to get attributes of modules. That is because modules use "tp_dictoffset" (at C level). The instance __dict__ is exposed to Python code using a types.MemberDescriptorType. My patch for issue #11133 currently assumes that accessing the instance __dict__ can trigger code execution, but that is impossible: The access itself can't trigger code execution (it just returns a PyObject in the C struct). Theoretically, it could return any Python object, but that doesn't matter, as the code that uses the object only calls dict methods directly, hence a TypeError is the worst thing that can happen (although it shouldn't ever happen in practise).

Attached is a patch that adds a test and fixes the issue.

----------
components: Library (Lib)
files: getattr_static_modules.patch
keywords: patch
messages: 133432
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static doesn't get module attributes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21596/getattr_static_modules.patch

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

From report at bugs.python.org  Sun Apr 10 01:07:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 23:07:20 +0000
Subject: [New-bugs-announce] [issue11814] possible typo in
	multiprocessing.Pool._terminate
In-Reply-To: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>
Message-ID: <1302390440.77.0.392480963039.issue11814@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There's the following code in pool.py, line 494 and following:

        debug('joining task handler')
        task_handler.join()

        debug('joining result handler')
        task_handler.join()

It seems the last line should read `result_handler.join()` instead.

Additionally, when _terminate() is called, it seems the worker_handler could still run while other threads shut down existing workers, meaning it could start new workers (in _repopulate_pool()) in parallel.

So perhaps the worker_handler should be joined before anything else in _terminate(). It would incur a small latency, though (because of the sleep() call there).

----------
messages: 133433
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
status: open
title: possible typo in multiprocessing.Pool._terminate
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr 10 01:37:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Apr 2011 23:37:47 +0000
Subject: [New-bugs-announce] [issue11815] Simplifications in
	concurrent.futures
In-Reply-To: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>
Message-ID: <1302392267.12.0.152242610702.issue11815@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Queue.get(block=True) cannot raise EmptyError, meaning there's some dead code that we can remove.

----------
components: Library (Lib)
files: cfsimplify.patch
keywords: patch
messages: 133435
nosy: bquinlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Simplifications in concurrent.futures
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21597/cfsimplify.patch

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

From report at bugs.python.org  Sun Apr 10 02:20:10 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 10 Apr 2011 00:20:10 +0000
Subject: [New-bugs-announce] [issue11816] Add functions to return
	disassembly as string
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>


New submission from Eugene Toder <eltoder at gmail.com>:

As discussed in Issue11549 a couple of tests need to inspect disassembly of some code. Currently they have to override sys.stdout, run dis and restore stdout back. It would be much nicer if dis module provided functions that return disassembly as a string.

Provided is a patch that adds file argument to most dis functions, defaulting to sys.stdout. On top of that there are 2 new functions: dis_to_str and disassembly_to_str that return disassembly as a string instead of writing it to a file.

----------
components: Library (Lib)
files: dis.diff
keywords: patch
messages: 133437
nosy: eltoder
priority: normal
severity: normal
status: open
title: Add functions to return disassembly as string
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21598/dis.diff

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

From report at bugs.python.org  Sun Apr 10 04:52:08 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 10 Apr 2011 02:52:08 +0000
Subject: [New-bugs-announce] [issue11817] berkeley db 5.1 support
In-Reply-To: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>
Message-ID: <1302403928.0.0.111230204951.issue11817@psf.upfronthosting.co.za>


New submission from Per ?yvind Karlsen <peroyvind at mandriva.org>:

This patch adds support for berkeley db <= 5.1.

----------
components: Extension Modules
files: Python-2.7.1-berkeley-db-5.1.patch
keywords: patch
messages: 133442
nosy: proyvind
priority: normal
severity: normal
status: open
title: berkeley db 5.1 support
versions: Python 2.7
Added file: http://bugs.python.org/file21601/Python-2.7.1-berkeley-db-5.1.patch

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

From report at bugs.python.org  Sun Apr 10 09:10:39 2011
From: report at bugs.python.org (eduardo)
Date: Sun, 10 Apr 2011 07:10:39 +0000
Subject: [New-bugs-announce] [issue11818] tempfile.TemporaryFile example in
	docs doesnt work
In-Reply-To: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>
Message-ID: <1302419439.43.0.340740214318.issue11818@psf.upfronthosting.co.za>


New submission from eduardo <schettino72 at gmail.com>:

>From the example:
 http://docs.python.org/py3k/library/tempfile.html#examples

The error message is weird... but I guess the problem is the default mode 'w+b'.


Python 3.3a0 (default:78a66c98288d, Apr  9 2011, 16:13:31) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> fp = tempfile.TemporaryFile()
>>> fp.write('hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface
>>> fp2 = tempfile.TemporaryFile('w+')
>>> fp2.write('hello')
5
>>>

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 133447
nosy: docs at python, schettino72
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile example in docs doesnt work
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr 10 09:35:31 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Apr 2011 07:35:31 +0000
Subject: [New-bugs-announce] [issue11819] 'unittest -m' should not pretend
	it works on Python	2.5/2.6
In-Reply-To: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>
Message-ID: <1302420931.81.0.0491321221951.issue11819@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The following command is broken on Python 2.5/2.6
  python -m unittest test_file
It outputs

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

But in Python 2.7 the same command works

----------------------------------------------------------------------
Ran 1 tests in 0.000s

OK

It is even more confusing with test class method on command line:
  python26 -m unittest test_file.SomeTest
Traceback (most recent call last):
  ...
  File "C:\~env\Python26\lib\unittest.py", line 598, in loadTestsFromName
    test = obj()
  File "C:\~env\Python26\lib\unittest.py", line 216, in __init__
    (self.__class__, methodName)
ValueError: no such test method in <class 'test_file.SomeTest'>: runTest


--- 
I know that our <...> policy denies backporting such fixes to Python 2.5/2.6, but such things that make an illusion that they work while in fact they never did - see #6514, make Python really suxx. I can feel user frustration while trying to maintain 2.6 compatibility and wasting time trying to run test suite. I wouldn't mind if `-m unittest` won't work in non-supported versions, but it should at least point to bug report.

(if I'll ever switch to Ruby - this one will definitely be in the list reasons)

----------
components: Tests
messages: 133449
nosy: techtonik
priority: normal
severity: normal
status: open
title: 'unittest -m' should not pretend it works on Python 2.5/2.6
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun Apr 10 09:45:40 2011
From: report at bugs.python.org (kent)
Date: Sun, 10 Apr 2011 07:45:40 +0000
Subject: [New-bugs-announce] [issue11820] idle3 shell os.system swallows
	shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>


New submission from kent <fuzzballz at comcast.net>:

attempting to run an os.system command under the idle 3 shell swallows the out put.
Idle 3 is running on a 32 bit kde mandriva linux.

>>> import os
>>> os.system('ls')
0
>>> os.system('pwd')
0


as you can see it returns a 0 indicating successful completion, but no output. However os.getcwd works perfectly.

>>> os.getcwd()
'/home/kent/Documents' 

running the same code from python in an xwindow terminal works fine.

apparently the idle shell does not echo the the standard output or error output as the python interpreter does.

----------
components: IDLE
messages: 133452
nosy: Thekent
priority: normal
severity: normal
status: open
title: idle3 shell os.system swallows shell command output
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Apr 10 11:24:29 2011
From: report at bugs.python.org (david)
Date: Sun, 10 Apr 2011 09:24:29 +0000
Subject: [New-bugs-announce] [issue11821] smtplib should provide a means to
	validate a remote	server ssl certificate(s)
In-Reply-To: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>
Message-ID: <1302427469.29.0.858818521824.issue11821@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

(This is similar to http://bugs.python.org/issue10274)
The smtplib module should provide a means to validate a remote server ssl certificate(s). 

It would be 'nice' if smtplib.SMTP_SSL & smtplib.starttls took in arguments to validate the remote SMTP's ssl certificate has been signed by a trusted certificate authority(and the common name matches what it should etc.).

----------
messages: 133457
nosy: db
priority: normal
severity: normal
status: open
title: smtplib should provide a means to validate a remote server ssl certificate(s)

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

From report at bugs.python.org  Sun Apr 10 22:25:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 20:25:52 +0000
Subject: [New-bugs-announce] [issue11822] Improve disassembly to show
	embedded code objects
In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>
Message-ID: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Now that list comprehensions mask run their internals in code objects (the same way that genexps do), it is getting harder to use dis() to see what code is generated.  For example, the pow() call isn't shown in the following disassembly:

>>> dis('[x**2 for x in range(3)]')
  1           0 LOAD_CONST               0 (<code object <listcomp> at 0x1005d1e88, file "<dis>", line 1>) 
              3 MAKE_FUNCTION            0 
              6 LOAD_NAME                0 (range) 
              9 LOAD_CONST               1 (3) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE    

I propose that dis() build-up a queue undisplayed code objects and then disassemble each of those after the main disassembly is done (effectively making it recursive and displaying code objects in the order that they are first seen in the disassembly).  For example, the output shown above would be followed by a disassembly of its internal code object:

<code object <listcomp> at 0x1005d1e88, file "<dis>", line 1>:
  1           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                16 (to 25) 
              9 STORE_FAST               1 (x) 
             12 LOAD_FAST                1 (x) 
             15 LOAD_CONST               0 (2) 
             18 BINARY_POWER         
             19 LIST_APPEND              2 
             22 JUMP_ABSOLUTE            6 
        >>   25 RETURN_VALUE

----------
components: Library (Lib)
messages: 133478
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve disassembly to show embedded code objects
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 10 23:11:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2011 21:11:40 +0000
Subject: [New-bugs-announce] [issue11823] disassembly needs to argument
	counts on calls with	keyword args
In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>
Message-ID: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The argument to CALL_FUNCTION is overloaded to show both the number of positional arguments and keyword arguments (shifted by 8-bits):

>>> dis("foo(10, opt=True)")
  1           0 LOAD_NAME                0 (foo) 
              3 LOAD_CONST               0 (10) 
              6 LOAD_CONST               1 ('opt') 
              9 LOAD_CONST               2 (True) 
             12 CALL_FUNCTION          257 
             15 RETURN_VALUE         

It is not obvious that the 257 argument causes three stack arguments to be popped.

The disassembly should add a parenthetical to explain the composition:

>>> dis("foo(10, opt=True)")
  1           0 LOAD_NAME                0 (foo) 
              3 LOAD_CONST               0 (10) 
              6 LOAD_CONST               1 ('opt') 
              9 LOAD_CONST               2 (True) 
             12 CALL_FUNCTION          257 (1 positional, 1 keyword pair)
             15 RETURN_VALUE

----------
components: Library (Lib)
messages: 133481
nosy: rhettinger
priority: normal
severity: normal
status: open
title: disassembly needs to argument counts on calls with keyword args
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 11 04:22:00 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 11 Apr 2011 02:22:00 +0000
Subject: [New-bugs-announce] [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The recent addition of ABI flags broke the freeze tool as it doesn't construct the paths to required files correctly any longer. The attached patch fixes the issue for me, but I'm not too sure that I used the right config values.

----------
components: Demos and Tools
files: freeze.patch
keywords: patch
messages: 133495
nosy: Trundle
priority: normal
severity: normal
status: open
title: freeze.py broken due to ABI flags
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21609/freeze.patch

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

From report at bugs.python.org  Mon Apr 11 08:26:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 06:26:32 +0000
Subject: [New-bugs-announce] [issue11825] faulthandler: failure without
	threads
In-Reply-To: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>
Message-ID: <1302503192.32.0.414479230775.issue11825@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi, the tests fail on Debian if the option --without-threads is used:

./configure --with-pydebug --without-threads
make
make test

./python -Wd -E -bb  ./Lib/test/regrtest.py -l 
== CPython 3.3a0 (default:9140f2363623+, Jan 30 2011, 04:52:32) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
==   Linux-2.6.23.1-i686-with-debian-4.0 little-endian
==   /home/stefan/hg/default/build/test_python_24329
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
[  1/355] test_grammar
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1607, in <module>
    main()
  File "./Lib/test/regrtest.py", line 650, in main
    rerun_failed=verbose3, timeout=timeout)
  File "./Lib/test/regrtest.py", line 824, in runtest
    faulthandler.dump_tracebacks_later(timeout, exit=True)
AttributeError: 'module' object has no attribute 'dump_tracebacks_later'

----------
assignee: haypo
components: Tests
messages: 133500
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: faulthandler: failure without threads
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 11 08:56:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Apr 2011 06:56:19 +0000
Subject: [New-bugs-announce] [issue11826] Leak in atexitmodule
In-Reply-To: <1302504979.95.0.857272040465.issue11826@psf.upfronthosting.co.za>
Message-ID: <1302504979.95.0.857272040465.issue11826@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Valgrind reports a leak (definitely lost) in atexitmodule.c. The
patch fixes the problem.

----------
components: Extension Modules
files: atexit-leak.patch
keywords: patch
messages: 133501
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Leak in atexitmodule
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21610/atexit-leak.patch

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

From report at bugs.python.org  Mon Apr 11 10:38:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 11 Apr 2011 08:38:17 +0000
Subject: [New-bugs-announce] [issue11827] mention of list2cmdline() in docs
	of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of subprocess.Popen mentions a function named list2cmdline():

----
  On Windows: the Popen class uses CreateProcess() to execute the child program, which operates on strings. If args is a sequence, it will be converted to a string using the list2cmdline() method. Please note that not all MS Windows applications interpret the command line the same way: list2cmdline() is designed for applications using the same rules as the MS C runtime.
----

I find this rather opaque and useless. list2cmdline() in subprocess is publicly accessible (doesn't begin with underscores) but it isn't documented.

The solution can be one of the following:

1. Document list2cmdline in the docs of subprocess, making the reference to is useful
2. Don't mention list2cmdline and instead mention what it does with the command-line list

----------
assignee: docs at python
components: Documentation
messages: 133507
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: mention of list2cmdline() in docs of subprocess.Popen
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 11 17:09:08 2011
From: report at bugs.python.org (Marijn Schouten)
Date: Mon, 11 Apr 2011 15:09:08 +0000
Subject: [New-bugs-announce] [issue11828] startswith and endswith don't
	accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>


New submission from Marijn Schouten <hkBst at gentoo.org>:

startswith and endswith don't accept None as slice index, as shown by below interaction. Same behavior for python-3.1.3(with print()) and python-2.7.1. If instead this is intended behavior then the error message is wrong.

$ python -c "print 'abc'[-1:None]"
c
$ python -c "print 'abc'.endswith('c',-1,None)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method

----------
components: None
messages: 133527
nosy: hkBst
priority: normal
severity: normal
status: open
title: startswith and endswith don't accept None as slice index
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Apr 12 00:46:41 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 11 Apr 2011 22:46:41 +0000
Subject: [New-bugs-announce] [issue11829] inspect.getattr_static code
	execution with	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The commit for issue #11133 omitted a part of the patch that checked whether the __dict__ attribute of metaclasses are shadowed. That makes it possible to trigger code execution in the case of metaclasses that have metaclasses.

Attached is a patch with a test and a fix.

----------
components: Library (Lib)
files: getattr_static_metaclasses.patch
keywords: patch
messages: 133549
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static code execution with meta-metaclasses
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21621/getattr_static_metaclasses.patch

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

From report at bugs.python.org  Tue Apr 12 00:46:57 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 11 Apr 2011 22:46:57 +0000
Subject: [New-bugs-announce] [issue11830] "import decimal" fails in Turkish
	locale
In-Reply-To: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>
Message-ID: <1302562017.26.0.78208251188.issue11830@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

For Python 2 (here with 2.7.1):
$ python -c 'import locale; locale.setlocale(locale.LC_ALL, "tr_TR.UTF-8"); import decimal'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/decimal.py", line 3715, in <module>
    val = globals()[globalname]
KeyError: 'ROUND_CEiLiNG'

The issue is that 'round_ceiling'.upper() is 'ROUND_CEiLiNG' in the Turkish locale, rather than 'ROUND_CEILING', as one might expect.

A workaround for this may be to convert the str instances to unicode
first, then call upper on them, then convert back to str.

This would work since upper() for a unicode instance is locale-independent as
per issue 1528802.
(though there seems to have been some debate there).

Patch attached, though it doesn't yet contain a test case.

Only affects Python 2; with Python 3, the symbols are already stored as unicode internally.

Reported downstream as:
  https://bugzilla.redhat.com/show_bug.cgi?id=694928
which has links to various other reports on this

----------
components: Library (Lib)
files: decimal.py.patch
keywords: patch
messages: 133550
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: "import decimal" fails in Turkish locale
versions: Python 2.7
Added file: http://bugs.python.org/file21622/decimal.py.patch

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

From report at bugs.python.org  Tue Apr 12 02:42:45 2011
From: report at bugs.python.org (Susam Pal)
Date: Tue, 12 Apr 2011 00:42:45 +0000
Subject: [New-bugs-announce] [issue11831] "python -w" causes "no Python
	documentation found" error	when the path is not current directory
In-Reply-To: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>
Message-ID: <1302568965.6.0.204734578124.issue11831@psf.upfronthosting.co.za>


New submission from Susam Pal <susam at susam.in>:

Steps to reproduce:

susam at nifty:~/pydoc-test$ tree ../pydoc-subject/
../pydoc-subject/
|-- calc
|   |-- formulae.py
|   `-- __init__.py
|-- config.py
|-- default.conf
|-- main.py
`-- spal.conf

1 directory, 6 files

susam at nifty:~/pydoc-test$ pydoc -w ../pydoc-subject/
no Python documentation found for 'calc'
no Python documentation found for 'config'
no Python documentation found for 'main'

----------
components: Library (Lib)
messages: 133557
nosy: susam
priority: normal
severity: normal
status: open
title: "python -w" causes "no Python documentation found" error when the path is not current directory
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Apr 12 05:23:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2011 03:23:48 +0000
Subject: [New-bugs-announce] [issue11832] Add option to pause regrtest to
	attach a debugger
In-Reply-To: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>
Message-ID: <1302578628.99.0.388714550632.issue11832@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Patch to add -a/--attach option to Lib/test/regrtest.py to pause before beginning test runs. This would allow a user to attach Visual Studio or some other debugger. Very simply, this option just blocks waiting for a keystroke during argument parsing - once you're ready, hit any key.

My use case is with Visual Studio, where I've wanted to debug C code used by tests and would prefer to attach to an external command prompt, rather than have to initiate the test from within VS.

----------
assignee: brian.curtin
components: Tests
files: attach.diff
keywords: patch
messages: 133559
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Add option to pause regrtest to attach a debugger
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21625/attach.diff

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

From report at bugs.python.org  Tue Apr 12 05:42:43 2011
From: report at bugs.python.org (Alec Taylor)
Date: Tue, 12 Apr 2011 03:42:43 +0000
Subject: [New-bugs-announce] [issue11833] ord() doesn't show complete UNICODE
In-Reply-To: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>
Message-ID: <1302579763.25.0.785259570503.issue11833@psf.upfronthosting.co.za>


New submission from Alec Taylor <alec.taylor6 at gmail.com>:

Unfortunately ord() doesn't show complete UNICODE. This can cause incorrectness problems.

>>> ord('?')
151
>>> ord('?')
165

Proof: Type Alt+0151, then type Alt+151. They should give you ? and ? respectively.

Please correct the UNICODE numbering.

Thanks,

Alec Taylor

----------
components: Unicode
messages: 133560
nosy: AlecTaylor
priority: normal
severity: normal
status: open
title: ord() doesn't show complete UNICODE
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 12 12:47:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Apr 2011 10:47:36 +0000
Subject: [New-bugs-announce] [issue11834] wrong module installation dir on
	Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/install/index.html#how-installation-works

Correct standard installation location for third-party modules on Windows for Python 2.x is
    prefix/Lib/site-packages

----------
assignee: docs at python
components: Documentation
messages: 133571
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: wrong module installation dir on Windows
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 12 17:39:26 2011
From: report at bugs.python.org (Abraham Soedjito)
Date: Tue, 12 Apr 2011 15:39:26 +0000
Subject: [New-bugs-announce] [issue11835] python (x64) ctypes incorrectly
	pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>


New submission from Abraham Soedjito <abraham.soedjito at gmail.com>:

void __cdecl foo(unsigned __int32 a,
                 unsigned __int32 b,
                 unsigned __int32 c,
                 unsigned __int32 d,
                 unsigned __int32 e,
                 unsigned __int32 f,
                 unsigned __int32 g);

struct myStruct
{
   unsigned __int32 a;
   unsigned __int32 b;
   unsigned __int32 c;
   unsigned __int32 d;
   unsigned __int32 e;
   unsigned __int32 f;
   unsigned __int32 g;
}
void __cdecl bar(myStruct s);

void __cdecl errorPassingParameter(myStruct s1,
                                   myStruct s2,
                                   unsigned __int32 x);    

Calling foo and bar from python completed successfully, calling errorParsingParameter resulted in stack corruption. It seems that python passed an extra pointer in the stack for s2.

----------
assignee: theller
components: ctypes
messages: 133583
nosy: Abraham.Soedjito, theller
priority: normal
severity: normal
status: open
title: python (x64) ctypes incorrectly pass structures parameter
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 12 17:56:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Apr 2011 15:56:25 +0000
Subject: [New-bugs-announce] [issue11836] multiprocessing.queues.SimpleQueue
	is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

multiprocessing.queues.SimpleQueue is undocumented and doesn't appear in multiprocessing.__all__.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 133586
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing.queues.SimpleQueue is undocumented
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr 12 19:09:21 2011
From: report at bugs.python.org (Axel Rau)
Date: Tue, 12 Apr 2011 17:09:21 +0000
Subject: [New-bugs-announce] [issue11837] smtplib._quote_periods triggers
	spurious type error in	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>


New submission from Axel Rau <Axel.Rau at Chaos1.DE>:

While debugging this
  http://article.gmane.org/gmane.comp.python.general/687767
email problem, I'm getting:
---
 File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 794, in send_message
    rcpt_options)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 762, in sendmail
    (code, resp) = self.data(msg)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 518, in data
    q = _quote_periods(msg)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/smtplib.py", line 166, in _quote_periods
    return re.sub(br'(?m)^\.', '..', bindata)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/re.py", line 168, in sub
    return _compile(pattern, flags).sub(repl, string, count)
TypeError: sequence item 1: expected bytes, str found
---
The following instrumentation:
---
def sub(pattern, repl, string, count=0, flags=0):
    print('re.sub: pattern=%s, repl=%s, string=%s' % (pattern.__class__.__name__, repl.__class__.__name__, string.__class__.__name__))
    return _compile(pattern, flags).sub(repl, string, count)
---
shows (in my test case with 2nd mail):
---
re.sub: pattern=bytes, repl=str, string=bytes
---
Changing smtplib._quote_periods(bindata) from
---
def _quote_periods(bindata):
    return re.sub(br'(?m)^\.', '..', bindata)
---
to:
---
def _quote_periods(bindata):
    return re.sub(br'(?m)^\.', b'..', bindata)
---
Fixes the problem for me.

Platform is Mac OS X 10.6.7, 64-bit.
Problem happens always on 2nd mail being sent.
Problem still exists with python 3.2.1a

----------
components: Library (Lib)
messages: 133590
nosy: axel
priority: normal
severity: normal
status: open
title: smtplib._quote_periods triggers spurious type error in re.sub
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 12 20:03:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Apr 2011 18:03:09 +0000
Subject: [New-bugs-announce] [issue11838] IDLE: make interactive code
	runnable.
In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>
Message-ID: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

One can currently save the contents of a shell window exactly as is, with opening message, prompts, and restarts. This essentially a screenshot of the frame -- fine for an IDLE doc but not useful for rerunning the code.
Similarly, if one pastes in interactive input/output, with or without secondary prompts, into an edit window, it is a nuisance to edit.

This issue proposes an option to 'flip' code and output lines, with prompts deleted and outputs commented, so that

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 1+2
3

becomes

#Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
#Type "copyright", "credits" or "license()" for more information.
1+2
#3

(Ignore linewrap artifact on first line).

----------
components: IDLE
messages: 133592
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: make interactive code runnable.
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 12 21:56:30 2011
From: report at bugs.python.org (Paolo Elvati)
Date: Tue, 12 Apr 2011 19:56:30 +0000
Subject: [New-bugs-announce] [issue11839] argparse: unexpected behavior of
	default for	FileType('w')
In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>
Message-ID: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>


New submission from Paolo Elvati <elvati at umich.edu>:

Hi,
when a default is specified for a file argument that is open with writing permission (FileType('w')), the default file is always created even if the argument is specified in the command line. 
For example he code:

import argparse 
parser = argparse.ArgumentParser() 
parser.add_argument( 
"-o", 
default = 'fake', 
dest = 'OutputFile', 
type = argparse.FileType('w') 
) 
args = parser.parse_args() 

will create the empty file "fake" even if the -o option is given. 
The value inside the code of args.Outputfile is not affected.

Paolo

----------
components: Library (Lib)
messages: 133598
nosy: Paolo.Elvati, bethard
priority: normal
severity: normal
status: open
title: argparse: unexpected behavior of default for FileType('w')
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 12 23:19:32 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 12 Apr 2011 21:19:32 +0000
Subject: [New-bugs-announce] [issue11840] Improvements to c-api/unicode
	documentation
In-Reply-To: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>
Message-ID: <1302643172.01.0.948666081662.issue11840@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
After reading tomo cocoa mail at docs@ I gave a look at c-api/unicode file and fixed some minor editing issues.

Regards,
Sandro

----------
assignee: docs at python
components: Documentation
files: unicode_doc-default.patch
keywords: patch
messages: 133600
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Improvements to c-api/unicode documentation
versions: Python 3.3
Added file: http://bugs.python.org/file21635/unicode_doc-default.patch

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

From report at bugs.python.org  Wed Apr 13 11:19:40 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 13 Apr 2011 09:19:40 +0000
Subject: [New-bugs-announce] [issue11841] Bug in the verson comparison
In-Reply-To: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>
Message-ID: <1302686380.66.0.407051830429.issue11841@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The NormalizedVersion class is not correctly sorting rc1:

>>> from packaging.version import NormalizedVersion
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0rc1')
True
>>> NormalizedVersion('0.7.0rc1')
NormalizedVersion('0.7rc1')
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0a1')
False
>>> NormalizedVersion('0.7.0') < NormalizedVersion('0.7.0c1')
False

----------
assignee: tarek
components: Distutils2
messages: 133656
nosy: alexis, brett.cannon, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Bug in the verson comparison
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 13 22:50:53 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 13 Apr 2011 20:50:53 +0000
Subject: [New-bugs-announce] [issue11842] slice.indices with negative step
	and default stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

slice.indices behaves strangely with negative step and default stop values (note that the doc says that it "computes information about the slice that the slice object would describe if applied to a sequence of length items"):

>>> s = slice(None, None, -2)
>>> s.indices(10)
(9, -1, -2)
>>> list(range(10))[9:-1:-2]
[]
>>> list(range(10))[s]
[9, 7, 5, 3, 1]
>>> 

Also with start given:

>>> s = slice(8, None, -2)
>>> s.indices(10)
(8, -1, -2)
>>> list(range(10))[8:-1:-2]
[]
>>> list(range(10))[s]
[8, 6, 4, 2, 0]
>>> 

Strangely giving these indices to range works:

>>> s = slice(8, None, -2)
>>> s.indices(10)
(8, -1, -2)
>>> list(range(8, -1, -2))
[8, 6, 4, 2, 0]
>>>

----------
components: Interpreter Core
messages: 133694
nosy: durban, mark.dickinson
priority: normal
severity: normal
status: open
title: slice.indices with negative step and default stop
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Apr 14 14:05:32 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 14 Apr 2011 12:05:32 +0000
Subject: [New-bugs-announce] [issue11843] distutils doc: duplicate line in
	table
In-Reply-To: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>
Message-ID: <1302782732.33.0.79290372609.issue11843@psf.upfronthosting.co.za>


New submission from Steven Samuel Cole <steven.samuel.cole at gmail.com>:

in the first table on http://docs.python.org/distutils/builtdist.html (search for 'available formats for built distributions'), the line with 'rpm / RPM / (5)' is in there twice

----------
assignee: docs at python
components: Documentation
messages: 133730
nosy: docs at python, ssc
priority: normal
severity: normal
status: open
title: distutils doc: duplicate line in table
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr 14 21:35:48 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Apr 2011 19:35:48 +0000
Subject: [New-bugs-announce] [issue11844] Update json to upstream simplejson
	latest release
In-Reply-To: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>
Message-ID: <1302809748.45.0.3421678902.issue11844@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

This issue is to track the update process of json to the latest upstream release (2.1.3).

As a start, here's the p-dev thread: http://mail.python.org/pipermail/python-dev/2011-April/110704.html

----------
assignee: sandro.tosi
components: Library (Lib)
messages: 133765
nosy: sandro.tosi
priority: normal
severity: normal
status: open
title: Update json to upstream simplejson latest release
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 14 21:50:48 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Apr 2011 19:50:48 +0000
Subject: [New-bugs-announce] [issue11845] Refcounting error in
	compute_slice_indices in	rangeobject.c
In-Reply-To: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>
Message-ID: <1302810648.64.0.569357364768.issue11845@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The attached crash.py script reliably crashes the 3.2 and 3.3 interpreter on my machine. The script does a lot of range slicing.

I think there is a typo in compute_slice_indices() in rangeobject.c, in line 475. In line 474 there is an assign to tmp_stop, and on the next line tmp_start is incref'd (I think instead of tmp_stop).

With this patch, the interpreter doesn't crash any more:

diff -r 7563f10275a2 Objects/rangeobject.c
--- a/Objects/rangeobject.c	Thu Apr 14 13:20:41 2011 +0800
+++ b/Objects/rangeobject.c	Thu Apr 14 21:40:32 2011 +0200
@@ -472,7 +472,7 @@
                     if (tmp_stop == NULL) goto Fail;
                 } else {
                     tmp_stop = r->length;
-                    Py_INCREF(tmp_start);
+                    Py_INCREF(tmp_stop);
                 }
             }
         }

----------
components: Interpreter Core
files: crash.py
messages: 133766
nosy: durban, ncoghlan
priority: normal
severity: normal
status: open
title: Refcounting error in compute_slice_indices in rangeobject.c
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21666/crash.py

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

From report at bugs.python.org  Thu Apr 14 23:12:47 2011
From: report at bugs.python.org (Anthony Long)
Date: Thu, 14 Apr 2011 21:12:47 +0000
Subject: [New-bugs-announce] [issue11846] Implementation question for (-5) -
	256 caching, and doc update for c-api/int.html
In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>
Message-ID: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

http://docs.python.org/c-api/int.html

"The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object. So it should be possible to change the value of 1. I suspect the behaviour of Python in this case is undefined. :-)"

This paragraph should be changed to reflect that you can (by construction) mutate anything you want in C, and (as per suggestion of dmalcolm)

"The current implementatin consolidates integers in the range -5 to 256 (inclusive) into singleton instances.  Do not manipulate the internal value of a PyIntObject after creation."

Also, the last line of that paragraph insinuates this functionality (caching of -5 to 256) is undocumented. I searched for a good while for an answer for this, and I didn't find one. If there is something written on the implementation details surrounding why '-5 is -5' works, while -6 is -6' wouldn't. 

If there is nothing written about this, I will put something together. My final question however which I have not been able to find an answer for, is: Is this even necessary functionality?

I encountered around 100 blog posts and a couple of stackoverflow questions about why this fails, and it seems like 1) a source of confusion 2) a point of ridicule. Is it really necessary?

>>> id(1)
4298196440
>>> a = 1
>>> id(a)
4298196440
>>> id(3000)
4320396376
>>> a = 3000
>>> id(a)
4320396160
>>>

----------
components: Library (Lib)
messages: 133769
nosy: antlong
priority: normal
severity: normal
status: open
title: Implementation question for (-5) - 256 caching, and doc update for c-api/int.html
type: behavior

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

From report at bugs.python.org  Fri Apr 15 00:03:51 2011
From: report at bugs.python.org (ackounts)
Date: Thu, 14 Apr 2011 22:03:51 +0000
Subject: [New-bugs-announce] [issue11847] OSError importing antigravity
	module
In-Reply-To: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>
Message-ID: <1302818631.56.0.0963133113635.issue11847@psf.upfronthosting.co.za>


New submission from ackounts <ackounts at gmail.com>:

When I try to import antigravity module on Linux I get an error (on Windows it runs fine):

Python 3.2 (r32:88445, Feb 21 2011, 01:55:53) 
[GCC 4.5.2 20110127 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import antigravity
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/antigravity.py", line 5, in <module>
    webbrowser.open("http://xkcd.com/353/")
  File "/usr/lib/python3.2/webbrowser.py", line 62, in open
    if browser.open(url, new, autoraise):
  File "/usr/lib/python3.2/webbrowser.py", line 276, in open
    success = self._invoke(args, True, autoraise)
  File "/usr/lib/python3.2/webbrowser.py", line 239, in _invoke
    stderr=inout, preexec_fn=setsid)
  File "/usr/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.2/subprocess.py", line 1330, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
messages: 133776
nosy: ackounts
priority: normal
severity: normal
status: open
title: OSError importing antigravity module
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 15 07:04:07 2011
From: report at bugs.python.org (Brandon W Maister)
Date: Fri, 15 Apr 2011 05:04:07 +0000
Subject: [New-bugs-announce] [issue11848] Comment for random.betavariate is
	intriguing and	incomplete
In-Reply-To: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>
Message-ID: <1302843847.91.0.747010170012.issue11848@psf.upfronthosting.co.za>


New submission from Brandon W Maister <quodlibetor at gmail.com>:

The comment just before the random.betavariate method reads in part:

## See
## http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470
## for Ivan Frohne's insightful analysis of why the original implementation:
## (snip original implementation) was dead wrong, and how it propbably got that way.

And I would like to read that comment, but the buglink is pretty deeply dead. I'm not sure what the correct thing to do here is, maybe stick the text of the bug into the comment, or just update the link.

But I'm definitely curious. Thanks.

----------
components: Demos and Tools
messages: 133788
nosy: quodlibetor
priority: normal
severity: normal
status: open
title: Comment for random.betavariate is intriguing and incomplete

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

From report at bugs.python.org  Fri Apr 15 11:08:38 2011
From: report at bugs.python.org (Kaifeng Zhu)
Date: Fri, 15 Apr 2011 09:08:38 +0000
Subject: [New-bugs-announce] [issue11849] ElementTree memory leak
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>


New submission from Kaifeng Zhu <cafeeee at gmail.com>:

I'm using xml.etree.ElementTree to parse large XML file, while the memory keep increasing consistently.

You can run attached test script to reproduce it.  From 'top' in Linux or 'Task Manager' in Windows, the memory usage of python is not decreased as expected when 'Done' is printed.

Tested with Python 2.5/3.1 in Windows 7, and Python 2.5 in CentOS 5.3.

----------
components: XML
files: test.py
messages: 133797
nosy: Kaifeng.Zhu
priority: normal
severity: normal
status: open
title: ElementTree memory leak
type: resource usage
versions: Python 2.5, Python 3.1
Added file: http://bugs.python.org/file21669/test.py

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

From report at bugs.python.org  Fri Apr 15 13:11:18 2011
From: report at bugs.python.org (JoeKuan)
Date: Fri, 15 Apr 2011 11:11:18 +0000
Subject: [New-bugs-announce] [issue11850] mktime - OverflowError: mktime
	argument out of range -	on very specific time
In-Reply-To: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>
Message-ID: <1302865878.94.0.0974910959.issue11850@psf.upfronthosting.co.za>


New submission from JoeKuan <kuan.joe at gmail.com>:

>>> a = (1970, 1, 1, 0, 59, 58, 0, 0, 0)
>>> time.mktime(a)
-2.0

>>> a = (1970, 1, 1, 0, 59, 59, 0, 0, 0)
>>> time.mktime(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range

>>> a = (1970, 1, 1, 1, 0, 0, 0, 0, 0)
>>> time.mktime(a)
0.0

>>> a = (1970, 1, 1, 0, 59, 60, 0, 0, 0)
>>> time.mktime(a)
0.0

----------
messages: 133806
nosy: JoeKuan
priority: normal
severity: normal
status: open
title: mktime - OverflowError: mktime argument out of range - on very specific time
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 15 15:41:26 2011
From: report at bugs.python.org (Edzard Pasma)
Date: Fri, 15 Apr 2011 13:41:26 +0000
Subject: [New-bugs-announce] [issue11851] Flushing the standard input causes
	an error
Message-ID: <1302874886.31.0.794832456015.issue11851@psf.upfronthosting.co.za>


Changes by Edzard Pasma <pasma10 at concepts.nl>:


----------
components: None
nosy: pasma10 at concepts.nl
priority: normal
severity: normal
status: open
title: Flushing the standard input causes an error
type: behavior

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

From report at bugs.python.org  Fri Apr 15 20:34:53 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Fri, 15 Apr 2011 18:34:53 +0000
Subject: [New-bugs-announce] [issue11852] New QueueListener is unusable due
	to threading and queue	import
In-Reply-To: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>
Message-ID: <1302892493.02.0.649799543417.issue11852@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

How to reproduce:

>>> from logging.handlers import QueueListener
>>> from multiprocessing import Queue
>>> q = Queue(100)
>>> l = QueueListener(q)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python32\lib\logging\handlers.py", line 1234, in __init__
    self._stop = threading.Event()
NameError: global name 'threading' is not defined

And after adding the 'threading' import, you run into a second missing module:

Traceback (most recent call last):
  File "C:\Python32\lib\threading.py", line 736, in _bootstrap_inner
    self.run()
  File "C:\Python32\lib\threading.py", line 689, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python32\lib\logging\handlers.py", line 1297, in _monitor
    except queue.Empty:
NameError: global name 'queue' is not defined
 
Solution:

Adds import of 'threading' and 'queue' module in logging.handlers module.

----------
components: Library (Lib)
messages: 133862
nosy: blep
priority: normal
severity: normal
status: open
title: New QueueListener is unusable due to threading and queue import
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 16 05:48:27 2011
From: report at bugs.python.org (John DeNero)
Date: Sat, 16 Apr 2011 03:48:27 +0000
Subject: [New-bugs-announce] [issue11853] idle3.2 on mac unresponsive on
	input() called from a	source file
In-Reply-To: <1302925707.76.0.539725680969.issue11853@psf.upfronthosting.co.za>
Message-ID: <1302925707.76.0.539725680969.issue11853@psf.upfronthosting.co.za>


New submission from John DeNero <denero at google.com>:

idle3.2 becomes unresponsive if the input() function is called from a source file run via F5.

To repeat:
- Create a script file with the contents: "input()"
- Press F5 to run
- Idle is now unresponsive and ^C interrupt is not caught unless issued at the command line

Note that calling input() from idle's interactive shell works fine, as does running the script from the command line.

----------
components: IDLE
files: input.py
messages: 133878
nosy: John.DeNero
priority: normal
severity: normal
status: open
title: idle3.2 on mac unresponsive on input() called from a source file
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21679/input.py

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

From report at bugs.python.org  Sat Apr 16 07:29:55 2011
From: report at bugs.python.org (Robert Burke)
Date: Sat, 16 Apr 2011 05:29:55 +0000
Subject: [New-bugs-announce] [issue11854] __or__, __and__, __sub__,
	and __xor__ instantiate subclass of set without calling __init__
In-Reply-To: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>
Message-ID: <1302931795.31.0.443472549499.issue11854@psf.upfronthosting.co.za>


New submission from Robert Burke <sharpobject at gmail.com>:

If you create a subclass of set but do not override __or__, __and__, __xor__, and __sub__, calling these functions will yield a new instance of your subclass.  The new instance will never have __init__ called on it.  Depending on what you expect __init__ to do, this can cause problems later on.

The simplest solution would be to make these functions work like list.__add__.  If you have two instances of some list subclass (foo and bar), type(foo.__add__(bar)) will just be list.

----------
files: demo
messages: 133880
nosy: Robert.Burke
priority: normal
severity: normal
status: open
title: __or__, __and__, __sub__, and __xor__ instantiate subclass of set without calling __init__
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file21680/demo

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

From report at bugs.python.org  Sat Apr 16 13:54:04 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 11:54:04 +0000
Subject: [New-bugs-announce] [issue11855] urlretrieve --> urlretrieve()
In-Reply-To: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>
Message-ID: <1302954844.99.0.142574002037.issue11855@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

A typo in the docs was found here: http://docs.python.org/library/urllib.html#urllib.urlretrieve

Two instances of the word "urlretrieve" need to be "urlretrieve()", as other instances of it are, with that fancy color and a link-like look. You know what I mean. If you care, please fix this.

----------
assignee: docs at python
components: Documentation
messages: 133887
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: urlretrieve --> urlretrieve()
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr 16 14:19:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Apr 2011 12:19:22 +0000
Subject: [New-bugs-announce] [issue11856] Optimize parsing of JSON numbers
In-Reply-To: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>
Message-ID: <1302956362.08.0.216789404235.issue11856@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In Python 3.x, parsing JSON numbers involve calling PyLong_FromUnicode or PyFloat_FromString with an unicode object. These functions are quite costly because they call PyUnicode_TransformDecimalToASCII(). But JSON numbers are always pure ASCII. This patch does the ASCII conversion ourselves.

Small benchmark with integers:
./python -m timeit -s \
  "from json import loads, dumps; d=list(i for i in range(1000)); s=dumps(d)" \
  "loads(s)"

-> without patch: 705 usec per loop
-> with patch: 103 usec per loop

----------
components: Library (Lib)
files: jsonnumbers.patch
keywords: patch
messages: 133891
nosy: mark.dickinson, pitrou, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize parsing of JSON numbers
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file21681/jsonnumbers.patch

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

From report at bugs.python.org  Sat Apr 16 17:33:27 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 16 Apr 2011 15:33:27 +0000
Subject: [New-bugs-announce] [issue11857] Hyphenate the argparse.rst file,
	patch added
In-Reply-To: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>
Message-ID: <1302968007.13.0.0484662149603.issue11857@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please apply this patch. And fix the occurences where you think the word "command line" acts as a noun.

----------
assignee: docs at python
components: Documentation
files: argparse.patch
keywords: patch
messages: 133893
nosy: Retro, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Hyphenate the argparse.rst file, patch added
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21682/argparse.patch

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

From report at bugs.python.org  Sat Apr 16 18:48:34 2011
From: report at bugs.python.org (Pink)
Date: Sat, 16 Apr 2011 16:48:34 +0000
Subject: [New-bugs-announce] [issue11858] configparser.ExtendedInterpolation
	and section case
In-Reply-To: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>
Message-ID: <1302972514.64.0.403074363027.issue11858@psf.upfronthosting.co.za>


New submission from Pink <ciasoms at gmail.com>:

configparser.ExtendedInterpolation in Python 3.2 has a bug that it will convert the section name in the interpolation to lowercase, and lead to an exception of NoSectionError if the section name has letters in uppercase.

In fact it just cannot pass the test of the second example in the doc (http://docs.python.org/py3k/library/configparser.html#configparser.ExtendedInterpolation).

The attached patch should fix it.

----------
components: Library (Lib)
files: configparser.diff
keywords: patch
messages: 133897
nosy: ciasoms, lukasz.langa
priority: normal
severity: normal
status: open
title: configparser.ExtendedInterpolation and section case
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file21685/configparser.diff

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

From report at bugs.python.org  Sun Apr 17 00:57:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2011 22:57:11 +0000
Subject: [New-bugs-announce] [issue11859] test_interrupted_write_text() of
	test_io failed of	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_interrupted_write_text() of test_io failed of Python 3.3 on FreeBSD 7.2:
-----------------------------------------------
[250/354] test_io
Exception in thread Thread-1316:
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 735, in _bootstrap_inner
    self.run()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 688, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2630, in _read
    s = os.read(r, 1)
OSError: [Errno 4] Interrupted system call

Timeout (1:00:00)!
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2651 in check_interrupted_write
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2672 in test_interrupted_write_text
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 442 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 494 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1078 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1166 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1192 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 2845 in test_main
  File "./Lib/test/regrtest.py", line 1041 in runtest_inner
  File "./Lib/test/regrtest.py", line 835 in runtest
  File "./Lib/test/regrtest.py", line 659 in main
  File "./Lib/test/regrtest.py", line 1619 in <module>
*** Error code 1

Stop in /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build.
program finished with exit code 1
elapsedTime=8703.824572
-----------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1695/steps/test/logs/stdio

----------
components: Tests
messages: 133908
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_interrupted_write_text() of test_io failed of Python 3.3 on FreeBSD 7.2
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 17 03:53:24 2011
From: report at bugs.python.org (Mike Kamermans)
Date: Sun, 17 Apr 2011 01:53:24 +0000
Subject: [New-bugs-announce] [issue11860] reference 2.3 has text that runs
	past the page
In-Reply-To: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>
Message-ID: <1303005204.18.0.459182918365.issue11860@psf.upfronthosting.co.za>


New submission from Mike Kamermans <nihongo at gmail.com>:

page 8 for the python 3.2 refernce document ("identifiers and keywords") has text that runs way past the page. This document (and probably every other document) should be run through LaTeX again with draft, to find all instances where text doesn't fit on the page, so that this can be fixed.

----------
assignee: docs at python
components: Documentation
messages: 133916
nosy: Mike.Kamermans, docs at python
priority: normal
severity: normal
status: open
title: reference 2.3 has text that runs past the page
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr 17 15:12:18 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 17 Apr 2011 13:12:18 +0000
Subject: [New-bugs-announce] [issue11861] 2to3 fails with a ParseError
In-Reply-To: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>
Message-ID: <1303045938.22.0.287313368996.issue11861@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

2to3 fails on boto/rds/__init__.py with a ParseError:

vinay at eta-natty:~/tools/boto$ 2to3 boto/rds/__init__.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Can't parse boto/rds/__init__.py: ParseError: bad input: type=1, value='RDSRegionInfo', context=('\n            ', (48, 12))
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse boto/rds/__init__.py: ParseError: bad input: type=1, value='RDSRegionInfo', context=('\n            ', (48, 12))

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: __init__.py
messages: 133922
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: 2to3 fails with a ParseError
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21693/__init__.py

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

From report at bugs.python.org  Sun Apr 17 20:23:14 2011
From: report at bugs.python.org (Tomasz Melcer)
Date: Sun, 17 Apr 2011 18:23:14 +0000
Subject: [New-bugs-announce] [issue11862] urlparse.ParseResult to have
	meaningful __str__
In-Reply-To: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>
Message-ID: <1303064594.29.0.64850729087.issue11862@psf.upfronthosting.co.za>


New submission from Tomasz Melcer <liori at o2.pl>:

I find it a minor annoyance that a result of `urlparse.urlparse` (an object of class urlparse.ParseResult) doesn't have a meaningful __str__/__unicode__ methods. `urlparse.ParseResult` is a subclass of `namedtuple` with __slots__, so I can't easily add it, too.

I propose to make __str__/__unicode__ equivalent to geturl() call.

----------
components: Extension Modules
messages: 133934
nosy: liori
priority: normal
severity: normal
status: open
title: urlparse.ParseResult to have meaningful __str__
type: feature request

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

From report at bugs.python.org  Mon Apr 18 02:08:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 00:08:57 +0000
Subject: [New-bugs-announce] [issue11863] Enforce PEP 11 - remove support
	for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PEP 11 calls for removing support for the following systems in 3.3:

    Name:             Systems using Mach C Threads
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             SunOS lightweight processes (LWP)
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             Systems using --with-pth (GNU pth threads)
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             Systems using Irix threads
    Unsupported in:   Python 3.2
    Code removed in:  Python 3.3

    Name:             OSF* systems (issue 8606)
    Unsupported in:   Python 3.2 
    Code removed in:  Python 3.3

----------
components: Build, Interpreter Core
keywords: easy
messages: 133944
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Enforce PEP 11 - remove support for legacy systems
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 18 02:12:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Apr 2011 00:12:52 +0000
Subject: [New-bugs-announce] [issue11864] sporadic failure in
	test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Happened on a buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2957/steps/test/logs/stdio

test test_concurrent_futures failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_concurrent_futures.py", line 276, in test_timeout
    future1]), finished)
AssertionError: Items in the first set but not the second:
<Future at 0xb802dc8 state=running>

----------
components: Library (Lib), Tests
messages: 133945
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: sporadic failure in test_concurrent_futures
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 18 08:51:14 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Mon, 18 Apr 2011 06:51:14 +0000
Subject: [New-bugs-announce] [issue11865] typo in Py_AddPendingCall document
In-Reply-To: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>
Message-ID: <1303109474.81.0.645690585196.issue11865@psf.upfronthosting.co.za>


New submission from Zhiping Deng <kofreestyler at gmail.com>:

http://docs.python.org/c-api/init.html?highlight=py_addpendingcall#Py_AddPendingCall

void Py_AddPendingCall(int (*func)(void *, void *arg))
which should be 
void Py_AddPendingCall(int (*func)(void *), void *arg)

----------
assignee: docs at python
components: Documentation
messages: 133953
nosy: Zhiping.Deng, docs at python
priority: normal
severity: normal
status: open
title: typo in Py_AddPendingCall document
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 18 13:29:02 2011
From: report at bugs.python.org (Peter Saveliev)
Date: Mon, 18 Apr 2011 11:29:02 +0000
Subject: [New-bugs-announce] [issue11866] race condition in
	threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>


New submission from Peter Saveliev <svinota.saveliev at gmail.com>:

The _newname() function has no locking.

It is called from the new thread constructor. Such constructor is executed within parent thread. So, when several threads create new threads simultaneously, there can be race condition, leading to the same name for two (or even more) threads.

8<--------------------------------

>>> import threading
>>> import dis
>>> dis.dis(threading._newname)
403           0 LOAD_GLOBAL              0 (_counter)
              3 LOAD_CONST               1 (1)
              6 BINARY_ADD         
              7 STORE_GLOBAL             0 (_counter)

404          10 LOAD_FAST                0 (template)
             13 LOAD_GLOBAL              0 (_counter)
             16 BINARY_MODULO      
             17 RETURN_VALUE       
>>> 
8<--------------------------------

The race condition can be achieved between BINARY_ADD and STORE_GLOBAL. Several threads can do BINARY_ADD before the first one will do STORE_GLOBAL. All racing threads will get the same name.

8<--------------------------------
$ for i in `seq 0 100`; do python thread_test.py |\
 awk -F Thread- '{print $2}' |\
 grep -vE '^$' |\
 sort |\
 uniq -c -d; done
      2 35
      2 12
      ...
8<--------------------------------

As you see, there are cases when several threads can get same name.

Proposals: use thread-safe increment counter (with atomic get-increment) like itertools.counter() (that does not release GIL)

----------
components: Extension Modules
files: thread_test.py
messages: 133963
nosy: Peter.Saveliev
priority: normal
severity: normal
status: open
title: race condition in threading._newname()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file21704/thread_test.py

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

From report at bugs.python.org  Mon Apr 18 15:19:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Apr 2011 13:19:04 +0000
Subject: [New-bugs-announce] [issue11867] Make test_mailbox deterministic
In-Reply-To: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>
Message-ID: <1303132744.64.0.479347573965.issue11867@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Attached is a patch to remove the last sleeps from test_mailbox.  I believe this makes the test suite deterministic.  It also shaves 4 seconds of fixed overhead off the test run time.

----------
components: Tests
files: mailbox_fork_with_ipc.patch
keywords: buildbot, patch
messages: 133967
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Make test_mailbox deterministic
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21705/mailbox_fork_with_ipc.patch

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

From report at bugs.python.org  Mon Apr 18 18:09:45 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 18 Apr 2011 16:09:45 +0000
Subject: [New-bugs-announce] [issue11868] Minor word-choice improvement in
	devguide "lifecycle of	a patch" opening paragraph
In-Reply-To: <1303142985.47.0.930183800843.issue11868@psf.upfronthosting.co.za>
Message-ID: <1303142985.47.0.930183800843.issue11868@psf.upfronthosting.co.za>


New submission from Carl Meyer <carl at dirtcircle.com>:

The opening paragraph of the "lifecycle of a patch" devguide page contains a confusing parenthetical aside implying that an "svn-like" workflow would mean never *saving* anything to your working copy and using "hg diff" to generate a patch. This is obviously wrong given the usual meaning of "save": if you never save anything to your working copy, "hg diff" will be empty.

Patch attached with proposed alternative wording.

----------
components: Devguide
files: svn-like-wording.diff
keywords: patch
messages: 133978
nosy: carljm
priority: normal
severity: normal
status: open
title: Minor word-choice improvement in devguide "lifecycle of a patch" opening paragraph
versions: 3rd party
Added file: http://bugs.python.org/file21707/svn-like-wording.diff

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

From report at bugs.python.org  Mon Apr 18 22:00:08 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2011 20:00:08 +0000
Subject: [New-bugs-announce] [issue11869] Include information about the bug
	tracker Rietveld code	review tool
In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>
Message-ID: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

As far as I can see, the developer's guide does not mention at all the new Rietveld code review tool integration with the Python bug tracker.  The guide should describe how the tool is expected to be used both by core developers reviewing submitted patches and by patch submitters.

----------
components: Devguide
messages: 133989
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Include information about the bug tracker Rietveld code review tool

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

From report at bugs.python.org  Mon Apr 18 22:18:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 20:18:00 +0000
Subject: [New-bugs-announce] [issue11870]
	test_3_join_in_forked_from_thread() of test_threading	hangs 1
	hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_3_join_in_forked_from_thread() of test_threading failed on "x86 Ubuntu Shared 3.x" buildbot:
-----------------------------------
[201/354] test_threading
[41179 refs]
[40407 refs]
[40407 refs]
[40407 refs]
Timeout (1:00:00)!
Thread 0x404218c0:
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 466 in _eintr_retry_call
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1486 in _try_wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1528 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 455 in _run_and_join
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 518 in test_3_join_in_forked_from_thread
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 387 in _executeTestPart
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 442 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 494 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1078 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1166 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1192 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 728 in test_main
  File "./Lib/test/regrtest.py", line 1041 in runtest_inner
  File "./Lib/test/regrtest.py", line 835 in runtest
  File "./Lib/test/regrtest.py", line 659 in main
  File "./Lib/test/regrtest.py", line 1619 in <module>
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=4426.776675
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/3577/steps/test/logs/stdio
-----------------------------------

Code of the test:
----------------------------------
    def _run_and_join(self, script):
        script = """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')
                # stdout is fully buffered because not a tty, we have to flush
                # before exit.
                sys.stdout.flush()
        \n""" + script

        p = subprocess.Popen([sys.executable, "-c", script], stdout=subprocess.PIPE)
        rc = p.wait() <~~~ HANG HERE?~~~~
        data = p.stdout.read().decode().replace('\r', '')
        p.stdout.close()
        self.assertEqual(data, "end of main\nend of thread\n")
        self.assertFalse(rc == 2, "interpreter was blocked")
        self.assertTrue(rc == 0, "Unexpected error")

    @unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
    def test_3_join_in_forked_from_thread(self):
        # Like the test above, but fork() was called from a worker thread
        # In the forked process, the main Thread object must be marked as stopped.

        # Skip platforms with known problems forking from a worker thread.
        # See http://bugs.python.org/issue3863.
        if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'netbsd5',
                           'os2emx'):
            raise unittest.SkipTest('due to known OS bugs on ' + sys.platform)
        script = """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('end of main')
                t.start()
                t.join() # Should not block: main_thread is already stopped

            w = threading.Thread(target=worker)
            w.start()
            """
        self._run_and_join(script)
----------------------------------

----------
components: Tests
messages: 133990
nosy: haypo
priority: normal
severity: normal
status: open
title: test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 18 23:59:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2011 21:59:04 +0000
Subject: [New-bugs-announce] [issue11871] test_default_timeout() of
	test_threading.BarrierTests	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While trying to reproduce issue #11870 using "gdb -args ./python Lib/test/regrtest.py -F -v --timeout=600 test_threading", I had the following error on Linux:
----------------------
test_default_timeout (test.test_threading.BarrierTests) ... [Thread 0x7ffff1acf700 (LWP 27178) exited]
[New Thread 0x7ffff1acf700 (LWP 27181)]
[New Thread 0x7ffff12ce700 (LWP 27182)]
[New Thread 0x7ffff3c99700 (LWP 27183)]
[New Thread 0x7ffff325a700 (LWP 27184)]
Unhandled exception in thread started by <function task at 0x1302340>
Unhandled exception in thread started by <function task at 0x1302340>
Unhandled exception in thread started by <function task at 0x1302340>
Traceback (most recent call last):
Unhandled exception in thread started by <function task at 0x1302340>
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
    f()
    f()
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 37, in task
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 838, in f
ERROR
----------------------

----------------------
ERROR: test_default_timeout (test.test_threading.BarrierTests)

Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 843, in test_default_timeout
    self.run_threads(f)
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 672, in run_threads
    f()
  File "/home/haypo/prog/HG/cpython/Lib/test/lock_tests.py", line 838, in f
    i = barrier.wait()
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 472, in wait
    self._enter() # Block while the barrier drains.
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 496, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
----------------------

The error occured on:

 * Ubuntu 10.04
 * Python 3.3 (2127df2c972e)
 * Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
 * 4 GB of memory

----------
components: Tests
messages: 133995
nosy: haypo
priority: normal
severity: normal
status: open
title: test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 19 10:06:02 2011
From: report at bugs.python.org (MattyG)
Date: Tue, 19 Apr 2011 08:06:02 +0000
Subject: [New-bugs-announce] [issue11872] cPickle gives strange error for
	large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>


New submission from MattyG <meawoppl at gmail.com>:

from numpy import *
import cPickle

a = zeros((300000, 1000)) 
f = open("test.pkl", "w") 
cPickle.dump(a, f)

------
SystemError: Traceback (most recent call last)

/home/kddcup/code/matt/svd-projection/take5/<ipython console> in <module>()

SystemError?: error return without exception set

Or using the .dump function:

a.dump("test.pkl")

SystemError? Traceback (most recent call last)

/home/kddcup/code/matt/svd-projection/take5/<ipython console> in <module>()

SystemError: NULL result without error in PyObject?_Call

I am not sure if this is a numpy or Pickle/cPickle glitch. In either case, even if this is a semi-known behavior, a more instructive error message would certainly help. I think the problem only happens for arrays larger than 2**(32-1) bytes but I would have to experiment more to be sure.

----------
components: Extension Modules
messages: 134017
nosy: meawoppl
priority: normal
severity: normal
status: open
title: cPickle gives strange error for large objects.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 19 10:12:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 08:12:22 +0000
Subject: [New-bugs-announce] [issue11873] test_regexp() of test_compileall
	failure on "x86	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Trace:
----------------------------------------------------------------------
[ 30/354] test_compileall
test test_compileall failed -- Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_compileall.py", line 253, in test_regexp
    self.assertCompiled(self.initfn)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_compileall.py", line 149, in assertCompiled
    self.assertTrue(os.path.exists(imp.cache_from_source(fn)))
AssertionError: False is not true
----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1097/steps/test/logs/stdio

----------
components: Tests
messages: 134019
nosy: haypo
priority: normal
severity: normal
status: open
title: test_regexp() of test_compileall failure on "x86 OpenIndiana 3.x"
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 19 10:20:52 2011
From: report at bugs.python.org (Hartmut Niemann)
Date: Tue, 19 Apr 2011 08:20:52 +0000
Subject: [New-bugs-announce] [issue11874] argparse assertion failure with
	brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>


New submission from Hartmut Niemann <Hartmut.Niemann at siemens.com>:

I run this script with option --help
-----8<------------------
import argparse
parser = argparse.ArgumentParser()
parser.add_argument ('--from-itm', dest="from_itm",action="store",default=None,help ="Source ITM file", metavar="ITMFILENAME")
parser.add_argument ("--from-fbm-sigtab",dest="from_sigtab",action="store",default=None,help="Source signal FB", metavar=" [LIB,]FBNAME")
parser.add_argument ("--c",dest="f",metavar="x]d")
args = parser.parse_args()
---------8<--------------------
and I get an assertion failure:
---------8<--------------------
D:\temp>argparsebug.py --help
Traceback (most recent call last):
  File "D:\temp\argparsebug.py", line 6, in <module>
    args = parser.parse_args()
  File "C:\Python27\lib\argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Python27\lib\argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "C:\Python27\lib\argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "C:\Python27\lib\argparse.py", line 993, in __call__
    parser.print_help()
  File "C:\Python27\lib\argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "C:\Python27\lib\argparse.py", line 2277, in format_help
    return formatter.format_help()
  File "C:\Python27\lib\argparse.py", line 278, in format_help
    help = self._root_section.format_help()
  File "C:\Python27\lib\argparse.py", line 208, in format_help
    func(*args)
  File "C:\Python27\lib\argparse.py", line 329, in _format_usage
    assert ' '.join(opt_parts) == opt_usage
AssertionError
--------------8<-------------------------------
It must be the combination of several argument lines because when I 
comment out one of the add_arguments, it works.

Is this a bug or do I do things I shouln't?
If it is not allowed to use [] in metavars (what I wanted was metavar='[optional,]mantatory'), I' like to receive a readable error message.

With best regards
Hartmut Niemann

----------
components: None
messages: 134021
nosy: htnieman
priority: normal
severity: normal
status: open
title: argparse assertion failure with brackets in metavars
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 19 10:28:24 2011
From: report at bugs.python.org (Mario Juric)
Date: Tue, 19 Apr 2011 08:28:24 +0000
Subject: [New-bugs-announce] [issue11875] OrderedDict.__reduce__ not
	threadsafe
In-Reply-To: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>
Message-ID: <1303201704.87.0.690807992306.issue11875@psf.upfronthosting.co.za>


New submission from Mario Juric <mjuric at ias.edu>:

The implementation of OrderedDict.__reduce__() in Python 2.7.1 is not thread safe because of the following four lines:

        tmp = self.__map, self.__root
        del self.__map, self.__root
        inst_dict = vars(self).copy()
        self.__map, self.__root = tmp

If one thread is pickling an OrderedDict, while another accesses it, a race condition occurs if the accessing thread accesses the dict after self.__map and self.__root have been delated, and before they've been set again (above).

This leads to an extremely difficult bug to diagnose when using multiprocessing.Queue to exchange OrderedDicts between multiple processes (because Queue uses a separate feeder thread to do the pickling).

The fix seems relatively easy -- use:

        inst_dict = vars(self).copy()
        del inst_dict['_OrderedDict__map'], inst_dict['_OrderedDict__root']

instead of the above four lines.

PS: This issue+fix may also apply to Python 3.x, although I haven't tested it there.

----------
components: Library (Lib)
messages: 134023
nosy: mjuric
priority: normal
severity: normal
status: open
title: OrderedDict.__reduce__ not threadsafe
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 19 11:45:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2011 09:45:44 +0000
Subject: [New-bugs-announce] [issue11876] SGI Irix threads,
	SunOS lightweight processes, GNU pth threads,
	Mach C Threads are now unsupported, and code will be removed in 3.3
In-Reply-To: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>
Message-ID: <1303206344.55.0.955794008969.issue11876@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python/thread.c contains the following messages:

#ifdef SGI_THREADS
#error SGI Irix threads are now unsupported, and code will be removed in 3.3.
#include "thread_sgi.h"
#endif


#ifdef SUN_LWP
#error SunOS lightweight processes are now unsupported, and code will be removed in 3.3.
#include "thread_lwp.h"
#endif

#ifdef HAVE_PTH
#error GNU pth threads are now unsupported, and code will be removed in 3.3.
#include "thread_pth.h"
#undef _POSIX_THREADS
#endif

#ifdef C_THREADS
#error Mach C Threads are now unsupported, and code will be removed in 3.3.
#include "thread_cthread.h"
#endif

----------
components: Interpreter Core
messages: 134029
nosy: haypo
priority: normal
severity: normal
status: open
title: SGI Irix threads, SunOS lightweight processes, GNU pth threads, Mach C Threads are now unsupported, and code will be removed in 3.3
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 19 13:35:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Apr 2011 11:35:38 +0000
Subject: [New-bugs-announce] [issue11877] Mac OS X fsync() should really be
	fcntl(F_FULLFSYNC)
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Issue 11277 revealed that Mac OS X fsync() does not always
and gracefully synchronize file data to physical backing store.
To gain real fsync(2) behaviour fcntl(2) must be called with
the F_FULLFSYNC flag.

----------
components: Library (Lib)
files: fsync.diff
keywords: patch
messages: 134043
nosy: sdaoden
priority: normal
severity: normal
status: open
title: Mac OS X fsync() should really be fcntl(F_FULLFSYNC)
versions: Python 3.3
Added file: http://bugs.python.org/file21718/fsync.diff

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

From report at bugs.python.org  Tue Apr 19 17:17:29 2011
From: report at bugs.python.org (Michiel Van den Berghe)
Date: Tue, 19 Apr 2011 15:17:29 +0000
Subject: [New-bugs-announce] [issue11878] No SOAP libraries available for
	Python 3.x
In-Reply-To: <1303226249.65.0.757912799322.issue11878@psf.upfronthosting.co.za>
Message-ID: <1303226249.65.0.757912799322.issue11878@psf.upfronthosting.co.za>


New submission from Michiel Van den Berghe <michiel.vdb at gmail.com>:

There doesn't seem to exist a SOAP library for Python 3.x. Several different third party libraries exist for the 2.x releases, but none of these are being ported to 3.x. None of these modules are easily ported using 2to3 due to string encoding issues.

Seeing how SOAP is a major webservices technologies, I think Python should get its own standard SOAP module to keep up with its "batteries included" principle.

----------
components: Library (Lib)
messages: 134064
nosy: Michiel.Van.den.Berghe
priority: normal
severity: normal
status: open
title: No SOAP libraries available for Python 3.x
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 19 18:03:35 2011
From: report at bugs.python.org (Michael Gold)
Date: Tue, 19 Apr 2011 16:03:35 +0000
Subject: [New-bugs-announce] [issue11879] TarFile.chown: should use
	TarInfo.uid if user lookup	fails
In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>
Message-ID: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za>


New submission from Michael Gold <mgold at qnx.com>:

In TarFile.chown, if the lookup
  u = pwd.getpwnam(tarinfo.uname)[2]
fails, this line is used:
  u = pwd.getpwuid(tarinfo.uid)[2]

This will fail if the uid isn't in /etc/passwd.  I think "u = tarinfo.uid" would make more sense.  This fallback could also be used if the pwd module isn't present or tarinfo.uname isn't filled.  Here's a code sample:
    u = tarinfo.uid
    if tarinfo.uname and pwd:
        try: u = pwd.getpwnam(tarinfo.uname)[2]
        except KeyError: pass

The same issue applies to group lookup.

----------
components: Library (Lib)
messages: 134074
nosy: mgold-qnx
priority: normal
severity: normal
status: open
title: TarFile.chown: should use TarInfo.uid if user lookup fails
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 19 18:51:05 2011
From: report at bugs.python.org (dholth)
Date: Tue, 19 Apr 2011 16:51:05 +0000
Subject: [New-bugs-announce] [issue11880] add a {dist-info} category to
	distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>


New submission from dholth <dholth at fastmail.fm>:

In distutils2 there is currently no way to add files such as egg_info.txt that should be part of the package metadata. A new category named the same as the .dist-info directory would be a nice way to do it.

distutils2 should raise an error if any of the reserved files are overwritten with this feature or it should just copy these first overwriting with the reserved names.

It might be a good idea to disallow subdirectories in dist-info.

----------
assignee: tarek
components: Distutils2
messages: 134077
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: add a {dist-info} category to distutils2
type: feature request

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

From report at bugs.python.org  Tue Apr 19 20:17:10 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 19 Apr 2011 18:17:10 +0000
Subject: [New-bugs-announce] [issue11881] Add list.get
In-Reply-To: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>
Message-ID: <1303237030.15.0.691261083336.issue11881@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

I have proposed on Core Mentorship list to add get(index, default) method to list object. I was suggested to bring it up here and also told, that improving operator module could be a better solution. This is why I would like to ask, if it makes sense to work on this?

I attach a patch for list objects. I would post a link to Core Mentorship thread, but I believe the archive is private.

The original idea came from a question on StackOverflow: http://stackoverflow.com/questions/2492087/how-to-get-the-nth-element-of-a-python-list-or-a-default-if-not-available

----------
components: Interpreter Core
files: list.get.patch
keywords: patch
messages: 134087
nosy: gruszczy
priority: normal
severity: normal
status: open
title: Add list.get
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21726/list.get.patch

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

From report at bugs.python.org  Tue Apr 19 21:41:53 2011
From: report at bugs.python.org (Kasun Herath)
Date: Tue, 19 Apr 2011 19:41:53 +0000
Subject: [New-bugs-announce] [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>


New submission from Kasun Herath <kasunh01 at gmail.com>:

test_imaplib failed on x86 ubuntu machine with following error(s)

======================================================================
FAIL: test_Internaldate2tuple (test.test_imaplib.TestImaplib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

----------------------------------------------------------------------
Ran 2 tests in 0.002s

FAILED (failures=1)
test test_imaplib failed -- Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

1 test failed:
    test_imaplib

----------
components: Tests
messages: 134091
nosy: kasun
priority: normal
severity: normal
status: open
title: test_imaplib failed on x86 ubuntu
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 19 22:59:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Apr 2011 20:59:23 +0000
Subject: [New-bugs-announce] [issue11883] Call connect() before sending an
	email with smtplib
In-Reply-To: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>
Message-ID: <1303246763.2.0.10135500331.issue11883@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-April/003742.html here are a couple of patches to call connect() after smtplib.SMTP() and sendmail(). Patches are:

2.7: to be applied in 2.7 and merged into 3.1
3.2: to be applied in 3.2 and merged into default

That's because in 3.2 we have a change in the example to use send_message() instead of sendmail() (in order to allow binary contents), and so there's also a small fix to actually make use of send_message() email-simple.

----------
assignee: docs at python
components: Documentation
files: smtp_connect-2.7.patch
keywords: patch
messages: 134100
nosy: docs at python, r.david.murray, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Call connect() before sending an email with smtplib
Added file: http://bugs.python.org/file21731/smtp_connect-2.7.patch

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

From report at bugs.python.org  Wed Apr 20 09:36:50 2011
From: report at bugs.python.org (John O'Hagan)
Date: Wed, 20 Apr 2011 07:36:50 +0000
Subject: [New-bugs-announce] [issue11884] Argparse calls ngettext but
	doesn't import it
In-Reply-To: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>
Message-ID: <1303285010.85.0.710971435429.issue11884@psf.upfronthosting.co.za>


New submission from John O'Hagan <research at johnohagan.com>:

Argparse in python3.2 includes two calls to ngettext to handle error messages, but ngettext is not imported. This causes NameError to be raised instead of ArgumentError.

Changing line 93 from:

    from gettext import gettext

to:

    from gettext import gettext, ngettext 

seems to fix the problem.

----------
components: Library (Lib)
messages: 134126
nosy: johnohagan
priority: normal
severity: normal
status: open
title: Argparse calls ngettext but doesn't import it
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr 20 13:58:40 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Apr 2011 11:58:40 +0000
Subject: [New-bugs-announce] [issue11885] argparse docs needs fixing
In-Reply-To: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>
Message-ID: <1303300720.91.0.791889164093.issue11885@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Hello, I am returning to report new fixes to be made to argparse docs. The issues can be observed in this link:

http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code


1) "When most everything in optparse had either been copy-pasted over or monkey-patched ..."

"When most in optparse had either been copy-pasted over or monkey-patched ..."

Word "everything" was removed.

2) "- Replace strings with implicit arguments such as %default or %prog with the standard python syntax to use dictionaries to format strings, that is, %(default)s and %(prog)s."

"- Replace strings with implicit arguments such as %default or %prog with the standard Python syntax to use dictionaries to format strings, that is %(default)s and %(prog)s."

Word "python" was fixed to "Python" and comma was deleted after "that is".


Please fix this. Thanks.

----------
messages: 134141
nosy: Retro
priority: normal
severity: normal
status: open
title: argparse docs needs fixing

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

From report at bugs.python.org  Wed Apr 20 15:53:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 13:53:13 +0000
Subject: [New-bugs-announce] [issue11886] test_time.test_tzset() fails on
	"x86 FreeBSD 7.2 3.x":	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": 'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.
======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 209, in test_tzset
    self.assertTrue(time.tzname[0] == 'AEST', str(time.tzname[0]))
AssertionError: False is not true : EST

----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1705/steps/test/logs/stdio

See also http://en.wikipedia.org/wiki/Time_in_Australia

----------
components: Library (Lib), Tests
messages: 134153
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": AEST timezone called "EST"
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 20 17:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 15:35:53 +0000
Subject: [New-bugs-announce] [issue11887] unittest fails on comparing str
	with bytes if python has	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

assertEqual(), assertListEqual(), assertSequenceEqual() emits a BytesWarning warning or raise a BytesWarning exception if python has -b or -bb option. Attached patch adds tests to demonstrate this issue.

----------
components: Library (Lib), Tests, Unicode
messages: 134158
nosy: eric.araujo, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: unittest fails on comparing str with bytes if python has the -bb option
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 20 17:58:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Apr 2011 15:58:52 +0000
Subject: [New-bugs-announce] [issue11888] Add C99's log2() function to the
	math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The three most popular logarithm bases are 10, e, and 2.  The math library has direct function calls for the first two but not the latter which is important in informatics.

Since a direct call can use a custom algorithm or native hardware support (such as the FLDLN2 fpu instruction), it provides better speed and accuracy than our existing math.log(x, 2) option.

----------
assignee: mark.dickinson
messages: 134159
nosy: mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Add C99's log2() function to the math library
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 20 18:08:56 2011
From: report at bugs.python.org (Peter Hammer)
Date: Wed, 20 Apr 2011 16:08:56 +0000
Subject: [New-bugs-announce] [issue11889] 'enumerate' 'start' parameter
	documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>


New submission from Peter Hammer <phammer at cardious.com>:

"""
A point of confusion using the builtin function 'enumerate' and
enlightenment for those who, like me, have been confused.

Note, this confusion was discussed at length at

  http://bugs.python.org/issue2831

prior to the 'start' parameter being added to 'enumerate'.  The
confusion discussed herein was forseen in that discussion, and
ultimately discounted.  There remains, IMO, an issue with the
clarity of the documentation that needs to be addressed.  That
is, the closed issue at

  http://bugs.python.org/issue8635

concerning the 'enumerate' docstring does not address the confusion
that prompted this posting.

Consider:

x=['a','b','c','d','e']
y=['f','g','h','i','j']
print 0,y[0]
for i,c in enumerate(y,1):
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]


This code produces the following unexpected output, using python 2.7,
which is apparently the correct behavior (see commentary below).  This
example is an abstract simplification of a program defect encountered
in practice:

>>> 
0 f
1 f
b
2 g
c y[2]=g
3 h
d
4 i
e
5 j

Traceback (most recent call last):
  File "Untitled", line 9
    print x[i]
IndexError: list index out of range


Help on 'enumerate' yields:

>>> help(enumerate)
Help on class enumerate in module __builtin__:

class enumerate(object)
 |  enumerate(iterable[, start]) -> iterator for index, value of iterable
 |  
 |  Return an enumerate object.  iterable must be another object that supports
 |  iteration.  The enumerate object yields pairs containing a count (from
 |  start, which defaults to zero) and a value yielded by the iterable argument.
 |  enumerate is useful for obtaining an indexed list:
 |      (0, seq[0]), (1, seq[1]), (2, seq[2]), ...
 |  
 |  Methods defined here:
 |  
 |  __getattribute__(...)
 |      x.__getattribute__('name') <==> x.name
 |  
 |  __iter__(...)
 |      x.__iter__() <==> iter(x)
 |  
 |  next(...)
 |      x.next() -> the next value, or raise StopIteration
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __new__ = <built-in method __new__ of type object>
 |      T.__new__(S, ...) -> a new object with type S, a subtype of T

>>> 

Commentary:

The expected output was:
>>>
0 f
1 g
b y[2]=g
2 h
c
3 i
d
4 j
e
>>>

That is, it was expected that the iterator would yield a value
corresponding to the index, whether the index started at zero or not.
Using the notation of the doc string, with start=1, the expected
behavior was:

 |      (1, seq[1]), (2, seq[2]), (3, seq[3]), ...

while the actual behavior is:

 |      (1, seq[0]), (2, seq[1]), (3, seq[2]), ...

The practical problem in the real world code was to do something
special with the zero index value of x and y, then run through the
remaining values, doing one of two things with x and y, correlated,
depending on the value of y.

I can see now that the doc string does in fact correctly specify the
actual behavior: nowhere does it say the iterator will begin at any
other place than the beginning, so this is not a python bug.  I do
however question the general usefulness of such behavior.  Normally,
indices and values are expected to be correlated.

The correct behavior can be simply implemented without using
'enumerate':

x=['a','b','c','d','e']
y=['f','g','h','i','j']
print 0,y[0]
for i in xrange(1,len(y)):
  c=y[i]
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]

This produces the expected results.

If one insists on using enumerate to produce the correct behavior in
this example, it can be done as follows:
"""
x=['a','b','c','d','e']
y=['f','g','h','i','j']
seq=enumerate(y)
print '%s %s' % seq.next()
for i,c in seq:
  print i,c
  if c=='g':
    print x[i], 'y[%i]=g' % (i)
    continue
  print x[i]
"""
This version produces the expected results, while achieving clarity
comparable to that which was sought in the original incorrect code.

Looking a little deeper, the python documentation on enumerate states:

enumerate(sequence[, start=0])
Return an enumerate object. sequence must be a sequence, an iterator,
or some other object which supports iteration. The next() method of the
iterator returned by enumerate() returns a tuple containing a count
(from start which defaults to 0) and the corresponding value obtained
from iterating over iterable. enumerate() is useful for obtaining an
indexed series:
  (0, seq[0]), (1, seq[1]), (2, seq[2]),


This makes a pretty clear implication the value corresponds to the
index, so perhaps there really is an issue here.  Have at it.  I'm
going back to work, using 'enumerate' as it actually is, now that I
clearly understand it.

One thing is certain: the documentation has to be clarified, for the
confusion foreseen prior to adding the start parameter is very real.
"""

----------
components: None
messages: 134162
nosy: phammer
priority: normal
severity: normal
status: open
title: 'enumerate' 'start' parameter documentation is confusing
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 20 18:59:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 16:59:51 +0000
Subject: [New-bugs-announce] [issue11890] COMPILER WARNING: warning: offset
	outside bounds of	constant string
In-Reply-To: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>
Message-ID: <1303318791.56.0.411259673759.issue11890@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Compiling current 3.1 and 3.2 show this warning:

"""
Python/sysmodule.c:1378: warning: offset outside bounds of constant string
"""

This is a bit scary. Could be a security/stability hazard?.

----------
messages: 134164
nosy: jcea
priority: normal
severity: normal
status: open
title: COMPILER WARNING: warning: offset outside bounds of constant string
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Apr 20 19:17:38 2011
From: report at bugs.python.org (Gary Yee)
Date: Wed, 20 Apr 2011 17:17:38 +0000
Subject: [New-bugs-announce] [issue11891] Poll call in
	multiprocessing/forking.py is not thread	safe. Results in
	"OSError: [Errno 10] No child processes" exceptions.
In-Reply-To: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>
Message-ID: <1303319858.78.0.604473058282.issue11891@psf.upfronthosting.co.za>


New submission from Gary Yee <gyee at penguincomputing.com>:

Background: 

I'm using multiprocessing not to run jobs in parallel, but to run functions in a different process space so they can be done as a different user.  I am thus using multiprocessing in a multithreaded (Linux) application.

Problem:

In multiprocessing/forking.py the poll() function is not thread safe.  If multiple threads call poll() you could have two back-to-back calls to os.waitpid() on the same PID (this happens frequently when multiprocessing's _cleanup() function is called).

Traceback (most recent call last):
  File "/opt/scyld/foo.py", line 178, in call
    pool = Pool(processes=1)
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/__init__.py", line 227, in Pool
    return Pool(processes, initializer, initargs)
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/pool.py", line 104, in __init__
    w.start()
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/process.py", line 99, in start
    _cleanup()
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/process.py", line 53, in _cleanup
    if p._popen.poll() is not None:
  File "/opt/scyld/python/2.6.5/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] No child processes


Suggested Fix:

Wrap the os.waitpid() call in a try/except block looking for OSError 10 exceptions and return the returncode currently available in that event.  The one potential problem this introduces is if someone calls os.waitpid() on that PID on the process without going through forking.py.  This will result in self.returncode never being set to a non-None value.  If you're using the multiprocessing module to create processes, however, you should be also using it to clean up after itself.

I've attached a test file.

----------
components: Library (Lib)
files: foo.py
messages: 134165
nosy: Gary.Yee
priority: normal
severity: normal
status: open
title: Poll call in multiprocessing/forking.py is not thread safe.  Results in "OSError: [Errno 10] No child processes" exceptions.
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21741/foo.py

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

From report at bugs.python.org  Wed Apr 20 21:35:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Apr 2011 19:35:29 +0000
Subject: [New-bugs-announce] [issue11892] Compiler warning: warning:
	implicit declaration of	function 'finite'
In-Reply-To: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>
Message-ID: <1303328129.11.0.303568754057.issue11892@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Compiling 3.1, I get this warning:

"""
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/cmathmodule.c:77: warning: implicit declaration of function 'finite'
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/mathmodule.c:149: warning: implicit declaration of function 'finite'
/export/home/buildbot/32bits/3.1.cea-indiana-x86/build/Modules/_json.c:1222: warning: implicit declaration of function 'finite'
"""

----------
assignee: jcea
components: Build
messages: 134175
nosy: jcea
priority: normal
severity: normal
status: open
title: Compiler warning: warning: implicit declaration of function 'finite'
versions: Python 3.1

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

From report at bugs.python.org  Wed Apr 20 22:54:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Apr 2011 20:54:44 +0000
Subject: [New-bugs-announce] [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

smtplib uses a wrapper class "SSLFakeFile" in order to call readline() on an SSL socket. But modern SSL sockets have makefile(), so using that wrapper class really shouldn't necessary (of course, it must be investigated whether that's true - and we have no tests for SMTP-over-SSL AFAIK :/).

----------
components: Library (Lib)
keywords: easy
messages: 134182
nosy: giampaolo.rodola, janssen, kasun, pitrou
priority: low
severity: normal
status: open
title: Obsolete SSLFakeFile in smtplib?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 20 23:22:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2011 21:22:51 +0000
Subject: [New-bugs-announce] [issue11894] test_multiprocessing failure on
	"AMD64 OpenIndiana 3.x":	KeyError on id_to_obj[ident] in
	serve_client()
In-Reply-To: <1303334571.86.0.241463514894.issue11894@psf.upfronthosting.co.za>
Message-ID: <1303334571.86.0.241463514894.issue11894@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

[129/354] test_multiprocessing
Process Process-72:
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/process.py", line 263, in _bootstrap
    self.run()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/process.py", line 118, in run
    self._target(*self._args, **self._kwargs)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 799, in _test_event
    event.set()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 1009, in set
    return self._callmethod('set')
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 776, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 245, in serve_client
    obj, exposed, gettypeid = id_to_obj[ident]
KeyError: '4e17d80'
---------------------------------------------------------------------------
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 831, in test_event
    self.assertEqual(wait(), True)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 98, in __call__
    return self.func(*args, **kwds)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 1013, in wait
    return self._callmethod('wait', (timeout,))
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 776, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/managers.py", line 245, in serve_client
    obj, exposed, gettypeid = id_to_obj[ident]
KeyError: '4e17d80'
---------------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1025/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 134184
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing failure on "AMD64 OpenIndiana 3.x": KeyError on id_to_obj[ident] in serve_client()
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 21 05:20:13 2011
From: report at bugs.python.org (Mikhail Terekhov)
Date: Thu, 21 Apr 2011 03:20:13 +0000
Subject: [New-bugs-announce] [issue11895] pybench prep_times calculation
	error
In-Reply-To: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>
Message-ID: <1303356013.22.0.66518331753.issue11895@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov <termim at gmail.com>:

For some time now my builds of python 3.2 on x86_64 platform in SuSE OBS are failing depending on the phase of the moon. The spec file for the python3-base package uses 'make profile-opt' command to build and Makefile.pre.in uses pybench.py for profile guided optimization. The pybench.py fails sometimes with the '* Internal Error (use --debug to display the traceback)' error. Adding --debug gives 'calibration setup did not work' i.e. some of the self.overhead_times values in the Test.calibrate_test method became negative. It happens for the  NestedForLoops test. The source inspection shows that most probably it was forgotten to divide by CALIBRATION_LOOPS when calculating prep_times. The patch against current head is attached, it solves the problem.

----------
components: Demos and Tools, Installation
files: pybench.patch
keywords: patch
messages: 134192
nosy: termim
priority: normal
severity: normal
status: open
title: pybench prep_times calculation error
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21745/pybench.patch

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

From report at bugs.python.org  Thu Apr 21 08:06:06 2011
From: report at bugs.python.org (marcus harris)
Date: Thu, 21 Apr 2011 06:06:06 +0000
Subject: [New-bugs-announce] [issue11896] Save on Close fails in IDLE,
	from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>


New submission from marcus harris <harrismh777 at charter.net>:

Under some circumstances, which I will detail later down the note, if I click File --> Close without explicitly saving, and without running the module with Run --> Run Module , then the last changes I made to the file do not get saved. The save dialogue pop-up does appear, and I do select YES--- I want to save before closing--- but when I re-open the file (IDLE or vi) the changes are not there... as though the save binding did not work, or like there was some timing glitch that prevented the save somehow before the edit window closed down. The error is not solid, in that, if the file is larger (significantly) then the File --> Close (select Yes on the dialogue) does work... ??

The work around is to do either 1) run the module, or 2) explicitly click File --> Save.

The alleged bug can be reproduced on both of my primary desk machines, Linux systems, using IDLE on 2.6, 2.7, and 3.2/  These are the instructions for reproducing this little snag:

1) Open a new edit window with File --> New Window

2) Enter the following code on the first two lines:
def testfunc():
    return None

3) Click File --> Save    ( testit.py )

4) Click File --> Close

5) Open the file with  File --> Recent Files   ( select testit.py )

6) Use the edit window to place these three lines above testfunc:
############################
# comment block
##############################

7) Click    File --> Close

8) When the Save on Close dialogue appears select "Yes"

9) Re-open the file with   File --> Recent Files   ( select testit.py )

10) The comment block will not be there...  didn't save. 


Running on Ubuntu 9.10  (all updates)

Tk  8.5.x

reproduced on built-in 2.6
   & compiled from sources...   2.7  &  3.2

kind regards,
m harris

----------
components: IDLE, Library (Lib), Tkinter
messages: 134194
nosy: marcus777, terry.reedy
priority: normal
severity: normal
status: open
title: Save on Close fails in IDLE, from Linux system
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Apr 21 12:09:20 2011
From: report at bugs.python.org (intgr)
Date: Thu, 21 Apr 2011 10:09:20 +0000
Subject: [New-bugs-announce] [issue11897] [PATCH] Documentation: fix typo,
	absolute_import not absolute_imports
In-Reply-To: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>
Message-ID: <1303380560.99.0.860911638141.issue11897@psf.upfronthosting.co.za>


New submission from intgr <marti at juffo.org>:

The "Porting Python 2 Code to Python 3" guide currently says:
   from __future__ import absolute_imports

However it should be singular:
   from __future__ import absolute_import

----------
assignee: docs at python
components: Documentation
files: absolute_import_singular.patch
keywords: patch
messages: 134206
nosy: docs at python, intgr
priority: normal
severity: normal
status: open
title: [PATCH] Documentation: fix typo, absolute_import not absolute_imports
versions: Python 3.2
Added file: http://bugs.python.org/file21746/absolute_import_singular.patch

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

From report at bugs.python.org  Thu Apr 21 15:42:34 2011
From: report at bugs.python.org (Bernhard Rosenkraenzer)
Date: Thu, 21 Apr 2011 13:42:34 +0000
Subject: [New-bugs-announce] [issue11898] Sending binary data with a POST
	request in httplib can	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>


New submission from Bernhard Rosenkraenzer <bero at arklinux.org>:

Sending e.g. a JPEG file with a httplib POST request (e.g. through mechanize) can result in an error like this:

  File "/usr/lib64/python2.7/httplib.py", line 947, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.7/httplib.py", line 988, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python2.7/httplib.py", line 941, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 802, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 2566: invalid start byte


The code triggering this is the attempt to merge the msg and message_body into a single request in httplib.py lines 791+

The patch I'm attaching treats an invalid string of unknown encoding (e.g. binary data wrapped as string) like something that isn't a string.

Works for me with the patch.

----------
components: Library (Lib)
files: python-2.7.1-fix-httplib-UnicodeDecodeError.patch
keywords: patch
messages: 134211
nosy: bero
priority: normal
severity: normal
status: open
title: Sending binary data with a POST request in httplib can cause Unicode exceptions
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file21747/python-2.7.1-fix-httplib-UnicodeDecodeError.patch

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

From report at bugs.python.org  Thu Apr 21 17:16:37 2011
From: report at bugs.python.org (Michael Gold)
Date: Thu, 21 Apr 2011 15:16:37 +0000
Subject: [New-bugs-announce] [issue11899] TarFile.gettarinfo modifies
	self.inodes
In-Reply-To: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>
Message-ID: <1303398997.96.0.910828864.issue11899@psf.upfronthosting.co.za>


New submission from Michael Gold <mgold at qnx.com>:

When I call tar.gettarinfo (where tar is a TarFile instance), the inode information is inserted into tar.inodes.  If I later call tar.gettarinfo on a linked file, the returned TarInfo will have type LNKTYPE.

I think it's incorrect to store this information in gettarinfo.  It should be done in addfile.

A comment in gettarinfo states "Is it a hardlink to an already archived file?".  But tar.inodes is modified in gettarinfo, and there's no reason to expect that the file will actually be archived, or will be archived with the same properties.  Bad links could result if the returned tarinfo object were modified before calling addfile.

I suggest changing the code as follows:
 - Create a static method (or non-member function) to fill in a given TarInfo object with stat/lstat/fstat results.  This would need a boolean "dereference" parameter.  (No TarFile instance should be required to create a TarInfo.)
 - Have tar.gettarinfo call the above function; then fill in tarinfo.tarfile, and modify tarinfo.type to LNKNAME if applicable.  Don't modify self.inodes.
 - In tar.addfile, call fstat, and store the inode info into self.inodes.

----------
components: Library (Lib)
messages: 134220
nosy: lars.gustaebel, mgold-qnx
priority: normal
severity: normal
status: open
title: TarFile.gettarinfo modifies self.inodes
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr 21 20:14:28 2011
From: report at bugs.python.org (Dave Opstad)
Date: Thu, 21 Apr 2011 18:14:28 +0000
Subject: [New-bugs-announce] [issue11900] 2.7.1 unicode subclasses not
	calling __str__() for print	statement
In-Reply-To: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>
Message-ID: <1303409668.43.0.708975922523.issue11900@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

Python 2.7.1 doesn't appear to do the usual implicit call to str() for subclasses of unicode. In the following snippet, I would have expected print myTest and print str(myTest) to behave the same:

>>> class Test(unicode):
...   def __str__(self):
...     print "In __str__"
...     return (u"*** " + self + u" ***").encode('utf-8')
...   def __unicode__(self):
...     print "In __unicode__"
...     return u"*** " + self + u" ***"
... 
>>> myTest = Test(u"abc")
>>> print myTest
abc
>>> print str(myTest)
In __str__
*** abc ***
>>> print unicode(myTest)
In __unicode__
*** abc ***

----------
components: Unicode
messages: 134231
nosy: opstad
priority: normal
severity: normal
status: open
title: 2.7.1 unicode subclasses not calling __str__() for print statement
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 21 20:24:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Apr 2011 18:24:23 +0000
Subject: [New-bugs-announce] [issue11901] Docs for sys.hexversion should
	give the algorithm
In-Reply-To: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>
Message-ID: <1303410263.92.0.721904855375.issue11901@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I went to write a test that would trigger something if it was run on 3.3.0, and had to look in the source code to figure out what the hexversion for that would be.  I think the hexversion algorithm should be documented in its sys entry.

----------
assignee: docs at python
components: Documentation
messages: 134232
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs for sys.hexversion should give the algorithm
type: feature request

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

From report at bugs.python.org  Thu Apr 21 21:15:50 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:15:50 +0000
Subject: [New-bugs-announce] [issue11902] typo in argparse doc's: "action.."
In-Reply-To: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>
Message-ID: <1303413350.17.0.602462261272.issue11902@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

There is a typo in argparse module documentation:
"The ``nargs`` keyword argument associates a different number of command-line arguments with a single action.." (two dots at end).

Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation.

----------
assignee: docs at python
components: Documentation
files: argparse_typo_action_dot_dot.patch
keywords: patch
messages: 134237
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in argparse doc's: "action.."
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file21751/argparse_typo_action_dot_dot.patch

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

From report at bugs.python.org  Thu Apr 21 21:24:11 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 21 Apr 2011 19:24:11 +0000
Subject: [New-bugs-announce] [issue11903] Incorrect test code in
	test_logging.py
In-Reply-To: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>
Message-ID: <1303413851.9.0.62222052132.issue11903@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In test file test_logging.py, around line 2359, list.append() is called with two arguments instead of one. I suppose it is meant to be called with a tuple.

class ModuleLevelMiscTest(BaseTest):
    [...]
    def _test_log(self, method, level=None):
        called = []
        patch(self, logging, 'basicConfig',
              lambda *a, **kw: called.append(a, kw))  # <====

----------
components: Tests
messages: 134239
nosy: scoder
priority: normal
severity: normal
status: open
title: Incorrect test code in test_logging.py
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 21 21:50:12 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:50:12 +0000
Subject: [New-bugs-announce] [issue11904] incorrect reStructuredText
	formatting in argparse module
In-Reply-To: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>
Message-ID: <1303415412.97.0.882157170829.issue11904@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

In Python 2.7 and 3 branch at http://svn.python.org/projects/python/branches/py3k/ file Doc/library/argparse.rst has incorrectly formatted list at line 648:

> * ``'store'`` - This just stores the argument's value.  This is the default
>    action. For example::

Second line must be indented according to first line.

Next item at line 656 has invalid indentation too.

----------
assignee: docs at python
components: Documentation
messages: 134240
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: incorrect reStructuredText formatting in argparse module
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Apr 21 21:57:18 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 21 Apr 2011 19:57:18 +0000
Subject: [New-bugs-announce] [issue11905] typo in argparse doc's: missing
	dot at end of sentence
In-Reply-To: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>
Message-ID: <1303415838.79.0.720051714713.issue11905@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

There is missed dot at end of sentence in argparse module documentation. Please see attached patch for details.

Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation.

----------
assignee: docs at python
components: Documentation
files: argparse_typo_missing_dot.patch
keywords: patch
messages: 134241
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in argparse doc's: missing dot at end of sentence
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file21752/argparse_typo_missing_dot.patch

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

From report at bugs.python.org  Fri Apr 22 05:26:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Apr 2011 03:26:11 +0000
Subject: [New-bugs-announce] [issue11906] Test_argparse failure but only in
	interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

(3.1 not checked because it seems not to have test_argparse)
Python 2.7 or 3.2, WinXP these pass:
C:\Programs\Python27>python -m test.regrtest test_argparse
C:\Programs\Python32>python -m test test_argparse
[1/1] test_argparse
1 test OK.

C:\Programs\Python32>python -m test -v test_argparse
C:\Programs\Python32>python -c "from test import test_argparse as t; t.test_main()"
Ran 1536 tests in 6.188s
OK

but interactively (command window interpreter or IDLE shell, 3.2 or 2.7)
>>> from test import test_argparse as t; t.test_main()

gives two failures related to extra spaces in usage string (I added a couple of newlines for clarity). I have no idea if problem is with argparse, test_argparse, regrtest, unittest, or interactive versus batch mode.

======================================================================
FAIL: test_groups_parents (test.test_argparse.TestParentParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 2217, in test_groups_parents
    '''.format(self.main_program)))
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 29, in assertEqual
    super(TestCase, self).assertEqual(obj1, obj2)
AssertionError:
'usage: [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n  -h, --help  s [truncated]... != 
'usage:  [-h] [-w W] [-x X] [-y Y | -z Z]\n\noptional arguments:\n  -h, --help   [truncated]...
- usage: [-h] [-w W] [-x X] [-y Y | -z Z]
+ usage:  [-h] [-w W] [-x X] [-y Y | -z Z]
?        +
  
  optional arguments:
    -h, --help  show this help message and exit
    -y Y
    -z Z
  
  g:
    gd
  
    -w W
    -x X


======================================================================
FAIL: test_parent_help (test.test_argparse.TestParentParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 2188, in test_parent_help
    '''.format(self.main_program)))
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 29, in assertEqual
    super(TestCase, self).assertEqual(obj1, obj2)
AssertionError:
'usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n  a\n   [truncated]... != 
'usage:  [-h] [-b B] [--d D] [--w W] [-y Y] a z\n\npositional arguments:\n  a\n  [truncated]...
- usage: [-h] [-b B] [--d D] [--w W] [-y Y] a z
+ usage:  [-h] [-b B] [--d D] [--w W] [-y Y] a z
?        +
  
  positional arguments:
    a
    z
  
  optional arguments:
    -h, --help  show this help message and exit
    -b B
    --w W
  
  c:
    --d D
  
  x:
    -y Y


----------------------------------------------------------------------
Ran 1536 tests in 29.438s

FAILED (failures=2)
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    from test import test_argparse as t; t.test_main()
  File "C:\Programs\Python32\lib\test\test_argparse.py", line 4423, in test_main
    support.run_unittest(__name__)
  File "C:\Programs\Python32\lib\test\support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "C:\Programs\Python32\lib\test\support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Library (Lib)
messages: 134259
nosy: bethard, terry.reedy
priority: normal
severity: normal
status: open
title: Test_argparse failure but only in interactive mode
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 22 15:52:18 2011
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBMYWxpbnNrw70=?=)
Date: Fri, 22 Apr 2011 13:52:18 +0000
Subject: [New-bugs-announce] [issue11907] SysLogHandler can't send long
	messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>


New submission from Luk?? Lalinsk? <lalinsky at gmail.com>:

It seems that logging.handlers.SysLogHandler can't handle messages that can't be passed atomically via the socket. I'm not sure what is the right behavior (the syslog() function truncates the message), but I think it shouldn't propagate the exception to the application.

Python 2.7.1 (r271:86832, Apr 18 2011, 08:47:29) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> handler = logging.handlers.SysLogHandler('/dev/log')
>>> logger = logging.getLogger()
>>> logger.addHandler(handler)
>>> logger.warn('x' * 4096)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/logging/handlers.py", line 808, in emit
    self.socket.send(msg)
error: [Errno 40] Message too long
Logged from file <stdin>, line 1

----------
messages: 134265
nosy: lukas.lalinsky
priority: normal
severity: normal
status: open
title: SysLogHandler can't send long messages
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 22 19:37:26 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 22 Apr 2011 17:37:26 +0000
Subject: [New-bugs-announce] [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

In the documentation for `itertools.islice` I see this line:

    it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1))

Is it really okay to do `s.stop or sys.maxint`? I'm assuming this was targeting `None`, but what if `s.stop == 0`? And `s.step` could (pathologically) be `0` too, no?

----------
assignee: docs at python
components: Documentation
messages: 134276
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Weird `slice.stop or sys.maxint`
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr 22 21:31:22 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 22 Apr 2011 19:31:22 +0000
Subject: [New-bugs-announce] [issue11909] Doctest sees directives in strings
	when it should only	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

>From the doctest source:

'Option directives are comments starting with "doctest:".  Warning: this may give false  positives for string-literals that contain the string "#doctest:".  Eliminating these false positives would require actually parsing the string; but we limit them by ignoring any line containing "#doctest:" that is *followed* by a quote mark.'

This isn't a huge deal, but it's a bit annoying. Above being confusing, this is in contradiction with the doctest documentation, which states:

'Doctest directives are expressed as a special Python comment following an example?s source code'

No mention is made of this corner case where the regexp breaks.

As per the comment in the source, the patched version parses the source using the tokenize module, and runs a modified directive regex on all comment tokens to find directives.

----------
components: Library (Lib)
files: comments.diff
keywords: patch
messages: 134278
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Doctest sees directives in strings when it should only see them in comments
Added file: http://bugs.python.org/file21757/comments.diff

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

From report at bugs.python.org  Sat Apr 23 04:04:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Apr 2011 02:04:19 +0000
Subject: [New-bugs-announce] [issue11910] test_heapq C tests are not skipped
	when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

When _heapq is missing, test_heapq still runs both the Py and the C tests instead of skipping the C ones.  The attached patch skips the C tests when _heapq is missing.

----------
files: issue11910.diff
keywords: patch
messages: 134293
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: test_heapq C tests are not skipped when _heapq is missing
Added file: http://bugs.python.org/file21760/issue11910.diff

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

From report at bugs.python.org  Sat Apr 23 10:17:59 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 23 Apr 2011 08:17:59 +0000
Subject: [New-bugs-announce] [issue11911] Interlink Python versions docs
In-Reply-To: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>
Message-ID: <1303546679.67.0.126016913542.issue11911@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I want to be able to jump from latest Python 2 docs to the same page in stable Python 3 doc in one click. E.g. from http://docs.python.org/library/string.html to http://docs.python.org/py3k/library/strings.html

----------
assignee: docs at python
components: Documentation
messages: 134296
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Interlink Python versions docs
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Apr 24 01:39:45 2011
From: report at bugs.python.org (Nils Breunese)
Date: Sat, 23 Apr 2011 23:39:45 +0000
Subject: [New-bugs-announce] [issue11912] Python shouldn't use the
	mprotect() system call
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>


New submission from Nils Breunese <nils at breun.nl>:

When I try to run iotop [0] on CentOS 5.6 on a kernel with grsecurity [1] then iotop won't start because grsecurity is blocking Python because of its use of the mprotect() system call.

Please see http://www.atomicorp.com/wiki/index.php/ASL_FAQ#grsec:_denied_RWX_mprotect for more information. The authors of this hardened Linux kernel suggested to file a bug with Python because using mprotect() is apparently a very bad thing to do.

[0] http://guichaz.free.fr/iotop/
[1] http://grsecurity.net/

----------
messages: 134314
nosy: breun
priority: normal
severity: normal
status: open
title: Python shouldn't use the mprotect() system call
type: security
versions: 3rd party

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

From report at bugs.python.org  Sun Apr 24 04:48:42 2011
From: report at bugs.python.org (Ingy dot Net)
Date: Sun, 24 Apr 2011 02:48:42 +0000
Subject: [New-bugs-announce] [issue11913] sdist should allow for README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>


New submission from Ingy dot Net <ingy at ingy.net>:

When I upload modules to PyPI, distutils is clucking about a missing README, even though PyPI accepts README.rst, and I am providing that.

Registering pyplay to http://pypi.python.org/pypi
Server response (200): OK
python setup.py sdist upload
running sdist
warning: sdist: standard file not found: should have one of README, README.txt

----------
assignee: tarek
components: Distutils
messages: 134322
nosy: eric.araujo, ingy, tarek
priority: normal
severity: normal
status: open
title: sdist should allow for README.rst
type: behavior

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

From report at bugs.python.org  Sun Apr 24 05:34:53 2011
From: report at bugs.python.org (Ben Okopnik)
Date: Sun, 24 Apr 2011 03:34:53 +0000
Subject: [New-bugs-announce] [issue11914] pydoc modules/help('modules')
	crash in dirs with	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>


New submission from Ben Okopnik <ben at okopnik.com>:

Long-standing problem (happens in every Python version I've tested). The usual situation is when invoking Python (and then "help('modules')") or "pydoc modules" in /tmp, but also happens when located anywhere with unreadable subdirs:

ben at Jotunheim:~$ mkdir /tmp/foo; cd /tmp/foo
ben at Jotunheim:/tmp/foo$ mkdir bar; sudo chmod 000 bar
[sudo] password for ben: 
ben at Jotunheim:/tmp/foo$ pydoc modules

Please wait a moment while I gather a list of all available modules...

Traceback (most recent call last):
  File "/usr/bin/pydoc2.6", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python2.6/pydoc.py", line 2309, in cli
    help.help(arg)
  File "/usr/lib/python2.6/pydoc.py", line 1765, in help
    elif request == 'modules': self.listmodules()
  File "/usr/lib/python2.6/pydoc.py", line 1886, in listmodules
    ModuleScanner().run(callback, onerror=onerror)
  File "/usr/lib/python2.6/pydoc.py", line 1937, in run
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
  File "/usr/lib/python2.6/pkgutil.py", line 105, in walk_packages
    for importer, name, ispkg in iter_modules(path, prefix):
  File "/usr/lib/python2.6/pkgutil.py", line 147, in iter_modules
    for name, ispkg in iter_importer_modules(i, prefix):
  File "/usr/lib/python2.6/pkgutil.py", line 211, in iter_modules
    for fn in os.listdir(path):
OSError: [Errno 13] Permission denied: './bar'

Proposed patch:

Seems like an easy fix. In Python 3.1.2, change line 206 in /usr/lib/python3.1/pkgutil.py from

if not modname and os.path.isdir(path) and '.' not in fn:

to

if not modname and os.path.isdir(path) and '.' not in fn and os.access(path, os.R_OK):

Other versions much the same (although the specified line number will probably be different.)


Best regards,
Ben Okopnik

----------
components: Demos and Tools
messages: 134323
nosy: okopnik
priority: normal
severity: normal
status: open
title: pydoc modules/help('modules') crash in dirs with unreadable subdirs
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 24 21:38:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Apr 2011 19:38:16 +0000
Subject: [New-bugs-announce] [issue11915] test_ctypes hangs in sandbox
In-Reply-To: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>
Message-ID: <1303673896.39.0.0238599913513.issue11915@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

After 19d9f0a177de and 020ebe0be33e, test_ctypes hangs when test suite is run in sandbox. This problem occurs only in Python 3.3.

$ sandbox python3.3 -B -m test.regrtest --timeout=10 -v test_ctypes
== CPython 3.3a0 (default:020ebe0be33e+, Apr 24 2011, 17:52:58) [GCC 4.5.2]
==   Linux-${version}
==   /tmp/test_python_23902
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=1, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
Timeout (0:00:10)!
Thread 0x00007fc205f54700:
  File "/usr/lib64/python3.3/subprocess.py", line 466 in _eintr_retry_call
  File "/usr/lib64/python3.3/subprocess.py", line 1412 in _execute_child
  File "/usr/lib64/python3.3/subprocess.py", line 766 in __init__
  File "/usr/lib64/python3.3/ctypes/util.py", line 198 in _findSoname_ldconfig
  File "/usr/lib64/python3.3/ctypes/util.py", line 206 in find_library
  File "/usr/lib64/python3.3/ctypes/test/test_find.py", line 15 in <module>
  File "/usr/lib64/python3.3/ctypes/test/__init__.py", line 64 in get_tests
  File "/usr/lib64/python3.3/test/test_ctypes.py", line 11 in test_main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1094 in runtest_inner
  File "/usr/lib64/python3.3/test/regrtest.py", line 887 in runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 587 in _runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 711 in main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1672 in <module>
  File "/usr/lib64/python3.3/runpy.py", line 73 in _run_code
  File "/usr/lib64/python3.3/runpy.py", line 160 in _run_module_as_main

----------
components: ctypes
messages: 134341
nosy: Arfrever, pitrou
priority: normal
severity: normal
status: open
title: test_ctypes hangs in sandbox
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 24 23:57:55 2011
From: report at bugs.python.org (Pierre Carrier)
Date: Sun, 24 Apr 2011 21:57:55 +0000
Subject: [New-bugs-announce] [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>


New submission from Pierre Carrier <prc at redhat.com>:

A few errnos from OSX are missing in the eponymous module.

--- 8< ---
#ifdef EAUTH
    inscode(d, ds, de, "EAUTH", EAUTH, "Authentication error");
#endif
#ifdef EBADARCH
    inscode(d, ds, de, "EBADARCH", EBADARCH, "Bad CPU type in executable");
#endif
#ifdef EBADEXEC
    inscode(d, ds, de, "EBADEXEC", EBADEXEC, "Bad executable (or shared library)");
#endif
#ifdef EBADMACHO
    inscode(d, ds, de, "EBADMACHO", EBADMACHO, "Malformed Mach-o file");
#endif
#ifdef EBADRPC
    inscode(d, ds, de, "EBADRPC", EBADRPC, "RPC struct is bad");
#endif
#ifdef ECANCELED
    inscode(d, ds, de, "ECANCELED", ECANCELED, "Operation canceled");
#endif
#ifdef EDEVERR
    inscode(d, ds, de, "EDEVERR", EDEVERR, "Device error");
#endif
#ifdef EFTYPE
    inscode(d, ds, de, "EFTYPE", EFTYPE, "Inappropriate file type or format");
#endif
#ifdef ENEEDAUTH
    inscode(d, ds, de, "ENEEDAUTH", ENEEDAUTH, "Need authenticator");
#endif
#ifdef ENOATTR
    inscode(d, ds, de, "ENOATTR", ENOATTR, "Attribute not found");
#endif
#ifdef ENOPOLICY
    inscode(d, ds, de, "ENOPOLICY", ENOPOLICY, "Policy not found");
#endif
#ifdef ENOTSUP
    inscode(d, ds, de, "ENOTSUP", ENOTSUP, "Operation not supported");
#endif
#ifdef EPROCLIM
    inscode(d, ds, de, "EPROCLIM", EPROCLIM, "Too many processes");
#endif
#ifdef EPROCUNAVAIL
    inscode(d, ds, de, "EPROCUNAVAIL", EPROCUNAVAIL, "Bad procedure for program");
#endif
#ifdef EPROGMISMATCH
    inscode(d, ds, de, "EPROGMISMATCH", EPROGMISMATCH, "Program version wrong");
#endif
#ifdef EPROGUNAVAIL
    inscode(d, ds, de, "EPROGUNAVAIL", EPROGUNAVAIL, "RPC prog. not avail");
#endif
#ifdef EPWROFF
    inscode(d, ds, de, "EPWROFF", EPWROFF, "Device power is off");
#endif
#ifdef ERPCMISMATCH
    inscode(d, ds, de, "ERPCMISMATCH", ERPCMISMATCH, "RPC version wrong");
#endif
#ifdef ESHLIBVERS
    inscode(d, ds, de, "ESHLIBVERS", ESHLIBVERS, "Shared library version mismatch");
#endif
--- >8 ---

(PS: catched by scripting around https://github.com/pcarrier/stuff/blob/master/sys/errnos.c if someone wants to play with other "exotic" architectures)

----------
components: Extension Modules
messages: 134351
nosy: pcarrier
priority: normal
severity: normal
status: open
title: A few errnos from OSX
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 25 13:08:42 2011
From: report at bugs.python.org (Hamid)
Date: Mon, 25 Apr 2011 11:08:42 +0000
Subject: [New-bugs-announce] [issue11917] Test Error
In-Reply-To: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>
Message-ID: <1303729722.53.0.730816268009.issue11917@psf.upfronthosting.co.za>


New submission from Hamid <abbaszadeh.h at gmail.com>:

== CPython 3.2 (r32:88445, Apr 24 2011, 14:27:42) [GCC 4.4.4 20100726 (Red Hat 4.4.4-13)]
==   Linux-2.6.32-71.el6.x86_64-x86_64-with-redhat-6.0-Santiago little-endian
==   /usr/local/src/Python-3.2/build/test_python_2976
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_whatever
test test_whatever crashed -- <class 'ImportError'>: No module named test_whatever
Traceback (most recent call last):
  File "/usr/local/src/Python-3.2/Lib/test/regrtest.py", line 962, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
ImportError: No module named test_whatever
1 test failed:
    test_whatever

----------
components: Tests
messages: 134377
nosy: Abbaszadeh
priority: normal
severity: normal
status: open
title: Test Error
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 25 16:21:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2011 14:21:45 +0000
Subject: [New-bugs-announce] [issue11918] Drop OS/2 and VMS support in
	Python 3.3
In-Reply-To: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>
Message-ID: <1303741305.45.0.808920067617.issue11918@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Because we don't have any OS/2 and VMS maintainer for Python 3, I propose to drop OS/2 and VMS support in Python 3.3: OSes unsupported in 3.3, code removed in 3.4 (see the PEP 11 for the process).

----------
components: Interpreter Core
messages: 134384
nosy: haypo
priority: normal
severity: normal
status: open
title: Drop OS/2 and VMS support in Python 3.3
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 25 16:54:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Apr 2011 14:54:22 +0000
Subject: [New-bugs-announce] [issue11919] test_imp failures
In-Reply-To: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>
Message-ID: <1303743262.64.0.49678573377.issue11919@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.2/builds/215/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1223/steps/test/logs/stdio

======================================================================
ERROR: test_issue9319 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.2.hansen-osx-x86-2/build/Lib/test/test_imp.py", line 175, in test_issue9319
    imp.find_module, "test/badsyntax_pep3120")
  File "/Users/pythonbuildbot/buildarea/3.2.hansen-osx-x86-2/build/Lib/unittest/case.py", line 574, in assertRaises
    callableObj(*args, **kwargs)
ImportError: No module named test/badsyntax_pep3120

----------
assignee: haypo
components: Tests
messages: 134387
nosy: haypo, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_imp failures
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 25 18:52:56 2011
From: report at bugs.python.org (Steve Thompson)
Date: Mon, 25 Apr 2011 16:52:56 +0000
Subject: [New-bugs-announce] [issue11920] ctypes: Strange bitfield structure
	sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

Consider the following:
import ctypes

class struct1( ctypes.Structure ):
    _pack_ = 1
    _fields_ =  [
                    ( "first",  ctypes.c_uint8,  1  ),
                    ( "second", ctypes.c_uint8,  1  ),
                    ( "third",  ctypes.c_uint8,  1  ),
                    ( "fourth", ctypes.c_uint8,  1  ),
                    ( "fifth",  ctypes.c_uint8,  1  ),
                    ( "pad",    ctypes.c_uint16, 11 ),
                ]
                
s1 = struct1()
print ctypes.sizeof( s1 )

class struct2( ctypes.Structure ):
    _pack_ = 1
    _fields_ =  [
                    ( "first",  ctypes.c_uint16, 1  ),
                    ( "second", ctypes.c_uint16, 1  ),
                    ( "third",  ctypes.c_uint16, 1  ),
                    ( "fourth", ctypes.c_uint16, 1  ),
                    ( "fifth",  ctypes.c_uint16, 1  ),
                    ( "pad",    ctypes.c_uint16, 11 ),
                ]
                
s2 = struct2()
print ctypes.sizeof( s2 )

The output is:
3
2

I'm generating python code from real c code.  The compiler I'm using for the real c code packs both of these structures into two bytes.  I need a way to make the first example work in python like the compiler without having to modify the source code.

Is this possible?

----------
components: ctypes
messages: 134393
nosy: Steve.Thompson
priority: normal
severity: normal
status: open
title: ctypes: Strange bitfield structure sizing issue
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 25 18:56:37 2011
From: report at bugs.python.org (dholth)
Date: Mon, 25 Apr 2011 16:56:37 +0000
Subject: [New-bugs-announce] [issue11921] distutils2 should be able to
	compile an Extension based	on the Python implementation version
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>


New submission from dholth <dholth at fastmail.fm>:

It might be useful to be able to declare optional Extensions that for example won't attempt to compile on Jython or any implementation of Python for which the extension (a) doesn't work or (b) would be slower than the Python fallback.

I suppose this could be accomplished without changing anything by packaging the extension separately and using the extant "; plat=win32" style dependency qualifiers?

----------
assignee: tarek
components: Distutils2
messages: 134394
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 should be able to compile an Extension based on the Python implementation version
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 25 19:21:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Apr 2011 17:21:47 +0000
Subject: [New-bugs-announce] [issue11922] Add General Index to Windows .chm
	help file Contents
In-Reply-To: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>
Message-ID: <1303752107.55.0.594682028964.issue11922@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The Windows distribution comes with the docs in a very nice Windows help file .chm form. When displayed, they is a left side bar with a Contents tab. The top entry is 'Python vx.y documentation' followed by 'Python Module Index' and 'What's New in Python' and so on down to 'History and Licence'. Everything on the "Python vx.y documentation' page is listed in the Contents EXCEPT the General Index. Consequently, if one only uses the contents lists, one might not even know it exists. In any case, it is harder to get to than anything else.

I presume the omission is unintentional. In any case, I would like to see it fixed, with 'General Index' added right after the module index entry. I presume this should be easy for someone who knows how the contents list is generated.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 134398
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add General Index to Windows .chm help file Contents
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 25 22:07:14 2011
From: report at bugs.python.org (Paul Griffith)
Date: Mon, 25 Apr 2011 20:07:14 +0000
Subject: [New-bugs-announce] [issue11923] gcc: unrecognized option '-n32'
In-Reply-To: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>
Message-ID: <1303762034.43.0.96724336471.issue11923@psf.upfronthosting.co.za>


New submission from Paul Griffith <paulg at cse.yorku.ca>:

In compiling Python 2.7.1 on RHEL I run into the following error message when running make.

gcc: unrecognized option '-n32'
gcc -pthread -n32  -Xlinker -export-dynamic -o python \
			Modules/python.o \
			-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  
gcc: unrecognized option '-n32'
running build
running build_ext


Configured with:

./configure --prefix=/cs/local --enable-shared --libdir=/cs/local/lib64 --with-gcc=yes

GCC:

 # gcc --version
gcc (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I checked the bug tracker, but I only thing I see related deals with IRIX.

----------
components: Build
messages: 134410
nosy: paulg_ca
priority: normal
severity: normal
status: open
title: gcc: unrecognized option '-n32'
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 25 23:27:43 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Apr 2011 21:27:43 +0000
Subject: [New-bugs-announce] [issue11924] Pickle and copyreg modules doesn't
	document the interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Python 3.2 here.

"copyreg" module documentation says "See the pickle module for more details on the interface expected of function and constructor.", but I don't see any useful "copyreg" reference in pickle documentation.

Some examples would be useful here, too.

----------
assignee: docs at python
messages: 134416
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: Pickle and copyreg modules doesn't document the interface
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr 26 02:00:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2011 00:00:10 +0000
Subject: [New-bugs-announce] [issue11925] test_ttk_guionly.test_traversal()
	failed on "x86	Windows7 3.x"
In-Reply-To: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>
Message-ID: <1303776010.8.0.380054844246.issue11925@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x":
---------------
[120/354] test_ttk_guionly
test test_ttk_guionly failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\tkinter\test\test_ttk\test_widgets.py", line 713, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.116458816' != '.116461336'
- .116458816
+ .116461336
---------------
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2984/steps/test/logs/stdio

----------
components: Tests, Tkinter, Windows
messages: 134430
nosy: haypo
priority: normal
severity: normal
status: open
title: test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x"
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 26 03:56:00 2011
From: report at bugs.python.org (Carl M. Johnson)
Date: Tue, 26 Apr 2011 01:56:00 +0000
Subject: [New-bugs-announce] [issue11926] help("keywords") returns
	incomplete list of keywords
In-Reply-To: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>
Message-ID: <1303782960.65.0.80653815306.issue11926@psf.upfronthosting.co.za>


New submission from Carl M. Johnson <cmjohnson.mailinglist at gmail.com>:

In Python 3.2, help("keywords") returns the following:



Here is a list of the Python keywords.  Enter any keyword to get more help.

and                 elif                import              raise
as                  else                in                  return
assert              except              is                  try
break               finally             lambda              while
class               for                 nonlocal            with
continue            from                not                 yield
def                 global              or                  
del                 if                  pass                

- - - -

This list is missing True, False, and None.

----------
assignee: docs at python
components: Documentation
messages: 134440
nosy: Carl.M.Johnson, docs at python
priority: normal
severity: normal
status: open
title: help("keywords") returns incomplete list of keywords
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 26 18:48:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2011 16:48:21 +0000
Subject: [New-bugs-announce] [issue11927] SMTP_SSL doesn't use port 465 by
	default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The SMTP_SSL doc says ?If port is omitted, the standard SMTP-over-SSL port (465) is used?, but actually port 25 is used by default. The fix is trivial: make "default_port" a class attribute (in both SMTP and SMTP_SSL) instead of setting it inside the constructor.

test_smtpnet uses an explicit port to connect to gmail, which is why it doesn't exhibit the issue.

(Kasun, I'm adding you since you might be interested. Sorry if it isn't the case)

----------
components: Library (Lib)
keywords: easy
messages: 134478
nosy: kasun, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: SMTP_SSL doesn't use port 465 by default
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr 26 18:51:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Apr 2011 16:51:47 +0000
Subject: [New-bugs-announce] [issue11928] fail if file with space at the end
	is present
In-Reply-To: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>
Message-ID: <1303836707.17.0.285457821827.issue11928@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I know this is a minor bug, but still.. Windows allows creation of filenames like "use MoveBufferArea " (note space at the end). When such file is present in current directory, `setup.py sdist` fails with `error: use MoveBufferArea : The system cannot find the file specified`.

----------
assignee: tarek
components: Distutils
messages: 134480
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: fail if file with space at the end is present
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr 26 20:19:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 26 Apr 2011 18:19:18 +0000
Subject: [New-bugs-announce] [issue11929] Improve usage of PEP8 in
	Docs/includes/*
In-Reply-To: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>
Message-ID: <1303841958.69.0.324750983113.issue11929@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004032.html I made a run of pep8 on Doc/includes/ py files.

i've prepared a patch against default; if it's considered worth I can prepare patches for the other branches (for sure 2.7 needs a different patch, and probably also 3.1).

----------
assignee: docs at python
components: Documentation
files: pep8_doc_includes.patch
keywords: patch
messages: 134486
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Improve usage of PEP8 in Docs/includes/*
versions: Python 3.3
Added file: http://bugs.python.org/file21784/pep8_doc_includes.patch

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

From report at bugs.python.org  Tue Apr 26 21:37:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Apr 2011 19:37:42 +0000
Subject: [New-bugs-announce] [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As implemented in issue 10827, use of 2-digits years in timetuples to mean 4-digit years straddling year 2000 is deprecated in 3.3.  There is no mechanism for issuing deprecation warning for access to a module variable, but a deprecation note was added to its documentation.

Attached patch removes time.accept2dyear and the associated behaviors.

----------
files: remove-accept2dyear.diff
keywords: patch
messages: 134493
nosy: belopolsky, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Remove time.accept2dyear
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21785/remove-accept2dyear.diff

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

From report at bugs.python.org  Wed Apr 27 00:06:26 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Apr 2011 22:06:26 +0000
Subject: [New-bugs-announce] [issue11931] Regular expression documentation
	patch
In-Reply-To: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>
Message-ID: <1303855586.52.0.604026571441.issue11931@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

I have read and fixed the regular expression documentation and made a patch. Ezio, please review it and apply it. Thanks.

----------
assignee: docs at python
components: Documentation
files: re.patch
keywords: patch
messages: 134506
nosy: Retro, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Regular expression documentation patch
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21787/re.patch

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

From report at bugs.python.org  Wed Apr 27 05:49:17 2011
From: report at bugs.python.org (David Strauss)
Date: Wed, 27 Apr 2011 03:49:17 +0000
Subject: [New-bugs-announce] [issue11932] Email multipart boundary detection
	fails on a wrapped	header
In-Reply-To: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>
Message-ID: <1303876157.91.0.419040488355.issue11932@psf.upfronthosting.co.za>


New submission from David Strauss <david at davidstrauss.net>:

I've attached a multipart message produced by Thunderbird. For some reason, the email.message parser doesn't properly recognize the boundary. This causes legitimate multipart messages to parse as if no boundary were specified. Simply removing the newline on the line starting with " boundary" allows it to parse correctly.

To see why this is valid, refer to section 2.2.3 of RFC2822 [1].

[1] http://tools.ietf.org/html/rfc2822#section-2.2.3

----------
components: Library (Lib)
files: wrapped_multipart.txt
messages: 134523
nosy: davidstrauss
priority: normal
severity: normal
status: open
title: Email multipart boundary detection fails on a wrapped header
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21789/wrapped_multipart.txt

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

From report at bugs.python.org  Wed Apr 27 06:29:50 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 27 Apr 2011 04:29:50 +0000
Subject: [New-bugs-announce] [issue11933] newer() function in dep_util.py
	mixes up new vs. old	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>


New submission from John S. Gruber <johnsgruber at gmail.com>:

In researching a bug I was surprised that a newly created file was being replaced when being processed a second time (it shouldn't have been processed a second time). 

I tracked the surprise to diff Lib/distutils/dep_util.py @ 57642:9211a5d7d0b4 where a comparison with a resolution of 1 second was replaced by a floating point comparison, though the new file was copied by file_util.py which tried to preserve the time using a method accurate to only 1 second (truncating the fraction). Since a new file with a truncated modification time looks older than an older file with a full precision stamp the problem resulted.

(For convenience--stat.st_mtime is floating point, stat[ST_MTIME] is integer seconds unless os.stat_float_times has been called to change the floating point behavior.

Using all floating point doesn't resolve the issue as OS timestamped files can have more resolution than python floating point may hold, again causing truncation and confusion. For reference see Python issue 10148.

In my humble opinion time setting and comparison should all be done consistently, and, if sub-second comparisons are desired, some fuzz should be used such that the comparison makes sense for the platform with the least amount of precision available with its floating point implementation.

I briefly looked at branches other than 2.7 and they don't seem to have the above change.

Probably of minor importance in most cases.

Thanks all for the good work, all. I've been learning python and I love it!

----------
assignee: tarek
components: Distutils
messages: 134526
nosy: eric.araujo, jsjgruber, tarek
priority: normal
severity: normal
status: open
title: newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 27 12:09:32 2011
From: report at bugs.python.org (ysj.ray)
Date: Wed, 27 Apr 2011 10:09:32 +0000
Subject: [New-bugs-announce] [issue11934] build with --prefix=/dev/null and
	zlib enabled in	Modules/Setup failed
In-Reply-To: <1303898972.2.0.53608607185.issue11934@psf.upfronthosting.co.za>
Message-ID: <1303898972.2.0.53608607185.issue11934@psf.upfronthosting.co.za>


New submission from ysj.ray <ysj.ray at gmail.com>:

The development guide(http://docs.python.org/devguide/setup.html) suggested that one can build with "--prefix=/dev/null" in order to avoid accidentally install it. But in the Modules/Setup.dist the zlib module is defined as:

zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz

So configure with "--prefix=/dev/null " and enable zlib in Module/Setup and then make results in such error: (debian 5)

cc1: error: /dev/null/include: Not a directory


Not sure if this is really a problem. But I need to modify the Module/Setup zlib line to
"""
zlib zlibmodule.c -L$(exec_prefix)/lib -lz
"""
instead of just uncomment it to make my build process success. I think it's better to be improved.

----------
components: Build
messages: 134544
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: build with --prefix=/dev/null and zlib enabled in Modules/Setup failed
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 27 13:39:37 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 27 Apr 2011 11:39:37 +0000
Subject: [New-bugs-announce] [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

According to the de-facto MBOX standard [1] and the MMDF
description [2] mtime and atime are used to detect wether
a mailbox has new mail:

   If the mtime on a nonempty mbox file is greater than the
   atime, the file has new mail.

For [1] this is documented under "UNSPECIFIED DETAILS", though.
The attached patch enables MUAs like mutt(1) to show the
new-mail-has-arrived status in the overview, too.
Note i've randomly chosen 3 seconds; it also could have been 5.

[1] http://qmail.org/man/man5/mbox.html
[2] http://linux.die.net/man/5/mmdf

----------
components: Library (Lib)
files: mailbox.diff
keywords: patch
messages: 134552
nosy: sdaoden
priority: normal
severity: normal
status: open
title: MMDF/MBOX mailbox need utime
versions: Python 3.3
Added file: http://bugs.python.org/file21795/mailbox.diff

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

From report at bugs.python.org  Wed Apr 27 15:07:02 2011
From: report at bugs.python.org (sorin)
Date: Wed, 27 Apr 2011 13:07:02 +0000
Subject: [New-bugs-announce] [issue11936] plistlib.writePlistToBytes does
	not exist on 2.6 (osx)	and documentation does not include
	information about version
In-Reply-To: <1303909622.91.0.842334291068.issue11936@psf.upfronthosting.co.za>
Message-ID: <1303909622.91.0.842334291068.issue11936@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

On OS X (10.6) with Python 2.6 

import plistlib
plistlib.writePlistToBytes(dict())
AttributeError: 'module' object has no attribute 'writePlistToBytes'

Python documentation contains no information regarding when writePlistToBytes was add. http://docs.python.org/dev/library/plistlib.html#plistlib.writePlistToBytes

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 134561
nosy: ronaldoussoren, sorin
priority: normal
severity: normal
status: open
title: plistlib.writePlistToBytes does not exist on 2.6  (osx) and documentation does not include information about version
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 27 15:43:45 2011
From: report at bugs.python.org (Markus Duft)
Date: Wed, 27 Apr 2011 13:43:45 +0000
Subject: [New-bugs-announce] [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>


New submission from Markus Duft <markus.duft at salomon.at>:

Hey!

For a while now, i'm maintaining python build patches for interix for the gentoo prefix project. I thought maybe i can bring them upstream :) currently i have python 2.7.1 building, and i'll start testing python 3.2 in a while...

may i ask your opinions on my patch, and maybe inclusion in the repository...?

Regards, Markus

----------
components: Build
files: python-2.7.1-interix.patch
keywords: patch
messages: 134564
nosy: mduft
priority: normal
severity: normal
status: open
title: Interix support
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file21796/python-2.7.1-interix.patch

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

From report at bugs.python.org  Wed Apr 27 15:51:24 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 27 Apr 2011 13:51:24 +0000
Subject: [New-bugs-announce] [issue11938] duplicated test name in
	getattr_static's test case
In-Reply-To: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>
Message-ID: <1303912284.26.0.777560143006.issue11938@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

There are two tests called "test_descriptor" in getattr_static's test case. Attached is a patch that renames one.

----------
components: Tests
files: duplicated_test_descriptor.patch
keywords: patch
messages: 134565
nosy: Trundle, michael.foord
priority: normal
severity: normal
status: open
title: duplicated test name in getattr_static's test case
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21797/duplicated_test_descriptor.patch

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

From report at bugs.python.org  Wed Apr 27 18:59:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Apr 2011 16:59:43 +0000
Subject: [New-bugs-announce] [issue11939] Implement stat.st_dev and
	os.path.samefile on windows
In-Reply-To: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za>
Message-ID: <1303923583.07.0.177662562381.issue11939@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Since 9cd1036455e7, os.stat() on Windows fills the st_ino member;
it could fill st_dev just as easily;
then os.path.samefile() could be shared with the posix implementation.

----------
components: Windows
messages: 134595
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Implement stat.st_dev and os.path.samefile on windows
type: feature request

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

From report at bugs.python.org  Wed Apr 27 22:04:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 27 Apr 2011 20:04:31 +0000
Subject: [New-bugs-announce] [issue11940] Howto/Advocacy - update the link
	to John Ousterhout paper
In-Reply-To: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>
Message-ID: <1303934671.48.0.846798146708.issue11940@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004031.html here's a patch to update the link to John Ousterhout paper. It can be applied on all active branches.

----------
assignee: docs at python
components: Documentation
files: howto_advocacy_ousterhout_link.patch
keywords: patch
messages: 134612
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Howto/Advocacy - update the link to John Ousterhout paper
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21809/howto_advocacy_ousterhout_link.patch

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

From report at bugs.python.org  Wed Apr 27 23:00:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 27 Apr 2011 21:00:22 +0000
Subject: [New-bugs-announce] [issue11941] Support st_atim,
	st_mtim and st_ctim attributes in os.stat_result
In-Reply-To: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>
Message-ID: <1303938022.85.0.623572797729.issue11941@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I would like to suggest to add st_atim, st_mtim and st_ctim attributes in os.stat_result objects returned by os.stat(). These attributes would be 2-tuples containing number of seconds and number of nanoseconds. They would expose relevant functionality from libc's stat() and provide better precision than floating-point-based st_atime, st_mtime and st_ctime attributes.

st_atim, st_mtim and st_ctim attributes would be available only if Python has been built on system with libc supporting st_atim, st_mtim and st_ctim in stat structure.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

----------
messages: 134616
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Support st_atim, st_mtim and st_ctim attributes in os.stat_result
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 27 23:07:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 27 Apr 2011 21:07:23 +0000
Subject: [New-bugs-announce] [issue11942] Fix signature of Py_AddPendingCall
In-Reply-To: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>
Message-ID: <1303938443.0.0.0267122808218.issue11942@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up with http://mail.python.org/pipermail/docs/2011-April/004021.html here's a couple of patch (the first for 2.7/3.1, the other for 3.2/default) to fix the signature of Py_AddPendingCall (in particular the return type).

Adding in CC Ezio since he fixed issue11865.

----------
assignee: docs at python
components: Documentation
files: py_addpendingcall-py27.patch
keywords: patch
messages: 134620
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix signature of Py_AddPendingCall
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21813/py_addpendingcall-py27.patch

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

From report at bugs.python.org  Thu Apr 28 00:28:51 2011
From: report at bugs.python.org (Quinn Slack)
Date: Wed, 27 Apr 2011 22:28:51 +0000
Subject: [New-bugs-announce] [issue11943] Add TLS-SRP (RFC 5054) support to
	ssl, _ssl, http, and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>


New submission from Quinn Slack <sqs at cs.stanford.edu>:

This patch adds support for TLS-SRP (RFC 5054[1]) to Python ssl.SSLSocket, _ssl.c, http, and urllib. TLS-SRP lets a client and server establish a mutually authenticated SSL channel using only a username and password (a certificate may also be used to supplement authentication).

TLS-SRP is supported in GnuTLS, OpenSSL 1.0.1 (soon to be released), cURL, TLSLite (a Python module), and mod_gnutls. There are also patches for Chrome, NSS, mod_ssl, Django, Firefox, WordPress, and SJCL (see [2]). Much of the
growing interest in TLS-SRP is because a couple key PAKE patents expired recently. Also, CAs are perceived as more vulnerable now than a few years ago, and in certain cases TLS-SRP is a good substitute for or supplement to certificate auth. Two Python-specific use cases for TLS-SRP are calling HTTP APIs that require auth, and test suites written in Python for networked software (e.g., Chromium uses TLSLite for network testing).

I'm submitting this patch now to begin gathering feedback.

###########################################################
EXAMPLE USAGE
###########################################################

import urllib.request
res = urllib.request.urlopen("https://tls-srp.test.trustedhttp.org/"
                             tls_username='jsmith', tls_password='abc')
print(res.read())
# => "user: jsmith"

###########################################################

import ssl, http
context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
context.set_tls_username_password('jsmith', 'abc')
h = http.client.HTTPSConnection('tls-srp.test.trustedhttp.org', 443, context=context)
h.request('GET', '/')
resp = h.getresponse()
print(resp.status)
# => 200
print(resp.read())
# => "user: jsmith"

###########################################################

import socket, ssl
with socket.socket() as sock:
    s = ssl.wrap_socket(sock,
                        ssl_version=ssl.PROTOCOL_TLSv1,
                        ciphers='SRP',
                        tls_username='jsmith',
                        tls_password='abc')
    s.connect(('tls-srp.test.trustedhttp.org', 443))
    s.write(b"GET / HTTP/1.0\n\n")
    print(s.read())

###########################################################



[1] http://tools.ietf.org/html/rfc5054
[2] http://trustedhttp.org/
[3] http://trustedhttp.org/wiki/TLS-SRP_in_Python

----------
components: Library (Lib)
files: python+tls-srp-20110427.patch
hgrepos: 23
keywords: patch
messages: 134627
nosy: sqs
priority: normal
severity: normal
status: open
title: Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib
versions: Python 3.3
Added file: http://bugs.python.org/file21815/python+tls-srp-20110427.patch

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

From report at bugs.python.org  Thu Apr 28 03:00:47 2011
From: report at bugs.python.org (Jeong-Min Lee)
Date: Thu, 28 Apr 2011 01:00:47 +0000
Subject: [New-bugs-announce] [issue11944] Function call with * and generator
	hide exception raised	by generator.
In-Reply-To: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>
Message-ID: <1303952447.32.0.22528411021.issue11944@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

Expected "TypeError: cannot concatenate 'str' and 'int' objects" exception raised, but got following result.


>>> def g():
...     '1' + 0
...     yield 1, 2
...     yield 3, 4
...
>>> zip(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: zip() argument after * must be a sequence, not generator
>>> (lambda xs: 0)(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: <lambda>() argument after * must be a sequence, not generator
>>> list(*g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type object argument after * must be a sequence, not generator
>>> list(g())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in g
TypeError: cannot concatenate 'str' and 'int' objects

----------
components: Interpreter Core
messages: 134632
nosy: falsetru
priority: normal
severity: normal
status: open
title: Function call with * and generator hide exception raised by generator.
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Apr 28 05:42:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Apr 2011 03:42:25 +0000
Subject: [New-bugs-announce] [issue11945] Adopt and document consistent
	semantics for handling NaN	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The question of the way Python handles NaN came up again on python-dev recently. The current semantics have been assessed as a reasonable compromise, but a poorly explained and inconsistently implemented one.

Based on a suggestion from Terry Reedy [1] I propose that a new glossary entry be added for "Reflexive Equality":

"Part of the standard mathematical definition of equality is that it is reflexive, that is ``x is y`` necessarily implies that ``x == y``. This is an essential property that is relied upon when designing and implementing container classes such as ``list`` and ``dict``.

However, the IEEE754 committee defined the float Not_a_Number (NaN) values as being unequal with all others floats, including themselves. While this design choice violates the basic mathematical definition of equality, it is still considered desirable to be able to correctly implement IEEE754 floating point semantics, and those of similar types such as ``decimal.Decimal``, directly in Python.

Accordingly, Python makes the follow compromise in order to cope with types that use non-reflexive definitions of equality without breaking the invariants of container classes that rely on reflexive definitions of equality:

1. Direct equality comparisons involving ``NaN``, such as ``nan=float('NaN'); nan == nan``, follow the IEEE754 rule and return False (or True in the case of ``!=``). This rule applies to ``float`` and ``decimal.Decimal`` within the builtins and standard library.

2. Indirect comparisons conducted internally by container classes, such as ``x in someset`` or ``seq.count(x)`` or ``somedict[x]``, enforce reflexivity by using the expressions ``x is y or x == y`` and ``x is not y and x != y`` respectively rather than assuming that ``x == y`` and ``x != y`` will always respect the reflexivity requirement. This rule applies to all container types within the builtins and standard library that may contain values of arbitrary types.

Also see [1] for a more comprehensive theoretical discussion of this topic.

[1] http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/"

Specific container methods that have currently been identified as relying on the reflexivity assumption are:
- __contains__() (for x in c: assert x in c)
- __eq__() (assert [x] == [x])
- __ne__() (assert not [x] != [x])
- index() (for x in c: assert 0 <= c.index(x) < len(c))
- count() (for x in c: assert c.count(x) > 0)

collections.Sequence and array.array (with the 'f' or 'd' type indicators) have already been identified as container classes in the standard library that fails to follow the second guideline and hence fail to correctly implement the above invariants in the presence of non-reflexive definitions of equality. They will be fixed as part of implementing this patch. Other container types that fail to correctly enforce reflexivity can be fixed as they are identified.

[1] http://mail.python.org/pipermail/python-dev/2011-April/110962.html

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 134639
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Adopt and document consistent semantics for handling NaN values in containers
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr 28 15:16:17 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Thu, 28 Apr 2011 13:16:17 +0000
Subject: [New-bugs-announce] [issue11946] 2.7.1 'test_commands' build test
	fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

After building from source in Python-2.7.1.tar.bz2 ,
I get this 'make test' failure :

test_commands
test test_commands failed -- Traceback (most recent call last): 
  File "/usr/src/Python-2.7/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."),re.VERBOSE)) 
AssertionError: None is not True

I don't get this error when building from Python-2.7.tar.bz2

----------
components: Tests
messages: 134674
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 2.7.1 'test_commands' build test fails
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 28 19:02:56 2011
From: report at bugs.python.org (Robert Meerman)
Date: Thu, 28 Apr 2011 17:02:56 +0000
Subject: [New-bugs-announce] [issue11947] re.IGNORECASE does not match
	literal "_" (underscore)
In-Reply-To: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>
Message-ID: <1304010176.69.0.487843608928.issue11947@psf.upfronthosting.co.za>


New submission from Robert Meerman <robert.meerman at gmail.com>:

Regular expressions which are written match literal underscores ("_", ASCII 
ordinal 95) and specify `re.IGNORECASE` during compilation do not consistently 
match underscores: it seems some occurrences are matched, but others are not.

The following session log shows the problem:

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import re
    >>> subject = "[Conclave-Mendoi]_ef_-_a_tale_of_memories_00-12_H264"
    >>> print subject.encode("base64")  # Incase my environment encoding is to blame
    W0NvbmNsYXZlLU1lbmRvaV1fZWZfLV9hX3RhbGVfb2ZfbWVtb3JpZXNfMDAtMTJfSDI2NA==

    >>> re.sub("_", "X", subject)  # No flags, does what I expect
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE)  # Misses some matches
    '[Conclave-Mendoi]XefX-_a_tale_of_memories_00-12_H264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.LOCALE)  # Misses fewer matches
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemories_00-12_H264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.LOCALE | re.UNICODE)  # Works OK
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> re.sub("_", "X", subject, re.IGNORECASE | re.UNICODE) # Works OK
    '[Conclave-Mendoi]XefX-XaXtaleXofXmemoriesX00-12XH264'
    >>> 
    >>> type(subject)  # Don't think this is a unicode string
    <type 'str'>
    >>> 

Since my `subject` variable is of type `str` and only contains ASCII characters
I do not believe that the `re.UNICODE` flag should be required.

----------
components: Regular Expressions
messages: 134700
nosy: RobM, effbot, ezio.melotti, pitrou
priority: normal
severity: normal
status: open
title: re.IGNORECASE does not match literal "_" (underscore)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 28 19:18:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 28 Apr 2011 17:18:31 +0000
Subject: [New-bugs-announce] [issue11948] Tutorial/Modules - small fix to
	better clarify the	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004029.html here's a small patch (applicable on all the active branches) to "actually" :) connects the two paragraphs about modules search path.

----------
assignee: docs at python
components: Documentation
files: tutorial_modules_actually.patch
keywords: patch
messages: 134704
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Tutorial/Modules - small fix to better clarify the modules search path
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21826/tutorial_modules_actually.patch

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

From report at bugs.python.org  Thu Apr 28 21:08:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Apr 2011 19:08:59 +0000
Subject: [New-bugs-announce] [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Rationale:

"""
IEEE 754 assigns values to all relational expressions involving NaN.
In the syntax of C, the predicate x != y is True but all others, x <
y , x <= y , x == y , x >= y and x > y, are False whenever x or y or
both are NaN, and then all but x != y and x == y are INVALID
operations too and must so signal.
"""
-- Lecture Notes on the Status of IEEE Standard 754 for Binary
Floating-Point Arithmetic by Prof. W. Kahan
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

The problem with faithfully implementing IEEE 754 in Python is that
exceptions in IEEE standard don't have the same meaning as in Python.
 IEEE 754 requires that a value is computed even when the operation
signals an exception.  The program can then decide whether to
terminate computation or propagate the value. In Python, we have to
choose between raising an exception and returning the value.  We
cannot have both.  It appears that in most cases IEEE 754 "INVALID"
exception is treated as a terminating exception by Python and
operations that signal INVALID in IEEE 754 raise an exception in
Python.  Therefore making <, >, etc. raise on NaN while keeping the
status quo for != and == would bring Python floats closer to
compliance with IEEE 754.

See http://mail.python.org/pipermail/python-ideas/2011-April/010057.html for discussion.

An instructive part of the patch is

--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -174,10 +174,22 @@
                    flags
                   )
 
+def is_negative_zero(x):
+    return x == 0 and math.copysign(1, x) < 0
+
+def almost_equal(value, expected):
+    if math.isfinite(expected) and math.isfinite(value):
+        return abs(value-expected) <= eps
+    if math.isnan(expected):
+        return math.isnan(value)
+    if is_negative_zero(expected):
+        return is_negative_zero(value)
+    return value == expected
+
 class MathTests(unittest.TestCase):
 
     def ftest(self, name, value, expected):
-        if abs(value-expected) > eps:
+        if not almost_equal(value, expected):


Although it may look like proposed change makes it harder to compare floats for approximate equality, the change actually helped to highlight a programming mistake: old ftest() accepts 0.0 where -0.0 is expected.

This is a typical situation when someone attempts to write clever code relying on unusual properties of NaNs. In most cases clever code does not account for all possibilities and it is always hard reason about such code.

----------
components: Interpreter Core
files: unorderable-nans.diff
keywords: patch
messages: 134713
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Make float('nan') unorderable
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21828/unorderable-nans.diff

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

From report at bugs.python.org  Thu Apr 28 21:29:19 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 28 Apr 2011 19:29:19 +0000
Subject: [New-bugs-announce] [issue11950] logger use dict for loggers
	instead of	WeakValueDictionary
In-Reply-To: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>
Message-ID: <1304018959.77.0.656415451022.issue11950@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

logger use dict for loggers instead of WeakValueDictionary

Now, when object returned by getLogger() gets unreferenced - it will not be garbage collected, as reference is stored in logging module. This will results in leaked file object, that cannot be closed in easy way. Some modules (notable yum) opens dozen of loggers that prevents me to unmount directory where logs placed. Now, I use workaround:

-----------------------
try:
    # work with yum
finally:
    yum_base_cli.close()
    yum_base_cli.closeRpmDB()
    yum_base_cli.doUnlock()
    del yum_base_cli
    # gc.collect() may be called here, but it does not actually change anything....
    for logger_name,logger in cli.logging.Logger.manager.loggerDict.iteritems():
        if not logger_name.startswith('yum'):
            continue
        for h in logger.handlers:
            h.flush()
            h.close()
-----------------------
The problem in that logging module stores many references in lists and dicts. So just replacing {} with WeakValueDictionary() 
does not eliminate problem fully.

I have checked, problem exists in all python versions

----------
components: Library (Lib)
messages: 134714
nosy: mmarkk
priority: normal
severity: normal
status: open
title: logger use dict for loggers instead of WeakValueDictionary
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr 28 23:00:59 2011
From: report at bugs.python.org (Brian Buckley)
Date: Thu, 28 Apr 2011 21:00:59 +0000
Subject: [New-bugs-announce] [issue11951] Mac OSX IDLE 3.2 does not allow
	entering text into	toolbar windows (such as the help search
	box) unless all shells	are closed or minimized
Message-ID: <1304024459.77.0.476340315499.issue11951@psf.upfronthosting.co.za>


Changes by Brian Buckley <bbuckley at gmail.com>:


----------
components: IDLE
nosy: Brian.Buckley
priority: normal
severity: normal
status: open
title: Mac OSX IDLE 3.2 does not allow entering text into toolbar windows (such as the help search box) unless all shells are closed or minimized
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 29 00:27:48 2011
From: report at bugs.python.org (akira)
Date: Thu, 28 Apr 2011 22:27:48 +0000
Subject: [New-bugs-announce] [issue11952] typo in multiprocessing
	documentation: __main__ method	should be replaced by __main__ module
In-Reply-To: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>
Message-ID: <1304029668.08.0.895041183069.issue11952@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

s/method/module/:

    Functionality within this package requires that the ``__main__`` method be
    importable by the children.

----------
assignee: docs at python
components: Documentation
messages: 134724
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: typo in multiprocessing documentation: __main__ method should be replaced by __main__ module
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr 29 00:38:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Apr 2011 22:38:50 +0000
Subject: [New-bugs-announce] [issue11953] Missing WSA* error codes
In-Reply-To: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>
Message-ID: <1304030330.14.0.209711289978.issue11953@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Apparently not all Windows socket error codes (see http://msdn.microsoft.com/en-us/library/ms740668%28v=vs.85%29.aspx) are mapped in the errno module.

For example, a buildbot recently got a 11004 error (see http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3001/steps/test/logs/stdio), which is:

?WSANO_DATA
11004

Valid name, no data record of requested type.

    The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record?indicating the host itself exists, but is not directly reachable.?


Not sure how this should be handled.

----------
messages: 134725
nosy: amaury.forgeotdarc, loewis, pitrou
priority: low
severity: normal
status: open
title: Missing WSA* error codes
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 29 14:01:18 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 12:01:18 +0000
Subject: [New-bugs-announce] [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

I do :
$  hg clone http://hg.python.org/cpython
( my existing Python-2.7, following upgrade to glibc-2.13, started
  producing erroneous results - see gnome.org glib bug :
    https://bugzilla.gnome.org/show_bug.cgi?id=648863
  So I tried downloading and building Python-2.7.1 , whose build
  tests fail ( Issue #11946 ) , and was recommended to try building
  latest python from HG . So I try that :
)
$ mkdir /mnt/sda3/Python-2.7 ; cd /mnt/sda3/Python-2.7
$ cat configure.sh
$ cat configure.sh
/usr/src/cpython/configure \
 --prefix=/usr --libdir=/usr/lib64 --enable-shared --with-pic \
 --with-system-ffi \
 --with-system-expat \
 --with-signal-module \
 --with-dbmliborder=bdb:gdbm \
 --with-threads \
 --without-pymalloc \
 --host=x86_64-pc-linux-gnu \
 --build=x86_64-pc-linux-gnu \
 --target=x86_64-pc-linux-gnu \
 --with-libs='-ldb-4.5 -lgdbm' \
 CPPFLAGS='-I/usr/include/db4 -I/usr/include/gdbm' \
 CC="${CC}" \
 CFLAGS="${CFLAGS}" \
 CXX="${CXX}" \
 CXXFLAGS="${CXXFLAGS}"
$ export -p | egrep 'CC|CXX|FLAG|LD|PATH|ARCH|ABI'
declare -x ABI="64"
declare -x ARCH="x86_64"
declare -x CC="/usr/bin/gcc"
declare -x CFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x CXX="/usr/bin/g++"
declare -x CXXFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x LD="/usr/bin/ld"
declare -x OLDPWD="/usr/src/cpython"
declare -x PATH=".:/bin:/usr/bin:/sbin:/usr/sbin"
$ bash -xf ./configure.sh 
...
$ echo $?
0
$ make -j2 2>&1 | tee make.log
$ echo $?
0
$ make test 2>&1 | tee make.test.log
...
[ 16/354] test_argparse
test test_argparse failed -- multiple errors occurred; run in verbose mode for details
...
[146/354] test_httpservers
/usr/src/cpython/Lib/unittest/case.py:799: BytesWarning: str() on a bytes instance
  (i, item1, item2))
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details
[147/354] test_imaplib
[148/354] test_imp
[149/354] test_import
test test_import failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

[150/354] test_importhooks
[151/354] test_importlib
[152/354] test_index
..[200/354] test_os
test test_os failed -- Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_os.py", line 675, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/usr/src/cpython/Lib/os.py", line 152, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '@test_28453_tmp/dir1'

...
[237/354] test_pyexpat
Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 591 in test1
  File "/usr/src/cpython/Lib/unittest/case.py", line 391 in _executeTestPart
  File "/usr/src/cpython/Lib/unittest/case.py", line 446 in run
  File "/usr/src/cpython/Lib/unittest/case.py", line 498 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/usr/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/src/cpython/Lib/test/support.py", line 1094 in run
  File "/usr/src/cpython/Lib/test/support.py", line 1182 in _run_suite
  File "/usr/src/cpython/Lib/test/support.py", line 1208 in run_unittest
  File "/usr/src/cpython/Lib/test/test_pyexpat.py", line 676 in test_main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/usr/src/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/usr/src/cpython/Lib/test/regrtest.py", line 662 in main
  File "/usr/src/cpython/Lib/test/regrtest.py", line 1622 in <module>
make: *** [test] Segmentation fault
...

Any suggestions for a python source HG commit or tarball that will
pass its 'make test' on a Linux x86_64 platform ?

Am I doing something wrong here ?

I don't like having to pass '-I/usr/include/db4' '-ldb-4.5', but when
one has both libdb-5.1 installed with 'libdb.so' linking to it, and
/usr/include/db being from libdb-5.1, what else to do ?

Come to think of it, why must python force me to enable any DB* modules
at all ? And why must the whole python executable require linking with
berkeley DB when only the bsddb DL module need do so ?

----------
messages: 134753
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 - 'make test' fails

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

From report at bugs.python.org  Fri Apr 29 18:15:41 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:15:41 +0000
Subject: [New-bugs-announce] [issue11955] 3.3 : test_argparse.py fails 'make
	test'
In-Reply-To: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>
Message-ID: <1304093741.94.0.09129303291.issue11955@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config and build procedure, please
see : issue #11954 .

So, running the new ./python fails test_argparse :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 \
  ./python /usr/src/cpython/Lib/test/test_argparse.py
...
======================================================================
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)     
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)      
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)       
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_no_groups_sysargs (__main__.TestFileTypeW)        
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_one_group_listargs (__main__.TestFileTypeW)       
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

======================================================================
FAIL: test_failures_one_group_sysargs (__main__.TestFileTypeW)        
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)                                                      
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)                       
AssertionError: ArgumentParserError not raised by parse_args                   

----------------------------------------------------------------------
Ran 1608 tests in 5.293s                                              

FAILED (failures=6)
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 4712, in <module>
    test_main()                                                            
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 4704, in test_main
    support.run_unittest(__name__)                                          
  File "/usr/src/cpython/Lib/test/support.py", line 1208, in run_unittest   
    _run_suite(suite)                                                       
  File "/usr/src/cpython/Lib/test/support.py", line 1191, in _run_suite     
    raise TestFailed(err)                                                   
test.support.TestFailed: multiple errors occurred 


Now, as someone with not too recent python programming experience,
I find it very difficult to understand exactly what is being
tested by :

class TestFileTypeW(TempDirMixin, ParserTestCase):
    """Test the FileType option/argument type for writing files"""

    def setUp(self):
        super(TestFileTypeW, self).setUp()
        self.create_readonly_file('readonly')

    argument_signatures = [
        Sig('-x', type=argparse.FileType('w')),
        Sig('spam', type=argparse.FileType('w')),
    ]
    failures = ['-x', '', 'readonly']
    successes = [
        ('foo', NS(x=None, spam=WFile('foo'))),
        ('-x foo bar', NS(x=WFile('foo'), spam=WFile('bar'))),
        ('bar -x foo', NS(x=WFile('foo'), spam=WFile('bar'))),
        ('-x - -', NS(x=sys.stdout, spam=sys.stdout)),
    ]


But it seems at least one bug is self-evident : test_argparse.py's
error messages are essentially meaningless, and contain no useful
information (beyond the name) about what failed or why - they are
all essentially duplicates of :

Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/src/cpython/Lib/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)

So why emit 6 copies of the same meaningless message ? 

I'm curious: how do you expect those error messages to help people
track down the source of the bug when every error message contains
the same data and line numbers, and they are line numbers not
of specific tests, but of some "error handler" routine ?

----------
components: Build
messages: 134779
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 : test_argparse.py fails 'make test'
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 29 18:21:26 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Fri, 29 Apr 2011 16:21:26 +0000
Subject: [New-bugs-announce] [issue11956] 3.3 : test_import.py causes 'make
	test' to fail
In-Reply-To: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>
Message-ID: <1304094086.01.0.944392387954.issue11956@psf.upfronthosting.co.za>


New submission from Jason Vas Dias <jason.vas.dias at gmail.com>:

Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config and build procedure, please
see : issue #11954 .

So, running the new ./python fails test_import.py :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 \
  ./python /usr/src/cpython/Lib/test/test_import.py
======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false

----------------------------------------------------------------------
Ran 40 tests in 0.851s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 658, in <module>
    test_main()
  File "/usr/src/cpython/Lib/test/test_import.py", line 652, in test_main
    RelativeImportFromImportlibTests)
  File "/usr/src/cpython/Lib/test/support.py", line 1208, in run_unittest
    _run_suite(suite)
  File "/usr/src/cpython/Lib/test/support.py", line 1191, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))
AssertionError: True is not false


Thanks for the helpful error backtrace ! 

This function is somehow failing (test_import.py @ line 545 ):

   @unittest.skipUnless(os.name == 'posix',
                         "test meaningful only on posix systems")
    def test_unwritable_directory(self):
        # When the umask causes the new __pycache__ directory to be
        # unwritable, the import still succeeds but no .pyc file is written.
        with temp_umask(0o222):
            __import__(TESTFN)
        self.assertTrue(os.path.exists('__pycache__'))
        self.assertFalse(os.path.exists(os.path.join(
            '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))





Running the same command under strace shows what the test is trying
to assert shouldn't exist really doesn't :
umask(022)                              = 0222
stat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
stat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)

(see full listing below)

 




umask(022)                              = 0222
stat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
stat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/test/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/lib/python33.zip/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/usr/src/cpython/Lib/plat-linux2/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/mnt/sda3/Python-2.7/build/lib.linux-x86_64-3.3/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/@test_9634_tmp.pyc") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/@test_9634_tmp.pyo") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/__pycache__/@test_9634_tmp.cpython-32.pyc") = -1 ENOENT (No such file or directory)
unlink("/home/root/.local/lib/python3.3/site-packages/__pycache__/@test_9634_tmp.cpython-32.pyo") = -1 ENOENT (No such file or directory)
lstat("__pycache__", {st_mode=S_IFDIR|S_ISGID|0555, st_size=4096, ...}) = 0
open("__pycache__", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 3 entries */, 32768)   = 104
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
lstat("__pycache__/@test_9634_tmp.cpython-32.pyc", {st_mode=S_IFREG|0444, st_size=110, ...}) = 0
unlink("__pycache__/@test_9634_tmp.cpython-32.pyc") = 0
rmdir("__pycache__")                    = 0
unlink("@test_9634_tmp.py")             = 0
stat("/usr/src/cpython/Lib/test/test_import.py", {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
open("/usr/src/cpython/Lib/test/test_import.py", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7ef66e98) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=24532, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = 0
read(3, "import builtins\nimport imp\nfrom importlib.test.import_ import test_relative_imports\nfrom importlib.test.import_ import util as importlib_util\nimport marshal\nimport os\nimport py_compile\nimport random\nimport stat\nimport sys\nimport unittest\nimport textwrap\n\nfrom test.support import (\n    EnvironmentVarGuard, TESTFN, check_warnings, forget, is_jython,\n    make_legacy_pyc, rmtree, run_unittest, swap_attr, swap_item, temp_umask,\n    unlink, unload)\nfrom test import script_helper\n\n\ndef remove_files(name):\n    for f in (name + \".py\",\n              name + \".pyc\",\n              name + \".pyo\",\n              name + \".pyw\",\n              name + \"$py.class\"):\n        unlink(f)\n    rmtree('__pycache__')\n\n\nclass ImportTests(unittest.TestCase):\n\n    def setUp(self):\n        remove_files(TESTFN)\n\n    def tearDown(self):\n        unload(TESTFN)\n\n    setUp = tearDown\n\n    def test_case_sensitivity(self):\n        # Brief digression to test that import is case-sensitive:  if we got\n        # this far, we know for sure that \"random\" exists.\n        with self.assertRaises(ImportError):\n            import RAnDoM\n\n    def test_double_const(self):\n        # Another brief digression to test the accuracy of manifest float\n        # constants.\n        from test import double_const  # don't blink -- that *was* the test\n\n    def test_import(self):\n        def test_with_extension(ext):\n            # The extension is normally \".py\", perhaps \".pyw\".\n            source = TESTFN + ext\n            pyo = TESTFN + \".pyo\"\n            if is_jython:\n                pyc = TESTFN + \"$py.class\"\n            else:\n                pyc = TESTFN + \".pyc\"\n\n            with open(source, \"w\") as f:\n                print(\"# This tests Python's ability to import a\",\n                      ext, \"file.\", file=f)\n                a = random.randrange(1000)\n                b = random.randrange(1000)\n                print(\"a =\", a, file=f)\n                print(\"b =\", b, file=f)\n\n            if TESTFN in sys.modules:\n                del sys.modules[TESTFN]\n            try:\n                try:\n                    mod = __import__(TESTFN)\n                except ImportError as err:\n                    self.fail(\"import from %s failed: %s\" % (ext, err))\n\n                self.assertEqual(mod.a, a,\n                    \"module loaded (%s) but contents invalid\" % mod)\n                self.assertEqual(mod.b, b,\n                    \"module loaded (%s) but contents invalid\" % mod)\n            finally:\n                forget(TESTFN)\n                unlink(source)\n                unlink(pyc)\n                unlink(pyo)\n\n        sys.path.insert(0, os.curdir)\n        try:\n            test_with_extension(\".py\")\n            if sys.platform.startswith(\"win\"):\n                for ext in [\".PY\", \".Py\", \".pY\", \".pyw\", \".PYW\", \".pYw\"]:\n                    test_with_extension(ext)\n        finally:\n            del sys.path[0]\n\n    @unittest.skipUnless(os.name == 'posix',\n                         \"test meaningful only on posix systems\")\n    def test_execute_bit_not_copied(self):\n        # Issue 6070: under posix .pyc files got their execute bit set if\n        # the .py file had the execute bit set, but they aren't executable.\n        with temp_umask(0o022):\n            sys.path.insert(0, os.curdir)\n            try:\n                fname = TESTFN + os.extsep + \"py\"\n                open(fname, 'w').close()\n                os.chmod(fname, (stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH |\n                                 stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH))\n                __import__(TESTFN)\n                fn = imp.cache_from_source(fname)\n                if not os.path.exists(fn):\n                    self.fail(\"__import__ did not result in creation of \"\n                              \"either a .pyc or .pyo file\")\n                    s = os.stat(fn)\n                    self.assertEqual(\n                        stat.S_IMODE(s.st_mode),\n                        stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH)\n            finally:\n                del sys.path[0]\n                remove_files(TESTFN)\n                u", 4096) = 4096
lseek(3, 0, SEEK_CUR)                   = 4096
read(3, "nload(TESTFN)\n\n    def test_imp_module(self):\n        # Verify that the imp module can correctly load and find .py files\n        # XXX (ncoghlan): It would be nice to use support.CleanImport\n        # here, but that breaks because the os module registers some\n        # handlers in copy_reg on import. Since CleanImport doesn't\n        # revert that registration, the module is left in a broken\n        # state after reversion. Reinitialising the module contents\n        # and just reverting os.environ to its previous state is an OK\n        # workaround\n        orig_path = os.path\n        orig_getenv = os.getenv\n        with EnvironmentVarGuard():\n            x = imp.find_module(\"os\")\n            self.addCleanup(x[0].close)\n            new_os = imp.load_module(\"os\", *x)\n            self.assertIs(os, new_os)\n            self.assertIs(orig_path, new_os.path)\n            self.assertIsNot(orig_getenv, new_os.getenv)\n\n    def test_module_with_large_stack(self, module='longlist'):\n        # Regression test for http://bugs.python.org/issue561858.\n        filename = module + '.py'\n\n        # Create a file with a list of 65000 elements.\n        with open(filename, 'w') as f:\n            f.write('d = [\\n')\n            for i in range(65000):\n                f.write('\"\",\\n')\n            f.write(']')\n\n        try:\n            # Compile & remove .py file; we only need .pyc (or .pyo).\n            # Bytecode must be relocated from the PEP 3147 bytecode-only location.\n            py_compile.compile(filename)\n        finally:\n            unlink(filename)\n\n        # Need to be able to load from current dir.\n        sys.path.append('')\n\n        try:\n            make_legacy_pyc(filename)\n            # This used to crash.\n            exec('import ' + module)\n        finally:\n            # Cleanup.\n            del sys.path[-1]\n            unlink(filename + 'c')\n            unlink(filename + 'o')\n\n    def test_failing_import_sticks(self):\n        source = TESTFN + \".py\"\n        with open(source, \"w\") as f:\n            print(\"a = 1/0\", file=f)\n\n        # New in 2.4, we shouldn't be able to import that no matter how often\n        # we try.\n        sys.path.insert(0, os.curdir)\n        if TESTFN in sys.modules:\n            del sys.modules[TESTFN]\n        try:\n            for i in [1, 2, 3]:\n                self.assertRaises(ZeroDivisionError, __import__, TESTFN)\n                self.assertNotIn(TESTFN, sys.modules,\n                                 \"damaged module in sys.modules on %i try\" % i)\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n\n    def test_import_name_binding(self):\n        # import x.y.z binds x in the current namespace\n        import test as x\n        import test.support\n        self.assertTrue(x is test, x.__name__)\n        self.assertTrue(hasattr(test.support, \"__file__\"))\n\n        # import x.y.z as w binds z as w\n        import test.support as y\n        self.assertTrue(y is test.support, y.__name__)\n\n    def test_failing_reload(self):\n        # A failing reload should leave the module object in sys.modules.\n        source = TESTFN + os.extsep + \"py\"\n        with open(source, \"w\") as f:\n            f.write(\"a = 1\\nb=2\\n\")\n\n        sys.path.insert(0, os.curdir)\n        try:\n            mod = __import__(TESTFN)\n            self.assertIn(TESTFN, sys.modules)\n            self.assertEqual(mod.a, 1, \"module has wrong attribute values\")\n            self.assertEqual(mod.b, 2, \"module has wrong attribute values\")\n\n            # On WinXP, just replacing the .py file wasn't enough to\n            # convince reload() to reparse it.  Maybe the timestamp didn't\n            # move enough.  We force it to get reparsed by removing the\n            # compiled file too.\n            remove_files(TESTFN)\n\n            # Now damage the module.\n            with open(source, \"w\") as f:\n                f.write(\"a = 10\\nb=20//0\\n\")\n\n            self.assertRaises(ZeroDivisionError, imp.reload, mod)\n            # But we still expect the module to be in sys.modules.\n            mod = sys.modules.get(TESTFN)\n            self.assertIsNot", 4096) = 4096
read(3, "(mod, None, \"expected module to be in sys.modules\")\n\n            # We should have replaced a w/ 10, but the old b value should\n            # stick.\n            self.assertEqual(mod.a, 10, \"module has wrong attribute values\")\n            self.assertEqual(mod.b, 2, \"module has wrong attribute values\")\n\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n            unload(TESTFN)\n\n    def test_file_to_source(self):\n        # check if __file__ points to the source file where available\n        source = TESTFN + \".py\"\n        with open(source, \"w\") as f:\n            f.write(\"test = None\\n\")\n\n        sys.path.insert(0, os.curdir)\n        try:\n            mod = __import__(TESTFN)\n            self.assertTrue(mod.__file__.endswith('.py'))\n            os.remove(source)\n            del sys.modules[TESTFN]\n            make_legacy_pyc(source)\n            mod = __import__(TESTFN)\n            base, ext = os.path.splitext(mod.__file__)\n            self.assertIn(ext, ('.pyc', '.pyo'))\n        finally:\n            del sys.path[0]\n            remove_files(TESTFN)\n            if TESTFN in sys.modules:\n                del sys.modules[TESTFN]\n\n    def test_import_name_binding(self):\n        # import x.y.z binds x in the current namespace.\n        import test as x\n        import test.support\n        self.assertIs(x, test, x.__name__)\n        self.assertTrue(hasattr(test.support, \"__file__\"))\n\n        # import x.y.z as w binds z as w.\n        import test.support as y\n        self.assertIs(y, test.support, y.__name__)\n\n    def test_import_initless_directory_warning(self):\n        with check_warnings(('', ImportWarning)):\n            # Just a random non-package directory we always expect to be\n            # somewhere in sys.path...\n            self.assertRaises(ImportError, __import__, \"site-packages\")\n\n    def test_import_by_filename(self):\n        path = os.path.abspath(TESTFN)\n        encoding = sys.getfilesystemencoding()\n        try:\n            path.encode(encoding)\n        except UnicodeEncodeError:\n            self.skipTest('path is not encodable to {}'.format(encoding))\n        with self.assertRaises(ImportError) as c:\n            __import__(path)\n\n    def test_import_in_del_does_not_crash(self):\n        # Issue 4236\n        testfn = script_helper.make_script('', TESTFN, textwrap.dedent(\"\"\"\\\n            import sys\n            class C:\n               def __del__(self):\n                  import imp\n            sys.argv.insert(0, C())\n            \"\"\"))\n        script_helper.assert_python_ok(testfn)\n\n\nclass PycRewritingTests(unittest.TestCase):\n    # Test that the `co_filename` attribute on code objects always points\n    # to the right file, even when various things happen (e.g. both the .py\n    # and the .pyc file are renamed).\n\n    module_name = \"unlikely_module_name\"\n    module_source = \"\"\"\nimport sys\ncode_filename = sys._getframe().f_code.co_filename\nmodule_filename = __file__\nconstant = 1\ndef func():\n    pass\nfunc_filename = func.__code__.co_filename\n\"\"\"\n    dir_name = os.path.abspath(TESTFN)\n    file_name = os.path.join(dir_name, module_name) + os.extsep + \"py\"\n    compiled_name = imp.cache_from_source(file_name)\n\n    def setUp(self):\n        self.sys_path = sys.path[:]\n        self.orig_module = sys.modules.pop(self.module_name, None)\n        os.mkdir(self.dir_name)\n        with open(self.file_name, \"w\") as f:\n            f.write(self.module_source)\n        sys.path.insert(0, self.dir_name)\n\n    def tearDown(self):\n        sys.path[:] = self.sys_path\n        if self.orig_module is not None:\n            sys.modules[self.module_name] = self.orig_module\n        else:\n            unload(self.module_name)\n        unlink(self.file_name)\n        unlink(self.compiled_name)\n        rmtree(self.dir_name)\n\n    def import_module(self):\n        ns = globals()\n        __import__(self.module_name, ns, ns)\n        return sys.modules[self.module_name]\n\n    def test_basics(self):\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.fil", 4096) = 4096
read(3, "e_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n        del sys.modules[self.module_name]\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.file_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n\n    def test_incorrect_code_name(self):\n        py_compile.compile(self.file_name, dfile=\"another_module.py\")\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, self.file_name)\n        self.assertEqual(mod.code_filename, self.file_name)\n        self.assertEqual(mod.func_filename, self.file_name)\n\n    def test_module_without_source(self):\n        target = \"another_module.py\"\n        py_compile.compile(self.file_name, dfile=target)\n        os.remove(self.file_name)\n        pyc_file = make_legacy_pyc(self.file_name)\n        mod = self.import_module()\n        self.assertEqual(mod.module_filename, pyc_file)\n        self.assertEqual(mod.code_filename, target)\n        self.assertEqual(mod.func_filename, target)\n\n    def test_foreign_code(self):\n        py_compile.compile(self.file_name)\n        with open(self.compiled_name, \"rb\") as f:\n            header = f.read(8)\n            code = marshal.load(f)\n        constants = list(code.co_consts)\n        foreign_code = test_main.__code__\n        pos = constants.index(1)\n        constants[pos] = foreign_code\n        code = type(code)(code.co_argcount, code.co_kwonlyargcount,\n                          code.co_nlocals, code.co_stacksize,\n                          code.co_flags, code.co_code, tuple(constants),\n                          code.co_names, code.co_varnames, code.co_filename,\n                          code.co_name, code.co_firstlineno, code.co_lnotab,\n                          code.co_freevars, code.co_cellvars)\n        with open(self.compiled_name, \"wb\") as f:\n            f.write(header)\n            marshal.dump(code, f)\n        mod = self.import_module()\n        self.assertEqual(mod.constant.co_filename, foreign_code.co_filename)\n\n\nclass PathsTests(unittest.TestCase):\n    SAMPLES = ('test', 'test\\u00e4\\u00f6\\u00fc\\u00df', 'test\\u00e9\\u00e8',\n               'test\\u00b0\\u00b3\\u00b2')\n    path = TESTFN\n\n    def setUp(self):\n        os.mkdir(self.path)\n        self.syspath = sys.path[:]\n\n    def tearDown(self):\n        rmtree(self.path)\n        sys.path[:] = self.syspath\n\n    # Regression test for http://bugs.python.org/issue1293.\n    def test_trailing_slash(self):\n        with open(os.path.join(self.path, 'test_trailing_slash.py'), 'w') as f:\n            f.write(\"testdata = 'test_trailing_slash'\")\n        sys.path.append(self.path+'/')\n        mod = __import__(\"test_trailing_slash\")\n        self.assertEqual(mod.testdata, 'test_trailing_slash')\n        unload(\"test_trailing_slash\")\n\n    # Regression test for http://bugs.python.org/issue3677.\n    def _test_UNC_path(self):\n        with open(os.path.join(self.path, 'test_trailing_slash.py'), 'w') as f:\n            f.write(\"testdata = 'test_trailing_slash'\")\n        # Create the UNC path, like \\\\myhost\\c$\\foo\\bar.\n        path = os.path.abspath(self.path)\n        import socket\n        hn = socket.gethostname()\n        drive = path[0]\n        unc = \"\\\\\\\\%s\\\\%s$\"%(hn, drive)\n        unc += path[2:]\n        sys.path.append(path)\n        mod = __import__(\"test_trailing_slash\")\n        self.assertEqual(mod.testdata, 'test_trailing_slash')\n        unload(\"test_trailing_slash\")\n\n    if sys.platform == \"win32\":\n        test_UNC_path = _test_UNC_path\n\n\nclass RelativeImportTests(unittest.TestCase):\n\n    def tearDown(self):\n        unload(\"test.relimport\")\n    setUp = tearDown\n\n    def test_relimport_star(self):\n        # This will import * from .test_import.\n        from . import relimport\n        self.assertTrue(hasattr(relimport, \"RelativeImportTests\"))\n\n    def test_issue3221(self):\n        # Note for mergers: the 'absolute' tests from the 2.x branch\n        # are missing in Py3k because implicit relative imports are\n        # a thing of the past\n        #\n        # Regression test for htt", 4096) = 4096
read(3, "p://bugs.python.org/issue3221.\n        def check_relative():\n            exec(\"from . import relimport\", ns)\n\n        # Check relative import OK with __package__ and __name__ correct\n        ns = dict(__package__='test', __name__='test.notarealmodule')\n        check_relative()\n\n        # Check relative import OK with only __name__ wrong\n        ns = dict(__package__='test', __name__='notarealpkg.notarealmodule')\n        check_relative()\n\n        # Check relative import fails with only __package__ wrong\n        ns = dict(__package__='foo', __name__='test.notarealmodule')\n        self.assertRaises(SystemError, check_relative)\n\n        # Check relative import fails with __package__ and __name__ wrong\n        ns = dict(__package__='foo', __name__='notarealpkg.notarealmodule')\n        self.assertRaises(SystemError, check_relative)\n\n        # Check relative import fails with package set to a non-string\n        ns = dict(__package__=object())\n        self.assertRaises(ValueError, check_relative)\n\n    def test_absolute_import_without_future(self):\n        # If explicit relative import syntax is used, then do not try\n        # to perform an absolute import in the face of failure.\n        # Issue #7902.\n        with self.assertRaises(ImportError):\n            from .os import sep\n            self.fail(\"explicit relative import triggered an \"\n                      \"implicit absolute import\")\n\n\nclass OverridingImportBuiltinTests(unittest.TestCase):\n    def test_override_builtin(self):\n        # Test that overriding builtins.__import__ can bypass sys.modules.\n        import os\n\n        def foo():\n            import os\n            return os\n        self.assertEqual(foo(), os)  # Quick sanity check.\n\n        with swap_attr(builtins, \"__import__\", lambda *x: 5):\n            self.assertEqual(foo(), 5)\n\n        # Test what happens when we shadow __import__ in globals(); this\n        # currently does not impact the import process, but if this changes,\n        # other code will need to change, so keep this test as a tripwire.\n        with swap_item(globals(), \"__import__\", lambda *x: 5):\n            self.assertEqual(foo(), os)\n\n\nclass PycacheTests(unittest.TestCase):\n    # Test the various PEP 3147 related behaviors.\n\n    tag = imp.get_tag()\n\n    def _clean(self):\n        forget(TESTFN)\n        rmtree('__pycache__')\n        unlink(self.source)\n\n    def setUp(self):\n        self.source = TESTFN + '.py'\n        self._clean()\n        with open(self.source, 'w') as fp:\n            print('# This is a test file written by test_import.py', file=fp)\n        sys.path.insert(0, os.curdir)\n\n    def tearDown(self):\n        assert sys.path[0] == os.curdir, 'Unexpected sys.path[0]'\n        del sys.path[0]\n        self._clean()\n\n    def test_import_pyc_path(self):\n        self.assertFalse(os.path.exists('__pycache__'))\n        __import__(TESTFN)\n        self.assertTrue(os.path.exists('__pycache__'))\n        self.assertTrue(os.path.exists(os.path.join(\n            '__pycache__', '{}.{}.py{}'.format(\n            TESTFN, self.tag, __debug__ and 'c' or 'o'))))\n\n    @unittest.skipUnless(os.name == 'posix',\n                         \"test meaningful only on posix systems\")\n    def test_unwritable_directory(self):\n        # When the umask causes the new __pycache__ directory to be\n        # unwritable, the import still succeeds but no .pyc file is written.\n        with temp_umask(0o222):\n            __import__(TESTFN)\n        self.assertTrue(os.path.exists('__pycache__'))\n        self.assertFalse(os.path.exists(os.path.join(\n            '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))\n\n    def test_missing_source(self):\n        # With PEP 3147 cache layout, removing the source but leaving the pyc\n        # file does not satisfy the import.\n        __import__(TESTFN)\n        pyc_file = imp.cache_from_source(self.source)\n        self.assertTrue(os.path.exists(pyc_file))\n        os.remove(self.source)\n        forget(TESTFN)\n        self.assertRaises(ImportError, __import__, TESTFN)\n\n    def test_missing_source_legacy(self):\n        # Like test_missing_source() ", 4096) = 4096
read(3, "except that for backward compatibility,\n        # when the pyc file lives where the py file would have been (and named\n        # without the tag), it is importable.  The __file__ of the imported\n        # module is the pyc location.\n        __import__(TESTFN)\n        # pyc_file gets removed in _clean() via tearDown().\n        pyc_file = make_legacy_pyc(self.source)\n        os.remove(self.source)\n        unload(TESTFN)\n        m = __import__(TESTFN)\n        self.assertEqual(m.__file__,\n                         os.path.join(os.curdir, os.path.relpath(pyc_file)))\n\n    def test___cached__(self):\n        # Modules now also have an __cached__ that points to the pyc file.\n        m = __import__(TESTFN)\n        pyc_file = imp.cache_from_source(TESTFN + '.py')\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, pyc_file))\n\n    def test___cached___legacy_pyc(self):\n        # Like test___cached__() except that for backward compatibility,\n        # when the pyc file lives where the py file would have been (and named\n        # without the tag), it is importable.  The __cached__ of the imported\n        # module is the pyc location.\n        __import__(TESTFN)\n        # pyc_file gets removed in _clean() via tearDown().\n        pyc_file = make_legacy_pyc(self.source)\n        os.remove(self.source)\n        unload(TESTFN)\n        m = __import__(TESTFN)\n        self.assertEqual(m.__cached__,\n                         os.path.join(os.curdir, os.path.relpath(pyc_file)))\n\n    def test_package___cached__(self):\n        # Like test___cached__ but for packages.\n        def cleanup():\n            rmtree('pep3147')\n        os.mkdir('pep3147')\n        self.addCleanup(cleanup)\n        # Touch the __init__.py\n        with open(os.path.join('pep3147', '__init__.py'), 'w'):\n            pass\n        with open(os.path.join('pep3147', 'foo.py'), 'w'):\n            pass\n        unload('pep3147.foo')\n        unload('pep3147')\n        m = __import__('pep3147.foo')\n        init_pyc = imp.cache_from_source(\n            os.path.join('pep3147', '__init__.py'))\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, init_pyc))\n        foo_pyc = imp.cache_from_source(os.path.join('pep3147', 'foo.py'))\n        self.assertEqual(sys.modules['pep3147.foo'].__cached__,\n                         os.path.join(os.curdir, foo_pyc))\n\n    def test_package___cached___from_pyc(self):\n        # Like test___cached__ but ensuring __cached__ when imported from a\n        # PEP 3147 pyc file.\n        def cleanup():\n            rmtree('pep3147')\n        os.mkdir('pep3147')\n        self.addCleanup(cleanup)\n        unload('pep3147.foo')\n        unload('pep3147')\n        # Touch the __init__.py\n        with open(os.path.join('pep3147', '__init__.py'), 'w'):\n            pass\n        with open(os.path.join('pep3147', 'foo.py'), 'w'):\n            pass\n        m = __import__('pep3147.foo')\n        unload('pep3147.foo')\n        unload('pep3147')\n        m = __import__('pep3147.foo')\n        init_pyc = imp.cache_from_source(\n            os.path.join('pep3147', '__init__.py'))\n        self.assertEqual(m.__cached__, os.path.join(os.curdir, init_pyc))\n        foo_pyc = imp.cache_from_source(os.path.join('pep3147', 'foo.py'))\n        self.assertEqual(sys.modules['pep3147.foo'].__cached__,\n                         os.path.join(os.curdir, foo_pyc))\n\n\nclass RelativeImportFromImportlibTests(test_relative_imports.RelativeImports):\n\n    def setUp(self):\n        self._importlib_util_flag = importlib_util.using___import__\n        importlib_util.using___import__ = True\n\n    def tearDown(self):\n        importlib_util.using___import__ = self._importlib_util_flag\n\n\ndef test_main(verbose=None):\n    run_unittest(ImportTests, PycacheTests,\n                 PycRewritingTests, PathsTests, RelativeImportTests,\n                 OverridingImportBuiltinTests,\n                 RelativeImportFromImportlibTests)\n\n\nif __name__ == '__main__':\n    # Test needs to be a package, so we can do relative imports.\n    from test.test_import import test_main\n    test_main()\n", 4096) = 4052
read(3, "", 4096)                       = 0
close(3)                                = 0
write(1, "FAIL\ntest_basics (test.test_import.PycRewritingTests) ... ", 58FAIL

----------
messages: 134781
nosy: Jason.Vas.Dias
priority: normal
severity: normal
status: open
title: 3.3 : test_import.py causes 'make test' to fail

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

From report at bugs.python.org  Fri Apr 29 20:27:10 2011
From: report at bugs.python.org (Mindaugas)
Date: Fri, 29 Apr 2011 18:27:10 +0000
Subject: [New-bugs-announce] [issue11957] re.sub problem with unicode string
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>


New submission from Mindaugas <mindaugas.rucys at gmail.com>:

re.sub don't substitute not ASCII characters:

Python 2.7.1 (r271:86832, Apr 15 2011, 12:11:58) Arch Linux

>>>import re

>>>a=u'aaa'
>>>print re.search('(\w+)',a,re.U).groups()
(u'aaa')
>>>print re.sub('(\w+)','x',a,re.U)
x

      BUT:

>>>a=u'???'
>>>print re.search('(\w+)',a,re.U).groups()
(u'\u0105\u0105\u0105')
>>>print re.sub('(\w+)','x',a,re.U)
???

----------
components: Regular Expressions, Unicode
messages: 134806
nosy: mindauga
priority: normal
severity: normal
status: open
title: re.sub problem with unicode string
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 29 23:08:01 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 29 Apr 2011 21:08:01 +0000
Subject: [New-bugs-announce] [issue11958]
	test.test_ftplib.TestIPv6Environment failure
In-Reply-To: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>
Message-ID: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>


New submission from Charles-Francois Natali <neologix at free.fr>:

test_ftplib fails in TestIPv6Environment:

======================================================================
ERROR: test_makepasv (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 651, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 220, in __init__
    self.bind(address)
  File "/home/cf/cpython/Lib/asyncore.py", line 339, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -2] Name or service not known

======================================================================
ERROR: test_transfer (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 651, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/cf/cpython/Lib/test/test_ftplib.py", line 220, in __init__
    self.bind(address)
  File "/home/cf/cpython/Lib/asyncore.py", line 339, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -2] Name or service not known

----------------------------------------------------------------------
Ran 74 tests in 6.595s

FAILED (errors=2)
test test_ftplib failed -- multiple errors occurred
1 test failed:
    test_ftplib

The reason is that support.HOST is 'localhost'. and on most machines, localhost is an alias for 127.0.0.1, and not the IPv6 loopback, so the address resolution fails.
One possible solution is simply to pass ::1 (IPv6 loopback address) instead of support.HOST.
Patch attached.

----------
components: Tests
files: test_ftplib_ipv6.diff
keywords: patch
messages: 134811
nosy: giampaolo.rodola, neologix
priority: normal
severity: normal
status: open
title: test.test_ftplib.TestIPv6Environment failure
type: behavior
Added file: http://bugs.python.org/file21837/test_ftplib_ipv6.diff

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

From report at bugs.python.org  Fri Apr 29 23:12:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Apr 2011 21:12:30 +0000
Subject: [New-bugs-announce] [issue11959] smtpd cannot be used without
	affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

It seems not possible to use smtpd in certain contexts, because it forces use of global state. For example, I'm looking at implementing a test SMTP server to test logging's SMTPHandler. Neither SMTPServer nor SMTPChannel allow a map to be passed in, forcing use of the global socket_map in asyncore. Both of these classes should accept an optional map argument - the map passed to SMTPServer should be stored in the server instance and passed when creating an SMTPChannel in handle_accepted.

----------
components: Library (Lib)
messages: 134812
nosy: giampaolo.rodola, vinay.sajip
priority: normal
severity: normal
status: open
title: smtpd cannot be used without affecting global state
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 30 03:16:30 2011
From: report at bugs.python.org (Alex Lai)
Date: Sat, 30 Apr 2011 01:16:30 +0000
Subject: [New-bugs-announce] [issue11960] Python crashes when running numpy
	test
In-Reply-To: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>
Message-ID: <1304126190.62.0.557405108675.issue11960@psf.upfronthosting.co.za>


New submission from Alex Lai <alex_lai at scotiacapital.com>:

Hi experts,

            I?m wondering if anyone would look into this issue. We recently installed Python 3.1.2 on a Solaris 10 machine. While testing numpy package, Python crashed with the following error:

sbtorsvr391:~ $ cd /home/dcottr/local/tests
sbtorsvr391:~/local/tests $ export PYTHONPATH=$PYTHONPATH:~/local/lib/python3.1/site-packages

sbtorsvr391:~/local/tests $ /usr/local/bin/python3 -c "import numpy; numpy.test()"
Running unit tests for numpy
NumPy version 1.5.1
NumPy is installed in /home/dcottr/local/lib/python3.1/site-packages/numpy

Python version 3.1.2 (r312:79147, Mar 23 2010, 02:42:06) [GCC 3.4.6]
nose version 1.0.0
..S...............................................................................................................................................S........Warning: invalid value encountered in isfinite
............................................................................................................................................................................................Warning: invalid value encountered in isinf
Warning: invalid value encountered in isinf
......................................................................................................SSS........................K...........................................................K.....................................................................................................................................................F.F....................K.............................................................................................K...SK.F.......S...........................................................................................Segmentation Fault (core dumped)


            Below is the stack trace from the core dump:

 

# mdb core_sbtorsvr391_python3_10439_5000_1304101376_11246

Loading modules: [ libc.so.1 libavl.so.1 libuutil.so.1 ld.so.1 ]

> 
> ::stack
libc.so.1`strlen+0x50(fba55238, ffbf9ef8, ffbf9761, 0, 0, 0)
libc.so.1`sprintf+0x40(ffbf9f18, 7fffffff, 7ffffc00, 2, 2, 1b74cc)
test_array_from_pyobj_ext.so`array_from_pyobj+0x4e0(6, 17d3ec0, 1, 7, 16176c0, ff13a5a0)
test_array_from_pyobj_ext.so`f2py_rout_wrap_call+0xbc(1, 1, 0, 17f000, fffffffe, fba65b94)
PyCFunction_Call+0x90(15ff350, 1841900, 1844e90, 0, 1, 183df38)
PyEval_EvalFrameEx+0x4f10(0, ffbfa1c0, 1615770, 1, 16491b0, 15ff350)
PyEval_EvalCodeEx+0x874(1615770, 161ff60, 0, 160cf3c, 5, 0)
function_call+0x8c(162e270, 160cf30, 0, 17f000, fffffffe, 40)
PyObject_Call+0x44(162e270, 160cf30, 0, 160cf3c, 4, 16176c0)
method_call+0x8c(162e270, 18418d0, 0, 1849f60, 1, 3f)
PyObject_Call+0x44(176b620, 18418d0, 0, 2ed5c, 2efe0, 176b620)
slot_tp_init+0x7c(176b620, 18418d0, 0, 2, 1, 16296d0)
type_call+0xdc(16521a0, 18418d0, 0, 17f000, fffffffe, 3e)
PyObject_Call+0x44(16521a0, 18418d0, 0, 18418d8, 1820030, 183ddbc)
PyEval_EvalFrameEx+0x37b4(0, ffbfa688, 162e9b0, 1, 16259c0, 16521a0)
PyEval_EvalFrameEx+0x5c98(0, ffbfa788, 16154e8, 1, 1626030, 162eb28)
PyEval_EvalFrameEx+0x5c98(0, ffbfa888, 52b260, 1, 57ec00, 162e468)
PyEval_EvalCodeEx+0x874(52b260, 5229c0, 0, 1808834, 2, 1ac03c)
function_call+0x8c(5a36a8, 1808828, 0, 17f000, fffffffe, 3a)
PyObject_Call+0x44(5a36a8, 1808828, 1825a50, 19b000, 163ab30, fe36c4)
PyEval_EvalFrameEx+0x13bc(0, fe36c8, 52b2f0, 1, 526d50, 1808828)
PyEval_EvalCodeEx+0x874(52b2f0, 1, 0, 1808c1c, 2, 0)
function_call+0x8c(5a3738, 1808c10, 0, 17f000, fffffffe, 38)
PyObject_Call+0x44(5a3738, 1808c10, 0, 1808c10, 1, 1849e50)
method_call+0x8c(5a3738, 1630450, 0, 1630440, 9, 37)
PyObject_Call+0x44(1612850, 1630450, 0, 193618, 2, 1612850)
slot_tp_call+0x7c(163ab30, 1630450, 0, 17f000, fffffffe, 36)
PyObject_Call+0x44(163ab30, 1630450, 0, 1630458, 1849e50, fe355c)
PyEval_EvalFrameEx+0x37b4(0, ffbfaf78, b1e0f8, 1, a873a0, 163ab30)
PyEval_EvalFrameEx+0x5c98(0, ffbfb078, b1e0b0, 1, b1db58, b1ed20)
PyEval_EvalCodeEx+0x874(b1e0b0, b0e810, 0, 180b67c, 2, 1ac03c)
function_call+0x8c(b1ecd8, 180b670, 0, 17f000, fffffffe, 33)
PyObject_Call+0x44(b1ecd8, 180b670, 18258a0, 19b000, 163abf0, fe2f3c)
PyEval_EvalFrameEx+0x13bc(0, fe2f40, b1ccc8, 1, b1a350, 180b670)
PyEval_EvalCodeEx+0x874(b1ccc8, 1, 0, 1844dac, 2, 0)
function_call+0x8c(b1ea50, 1844da0, 0, 17f000, fffffffe, 31)
PyObject_Call+0x44(b1ea50, 1844da0, 0, 1844da0, 1, e4ddf0)
method_call+0x8c(b1ea50, 16306d0, 0, 16306c0, b, 30)
PyObject_Call+0x44(176b5a8, 16306d0, 0, 1ab728, 18f708, 176b5a8)
slot_tp_call+0x7c(163abf0, 16306d0, 0, 17f000, fffffffe, 2f)
PyObject_Call+0x44(163abf0, 16306d0, 0, 16306d8, e4ddf0, 18374d8)
PyEval_EvalFrameEx+0x37b4(0, ffbfb768, b2e4e8, 1, ad9ce8, 163abf0)
PyEval_EvalCodeEx+0x874(b2e4e8, b1b4b0, 0, 18087bc, 2, 1ac03c)
function_call+0x8c(a00390, 18087b0, 0, 17f000, fffffffe, 2d)
PyObject_Call+0x44(a00390, 18087b0, 176c810, 19b000, 165c450, 182ea24)
PyEval_EvalFrameEx+0x13bc(0, 182ea28, b2e380, 1, b1ad50, 18087b0)
PyEval_EvalCodeEx+0x874(b2e380, 1, 0, 176b8ac, 2, 0)
function_call+0x8c(a002b8, 176b8a0, 0, 17f000, fffffffe, 2b)
PyObject_Call+0x44(a002b8, 176b8a0, 0, 176b8a0, 1, e4ddf0)
method_call+0x8c(a002b8, 16141b0, 0, 16141a0, 9, 2a)
PyObject_Call+0x44(1612c10, 16141b0, 0, 1ab728, 18f708, 1612c10)
slot_tp_call+0x7c(165c450, 16141b0, 0, 17f000, fffffffe, 29)
PyObject_Call+0x44(165c450, 16141b0, 0, 16141b8, e4ddf0, 1645cf0)
PyEval_EvalFrameEx+0x37b4(0, ffbfbe58, b2e4e8, 1, ad9ce8, 165c450)
PyEval_EvalCodeEx+0x874(b2e4e8, b1b4b0, 0, 16296a4, 2, 1ac03c)
function_call+0x8c(a00390, 1629698, 0, 17f000, fffffffe, 27)
PyObject_Call+0x44(a00390, 1629698, 161f8a0, 19b000, 176a270, 124868c)
PyEval_EvalFrameEx+0x13bc(0, 1248690, b2e380, 1, b1ad50, 1629698)
PyEval_EvalCodeEx+0x874(b2e380, 1, 0, 16127bc, 2, 0)
> ::quit

The C library used by Python is as follows:


sbtorsvr391:~/local/tests $ ldd /usr/local/bin/python3|grep libc
        libc.so.1 =>        /lib/libc.so.1
        /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
 
sbtorsvr391:~ $ ls -l /lib/libc.so.1
-rwxr-xr-x 1 root bin 1640776 Aug 10  2010 /lib/libc.so.1

sbtorsvr391:~ $ pkgchk -l -p /lib/libc.so.1
NOTE: Couldn't lock the package database.
Pathname: /lib/libc.so.1
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: bin
Expected file size (bytes): 1640776
Expected sum(1) of contents: 50250
Expected last modification: Aug 10 13:55:34 2010
Referenced by the following packages:
        SUNWcslr
Current status: installed

sbtorsvr391:~ $ pkginfo -l SUNWcslr
   PKGINST:  SUNWcslr
      NAME:  Core Solaris Libraries (Root)
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  11.10.0,REV=2005.01.21.15.53
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  core software for a specific instruction-set architecture
    PSTAMP:  on10-patch20100511083333
  INSTDATE:  Jan 22 2011 16:10
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:      245 installed pathnames
                   2 shared pathnames
                   5 directories
                 133 executables
               34303 blocks used (approx)


The same problem doesn't occur when the command is run as root.

I opened a ticket with Oracle support for the libc isse, they responsed with the comment "The python program is passing an invalid address to the third parameter of sprintf. This is not a Solaris issue. Please contact python support."

I'm hoping I will find answer to this issue here...


Thanks in advance,

Alex

----------
components: Interpreter Core
messages: 134827
nosy: alex_lai
priority: normal
severity: normal
status: open
title: Python crashes when running numpy test
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Apr 30 04:16:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Apr 2011 02:16:45 +0000
Subject: [New-bugs-announce] [issue11961] Document STARTUPINFO and
	creationflags options for	Windows
In-Reply-To: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>
Message-ID: <1304129805.59.0.427649985572.issue11961@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Attached is a patch that adds documentation for a few things that have existed in subprocess for a while without documentation.

The "startupinfo" parameter takes subprocess.STARTUPINFO object which takes a few different options for its attributes, but none of this was documented.

The "creationflags" parameter takes subprocess.CREATE_NEW_WINDOW or subprocess.CREATE_NEW_PROCESS_GROUP, but neither were documented as options or what the options mean.

----------
assignee: brian.curtin
components: Documentation, Windows
files: windows_additions.diff
keywords: needs review, patch
messages: 134829
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Document STARTUPINFO and creationflags options for Windows
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21838/windows_additions.diff

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

From report at bugs.python.org  Sat Apr 30 08:43:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 30 Apr 2011 06:43:11 +0000
Subject: [New-bugs-announce] [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The FreeBSD-AMD64 bot exhibits sporadic hanging in unspecific places.
FreeBSD is running under kvm in the background. When the hanging occurs,
the virtual machine uses 100% CPU and I can't log in via ssh, so I have
to kill the kvm process.

The fact that the ssh login fails if a user process is misbehaving
seems like a FreeBSD/kvm issue to me. However, this problem did not
occur when I set up the bot a couple of weeks ago.


I've started a series of older revision builds to see if anything
recent causes this.

----------
components: Tests
messages: 134839
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: FreeBSD-AMD64 bot sporadic hanging
type: behavior

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

From report at bugs.python.org  Sat Apr 30 17:43:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:43:25 +0000
Subject: [New-bugs-announce] [issue11963] Use real assert* for
	test_trigger_memory_error	(test_parser)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I?ve always found strange that one test relied on visual (i.e. human) checking instead of using an assert* method.  I changed it and found that the test still passed (see attached patch).  Is there any reason to do it the old way?

----------
components: Tests
files: real-assert-in-test_parser.diff
keywords: patch
messages: 134868
nosy: benjamin.peterson, eric.araujo, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Use real assert* for test_trigger_memory_error (test_parser)
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file21842/real-assert-in-test_parser.diff

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

From report at bugs.python.org  Sat Apr 30 17:47:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:47:15 +0000
Subject: [New-bugs-announce] [issue11964] Undocumented change to indent
	param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found out that the indent parameter of json.dump was changed in 3.2: it can be a string as well as an int.  The docstring was not updated; the reST doc was, but without a versionchanged directive.

This probably applies to the doc and docstring of the classes implementing dump, too, and there may be other half-documented changes.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 134869
nosy: bob.ippolito, docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Undocumented change to indent param of json.dump in 3.2
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr 30 17:49:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Apr 2011 15:49:30 +0000
Subject: [New-bugs-announce] [issue11965] Simplify context manager in
	os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Previous to 3.2, os.popen was made a context manager thanks to a private helper, os._wrap_close (contextlib.closing was maybe unavailable due to a bootstrapping issue).  Now that subprocess.Popen directly implements the context manager protocol, this could be cleaned up.

----------
components: Library (Lib)
keywords: easy
messages: 134870
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify context manager in os.popen
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 30 18:32:23 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 30 Apr 2011 16:32:23 +0000
Subject: [New-bugs-announce] [issue11966] Typo in PyModule_AddIntMacro's
	documentation
In-Reply-To: <1304181143.38.0.500156763216.issue11966@psf.upfronthosting.co.za>
Message-ID: <1304181143.38.0.500156763216.issue11966@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

The example says "PyModule_AddConstant" instead of "PyModule_AddIntMacro". Attached is a patch for 3.1 branch, but it applies to all branches.

----------
assignee: docs at python
components: Documentation
files: PyModule_AddIntMacro_doc.patch
keywords: patch
messages: 134879
nosy: Trundle, docs at python
priority: normal
severity: normal
status: open
title: Typo in PyModule_AddIntMacro's documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21843/PyModule_AddIntMacro_doc.patch

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