.TMP

Component	Meaning
	Path specified by the lpPathName parameter
	First three letters of the lpPrefixString string
	Hexadecimal value of uUnique

Only the lower 16 bits of the uUnique parameter are used. This limits GetTempFileName to a maximum of 65,535 unique file names if the lpPathName and lpPrefixString parameters remain the same.

----------
components: Library (Lib)
files: tempfile.py.diff
keywords: patch
messages: 135261
nosy: planet36
priority: normal
severity: normal
status: open
title: possible characters in temporary file name is too few
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21906/tempfile.py.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 11:16:17 2011
From: report at bugs.python.org (zy)
Date: Fri, 06 May 2011 09:16:17 +0000
Subject: [New-bugs-announce] [issue12016] Wrong behavior for
	'\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>


New submission from zy :

let s='\xff\n' 
The expected result of s.decode('gb2312', 'ignore') is u"\n", while in 2.6.6 it is u"".
  s can be replaced with chr(m) + chr(n) , where m is in range of 128~255, and n in 0~127.
  In the above cases, try decoding from chr(n) will never interfere with later parts in the string if there is any, since chr(n) do not start a multibyte sequence.

----------
components: Unicode
messages: 135268
nosy: cdqzzy
priority: normal
severity: normal
status: open
title: Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 14:25:57 2011
From: report at bugs.python.org (ivank)
Date: Fri, 06 May 2011 12:25:57 +0000
Subject: [New-bugs-announce] [issue12017] Decoding a highly-nested object
	with json (_speedups	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>


New submission from ivank :

Decoding a highly-nested object with json (_speedups enabled) can cause a segfault due to a stack overflow:

# python -c "import json; json.loads('[' * 100000 + '1' + ']' * 100000)"
zsh: segmentation fault  python -c "import json; json.loads('[' * 100000 + '1' + ']' * 100000)"

# python -c "import json; json.loads('{\"a\":' * 100000 + '1' + '}' * 100000)"
zsh: segmentation fault  python -c "import json; json.loads('{\"a\":' * 100000 + '1' + '}' * 100000)"

simplejson has the same problem:
https://github.com/simplejson/simplejson/pull/11

I've started on a fix (see patch at that URL), but it doesn't support customizing max_depth yet.

----------
components: Library (Lib)
messages: 135281
nosy: ivank
priority: normal
severity: normal
status: open
title: Decoding a highly-nested object with json (_speedups enabled) causes segfault
type: security
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 17:12:50 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 15:12:50 +0000
Subject: [New-bugs-announce] [issue12018] No tests for ntpath.samefile,
	ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>


New submission from Ronald Oussoren :

Python 3.2 introduced ntpath.samefile, but the implementation is not tested in test_ntpath.py. The same seems true of ntpath.sameopenfile.

As noted in #10684 ntpath.samefile is broken on XP, which would have been caught by unittest. I've committed a fix for that particular bug, but haven't added unittests.

----------
components: Windows
keywords: easy
messages: 135307
nosy: ronaldoussoren
priority: low
severity: normal
stage: test needed
status: open
title: No tests for ntpath.samefile, ntpath.sameopenfile
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 18:08:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:08:27 +0000
Subject: [New-bugs-announce] [issue12019] Dead or buggy code in
	importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

I was stealing importlib?s test/__main__ file for packaging (thanks!) and I noticed this bug thanks to pyflakes: ?sep? is undefined.  It looks like the bug hasn?t been noticed because it?s in a dead block that depends on __file__ containing '__pycache__'.  Is this a leftover from a previous version of the PEP without __file__/__cached__ distinction?  Or maybe __file__ is set to the pyc file for pyc-only imports?

----------
components: Tests
messages: 135314
nosy: barry, brett.cannon, eric.araujo
priority: normal
severity: normal
status: open
title: Dead or buggy code in importlib.test.__main__
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 19:44:37 2011
From: report at bugs.python.org (James Hutchison)
Date: Fri, 06 May 2011 17:44:37 +0000
Subject: [New-bugs-announce] [issue12020] Attribute error with flush on
	stdout, stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>


New submission from James Hutchison :

When upgrading from Python 3.1 to Python 3.2 I noticed that when my program closed it printed out a non-consequential AttributeError Exception. My program had a custom class that replaced stdout and stderr for use in a piped program (it flushed the buffer after every print statement)

I was able to reduce my code down to this simple test case that will reproduce the issue. Note that this doesn't show up in idle.

code:
import sys
from time import sleep
import subprocess

python31loc = r"C:\python31\python.exe";
python32loc = r"C:\python32\python.exe";
myname = "attributeError.py";

class FlushFile(object):
    #"""Write-only flushing wrapper for file-type objects."""
    def __init__(self, f):
        self.f = f
        try:
            self.encoding = f.encoding;
        except:
            pass;
    def write(self, x):
        self.f.write(x)
        self.f.flush()

# sets stdout and stderr to autoflush
def setAutoFlush():
    if sys.__stdout__ != None: # will be None in IDLE
        sys.stdout = FlushFile(sys.__stdout__);
        sys.stderr = FlushFile(sys.__stderr__);

if __name__ == "__main__":
    setAutoFlush();
    if(len(sys.argv) == 1):
        print("Testing python 3.1");
        output = subprocess.check_output("%s %s -output" % (python31loc, myname));
        print("Should see no error");
        print("Testing python 3.2");
        output = subprocess.check_output("%s %s -output" % (python32loc, myname));
        print("Should see no error");
        sleep(16);


Output:
Testing python 3.1
Should see no error
Testing python 3.2
Exception AttributeError: 'flush' in <__main__.FlushFile object at 0x00C347F0> i
gnored
Should see no error

----------
components: IO, Windows
messages: 135347
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Attribute error with flush on stdout,stderr
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 21:54:14 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Fri, 06 May 2011 19:54:14 +0000
Subject: [New-bugs-announce] [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>


New submission from K Richard Pixley :

mmap.read requires a argument.  Since most file-like objects do not, this breaks the file-like object illusion.

mmap.read argument should be optional, presumably defaulting to the entire mmap'd area.

----------
messages: 135362
nosy: rich-noir
priority: normal
severity: normal
status: open
title: mmap.read requires an argument
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May  6 22:07:22 2011
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 06 May 2011 20:07:22 +0000
Subject: [New-bugs-announce] [issue12022] 'transaction'
	module-as-context-manager thwarted by	Python 2.7.1
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>


New submission from Daniel Holth :

"How much do we care about special method lookup?" Python recently bypasses __getattr__ entirely when looking up context managers. http://mail.python.org/pipermail/python-dev/2009-May/089535.html

Could this be the reason that ZODB's transaction module, which attempts to be a context manager by declaring

manager = ThreadTransactionManager()
__enter__ = manager.get
__exit__ = manager.__exit__

Does not work in Python 2.7.1 on Ubuntu 11.04 or RHEL5? Frustratingly, the exception is no more specific than an AttributeError, even though hasattr(transaction, '__exit__')?

I would prefer to never get AttributeError: transaction.__exit__ when hasattr(transaction, '__exit__') as I find that to be very confusing. Maybe the interpreter could raise SpecialAttributeError('transaction.__exit__ is not sufficiently special') instead.

http://svn.zope.org/repos/main/transaction/trunk/transaction/__init__.py

----------
components: Interpreter Core
messages: 135365
nosy: dholth
priority: normal
severity: normal
status: open
title: 'transaction' module-as-context-manager thwarted by Python 2.7.1
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 00:53:05 2011
From: report at bugs.python.org (Rodrigo Ventura)
Date: Fri, 06 May 2011 22:53:05 +0000
Subject: [New-bugs-announce] [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>


New submission from Rodrigo Ventura :

Consider these two functions:
---
def nok():
    a = None
    def f():
        if a:
            a = 1
    f()

def ok():
    a = None
    def f():
        if a:
            b = 1
    f()
---

Function ok() executes fine, but function nok() trigger an exception:

Traceback (most recent call last):
  File "pb.py", line 20, in 
    nok()
  File "pb.py", line 7, in nok
    f()
  File "pb.py", line 5, in f
    if a:
UnboundLocalError: local variable 'a' referenced before assignment

There is no reason for this to happen

Regards,
Rodrigo Ventura

----------
messages: 135380
nosy: Rodrigo.Ventura
priority: normal
severity: normal
status: open
title: non causal behavior
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 01:20:15 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2011 23:20:15 +0000
Subject: [New-bugs-announce] [issue12024] 2.6 svn and hg branches are out of
	sync
In-Reply-To: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>
Message-ID: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw :

Martin points out that the svn and hg branches for 2.6 are out of sync.  I made the 2.6.7rc1 release from svn, without sync'ing them up.  I have no time to do the sync right now, so for 2.6.7 final (or 2.6.7rc2?) the branches must be synchronized.

Possibly related: decide whether to actually do the final release from hg or svn.

----------
assignee: barry
messages: 135383
nosy: barry
priority: release blocker
severity: normal
status: open
title: 2.6 svn and hg branches are out of sync
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 04:22:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 May 2011 02:22:57 +0000
Subject: [New-bugs-announce] [issue12025] strangely missing separator in
	"resource" table
In-Reply-To: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>
Message-ID: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n :

"resource" page in python docs is missing a separator between 6 and 7. Checking the RST source code, everything seems correct. But the fact is that a line is missing in the HTML output.

Checking the HTML output code, it seems OK. Disabling CSS, I see the table is correct. Maybe an issue with the CSS?. A bug in Firefox 4.0.1? (my current browser).

Viewing in iPhone, the display is OK :-?.

Python 2.7:
http://docs.python.org/library/resource.html#resource-usage

Python 3.1:
http://docs.python.org/release/3.1.3/library/resource.html#resource-usage

Python 3.2:
http://docs.python.org/py3k/library/resource.html#resource-usage

Python 3.3:
http://docs.python.org/dev/library/resource.html#resource-usage

----------
assignee: docs at python
components: Documentation
messages: 135397
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: strangely missing separator in "resource" table
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 06:50:25 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 07 May 2011 04:50:25 +0000
Subject: [New-bugs-announce] [issue12026] Support more of MSI api by
	exposing handles
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon :

Background:
My main use case for msilib is for working with/editing existing MSI files and not creating MSI files.

As such I find much of the MSI API that I need missing.

While not difficult to re-create _msi.c with ctypes, I thought it might be good to use as much of _msi.c as implemented (faster :) )

Patch:
The patch exposes the 'h' member of msiobj as 'handle', and updates the doc to refer to them.

There are no tests in the patch yet. Any recommendation on tests? (just check that the member exists and has an 'int' value?

----------
components: Library (Lib)
files: expose_msi.c_handles.diff
keywords: patch
messages: 135401
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Support more of MSI api by exposing handles
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21914/expose_msi.c_handles.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 11:52:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:52:54 +0000
Subject: [New-bugs-announce] [issue12027] Optimize import this (patch to
	make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Patch to optimize this: make it 10 times faster.

Try attached benchmark script. On a debug build I got the following results:
 * original: 299.8 ms
 * patched: 23.2 ms

I expected a factor of 10 because it uses a C implementation of rot13 instead of an hand made Python implementation.

----------
components: Library (Lib)
files: python27_this_rot13.patch
keywords: patch
messages: 135432
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize import this (patch to make it 10x faster)
versions: Python 2.7
Added file: http://bugs.python.org/file21919/python27_this_rot13.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May  7 12:24:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:24:45 +0000
Subject: [New-bugs-announce] [issue12028] threading._get_ident(): remove it
	in the doc and make it	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>


New submission from STINNER Victor :

I don't know why threading._get_ident() (which is _thread.get_ident()) is private: this function is safe.

This function becomes useful with pthread_kill() which will be added by #8407.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 135441
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: threading._get_ident(): remove it in the doc and make it public
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 10:53:43 2011
From: report at bugs.python.org (andrew cooke)
Date: Sun, 08 May 2011 08:53:43 +0000
Subject: [New-bugs-announce] [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>


New submission from andrew cooke :

Hi,

In general, registering a class with an ABC is equivalent to making it a subclass (isinstance and issubclass are patched through ABCMeta).  However, this does not work for exceptions (see example below, where exception is not caught).

This doesn't seem terribly surprising to me - I imagine that checking would slow down exception handling - but I couldn't find any documentation (and posting on c.l.p didn't turn up anything either).

So I thought I would raise it here - perhaps there is a possible fix (my obscure use case is that I have a backtracking search; backtracking occurs when a certain exception is encountered; making that exception an ABC and allowing existing exceptions to be registered with it allows the search to work with existing code without a wrapper that catches and translates exceptions that should trigger a backtrack).  Or perhaps the docs could be extended.  Or perhaps I've misunderstood something...

Cheers,
Andrew

Python 3.2 (r32:88445, Feb 27 2011, 13:00:05) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from abc import ABCMeta
>>> class RootException(Exception,metaclass=ABCMeta): pass
... 
>>> class MyException(Exception): pass
... 
>>> RootException.register(MyException)
>>> try:
...     raise MyException
... except RootException:
...     print('caught')
... 
Traceback (most recent call last):
  File "", line 2, in 
__main__.MyException

----------
components: Interpreter Core
messages: 135521
nosy: acooke
priority: normal
severity: normal
status: open
title: ABC registration of Exceptions
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 16:32:59 2011
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 08 May 2011 14:32:59 +0000
Subject: [New-bugs-announce] [issue12030] Roundup Refused Update with No
	text/plain
In-Reply-To: <1304865179.02.0.563101474809.issue12030@psf.upfronthosting.co.za>
Message-ID: <1304865179.02.0.563101474809.issue12030@psf.upfronthosting.co.za>


New submission from Ralph Corderoy :

I tried to reply to the email I was sent when eric.araujo added a comment to #10713.  The email I sent was plain text but wasn't a MIME email.  It was rejected, "Failed issue tracker submission", "Roundup requires the submission to be plain text. The message parser could
not find a text/plain part to use."

I understand why it looks for plain/text parts of a MIME email, but shouldn't it be happy with a non-MIME email that by definition is plain text and has only one part?  I've attached the rejected email.

----------
components: None
files: nonmime.txt
messages: 135525
nosy: ralph.corderoy
priority: normal
severity: normal
status: open
title: Roundup Refused Update with No text/plain
versions: 3rd party
Added file: http://bugs.python.org/file21933/nonmime.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 18:19:01 2011
From: report at bugs.python.org (marko kreen)
Date: Sun, 08 May 2011 16:19:01 +0000
Subject: [New-bugs-announce] [issue12031] subprocess module does not accept
	file twice
In-Reply-To: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>
Message-ID: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>


New submission from marko kreen :

I want to pass /dev/null as stdin and stderr.

This works from python 2.4 .. 3.2a3

It fails in final 3.2 with 'Bad file descriptor':

Traceback (most recent call last):
  File "test.py", line 11, in 
    Popen(['cat', 'file.txt'], stdout = PIPE, stdin = _in, stderr = _err)
  File "/opt/apps/python320/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/opt/apps/python320/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)
files: test.py
messages: 135530
nosy: zmk
priority: normal
severity: normal
status: open
title: subprocess module does not accept file twice
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21935/test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 18:55:31 2011
From: report at bugs.python.org (Stephen Ferg)
Date: Sun, 08 May 2011 16:55:31 +0000
Subject: [New-bugs-announce] [issue12032] Tools/Scripts/crlv.py needs
	updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>


New submission from Stephen Ferg :

I think this is a consequence of the new Unicode support in Python 3+

Here is code copied from C:\Python32\Tools\Scripts\crlf.py (on windows)
==================================================================
    for filename in os.listdir("."):
        if os.path.isdir(filename):
            print(filename, "Directory!")
            continue
        data = open(filename, "rb").read()
        if '\0' in data:
            print(filename, "Binary!")
            continue
        newdata = data.replace("\r\n", "\n")
        if newdata != data:
            print(filename)

===================================================================

When run, it produces this (run under the PyCharm debugger)

===================================================================
C:\Python32\python.exe C:/pydev/zob/zobtest.py
Traceback (most recent call last):
  File "C:/pydev/zob/zobtest.py", line 134, in 
    x() 
  File "C:/pydev/zob/zobtest.py", line 126, in x
    if '\0' in data:
TypeError: Type str doesn't support the buffer API

Process finished with exit code 1
===================================================================

Removing the test for "\0" produces this:
===================================================================
C:\Python32\python.exe C:/pydev/zob/zobtest.py
Traceback (most recent call last):
  File "C:/pydev/zob/zobtest.py", line 131, in 
    x()  
  File "C:/pydev/zob/zobtest.py", line 126, in x
    newdata = data.replace("\r\n", "\n")
TypeError: expected an object with the buffer interface

Process finished with exit code 1
===================================================================

----------
components: Demos and Tools
messages: 135531
nosy: stephen_ferg
priority: normal
severity: normal
status: open
title: Tools/Scripts/crlv.py needs updating for python 3+
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 19:17:04 2011
From: report at bugs.python.org (Alex Lai)
Date: Sun, 08 May 2011 17:17:04 +0000
Subject: [New-bugs-announce] [issue12033] AttributeError: 'module' object
	has no attribute 'scipy'
In-Reply-To: <1304875024.3.0.0342220610615.issue12033@psf.upfronthosting.co.za>
Message-ID: <1304875024.3.0.0342220610615.issue12033@psf.upfronthosting.co.za>


New submission from Alex Lai :

Hi experts,
  I'm new to Python. I've just successfully compiled and installed NumPy and SciPy. When I run the tests, Numpy shows no issues:

# python3 -c "import numpy; numpy.test()"
Running unit tests for numpy
NumPy version 1.5.1
NumPy is installed in /usr/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

----------------------------------------------------------------------
Ran 0 tests in 0.027s


  However, test for Scipy gave the following error:

# python3 -c "import numpy; import scipy; numpy.scipy()"
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'scipy'

  Any idea what might be missing here?

Thanks in advance,

Alex

----------
components: Tests
messages: 135533
nosy: alex_lai
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'scipy'
type: behavior
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May  8 22:00:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 20:00:06 +0000
Subject: [New-bugs-announce] [issue12034] check_GetFinalPathNameByHandle()
	suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

The code for check_GetFinalPathNameByHandle() goes like this:


static int has_GetFinalPathNameByHandle = 0;
[...]

static int
check_GetFinalPathNameByHandle()
{
    HINSTANCE hKernel32;
    /* only recheck */
    if (!has_GetFinalPathNameByHandle)
    {
        [...]
        has_GetFinalPathNameByHandle = Py_GetFinalPathNameByHandleA &&
                                       Py_GetFinalPathNameByHandleW;
    }
    return has_GetFinalPathNameByHandle;
}


It means that if the computed value is 0 (system doesn't have GetFinalPathNameByHandle*), the value will be re-computed each time the function is called.  has_GetFinalPathNameByHandle should probably be tri-state instead (0, 1, unknown).

----------
components: Extension Modules
keywords: easy
messages: 135540
nosy: brian.curtin, pitrou
priority: low
severity: normal
status: open
title: check_GetFinalPathNameByHandle() suboptimal
type: performance
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 09:49:39 2011
From: report at bugs.python.org (sulakshana)
Date: Mon, 09 May 2011 07:49:39 +0000
Subject: [New-bugs-announce] [issue12035] problem with installing
	validator.nu on windows
In-Reply-To: <1304927379.74.0.0716005360377.issue12035@psf.upfronthosting.co.za>
Message-ID: <1304927379.74.0.0716005360377.issue12035@psf.upfronthosting.co.za>


New submission from sulakshana :

I tried following instructions given in http://about.validator.nu/#src to install validator.nu on windows. 1. changed hg clone https://bitbucket.org/validator/build build to hg.py clone https://bitbucket.org/validator/build build as HG was not getting recognised in windows. 2. when i tried to run python build/build.py all getting the following error..

pasting the entire thing... how to solve this???

C:\www\checker>python build/build.py all "hg.py" pull --update -R build https://bitbucket.org/validator/build/ Traceback (most recent call last): File "build/build.py", line 1041, in selfUpdate()

File "build/build.py", line 797, in selfUpdate hgCloneOrUpdate("build", hgRoot)

File "build/build.py", line 777, in hgCloneOrUpdate runCmd('"%s" pull --update -R %s %s%s/' % (hgCmd, mod, baseUrl, mod))

File "build/build.py", line 173, in runCmd subprocess.call(cmd)

File "C:\www\Python27\lib\subprocess.py", line 486, in call return Popen(*popenargs, **kwargs).wait()

File "C:\www\Python27\lib\subprocess.py", line 672, in init errread, errwrite)

File "C:\www\Python27\lib\subprocess.py", line 882, in _execute_child startupinfo)

WindowsError: [Error 193] %1 is not a valid Win32 application

----------
components: Windows
messages: 135570
nosy: sulakshana
priority: normal
severity: normal
status: open
title: problem with installing validator.nu on windows
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 16:38:21 2011
From: report at bugs.python.org (Isaac Jurado)
Date: Mon, 09 May 2011 14:38:21 +0000
Subject: [New-bugs-announce] [issue12036] ConfigParser: items() adds the
	vars dictionary to the	result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>


New submission from Isaac Jurado :

>From the following python code:

import os
from ConfigParser import ConfigParser
from pprint import pprint
c = ConfigParser()
c.read(['test.ini'])
pprint(c.items('test', raw=False, vars=os.environ))

I see the values contained in os.environ as well as in section "test" (in the attached configuration example).

The problem seems to come from the following line:

http://hg.python.org/cpython/file/5395f96588d4/Lib/ConfigParser.py#l605

Which is fixed in py3k but for the 2.x branch has not been modified sin 2002:

http://hg.python.org/cpython/annotate/8bb6003f7f54/Lib/ConfigParser.py#514

----------
components: Library (Lib)
files: test.ini
messages: 135591
nosy: Isaac.Jurado
priority: normal
severity: normal
status: open
title: ConfigParser: items() adds the vars dictionary to the result
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21942/test.ini

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 18:33:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 16:33:49 +0000
Subject: [New-bugs-announce] [issue12037] test_email failures under Windows
	with the eol extension	activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

The title says it all. Ideally (!), changing .hgignore should be enough to fix this issue.
(NB: I have only tested the default branch)

======================================================================
FAIL: test_byte_message_rfc822_only (test_email.TestMessageAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cp\lib\test\test_email\test_email.py", line 189, in test_byte_messa
ge_rfc822_only
    self.assertEqual(out.getvalue(), msgdata)
AssertionError: Lists differ: ["b'Return-Path: \n'
b'Return-Path: \r\n'

- ["b'Return-Path: \\n'",
+ ["b'Return-Path: \\r\\n'",
?                                        +++

-  "b'Delivery-Date: Mon, 08 Feb 2010 14:05:16 +0100\\n'",
+  "b'Delivery-Date: Mon, 08 Feb 2010 14:05:16 +0100\\r\\n'",
?                                                     +++

-  "b'Received: from example.org (example.org [64.5.53.58])\\n'",
+  "b'Received: from example.org (example.org [64.5.53.58])\\r\\n'",
?                                                            +++

-  "b'    by example.net (node=mxbap2) with ESMTP (Nemesis)\\n'",
+  "b'    by example.net (node=mxbap2) with ESMTP (Nemesis)\\r\\n'",
?                                                            +++

-  "b'    id UNIQUE for someone at example.com; Mon, 08 Feb 2010 14:05:16 +0100\\n'
",
+  "b'    id UNIQUE for someone at example.com; Mon, 08 Feb 2010 14:05:16 +0100\\r\
\n'",
?                                                                             ++
+

-  "b'Date: Mon, 01 Feb 2010 12:21:16 +0100\\n'",
+  "b'Date: Mon, 01 Feb 2010 12:21:16 +0100\\r\\n'",
?                                            +++

-  'b\'From: "Sender" \\n\'',
+  'b\'From: "Sender" \\r\\n\'',
?                                           +++

-  "b'To: \\n'",
+  "b'To: \\r\\n'",
?                                +++

-  "b'Subject: GroupwiseForwardingTest\\n'",
+  "b'Subject: GroupwiseForwardingTest\\r\\n'",
?                                       +++

-  "b'Mime-Version: 1.0\\n'",
+  "b'Mime-Version: 1.0\\r\\n'",
?                      +++

-  "b'Content-Type: message/rfc822\\n'",
+  "b'Content-Type: message/rfc822\\r\\n'",
?                                   +++

-  "b'\\n'",
+  "b'\\r\\n'",
?     +++

   "b'Return-path: \\r\\n'",
   "b'Message-ID: <4B66B890.4070408 at teconcept.de>\\r\\n'",
   "b'Date: Mon, 01 Feb 2010 12:18:40 +0100\\r\\n'",
   'b\'From: "Dr. Sender" \\r\\n\'',
   "b'MIME-Version: 1.0\\r\\n'",
   'b\'To: "Recipient" \\r\\n\'',
   "b'Subject: GroupwiseForwardingTest\\r\\n'",
   "b'Content-Type: text/plain; charset=ISO-8859-15\\r\\n'",
   "b'Content-Transfer-Encoding: 7bit\\r\\n'",
   "b'\\r\\n'",
   "b'Testing email forwarding with Groupwise 1.2.2010\\r\\n'"]

======================================================================
FAIL: test_flatten_linesep_overrides_policy (test_email.TestParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cp\lib\test\test_email\test_email.py", line 3074, in test_flatten_l
inesep_overrides_policy
    self.assertEqual(s.getvalue(), text)
AssertionError: 'Return-Path: \nReceived: by mail.dom.ain (Post
fix, from userid [truncated]... != 'Return-Path: \r\nReceived:
by mail.dom.ain (Postfix, from user [truncated]...
- Return-Path: 
+ Return-Path: 
?                               +
- Received: by mail.dom.ain (Postfix, from userid 889)
+ Received: by mail.dom.ain (Postfix, from userid 889)
?                                                     +
-       id B9D0AD35DB; Tue,  4 Jun 2002 21:46:59 -0400 (EDT)
+       id B9D0AD35DB; Tue,  4 Jun 2002 21:46:59 -0400 (EDT)
?                                                           +
- Message-ID: <15613.28051.707126.569693 at dom.ain>
+ Message-ID: <15613.28051.707126.569693 at dom.ain>
?                                                +
- Date: Tue, 4 Jun 2002 21:46:59 -0400
+ Date: Tue, 4 Jun 2002 21:46:59 -0400
?                                     +
- MIME-Version: 1.0
+ MIME-Version: 1.0
?                  +
- Content-Type: text/plain; charset=us-ascii
+ Content-Type: text/plain; charset=us-ascii
?                                           +
- Content-Transfer-Encoding: 7bit
+ Content-Transfer-Encoding: 7bit
?                                +
- Subject: bug demonstration
+ Subject: bug demonstration
?                           +
-       123456789112345678921234567893123456789412345678951234567896123456789712
34567898112345678911234567892123456789112345678911234567892123456789
+       123456789112345678921234567893123456789412345678951234567896123456789712
34567898112345678911234567892123456789112345678911234567892123456789
?
                                                                    +
-       more text
+       more text
?                +
- From: aperson at dom.ain (Anne P. Erson)
+ From: aperson at dom.ain (Anne P. Erson)
?                                      +
- To: bperson at dom.ain (Barney P. Erson)
+ To: bperson at dom.ain (Barney P. Erson)
?                                      +
-
+
  test


----------------------------------------------------------------------
Ran 502 tests in 4.438s

FAILED (failures=3, skipped=1)

----------
assignee: r.david.murray
components: Tests
messages: 135606
nosy: pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_email failures under Windows with the eol extension activated
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 18:36:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 16:36:52 +0000
Subject: [New-bugs-announce] [issue12038] assertEqual doesn't display
	newline differences quite	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

>>> tc.assertEqual("x\n" * 40 + "\n", "x\n" * 40 + "\r\n")
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 662, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 1041, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 531, in fail
    raise self.failureException(msg)
AssertionError: 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx [truncated]... != 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx [truncated]...
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
- 
+ 


It isn't obvious when looking at this printout that the last newline differed.

----------
components: Library (Lib)
messages: 135608
nosy: ezio.melotti, michael.foord, pitrou
priority: low
severity: normal
status: open
title: assertEqual doesn't display newline differences quite well
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 20:00:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 18:00:46 +0000
Subject: [New-bugs-announce] [issue12039] test_logging: bad file descriptor
	on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>


New submission from Stefan Krah :

The FreeBSD-AMD64 bot shows an error in test_logging:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/243/steps/test/logs/stdio

Exception in thread Thread-281:
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 690, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 726, in serve_forever
    asyncore.loop(poll_interval, map=self.sockmap)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/asyncore.py", line 214, in loop
    poll_fun(timeout, map)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1493
/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/__init__.py:837: ResourceWarning: unclosed 
  self.emit(record)
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1493

----------
components: Tests
messages: 135622
nosy: skrah, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging: bad file descriptor on FreeBSD bot
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 20:39:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 18:39:23 +0000
Subject: [New-bugs-announce] [issue12040] Expose a Process.sentinel property
	(and fix polling loop	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This patch exposes a new read-only property of multiprocessing.Process objects, named "sentinel".
As the doc indicates, this is a file descriptor undex Unix, and a handle under Windows. Both are suitable for flexible polling/waiting with the appropriate OS primitives. They become ready when the process has ended.
Under Unix, this also replaces the repeated polling in _Popen.wait() (called from Process.join()) with a regular select() call, making it friendlier with CPU low-power states.

This is necessary for issue9205.

----------
components: Library (Lib)
files: process_sentinel.patch
keywords: patch
messages: 135623
nosy: asksol, brian.curtin, gregory.p.smith, jnoller, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Expose a Process.sentinel property (and fix polling loop in Process.join())
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21945/process_sentinel.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 20:46:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 18:46:15 +0000
Subject: [New-bugs-announce] [issue12041] test_os test_ctypes test_wait3
	causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>


New submission from R. David Murray :

It doesn't matter which order test_os and test_ctypes run in, but if they precede test_wait3 test_wait3 will fail.  When the test is immediately re-run it passes.

The reason ought to be interesting once we figure it out :)

Tested on linux.  Doesn't appear to affect other branches.

[1/3] test_os
[2/3] test_ctypes
[3/3] test_wait3
test test_wait3 failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/p33/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "/home/rdmurray/python/p33/Lib/test/test_wait3.py", line 30, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 14480 != 14487

----------
keywords: buildbot
messages: 135625
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os test_ctypes test_wait3 causes test_wait3 error
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 20:55:17 2011
From: report at bugs.python.org (Davi Post)
Date: Mon, 09 May 2011 18:55:17 +0000
Subject: [New-bugs-announce] [issue12042] What's New multiprocessing example
	error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>


New submission from Davi Post :

In this section:
http://docs.python.org/whatsnew/2.6.html#pep-371-the-multiprocessing-package

This sentence follows the first example:
"A Queue is used to communicate the input parameter N and the result."

In the example, the queue is used only for the result, not the input parameter N.

[P.S. I'd be happy to submit corrections, but don't want to have to install and learn Mercurial. Is there a simpler way?]

----------
assignee: docs at python
components: Documentation
messages: 135626
nosy: davipo, docs at python
priority: normal
severity: normal
status: open
title: What's New multiprocessing example error
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 20:59:05 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 May 2011 18:59:05 +0000
Subject: [New-bugs-announce] [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

This issue is to keep track of the 'shutil' documentation update, since it seems to miss several information (in particular in comparison with the docstrings).

I'll post patches as soon as I get them.

----------
assignee: docs at python
components: Documentation
messages: 135628
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: needs patch
status: open
title: Update shutil documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 21:24:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 19:24:15 +0000
Subject: [New-bugs-announce] [issue12044] subprocess.Popen.__exit__ doesn't
	wait for process end
In-Reply-To: <1304969055.59.0.685744558647.issue12044@psf.upfronthosting.co.za>
Message-ID: <1304969055.59.0.685744558647.issue12044@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I find it a bit strange that Popen.__exit__ closes all standard file descriptors leading to the child process, but doesn't wait for process end afterwards.
(context management support was added in issue10554)

----------
messages: 135635
nosy: brian.curtin, gregory.p.smith, neologix, pitrou
priority: normal
severity: normal
status: open
title: subprocess.Popen.__exit__ doesn't wait for process end
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May  9 23:09:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 21:09:07 +0000
Subject: [New-bugs-announce] [issue12045] external shell command executed
	twice in	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

It seems `cmd` is executed twice, for no obvious reason, in the following code:
http://hg.python.org/cpython/file/2d4ef202d4ed/Lib/ctypes/util.py#l129

----------
components: Library (Lib)
messages: 135650
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: external shell command executed twice in ctypes.util._get_soname
type: performance
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 01:04:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 May 2011 23:04:15 +0000
Subject: [New-bugs-announce] [issue12046] Windows build identification
	incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>


New submission from Martin v. L?wis :

The Unix build identifies itself with a string such as

Python 3.2.1b1 (3.2:5b34f84ca773, May 10 2011, 00:58:43)

and sys._mercurial then is ('CPython', '3.2', '5b34f84ca773')

In the Windows build, the identification is

Python 3.2.1b1 (default, May 10 2011, 00:33:43) [MSC v.1500 32 bit (Intel)] on win32

and sys._mercurial is ('CPython', '', '')

Not sure whether this is a release blocker, but it's definitely a step backwards from 3.2.0.

----------
messages: 135664
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Windows build identification incomplete
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 08:51:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 May 2011 06:51:17 +0000
Subject: [New-bugs-announce] [issue12047] Expand the style guide
Message-ID: <1305010277.63.0.0752663302866.issue12047@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee: georg.brandl
components: Documentation
files: style.diff
keywords: patch
nosy: georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: Expand the style guide
Added file: http://bugs.python.org/file21951/style.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 09:59:57 2011
From: report at bugs.python.org (yaoyu)
Date: Tue, 10 May 2011 07:59:57 +0000
Subject: [New-bugs-announce] [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>


New submission from yaoyu :

Python 3, ZipFile Bug In Chinese:
1. In Python3.1.3 can't extract "?? test.txt" from test.zip
???? test.txt
Traceback (most recent call last):
  File "C:\Temp\PythonZipTest\pythonzip.py", line 14, in 
    main()
  File "C:\Temp\PythonZipTest\pythonzip.py", line 11, in main
    z.extract(z.namelist()[0])
  File "c:\python31\lib\zipfile.py", line 980, in extract
    return self._extract_member(member, path, pwd)
  File "c:\python31\lib\zipfile.py", line 1023, in _extract_member
    source = self.open(member, pwd=pwd)
  File "c:\python31\lib\zipfile.py", line 928, in open
    % (zinfo.orig_filename, fname))
zipfile.BadZipfile: File name in directory '???? test.txt' and header b'\xb8\xb4\xbc\xfe test.txt' differ.

2.  In Python3.2 extract "?? test.txt" from test.zip uncorrect
  It extract the file as "???? test.txt"

3. In Python 2.7.1, It's OK!

??????????2011-05-10
Source Code
######################################################################
#coding=gbk

import zipfile
import os

def main():
  szTestDir = os.path.dirname(__file__)
  szFile = os.path.join(szTestDir, 'test.zip')
  z = zipfile.ZipFile(szFile)
  print(z.namelist()[0])
  z.extract(z.namelist()[0])

if __name__ == '__main__':
  main()

----------
files: test.zip
messages: 135687
nosy: yaoyu
priority: normal
severity: normal
status: open
title: Python 3, ZipFile Bug In Chinese
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file21952/test.zip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 10:10:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 08:10:11 +0000
Subject: [New-bugs-announce] [issue12049] expose RAND_bytes() function of
	OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The _ssl module has RAND_add() RAND_status() and RAND_egd() functions, but not RAND_bytes(). I would be nice to be able to generate random bytes using RAND_bytes().

And maybe also RAND_pseudo_bytes()?

I will work on a patch, it's just a reminder.

----------
components: Library (Lib)
messages: 135688
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: expose RAND_bytes() function of OpenSSL
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 12:44:14 2011
From: report at bugs.python.org (Takeshi Yoshino)
Date: Tue, 10 May 2011 10:44:14 +0000
Subject: [New-bugs-announce] [issue12050] unconsumed_tail of zlib.Decompress
	is not always cleared	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>


New submission from Takeshi Yoshino :

http://docs.python.org/library/zlib.html
says
"If max_length is not supplied then the whole input is decompressed, and unconsumed_tail is an empty string."

However, if there's preceding decompress call with max_length specified, unconsumed_tail will not be empty.

----
import zlib

c = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -zlib.MAX_WBITS)
compressed = c.compress('abc')
compressed += c.flush(zlib.Z_SYNC_FLUSH)

d = zlib.decompressobj(-zlib.MAX_WBITS)
original = d.decompress(data, 1)
original += d.decompress(d.unconsumed_tail)
print "%r" % d.unconsumed_tail
----

Result is

----
'\x06\x00\x00\x00\xff\xff'
----

Document or code should be fixed.

----------
components: Library (Lib)
messages: 135697
nosy: Takeshi.Yoshino
priority: normal
severity: normal
status: open
title: unconsumed_tail of zlib.Decompress is not always cleared on decompress() call
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 18:17:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 16:17:29 +0000
Subject: [New-bugs-announce] [issue12051] Segfault in JSONEncoder subclasses
	with	check_circular=False
In-Reply-To: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>
Message-ID: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

Subclasses of JSONEncoder that use check_circular=False can segfault json:
>>> import json
>>> class EndlessJSONEncoder(json.JSONEncoder):
...     def default(self, o):
...         return [o]
... 
>>> EndlessJSONEncoder(check_circular=False).encode(5j)
Segmentation fault

The attached patch fixes it raising a "RuntimeError: maximum recursion depth exceeded".

There might be other ways to get a segfault, because there are other recursive calls involving more functions (i.e. a calls b, and b calls a) that are not covered by the patch.

----------
assignee: ezio.melotti
components: Extension Modules
files: issue12051.diff
keywords: needs review, patch
messages: 135716
nosy: ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Segfault in JSONEncoder subclasses with check_circular=False
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file21955/issue12051.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 20:16:43 2011
From: report at bugs.python.org (Neil)
Date: Tue, 10 May 2011 18:16:43 +0000
Subject: [New-bugs-announce] [issue12052] round() erroneous for some large
	arguments
In-Reply-To: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>
Message-ID: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>


New submission from Neil :

round() returns incorrect results for certain large real-integer arguments. Demonstration via interpreter session:
>>> x = 2.0**52+1  # Huge, odd double integer near limits of what IEEE format can fully represent in its mantissa part
>>> round(x) - x   # Difference should be zero
1.0
>>> x = 2.0**53+1  # Even larger odd argument ...
>>> round(x) - x   # ... returns correct result!
0.0
>>> x = 2.0**51+1  # And a smaller argument ...
>>> round(x) - x   # ... also returns correct result!
0.0

Discussion:
It is not sufficient to implement round(x) as ceil(x - .5) for negative x and floor(x + .5) otherwise, since large integers near the representation limits will be changed incorrectly by these operations, apparently due to internal FPU semantics. One must test the argument first to see if it is a floating-point integer (e.g., math.floor(x) == x), and only bias & truncate towards zero if it is not. C math libraries that implement round(), such as on Linux & MacOS, do this correctly.

----------
components: None
messages: 135724
nosy: nasix
priority: normal
severity: normal
status: open
title: round() erroneous for some large arguments
type: behavior
versions: Python 2.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 21:37:25 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 19:37:25 +0000
Subject: [New-bugs-announce] [issue12053] Add prefetch() for Buffered IO
	(experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>


New submission from John O'Connor :

A prefetch() method for Buffered IO may greatly assist 3rd party buffering among other gains. If nothing else, it is worth experimenting with. 

Discussion on the topic is here: http://mail.python.org/pipermail/python-ideas/2010-September/008180.html

A summary of the method proposed (by Antoine Pitrou):

prefetch(self, buffer, skip, minread)

Skip `skip` bytes from the stream.  Then, try to read at
least `minread` bytes and write them into `buffer`. The file
pointer is advanced by at most `skip + minread`, or less if
the end of file was reached. The total number of bytes written
in `buffer` is returned, which can be more than `minread`
if additional bytes could be prefetched (but, of course,
cannot be more than `len(buffer)`).

Arguments:
- `buffer`: a writable buffer (e.g. bytearray)
- `skip`: number of bytes to skip (must be >= 0)
- `minread`: number of bytes to read (must be >= 0 and <= len(buffer))

----------
components: IO
messages: 135731
nosy: benjamin.peterson, haypo, jcon, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Add prefetch() for Buffered IO (experiment)
type: feature request
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 10 22:33:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 10 May 2011 20:33:03 +0000
Subject: [New-bugs-announce] [issue12054] test_socket: replace custom
	_get_unused_port() by	support.find_unused_port()
In-Reply-To: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>
Message-ID: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

Lib/test/test_socket.py uses custom _get_unused_port to return a port which will be likely available for binding in some tests.
The same functionality is already provided by support.find_unuse_port, let's make use of it.
Patch attached.

----------
components: Tests
files: test_socket_unused_port.diff
keywords: patch
messages: 135738
nosy: neologix
priority: low
severity: normal
status: open
title: test_socket: replace custom _get_unused_port() by support.find_unused_port()
type: feature request
Added file: http://bugs.python.org/file21958/test_socket_unused_port.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 13:56:41 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 11 May 2011 11:56:41 +0000
Subject: [New-bugs-announce] [issue12055] doctest not working on nested
	functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>


New submission from Dave Abrahams :

The attached file demonstrates

----------
components: Library (Lib)
files: bug.py
messages: 135770
nosy: dabrahams
priority: normal
severity: normal
status: open
title: doctest not working on nested functions
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21964/bug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 14:29:23 2011
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 11 May 2011 12:29:23 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMTIwNTZdICLigKYiIChIT1JJ?=
 =?utf-8?q?ZONTAL_ELLIPSIS=29_should_be_an_alternative_syntax_for_=22=2E?=
 =?utf-8?q?=2E=2E=22_=28FULL_STOP_FULL_STOP_FULL_STOP=29?=
In-Reply-To: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>
Message-ID: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>


New submission from Xavier Morel :

In Python 3, "..." became useable as a normal expression, and translates into an ellipsis instance.

Unicode defines an ellipsis character "?" (U+2026 HORIZONTAL ELLIPSIS) which is canonically equivalent to a 3-sequence of FULL STOP [U+002E U+002E U+002E]

I think it would be nice if Python supported "?" as an alternative to "..."

----------
components: Interpreter Core, Unicode
messages: 135771
nosy: xmorel
priority: normal
severity: normal
status: open
title: "?" (HORIZONTAL ELLIPSIS) should be an alternative syntax for "..." (FULL STOP FULL STOP FULL STOP)
type: feature request
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 15:01:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:01:58 +0000
Subject: [New-bugs-announce] [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>


New submission from STINNER Victor :

All CJK codecs have tests except the chinese HZ codec, I don't know why.

But to add a test, I need to add data to Lib/test/cjkencodings_test.py and the format of this file is not documented. It is not too difficult to understand the format by reading the code of the tests, but it's hard to maintain these tests (add more tests or change a test).

I need tests to be able to patch the codec to fix #12016.

My plan is to:

 - Change Lib/test/cjkencodings_test.py format: use two files for each encoding (one in the tested encoding, one in UTF-8)
 - Add tests to the HZ codec
 - Close this issue
 - Fix #12016

----------
components: Library (Lib), Unicode
messages: 135773
nosy: cdqzzy, ezio.melotti, haypo, lemburg, terry.reedy
priority: normal
severity: normal
status: open
title: HZ codec has no test
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 18:51:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 May 2011 16:51:40 +0000
Subject: [New-bugs-announce] [issue12058] Minor edits to comments in
	faulthandler
In-Reply-To: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>
Message-ID: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

I fixed or improved some comments in faulthandler.  The only non-trivial change is a replacement of ?until? to ?before? (until did not make sense).  Please review and if you agree, commit.

----------
files: faulthandler-comments.diff
keywords: patch
messages: 135784
nosy: eric.araujo, haypo
priority: normal
severity: normal
status: open
title: Minor edits to comments in faulthandler
versions: Python 3.3
Added file: http://bugs.python.org/file21970/faulthandler-comments.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 20:59:19 2011
From: report at bugs.python.org (Ian Wienand)
Date: Wed, 11 May 2011 18:59:19 +0000
Subject: [New-bugs-announce] [issue12059] hashlib does not handle missing
	hash functions correctly
In-Reply-To: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>
Message-ID: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>


New submission from Ian Wienand :

If one of the hash functions isn't defined in _hashlib, the code suggests it should just be skipped

===
      # this one has no builtin implementation, don't define it
                pass
===

This doesn't happen however; due to ImportError not being caught the module decides the whole _hashlib module isn't available and tries to fall back to the older individual libraries.  You then get thrown an unrelated error about _md5 being unavailable

You can easily replicate this

---
$ python
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
...     raise ValueError
... 
>>> import _hashlib
>>> _hashlib.openssl_sha224 = foo
>>> import hashlib
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.6/hashlib.py", line 136, in 
    md5 = __get_builtin_constructor('md5')
  File "/usr/lib/python2.6/hashlib.py", line 63, in __get_builtin_constructor
    import _md5
ImportError: No module named _md5
>>> 
---

I think the solution is to catch the ImportError in __get_builtin_constructor and, if caught, consider the hash function unsupported

----------
files: hashlib.py.diff
keywords: patch
messages: 135794
nosy: Ian.Wienand
priority: normal
severity: normal
status: open
title: hashlib does not handle missing hash functions correctly
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21971/hashlib.py.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 11 23:57:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 21:57:42 +0000
Subject: [New-bugs-announce] [issue12060] Python doesn't support real time
	signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>


New submission from STINNER Victor :

If a real time signal is raised 2 times whereas the signal is blocked, unblock the signal will call the signal handler twice. The C signal handler of the Python signal module only stores a boolean to say if the Python signal handler should be called or not in Py_CheckSignals().

If the C signal handler is called twice, the Python signal handler is only called once.

Attached patch is a draft to fix this issue. The patch is not completly safe.

----------
components: Interpreter Core
files: rt_signal.patch
keywords: patch
messages: 135808
nosy: haypo
priority: normal
severity: normal
status: open
title: Python doesn't support real time signals
versions: Python 3.3
Added file: http://bugs.python.org/file21976/rt_signal.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 00:33:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 11 May 2011 22:33:07 +0000
Subject: [New-bugs-announce] [issue12061] Remove duplicate 'key functions'
	entry in Glossary
In-Reply-To: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>
Message-ID: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Hi, only on 2.7 there were 2 entries for 'key function': this patches remove the second occurrence, leaving that part of Glossary equals to the other branches.

----------
assignee: docs at python
components: Documentation
files: remove_duplicate_key_functions-2.7.patch
keywords: patch
messages: 135810
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Remove duplicate 'key functions' entry in Glossary
versions: Python 2.7
Added file: http://bugs.python.org/file21978/remove_duplicate_key_functions-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 15:07:28 2011
From: report at bugs.python.org (Genstein)
Date: Thu, 12 May 2011 13:07:28 +0000
Subject: [New-bugs-announce] [issue12062] Buffered I/O inconsistent with
	unbuffered I/O in certain	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>


New submission from Genstein :

Reporting this as requested by Antoine Pitrou: Under certain circumstances in Python 3.2 (r32:88445) it's possible for buffered I/O to lose data before it is written and/or return the wrong results when reading. I tripped over this issue whilst writing an assembler which first writes out a bunch of binary data and then goes back over it in a somewhat arbitrary order patching addresses.

The following code demonstrates the issue:

[code]
START = 0
MID = 1
LENGTH = 4

def test(buffering):
    f = open("test.bin", "w+b", buffering = buffering)
    for i in range(LENGTH):
        f.write(b'\x00')
    f.seek(MID)
    f.read(1)
    f.write(b'\x00')
    f.seek(MID)
    f.write(b'\x01')
    f.seek(START)
    f.seek(MID)
    print(f.read(1))
    f.close()

print("Buffered result: ")
test(-1)
print("Unbuffered result:")
test(0)
[end code]

Output on both Gentoo and Vista is:
    Buffered result:
    b'\x00'
    Unbuffered result:
    b'\x01'

Expected output is b'\x01' in both cases.

The issue is reproducible with larger files provided that the constants are increased ~proportionally (START 0, MID 500, LENGTH 1000 for example). Transposing the buffered/unbuffered tests and/or using different buffer sizes for the buffered test seem have no effect. 

The lengthy code at this URL also demonstrates the issue: http://pastebin.com/xqrzKr5D The above was produced from this code, which was autogenerated by intercepting my assembler's output.

----------
components: IO
messages: 135830
nosy: genstein
priority: normal
severity: normal
status: open
title: Buffered I/O inconsistent with unbuffered I/O in certain cases
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 16:19:30 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 12 May 2011 14:19:30 +0000
Subject: [New-bugs-announce] [issue12063] tokenize module appears to treat
	unterminated single and	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre :

Tokenizing `' 1 2 3` versus `''' 1 2 3` yields different results.

Tokenizing `' 1 2 3` gives:

1,0-1,1:	ERRORTOKEN	"'"
1,2-1,3:	NUMBER	'1'
1,4-1,5:	NUMBER	'2'
1,6-1,7:	NUMBER	'3'
2,0-2,0:	ENDMARKER	''

while tokenizing `''' 1 2 3` yields:

Traceback (most recent call last):
  File "prog.py", line 4, in 
    tokenize.tokenize(iter(["''' 1 2 3"]).next)
  File "/usr/lib/python2.6/tokenize.py", line 169, in tokenize
    tokenize_loop(readline, tokeneater)
  File "/usr/lib/python2.6/tokenize.py", line 175, in tokenize_loop
    for token_info in generate_tokens(readline):
  File "/usr/lib/python2.6/tokenize.py", line 296, in generate_tokens
    raise TokenError, ("EOF in multi-line string", strstart)
tokenize.TokenError: ('EOF in multi-line string', (1, 0))


Apparently tokenize decides to re-tokenize after the erroneous quote in the case of a single-quote, but not a triple-quote. I guess that this is because retokenizing the rest of the file after an unclosed triple-quote would be expensive; however, I've also been told it's very strange and possibly wrong for tokenize to be inconsistent this way.

If this is the right behavior, I guess I'd like it if it were documented. This sort of thing is confusing / potentially misleading for users of the tokenize module. Or at least, when I saw how single quotes were handled, I assumed incorrectly that all quotes were handled that way.

----------
messages: 135836
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module appears to treat unterminated single and double-quoted strings inconsistently

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 19:52:56 2011
From: report at bugs.python.org (Mathias Svensson)
Date: Thu, 12 May 2011 17:52:56 +0000
Subject: [New-bugs-announce] [issue12064] unexpected behavior with exception
	variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>


New submission from Mathias Svensson :

Current behavior:
In the very simple attached example an existing variable-name is used as the target in the except-part of a try-statement. The existing variable is deleted if an exception is throw.

Excepted behavior:
The only reasonable behaviors are keeping the original variable or keeping the exception. The current behavior is very unintuitive.

----------
components: Interpreter Core
files: test.py
messages: 135845
nosy: Mathias.Svensson
priority: normal
severity: normal
status: open
title: unexpected behavior with exception variable
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file21984/test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 21:33:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2011 19:33:13 +0000
Subject: [New-bugs-announce] [issue12065] test_ssl failure when
	svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>


New submission from R. David Murray :

See

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.2/builds/34/steps/test/logs/stdio

Antoine says that connect_ex should be returning an error, not None, in that situation.

----------
components: Tests
keywords: buildbot
messages: 135853
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl failure when svn.python.org fails to resolve
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 23:11:16 2011
From: report at bugs.python.org (Atamurad Hezretkuliyev)
Date: Thu, 12 May 2011 21:11:16 +0000
Subject: [New-bugs-announce] [issue12066] Empty ('') xmlns attribute is not
	properly handled by	xml.dom.minidom
In-Reply-To: <1305234676.35.0.0571872848833.issue12066@psf.upfronthosting.co.za>
Message-ID: <1305234676.35.0.0571872848833.issue12066@psf.upfronthosting.co.za>


New submission from Atamurad Hezretkuliyev :

Parsing "" with minidom and converting back to string raises an exception.

>>> import xml.dom.minidom
>>> xml.dom.minidom.parseString("").toxml()
Traceback (most recent call last):
  File "", line 1, in 
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 45, in toxml
    return self.toprettyxml("", "", encoding)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 57, in toprettyxml
    self.writexml(writer, "", indent, newl, encoding)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 1749, in writexml
    node.writexml(writer, indent, addindent, newl)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 812, in writexml
    _write_data(writer, attrs[a_name].value)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 301, in _write_data
    data = data.replace("&", "&").replace("<", "<")
AttributeError: 'NoneType' object has no attribute 'replace'
>>> 

Ii am not familiar with the XML spec so I've no idea if ignoring or accepting empty namespace is the right thing to do. If someone advices me on how it should be handled, I'd like to write a patch.

----------
components: Library (Lib)
messages: 135867
nosy: atamyrat
priority: normal
severity: normal
status: open
title: Empty ('') xmlns attribute is not properly handled by xml.dom.minidom
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 12 23:59:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 May 2011 21:59:33 +0000
Subject: [New-bugs-announce] [issue12067] Doc: remove errors about
	mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type comparisons.

"The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, the == and != operators *always* consider objects of different types to be unequal, while the <, >, >= and <= operators raise a TypeError when comparing objects of different types that do not implement these operators for the given pair of types. You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization."

Sentence 3: "If both are numbers, they are converted to a common type." I suspect it would be more true to say 'common internal type' as I would not think it a language requirement to produce Python objects.

In any case, I think it is only true for built-in number types, and I do not see that qualification anywhere previously.

That aside, it does not appear to be true for Decimals and Fractions in 2.7.1.

Sentence 4: first clause is only true for built-in types. That qualification is not obvious to everyone, as evidenced by a current python-list sub thread.

For 2.7, which has a different continuation, I suggest adding 'built-in' before 'objects of'.
For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError' so that the 'when' condition applies to equality comparisons also.

After discussion about same-type comparisons, there is another paragraph about mixed-type comparison:

"Comparison of objects of the differing types depends on whether either of the types provide explicit support for the comparison. Most numeric types can be compared with one another, but comparisons of float and Decimal are not supported to avoid the inevitable confusion arising from representation issues such as float('1.1') being inexactly represented and therefore not exactly equal to Decimal('1.1') which is. When cross-type comparison is not supported, the comparison method returns NotImplemented. This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)."

I suggest deleting this entirely. The first sentence and first clause of the second repeat what was said above. The rest is obsolete as float/decimal comparisons *are* implemented in 2.7.1 and 3.2.0.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 135873
nosy: docs at python, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc: remove errors about mixed-type comparisons.
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 13 00:02:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 22:02:12 +0000
Subject: [New-bugs-announce] [issue12068] test_logging failure in
	test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This has started popping up on several buildbots:


======================================================================
FAIL: test_rollover (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_logging.py", line 3529, in test_rollover
    self.assertTrue(found, msg=msg)
AssertionError: False is not true : No rotated files found, went back 1 seconds

(http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/101/steps/test/logs/stdio)

----------
assignee: vinay.sajip
components: Tests
messages: 135874
nosy: pitrou, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_logging failure in test_rollover
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 13 01:02:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 23:02:47 +0000
Subject: [New-bugs-announce] [issue12069]
	test_signal.test_without_siginterrupt() failure on
	AMD64	OpenIndiana 3.x
In-Reply-To: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>
Message-ID: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>


New submission from STINNER Victor :

test_signal fails sometimes on the "AMD64 OpenIndiana 3.x" buildbot:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 358, in test_without_siginterrupt
    self.assertTrue(i)
AssertionError: False is not true

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

This failure may be related to my recent work on signals, see #8407.

----------
messages: 135882
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 13 15:58:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 13:58:19 +0000
Subject: [New-bugs-announce] [issue12070] Unlimited loop in
	sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>


New submission from STINNER Victor :

$ ./python -c "import sysconfig; sysconfig._parse_makefile('Makefile.loop')"

It loops on the following variables:

'DESTSHARED'='$(BINLIBDEST)/lib-dynload'
'INCLDIRSTOMAKE'='$(INCLUDEDIR) $(CONFINCLUDEDIR) $(INCLUDEPY) $(CONFINCLUDEPY)'
'CONFINCLUDEPY'='$(CONFINCLUDEDIR)/python$(LDVERSION)'
'DESTLIB'='$(LIBDEST)'
'INCLUDEPY'='$(INCLUDEDIR)/python$(LDVERSION)'
'MANDIR'='${datarootdir}/man'
'DESTDIRS'='$(exec_prefix) $(LIBDIR) $(BINLIBDEST) $(DESTSHARED)'
'CONFINCLUDEDIR'='$(exec_prefix)/include'
'exec_prefix'='${prefix}'
'LIBDIR'='${exec_prefix}/lib'
'LIBDEST'='$(SCRIPTDIR)/python$(VERSION)'
'INCLUDEDIR'='${prefix}/include'
'BINDIR'='${exec_prefix}/bin'
'LIBPC'='$(LIBDIR)/pkgconfig'
'datarootdir'='${prefix}/share'
'SCRIPTDIR'='$(prefix)/lib'
'BINLIBDEST'='$(LIBDIR)/python$(VERSION)'
'LIBPL'='$(LIBDEST)/config-$(LDVERSION)'
'MACHDESTLIB'='$(BINLIBDEST)'

I had the bug while trying to debug #6011.

----------
components: Library (Lib)
messages: 135909
nosy: haypo
priority: normal
severity: normal
status: open
title: Unlimited loop in sysconfig._parse_makefile()
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 13 16:14:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:14:55 +0000
Subject: [New-bugs-announce] [issue12071] test_concurrent_futures hangs on
	OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>


New submission from STINNER Victor :

test_concurrent_futures of Python 3.3 (rev [6d8678555c04]) hangs on OpenIndiana. I dumped manually the tracebacks of the parent process (test_concurrent_futures) and of the 3 child processes. In the parent process, the test hangs when exiting the context manager:

---------------------------------------------
    def test_context_manager_shutdown(self):
        with futures.ProcessPoolExecutor(max_workers=5) as e:
            processes = e._processes
            self.assertEqual(list(e.map(abs, range(-5, 5))),
                             [5, 4, 3, 2, 1, 0, 1, 2, 3, 4])
            ####### HERE #########
        for p in processes:
            p.join()
---------------------------------------------

I may be related to issue #9205.

Have fun with the following tracebacks!

[123/354] test_concurrent_futures

=== Parent ===

Thread 0x000004af:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x000004ae:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x000004a0:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049f:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049e:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049d:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000479:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000478:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000477:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000476:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000475:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000474:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000473:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000472:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000471:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000470:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046f:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046e:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046d:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046c:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044d:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044c:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044b:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044a:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000449:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000448:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000447:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000446:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 851 in join
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 352 in shutdown
    self._queue_management_thread.join()
  File "/home/haypo/cpython/Lib/concurrent/futures/_base.py", line 570 in __exit__
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 164 in test_context_manager_shutdown
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 462 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in 
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #1 =========

Thread 0x00000445:

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 423 in wait
  File "/home/haypo/cpython/Lib/threading.py", line 685 in start
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 187 in _start_thread
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 107 in put
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 168 in _add_call_item_to_queue
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 206 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 115 in get
    self._rlock.acquire()
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in 
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in 
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #2 =========

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 117 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in 
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in 
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #3 =========

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 115 in get
    self._rlock.acquire()
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in 
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in 
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

----------
components: Tests
messages: 135911
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures hangs on OpenIndiana
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 13 20:11:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 13 May 2011 18:11:47 +0000
Subject: [New-bugs-announce] [issue12072] Missing parenthesis in
	c-api/buffer	PyBuffer_FillContiguousStrides
In-Reply-To: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>
Message-ID: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Following up with http://mail.python.org/pipermail/docs/2011-April/004159.html here's a tiny patch to add a missing parenthesis.

----------
assignee: docs at python
components: Documentation
files: capi_buffer_PyBuffer_FillContiguousStrides-py27.patch
keywords: patch
messages: 135938
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21994/capi_buffer_PyBuffer_FillContiguousStrides-py27.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 01:01:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:01:57 +0000
Subject: [New-bugs-announce] [issue12073] regrtest: use faulthandler to dump
	the tracebacks on	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>


New submission from STINNER Victor :

When you run the test suite manually and a test hangs, it would be nice to be able to dump immediatly the tracebacks of all threads without having to wait the timeout (which is 1 hour by default...).

Attached patch installs a signal handler for the SIGUSR1 signal. So "kill -USR1 " dumps immedialty the tracebacks without stopping the tests.

I already used it many times. It's useful and I did not notice any failure introduced by this change. I tested on Linux, FreeBSD and OpenIndiana. faulthandler.register() is not implemented on Windows (which doesn't have SIGUSR1 by the way).

I moved also the call to faulthandler.register() into main() to get the same behaviour using:
./python Lib/test/regrtest.py ...
./python -m test.regrtest ...
./python -m test ...

Actually, the last one doesn't enable faulthandler.

----------
components: Tests
files: regrtest_sigusr1.patch
keywords: patch
messages: 135947
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: use faulthandler to dump the tracebacks on SIGUSR1
versions: Python 3.3
Added file: http://bugs.python.org/file21995/regrtest_sigusr1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 01:16:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:16:00 +0000
Subject: [New-bugs-announce] [issue12074] regrtest: display the current
	number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The full test suite has something like 354 tests. regrtest writes one line per test, and if you use Python compiled in debug mode you have much more lines because of "[123 refs]" lines written by subprocesses.

It's difficult to check if a previous test failed or not. If your terminal has a small backlog (e.g. 200 lines), it is maybe just not possible to know. In buildbot logs, it is also hard to search the first failure because the log is very verbose.

Attached patch adds " -- 1 failure" suffix after the first failure. If you use the -j option, the number of failure is written directly (because the test name is only printed after the test is done). By default, the counter is incremented *after* the failure.

--

Example (I modified test_os to ensure that it fails):

marge$ ./python -m test test_os test_sys test_os test_sys
[1/4] test_os
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in 
    assert 1 == 0
AssertionError

[2/4] test_sys -- 1 failure
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
[3/4] test_os -- 1 failure
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in 
    assert 1 == 0
AssertionError

[4/4] test_sys -- 2 failures
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
2 tests OK.
1 test failed:
    test_os
[98160 refs]

----------
components: Tests
files: regrtest_failures.patch
keywords: patch
messages: 135949
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: display the current number of failures
versions: Python 3.3
Added file: http://bugs.python.org/file21996/regrtest_failures.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 09:16:32 2011
From: report at bugs.python.org (kai zhu)
Date: Sat, 14 May 2011 07:16:32 +0000
Subject: [New-bugs-announce] [issue12075] python3.2 memory leak when setting
	integer key in	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>


New submission from kai zhu :

i'm using the latest debian unstable python3.2 build on colinux (2011, may, 14)

## leak.py
## >>> import imp, leak; imp.reload(leak)
## will leak ~2.5mb per reload
## on i386 debian unstable machine (according to top).
## in my real world app (an automatic build system),
## i run out of memory after a number reloads :(
class Foo(object): pass
Foo.leaky_dictionary = {}
for aa in range(256):
  for bb in range(256):
    Foo.leaky_dictionary[(bb << 8) | aa] = None


$ python3.2
Python 3.2.1a0 (default, May  5 2011, 00:47:12)
[GCC 4.6.1 20110428 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, leak; imp.reload(leak) ## 11mb

>>> import imp, leak; imp.reload(leak) ## 13mb

>>> import imp, leak; imp.reload(leak) ## 16mb

>>> import imp, leak; imp.reload(leak) ## 19mb


----------
messages: 135961
nosy: kaizhu
priority: normal
severity: normal
status: open
title: python3.2 memory leak when setting integer key in dictionary
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 13:25:52 2011
From: report at bugs.python.org (Chris Paton)
Date: Sat, 14 May 2011 11:25:52 +0000
Subject: [New-bugs-announce] [issue12076] IDLE v.3.2 crashing randomly on
	MacOSX 10.6.7
In-Reply-To: <1305372352.94.0.545379842287.issue12076@psf.upfronthosting.co.za>
Message-ID: <1305372352.94.0.545379842287.issue12076@psf.upfronthosting.co.za>


New submission from Chris Paton :

I don't know much about Python (in fact, I'm a noob) so not understanding much of the technical lingo. I've installed Python 3.2, and Active TCL 8.5.9 on my machine. IDLE crashes at random points - compiling, saving, loading or even just typing! Why is this? What can i do to get it working? There is no error message, I just get my spinning beach ball and then I have to force quit the program, so it doesn't seem to be anything official. Any help at all would be great, I really need to get this going for my thesis project!

----------
components: IDLE
messages: 135966
nosy: Chris.Paton
priority: normal
severity: normal
status: open
title: IDLE v.3.2 crashing randomly on MacOSX 10.6.7
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 15:56:25 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sat, 14 May 2011 13:56:25 +0000
Subject: [New-bugs-announce] [issue12077] Harmonizing descriptor protocol
	documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>


New submission from Davide Rizzo :

There are three sources of information for the descriptor protocol:
- Data model reference (Doc/reference/datamodel.rst)
- Descriptor HowTo guide (Doc/howto/descriptor.rst)
- PEP 252

A developer who already knows descriptor tipically reads the first one:
object.__get__(self, instance, owner) "... owner is always the owner class ..."
Reading a bit further there are the ways a descriptor can be called, and the "direct call" is x.__get__(a). That is, without the third argument (owner) specified.

The how-to definition is slightly different:
descr.__get__(self, obj, type=None) --> value
Here the arguments have different names ("type" shadowing the type bultin) and it seems to be implied that the third argument is optional. The ClassMethod example at the end of the document seems to confirm this:
def __get__(self, obj, klass=None):
(though another example doesn't).
And the method contains an explicit check on klass being None.
Also it could be confusing that through the examples in the same document many different names are used for the same argument (type, objtype, klass), and all different than the name used in the reference.

Lastly the PEP is more explicit:
__get__(): a function callable with one or two arguments. [...] When X is None, the optional second argument, T, should be meta-object. [...] When both X and T are specified ...

One more quirk: the reference explains the distinction between data and non-data descriptors, though says nothing about __set__ raising AttributeError for read-only data descriptors.

My proposal:
- use the same names for __get__ arguments throughout the documentation (both the reference and the tutorial), e.g. __get__(self, instance, owner)
- decide whether the third argument should be optional, or state the common usage in the reference, and fix accordingly the examples in the howto
- explain data, non-data and read-only descriptors in the __set__ reference, or more simply, how the defintion of __set__ affects these things.

----------
assignee: docs at python
components: Documentation
messages: 135974
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: Harmonizing descriptor protocol documentation
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 14 17:04:53 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 15:04:53 +0000
Subject: [New-bugs-announce] [issue12078] re.sub() replaces only several
	matches
Message-ID: <1305385493.13.0.0440581488003.issue12078@psf.upfronthosting.co.za>


Changes by Andriy Rysin :


----------
components: Regular Expressions
files: repl.sh
nosy: arysin
priority: normal
severity: normal
status: open
title: re.sub() replaces only several matches
versions: Python 3.1
Added file: http://bugs.python.org/file21999/repl.sh

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 15 09:50:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 May 2011 07:50:06 +0000
Subject: [New-bugs-announce] [issue12079] decimal.py: TypeError precedence
	in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>


New submission from Stefan Krah :

Hi, I think that TypeError should take precedence over InvalidOperation
in these two cases:

>>> Decimal('Infinity').fma(Decimal('0'), (3.91224318126786e+19+0j))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.2/decimal.py", line 1879, in fma
    'INF * 0 in fma')
  File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: INF * 0 in fma
>>> 


>>> Decimal('1').fma(Decimal('snan'), 1.2222222222)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.2/decimal.py", line 1871, in fma
    return context._raise_error(InvalidOperation, 'sNaN', other)
  File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: sNaN
>>>

----------
components: Library (Lib)
messages: 136014
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: decimal.py: TypeError precedence in fma()
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 15 10:28:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 May 2011 08:28:21 +0000
Subject: [New-bugs-announce] [issue12080] decimal.py: performance in
	_power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>


New submission from Stefan Krah :

I found another performance issue in _power_exact:

>>> Decimal(4) ** Decimal("-1.2e-999999999")
^CTraceback (most recent call last):
  File "", line 1, in 
  File "/home/stefan/pydev/cpython/Lib/decimal.py", line 2343, in __pow__
    ans = self._power_exact(other, context.prec + 1)
  File "/home/stefan/pydev/cpython/Lib/decimal.py", line 2098, in _power_exact
    ten_pow = 10**-ye
KeyboardInterrupt



This one is in the power operation in line 2098. There are several
other places where huge integer powers are calculated if 'ye' is
sufficiently large.

----------
components: Library (Lib)
messages: 136022
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: performance in _power_exact
type: performance
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 15 17:37:06 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 May 2011 15:37:06 +0000
Subject: [New-bugs-announce] [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>


New submission from Benjamin Peterson :

I believe the bugs which the patched version of libffi used have been fixed in recent versions. We should stop distributing an old version.

----------
components: ctypes
messages: 136034
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Remove distributed copy of libffi
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 01:45:18 2011
From: report at bugs.python.org (Josh Triplett)
Date: Sun, 15 May 2011 23:45:18 +0000
Subject: [New-bugs-announce] [issue12082] Python/import.c still references
	fstat even with	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>


New submission from Josh Triplett :

Even if pyconfig.h defines DONT_HAVE_STAT and DONT_HAVE_FSTAT (which prevents the definitions of HAVE_STAT and HAVE_FSTAT), Python still references fstat in Python/import.c, along with struct stat and constants like S_IXUSR.  I ran into this when attempting to compile Python for an embedded platform, which has some basic file operations but does not have stat.  (I will likely end up faking fstat for now, but I'd rather not have to do so.)

----------
components: Build
messages: 136055
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 01:49:41 2011
From: report at bugs.python.org (Josh Triplett)
Date: Sun, 15 May 2011 23:49:41 +0000
Subject: [New-bugs-announce] [issue12083] Compile-time option to avoid
	writing files, including generated bytecode
In-Reply-To: <1305503381.77.0.166373977.issue12083@psf.upfronthosting.co.za>
Message-ID: <1305503381.77.0.166373977.issue12083@psf.upfronthosting.co.za>


New submission from Josh Triplett :

PEP 304 provides a runtime option to avoid saving generating bytecode files.  However, for embedded usage, it would help to have a compile-time option to remove all the file-writing code entirely, hardcoding PYTHONBYTECODEBASE="".  I ran into this when porting Python to an embedded platform, which will never support any form of filesystem write operations; currently, I have to provide dummy functions for writing files, which error out when attempting to write to anything other than stdout or stderr.

----------
components: Build
messages: 136056
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Compile-time option to avoid writing files, including generated bytecode
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 04:53:22 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 16 May 2011 02:53:22 +0000
Subject: [New-bugs-announce] [issue12084] os.stat() on windows doesn't
	consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto :

Hello. I noticed os.stat() on windows may traverse wrong path on relative symbolic when current working directory != the directory where symbolic link is in. This is because the relative path DeviceIoControl() returns is just passed to win32_xstat without converting to absolute path.

I'm sorry because I implemented this function, and it's hard for me to debug this because I don't have Vista/7. This patch uses GetFinalPathNameByHandle like original code does, plus should handle symlink to system locked file.

Can anyone test and commit this patch?

----------
components: Windows
files: patches_v2.tar.gz
keywords: 3.2regression
messages: 136062
nosy: georg.brandl, ocean-city
priority: release blocker
severity: normal
stage: patch review
status: open
title: os.stat() on windows doesn't consider relative symlink
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22006/patches_v2.tar.gz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 05:08:55 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Mon, 16 May 2011 03:08:55 +0000
Subject: [New-bugs-announce] [issue12085] subprocess.Popen.__del__ raises
	AttributeError if	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>


New submission from Oleg Oshmyan :

If subprocess.Popen is called with a keyword argument whose name is undefined or simply too many arguments, an instance of the Popen class is created but its __init__ method call fails due to the invalid argument list. (Immediately) afterwards, the new instance is destroyed and its __del__ method is called, which checks the _child_created field that is defined by __init__; but __init__ never got the chance to execute, so the field is not defined, and __del__ raises an AttributeError, which is written out to stderr.

>>> subprocess.Popen(fdsa=1)
Exception AttributeError: "'Popen' object has no attribute '_child_created'" in > ignored
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() got an unexpected keyword argument 'fdsa'
>>> subprocess.Popen((), 0, None, None, None, None, None, True, False, None, None, False, None, 0, True, False, (), None)
Exception AttributeError: "'Popen' object has no attribute '_child_created'" in > ignored
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes at most 18 positional arguments (19 given)

I encountered this while trying to write a piece of code compatible with Python 3.2 and earlier versions simultaneously. The subprocess module in Python 3.2 adds a new argument to the constructor of Popen, pass_fds, while changing the default value of another, close_fds, from False to True. In order to utilize pass_fds, I tried code that looked like this:

    try:
        process = Popen(*args, pass_fds=myfds, **kwargs)
    except TypeError:
        process = Popen(*args, **kwargs)

It worked but printed a message about the exception in __del__, which interfered with my own output. Without delving too much into the details of my code, I ended up just passing close_fds=False.

The attached patch avoids the exception by converting the reference to _child_created in __del__ into a three-argument getattr call.

----------
components: Library (Lib)
files: _child_created.diff
keywords: patch
messages: 136064
nosy: chortos
priority: normal
severity: normal
status: open
title: subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22007/_child_created.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 10:35:44 2011
From: report at bugs.python.org (Radomir Dopieralski)
Date: Mon, 16 May 2011 08:35:44 +0000
Subject: [New-bugs-announce] [issue12086] Tutorial doesn't discourage name
	mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>


New submission from Radomir Dopieralski :

In the tutorial, at http://docs.python.org/tutorial/classes.html#private-variables you can read:

----
9.6. Private Variables
?Private? instance variables that cannot be accessed except from inside an object don?t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

Since there is a valid use-case for class-private members (namely to avoid name clashes of names with names defined by subclasses), there is limited support for such a mechanism, called name mangling. Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped. This mangling is done without regard to the syntactic position of the identifier, as long as it occurs within the definition of a class.

Note that the mangling rules are designed mostly to avoid accidents; it still is possible to access or modify a variable that is considered private. This can even be useful in special circumstances, such as in the debugger.

[...]
----

I think that this section doesn't stress enough how special the "__foo" syntax is and how rarely it should be used. If I was a programmer coming from Java to Python, I would start using "__foo" everywhere after reading this. I actually receive code written like that from programmers new to Python, and they point to that section of documentation when I ask why they did it.

At minimum, I'd add a paragraph that warns about how name mangling makes the code hard to reuse, difficult to test and unpleasant to debug.

----------
assignee: docs at python
components: Documentation
messages: 136072
nosy: docs at python, sheep
priority: normal
severity: normal
status: open
title: Tutorial doesn't discourage name mangling
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 14:21:35 2011
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 16 May 2011 12:21:35 +0000
Subject: [New-bugs-announce] [issue12087] install_egg_info fails with
	UnicodeEncodeError depending	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau :

With issue 10419 fixed, I've run into the next distutils unicode bug: The command "install_egg_info" doesn't specify an encoding when opening the ".egg-info" file for writing. Depending on the locale, this may result in something like the following:

$ python setup.py install
[...]
Traceback (most recent call last):
  File "setup.py", line 67, in 
    main()
  File "setup.py", line 62, in main
    cmdclass={"test":TestCommand},
  File "/home/hagen/src/python/Lib/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/home/hagen/src/python/Lib/distutils/command/install.py", line 583, in run
    self.run_command(cmd_name)
  File "/home/hagen/src/python/Lib/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/home/hagen/src/python/Lib/distutils/command/install_egg_info.py", line 44, in run
    self.distribution.metadata.write_pkg_file(f)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 1033, in write_pkg_file
    file.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 15: ordinal not in range(128)


I guess some encoding (UTF-8?) should be specified in the "run" method of "install_egg_info".

----------
assignee: tarek
components: Distutils
messages: 136084
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: install_egg_info fails with UnicodeEncodeError depending on locale
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 16:01:04 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Mon, 16 May 2011 14:01:04 +0000
Subject: [New-bugs-announce] [issue12088] tarfile.extractall fails to
	overwrite unresolved	symlinks and hard links
In-Reply-To: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>
Message-ID: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>


New submission from Scott Leerssen :

I'm opening this as a continuation of issue10761 since it was closed as fixed, and there's a bit more work to do there.

The fix for issue10761 was incomplete.  It did not handle the case where the symlink being overwritten did not resolve to another file (i.e. a "broken" link).  It also did not address the same issues with hard links.

The comments starting at http://bugs.python.org/issue10761#msg135924 detail the updates needed to complete this fix.

----------
components: Library (Lib)
messages: 136091
nosy: Scott.Leerssen
priority: normal
severity: normal
status: open
title: tarfile.extractall fails to overwrite unresolved symlinks and hard links
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 17:14:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 15:14:04 +0000
Subject: [New-bugs-announce] [issue12089] regrtest.py doesn't check for
	unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>


New submission from STINNER Victor :

In Python 3.1, a test fails if it writes to stdout/stderr. It is no more the case in Python 3.2 and 3.3. Why? If we decided to not check for unexpected output in Python 3.2+, the following code should be removed:

    if verbose:
        capture_stdout = None
    else:
        capture_stdout = io.StringIO()

----------
components: Tests
messages: 136103
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest.py doesn't check for unexpected output anymore?
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 19:56:51 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 May 2011 17:56:51 +0000
Subject: [New-bugs-announce] [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>


New submission from Stefan Krah :

The new Fedora buildbot (--without-threads) fails to compile:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.2/builds/1


I didn't check the release branch yet.

----------
components: Build
keywords: buildbot
messages: 136114
nosy: georg.brandl, skrah
priority: normal
severity: normal
status: open
title: 3.2: build --without-threads fails
type: compile error
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 21:52:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 16 May 2011 19:52:30 +0000
Subject: [New-bugs-announce] [issue12091] multiprocessing: simplify
	ApplyResult and MapResult with	threading.Event
In-Reply-To: <1305575550.96.0.535779831013.issue12091@psf.upfronthosting.co.za>
Message-ID: <1305575550.96.0.535779831013.issue12091@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

Multiprocessing's MapResult and ApplyResult use a notification mechanism to signal callers when the underlying value is available.
Instead of re-inventing the wheel, we could use threading.Event instead: this leads to cleaner and simpler code (with no noticable performance impact).
Patch attached.

----------
components: Library (Lib)
files: multiprocessing_event.diff
keywords: patch
messages: 136122
nosy: asksol, jnoller, neologix
priority: low
severity: normal
stage: patch review
status: open
title: multiprocessing: simplify ApplyResult and MapResult with threading.Event
type: behavior
Added file: http://bugs.python.org/file22009/multiprocessing_event.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 16 23:50:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 16 May 2011 21:50:21 +0000
Subject: [New-bugs-announce] [issue12092] Clarify sentence in tutorial
In-Reply-To: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>
Message-ID: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

following up http://mail.python.org/pipermail/docs/2011-April/004161.html, it would be nice to have changeset 1811eb03ba00 applied in 2.7 (it's already there in 3.1, 3.2 and default). Added Georg to the nosy list since it's the author of the given cs.

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 136128
nosy: docs at python, georg.brandl, sandro.tosi
priority: normal
severity: normal
stage: commit review
status: open
title: Clarify sentence in tutorial
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 00:36:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 16 May 2011 22:36:11 +0000
Subject: [New-bugs-announce] [issue12093] Typo in struct unpacking example
In-Reply-To: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>
Message-ID: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

following up http://mail.python.org/pipermail/docs/2011-April/004154.html and what was done in 1de718a31004, here's a tiny patch to correct that typo in 2.7 too.

----------
assignee: docs at python
components: Documentation
files: struct_unpack_record.patch
keywords: patch
messages: 136129
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Typo in struct unpacking example
versions: Python 2.7
Added file: http://bugs.python.org/file22011/struct_unpack_record.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 01:06:02 2011
From: report at bugs.python.org (Nathan)
Date: Mon, 16 May 2011 23:06:02 +0000
Subject: [New-bugs-announce] [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>


New submission from Nathan :

To Whom it may concern ? I have suddenly lost my ability to launch IDLE.  I am using 2.6 with windows xp.  I was using ipython with PyReadline.  I have uninstalled and reinstalled just python 2.6.6 with no luck.

I get the following error:

Thanks in advance 

C:\Python26>python.exe Lib\idlelib\idle.py
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 6, in 
    import PyShell
  File "C:\Python26\Lib\idlelib\PyShell.py", line 3, in 
    import os
  File "C:\Python26\lib\os.py", line 398, in 
    import UserDict
  File "C:\Python26\lib\UserDict.py", line 82, in 
    import _abcoll
  File "C:\Python26\lib\_abcoll.py", line 11, in 
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta

----------
components: IDLE
messages: 136130
nosy: nbuck
priority: normal
severity: normal
status: open
title: Cannot Launch IDLE
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 13:27:58 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 11:27:58 +0000
Subject: [New-bugs-announce] [issue12095] test failures due to missing module
In-Reply-To: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>
Message-ID: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>


New submission from Ronald Oussoren :

When I run the test suite on OSX (configure; make test) I get unexpected est failures:

6 tests failed:
    test_codecencodings_cn test_codecencodings_hk
    test_codecencodings_jp test_codecencodings_kr
    test_codecencodings_tw

When I run one of these manually I get the following traceback:


./python.exe ../Lib/test/test_codecencodings_cn.py
Traceback (most recent call last):
  File "../Lib/test/test_codecencodings_cn.py", line 11, in 
    class Test_GB2312(test_multibytecodec_support.TestBase, unittest.TestCase):
  File "../Lib/test/test_codecencodings_cn.py", line 13, in Test_GB2312
    tstring = test_multibytecodec_support.load_teststring('gb2312')
  File "/Users/ronald/Projects/python/rw/2.7/Lib/test/test_multibytecodec_support.py", line 330, in load_teststring
    from test import cjkencodings_test
ImportError: cannot import name cjkencodings_test


The only reference to cjkencodings_test in the entire 2.7 tree is this import line, there is no module or extension with this name.

----------
components: Library (Lib)
messages: 136148
nosy: ronaldoussoren
priority: high
severity: normal
status: open
title: test failures due to missing module
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 17:22:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 15:22:55 +0000
Subject: [New-bugs-announce] [issue12096] test_threading.test_waitfor()
	timeout (1 hour) on x86	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Builder x86 Gentoo 3.x Build #130:

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

[263/354] test_threading
Timeout (1:00:00)!
Thread 0x48f0bb70:
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/threading.py", line 278 in wait_for
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 472 in f
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 37 in task

Thread 0x401aa010:
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 16 in _wait
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 51 in wait_for_finished
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 482 in test_waitfor
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 462 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 514 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1096 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1184 in _run_suite
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1210 in run_unittest
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_threading.py", line 743 in test_main
  File "./Lib/test/regrtest.py", line 1044 in runtest_inner
  File "./Lib/test/regrtest.py", line 838 in runtest
  File "./Lib/test/regrtest.py", line 662 in main
  File "./Lib/test/regrtest.py", line 1622 in 

----------
components: Library (Lib)
messages: 136164
nosy: haypo
priority: normal
severity: normal
status: open
title: test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 21:12:07 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 17 May 2011 19:12:07 +0000
Subject: [New-bugs-announce] [issue12097] python.exe crashes if it is unable
	to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

On Windows, if Python is unable to find its .dll it crashes badly. This affects `vurtualenv` project that doesn't copy .dll file. It would be more user friendly if python.exe launcher could detect this situation and fail gracefully.

Such kind of dynamic linking can also serve as an example for building launchers for applications that optionally provide Python scripting depending on if Python .dll is present on the system.

And the ultimate launcher will allow to load any available .dll  This can be extremely handy for apps with embedded Python that use scripts compatible with Python 2.5+

----------
messages: 136173
nosy: techtonik
priority: normal
severity: normal
status: open
title: python.exe crashes if it is unable to find its .dll
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 17 22:38:53 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Tue, 17 May 2011 20:38:53 +0000
Subject: [New-bugs-announce] [issue12098] Child process running as debug
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>


New submission from Sergey Mezentsev :

I run this code:
"""
from multiprocessing import Pool

def myfunc(x):
    assert False
    #if __debug__: print 'debug'
    return x - 1

if __name__ == '__main__':
    pool = Pool(processes=1)
    it = pool.imap(myfunc, xrange(5)) # or imap_unordered, map
    print it.next()

python -O myscript.py
"""

The myfunc() always raise AssertionError. But I run script with "-O" (optimization) command.

Interpreter is:
"""
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on win32
"""

Thanks!

----------
components: Interpreter Core, Library (Lib), Windows
messages: 136178
nosy: thebits
priority: normal
severity: normal
status: open
title: Child process running as debug
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 01:07:07 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 17 May 2011 23:07:07 +0000
Subject: [New-bugs-announce] [issue12099] re pattern objects have no
	__class__
In-Reply-To: <1305673627.82.0.93003705972.issue12099@psf.upfronthosting.co.za>
Message-ID: <1305673627.82.0.93003705972.issue12099@psf.upfronthosting.co.za>


New submission from Michael Foord :

>>> import re
>>> re.compile('foo')
<_sre.SRE_Pattern object at 0x1043230>
>>> p = re.compile('foo')
>>> p.__class__
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: __class__

Already fixed in 3.2.

----------
messages: 136193
nosy: michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: re pattern objects have no __class__
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 01:10:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 23:10:05 +0000
Subject: [New-bugs-announce] [issue12100] Incremental encoders of CJK codecs
	reset the codec at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Stateful CJK codecs reset the codec at each call to encode() producing a valid but overlong output:

>>> import codecs
>>> encoder = codecs.getincrementalencoder('hz')()
>>> encoder.encode('\u804a') + encoder.encode('\u804a')
b'~{AD~}~{AD~}'
>>> '\u804a\u804a'.encode('hz')
b'~{ADAD~}'

Multibyte encodings: HZ and all encodings of the ISO 2022 family (e.g. iso-2022-jp).

Attached patch fixes this issue. I don't like how I added the tests, these tests may be moved somewhere else, but HZ codec doesn't have tests today (I opened issue #12057 for that), and ISO 2022 codecs don't have specific tests (test_multibytecodec is "Unit test for multibytecodec itself"). We should maybe also add tests specific to ISO 2022 first?

I hesitate to reset the codec on .encode(text, final=True), but UTF-8-SIG or UTF-16 don't reset the codec if final=True. io.TextIOWrapper only calls encoder.reset() on file.seek(0). On a seek to another position, it calls encoder.setstate(0).

See also issues #12016 and #12057.

----------
components: Interpreter Core
files: cjk_no_reset.patch
keywords: patch
messages: 136194
nosy: haypo, hyeshik.chang, lemburg
priority: normal
severity: normal
status: open
title: Incremental encoders of CJK codecs reset the codec at each call to encode()
versions: Python 3.3
Added file: http://bugs.python.org/file22017/cjk_no_reset.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 07:12:17 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 18 May 2011 05:12:17 +0000
Subject: [New-bugs-announce] [issue12101] PEPs should have consecutive
	revision numbers
In-Reply-To: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>
Message-ID: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

Currently, PEPs have only hash number, which doesn't explain about how many changes were done to the PEP since my last review. It will be convenient to have consecutive revision number for PEP edits and link it to short history log (like wiki history) with current revision highlighted. This is useful to track when PEP on site is not updated to current version.

----------
components: Devguide
messages: 136204
nosy: techtonik
priority: normal
severity: normal
status: open
title: PEPs should have consecutive revision numbers

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 11:56:04 2011
From: report at bugs.python.org (rion)
Date: Wed, 18 May 2011 09:56:04 +0000
Subject: [New-bugs-announce] [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>


New submission from rion :

Not flushed file gives next results:

rion at rionhost ~/temp $ python2 test.py 
Traceback (most recent call last):
  File "test.py", line 10, in 
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
mmap.error: [Errno 22] Invalid argument
rion at rionhost ~/temp $ python3 test.py 
Traceback (most recent call last):
  File "test.py", line 10, in 
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
ValueError: mmap offset is greater than file size


testcase:

import mmap
from tempfile import TemporaryFile

f = TemporaryFile()
f.write(b"hello world")

#f.flush()

m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)


just uncomment f.flush() and try again. feel the difference.

suggestion: force flush on file descriptor when passed to mmap.

----------
components: None
messages: 136217
nosy: rion4ik at gmail.com
priority: normal
severity: normal
status: open
title: mmap requires file to be synced
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 13:01:25 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 11:01:25 +0000
Subject: [New-bugs-announce] [issue12103] Documentation of open() does not
	claim 'e' support in	mode string
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>


New submission from ???? ????????? :

open() and friends (like temporaryfile) does not document 'e' letter in second arguement. At least on Linux, it opens file with O_CLOEXEC.
Not sure under Windows.

Also, there are other interesting letters (man -a fopen), like:

c (since glibc 2.3.3)
       Do not make the open operation, or  subsequent  read  and  write operations, thread cancellation points.
e (since glibc 2.7)
       Open  the  file  with  the O_CLOEXEC flag.  See open(2) for more information.
m (since glibc 2.3)
       Attempt to access the file using mmap(2), rather than I/O system calls  (read(2),  write(2)).   Currently, use of mmap(2) is only attempted for a file opened for reading.

x      Open the file exclusively (like the O_EXCL flag of open(2)).  If the  file  already exists, fopen() fails, and sets errno to EEXIST.  This flag is ignored for fdopen().

----------
assignee: docs at python
components: Documentation
messages: 136223
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: Documentation of open() does not claim 'e' support in mode string

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 21:05:26 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 19:05:26 +0000
Subject: [New-bugs-announce] [issue12104] os.path.join('/some/path',
	'') adds extra slash at end of result
In-Reply-To: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>
Message-ID: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>


New submission from ???? ????????? :

os.path.join('/some/path', '') adds extra slash at end of result. I expect in that case return value should be '/some/path' but not '/some/path/'

----------
components: Library (Lib)
messages: 136258
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.path.join('/some/path', '') adds extra slash at end of result
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 21:11:29 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 19:11:29 +0000
Subject: [New-bugs-announce] [issue12105] open() does not able to set flags,
	such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>


New submission from ???? ????????? :

In Python3 I'm not able to use open('xxx', 're') as it does not call fopen() anymore. What about extra flags like 'e'=O_CLOEXEC?

P.S.
see issue12103 for list of needed flags

P.P.S
does 2to3 tool properly detect such cases?

----------
messages: 136259
nosy: mmarkk
priority: normal
severity: normal
status: open
title: open() does not able to set flags, such as O_CLOEXEC
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 18 23:45:19 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 18 May 2011 21:45:19 +0000
Subject: [New-bugs-announce] [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>


New submission from Benjamin Peterson :

This patch causes multiple with statements with multiple with items to be represented in the AST instead of flattened as currently happens.

----------
components: Interpreter Core
files: fixwith.patch
keywords: patch
messages: 136262
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: reflect syntatic sugar in with ast
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22024/fixwith.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 12:09:57 2011
From: report at bugs.python.org (Christophe Devriese)
Date: Thu, 19 May 2011 10:09:57 +0000
Subject: [New-bugs-announce] [issue12107] TCP listening sockets created
	without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>


New submission from Christophe Devriese :

The specific issue this is creating is that a malicious user could use this socket in a subprocess which is started from a library (ie. I'm using a .so, which calls fork/exec).

A second failure mode is starting a daemon from withing, say, a django application. Djano opens a TCP listening socket, then starts up a daemon to provide some sort of service in the background. The daemon keeps running and inherits the socket. Now you restart the django app.

It refuses to start ! Why ? Because the socket was inherited, the listening socket isn't actually closed, and this results in the socket being stuck in CLOSE_WAIT as long as the daemon is running.

It seems to me that it is almost never the case that you'd want a TCP listening socket to be preserved across exec, and not setting this flag should thus be considered a bug for 2 reasons :

1) it results in accidental disclosure of information that shouldn't be exposed in certain cases.
2) it can result in denial of service

Solution : 

update SocketServer.py :
  in the class TCPServer
  add the following 2 lines in __init__ after self.socket = socket( ...:
    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

----------
messages: 136273
nosy: Christophe.Devriese
priority: normal
severity: normal
status: open
title: TCP listening sockets created without FD_CLOEXEC flag
type: security

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 13:36:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:10 +0000
Subject: [New-bugs-announce] [issue12108] test_packaging monkeypatches
	httplib
Message-ID: <1305804970.53.0.916990970269.issue12108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou :


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_packaging monkeypatches httplib

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 13:36:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:44 +0000
Subject: [New-bugs-announce] [issue12109] test_packaging monkeypatches
	httplib
In-Reply-To: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>
Message-ID: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

======================================================================
ERROR: test_https (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 457, in test_https
    data = self.urlopen("https://localhost:%s/bizarre" % handler.port)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

======================================================================
ERROR: test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 465, in test_https_with_cafile
    cafile=CERT_localhost)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136274
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging monkeypatches httplib
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 13:36:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:46 +0000
Subject: [New-bugs-announce] [issue12110] test_packaging monkeypatches
	httplib
In-Reply-To: <1305805006.32.0.311431989119.issue12110@psf.upfronthosting.co.za>
Message-ID: <1305805006.32.0.311431989119.issue12110@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

======================================================================
ERROR: test_https (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 457, in test_https
    data = self.urlopen("https://localhost:%s/bizarre" % handler.port)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

======================================================================
ERROR: test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 465, in test_https_with_cafile
    cafile=CERT_localhost)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136275
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging monkeypatches httplib
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 13:37:22 2011
From: report at bugs.python.org (Toni Mueller)
Date: Thu, 19 May 2011 11:37:22 +0000
Subject: [New-bugs-announce] [issue12111] email's use of __setitem__ is
	highly counterintuitive
In-Reply-To: <1305805042.77.0.328218985271.issue12111@psf.upfronthosting.co.za>
Message-ID: <1305805042.77.0.328218985271.issue12111@psf.upfronthosting.co.za>


New submission from Toni Mueller :

email's usage of __setitem__ is highly counterintuitive to the point of being dangerous. The documented behaviour is (quote):


__setitem__(name, val)

    Add a header to the message with field name name and value val. The field is appended to the end of the message?s existing fields.

    Note that this does not overwrite or delete any existing header with the same name. If you want to ensure that the new header is the only one present in the message with field name name, delete the field first, e.g.:
...

(taken from http://docs.python.org/library/email.message.html )

The use case of *appending* a header of the same type (eg. a "Received:" header) should be performed by the add_header() method, or an extend_header() method, or something similar, and not by abusing the __setitem__ method. The current behaviour imho deviates extremely from the behaviour of similar libraries in all other programming languages that I'm aware of, and from the standard dict functionality, too. It makes it much too easy to have duplicate headers, esp., duplicate "To:" headers, resulting in mailbombing and information leakage. For the potential damage, this property of the library is highly under-advertised.

A side effect appears to be that trying to have your message headers set up in a unique fashion, probably the most frequent use case, one has to make sure to use each operator only once, or "decorate" everything with a del msg[myheader], as the operation is not idempotent.

----------
messages: 136276
nosy: tonimueller
priority: normal
severity: normal
status: open
title: email's use of __setitem__ is highly counterintuitive
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 13:54:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 11:54:28 +0000
Subject: [New-bugs-announce] [issue12112] The new packaging module should
	not use the locale	encoding
In-Reply-To: <1305806068.46.0.0788802994526.issue12112@psf.upfronthosting.co.za>
Message-ID: <1305806068.46.0.0788802994526.issue12112@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The locale encoding is not portable, packaging should use UTF-8 instead.

Attached patch is a draft to workaround "LANG=C ./python -m test test_packaging" failures. I'm not sure that my test in Metadata.write_file() of packaging.metadata is a good idea.

Moreover, packaging should also maybe use the surrogateescape error handler, but I propose to decide that later and in another issue. We may use this error handler only to read files (like the Python makefile).

For write a complete patch, *all* calls to open() in Lib/packaging/* (including Lib/packaging/tests/*) should be checked.

distutils uses the locale encoding, which is UTF-8 on Mac OS X and most Linux setup (but never on Windows). But distutils cannot be fixed, whereas packaging is a new module and can be fixed.

----------
files: packaging_utf8.patch
keywords: patch
messages: 136280
nosy: haypo
priority: normal
severity: normal
status: open
title: The new packaging module should not use the locale encoding
versions: Python 3.3
Added file: http://bugs.python.org/file22028/packaging_utf8.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 14:09:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 12:09:41 +0000
Subject: [New-bugs-announce] [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

$ ./python -m test -Fv -unetwork test_packaging 

[...]

======================================================================
ERROR: test_download (packaging.tests.test_pypi_dist.TestDistInfo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/packaging/tests/pypi_server.py", line 68, in wrapped
    func(server=server, *args, **kwargs)
  File "/home/antoine/cpython/default/Lib/packaging/tests/test_pypi_dist.py", line 132, in test_download
    dist.download(self.mkdtemp())
  File "/home/antoine/cpython/default/Lib/packaging/pypi/dist.py", line 306, in download
    self._check_md5(filename)
  File "/home/antoine/cpython/default/Lib/packaging/pypi/dist.py", line 339, in _check_md5
    % (hashval.hexdigest(), expected_hashval))
packaging.pypi.errors.HashDoesNotMatch: got 8ae6ff9df26ff04232189724d520a17c instead of fe18804c5b722ff024cabdf514924fc4

======================================================================
FAIL: test_hooks_get_run (packaging.tests.test_dist.DistributionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/packaging/tests/test_dist.py", line 234, in test_hooks_get_run
    'post-test_dist'])
AssertionError: Lists differ: ['finalize', 'pre-test_dist', ... != ['finalize', 'pre-test_dist', ...

First list contains 4 additional elements.
First extra element 4:
finalize

+ ['finalize', 'pre-test_dist', 'run', 'post-test_dist']
- ['finalize',
-  'pre-test_dist',
-  'run',
-  'post-test_dist',
-  'finalize',
-  'pre-test_dist',
-  'run',
-  'post-test_dist']

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

----------
assignee: tarek
components: Distutils2, Tests
messages: 136283
nosy: alexis, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging fails when run twice
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 15:05:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 13:05:02 +0000
Subject: [New-bugs-announce] [issue12114]
	packaging.util._find_exe_version(): potential deadlock
In-Reply-To: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>
Message-ID: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The following code does deadlock if the subprocess writes a lot of output to stdout and stderr:

    pipe = Popen(cmd, shell=True, stdout=PIPE, stderr=PIPE)
    try:
        stdout, stderr = pipe.stdout.read(), pipe.stderr.read()
    finally:
        pipe.stdout.close()
        pipe.stderr.close()

Popen.communicate() should be used to avoid the issue.

Attached patch uses the .communicate() method and the context manager syntax (with).

----------
components: Library (Lib)
files: packaging_popen_communicate.patch
keywords: patch
messages: 136286
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: packaging.util._find_exe_version(): potential deadlock
versions: Python 3.3
Added file: http://bugs.python.org/file22029/packaging_popen_communicate.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 15:07:49 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 13:07:49 +0000
Subject: [New-bugs-announce] [issue12115] some tests need to be skipped on
	threadless systems
In-Reply-To: <1305810469.1.0.258347676504.issue12115@psf.upfronthosting.co.za>
Message-ID: <1305810469.1.0.258347676504.issue12115@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

======================================================================
ERROR: packaging.tests.test_command_upload_docs (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/case.py", line 407, in _executeTestPart
    function()
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: packaging.tests.test_command_upload_docs
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 257, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 235, in _get_module_from_name
    __import__(name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/packaging/tests/test_command_upload_docs.py", line 14, in 
    from packaging.tests.pypi_server import PyPIServerTestCase
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/packaging/tests/pypi_server.py", line 36, in 
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in 
    import _thread
ImportError: No module named '_thread'

----------
assignee: tarek
components: Library (Lib)
messages: 136287
nosy: alexis, tarek
priority: normal
severity: normal
status: open
title: some tests need to be skipped on threadless systems
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:04:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 16:04:46 +0000
Subject: [New-bugs-announce] [issue12116] io.Buffer*.seek() doesn't seek if
	"seeking leaves us	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Example:

with open("setup.py", "rb") as f:
    # read smaller than the file size to fill the readahead buffer
    f.read(1)
    # seek doesn't seek
    f.seek(0)
    print("f pos=", f.tell())
    print("f.raw pos=", f.raw.tell())

Output:

f pos= 0
f.raw pos= 4096

I expect f.raw.tell() to be 0.

Extract of Modules/_io/buffered.c:

    if (whence != 2 && self->readable) {
        Py_off_t current, avail;
        /* Check if seeking leaves us inside the current buffer,
           so as to return quickly if possible. Also, we needn't take the
           lock in this fast path.
           Don't know how to do that when whence == 2, though. */
        /* NOTE: RAW_TELL() can release the GIL but the object is in a stable
           state at this point. */
        current = RAW_TELL(self);
        avail = READAHEAD(self);
        printf("current=%"  PY_PRIdOFF ", avail=%"  PY_PRIdOFF "\n", current, avail);
        if (avail > 0) {
            Py_off_t offset;
            if (whence == 0)
                offset = target - (current - RAW_OFFSET(self));
            else
                offset = target;
            printf("offset=%"  PY_PRIdOFF "\n", offset);
            if (offset >= -self->pos && offset <= avail) {
                printf("NO SEEK!\n");
                self->pos += offset;
                return PyLong_FromOff_t(current - avail + offset);
            }
        }
    }

I found this weird behaviour when trying to understand why:

        with open("setup.py", 'rb') as f:
            encoding, lines = tokenize.detect_encoding(f.readline)
        with open("setup.py", 'r', encoding=encoding) as f:
            imp.load_module("setup", f, "setup.py", (".py", "r", imp.PY_SOURCE))

is different than:

        with tokenize.open("setup.py") as f:
            imp.load_module("setup", f, "setup.py", (".py", "r", imp.PY_SOURCE))

imp.load_module() clones the file using something like fd = os.dup(f.fileno()); clone = os.fdopen(fd, "r").

For tokenizer.open(), a workaround is to replace:
   buffer.seek(0)
by
   buffer.seek(0); buffer.raw.seek(0)

----------
components: IO
messages: 136296
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: io.Buffer*.seek() doesn't seek if "seeking leaves us inside the current buffer"
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:18:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:18:06 +0000
Subject: [New-bugs-announce] [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failure under a fresh checkout:

======================================================================
ERROR: test_file_from_empty_string_dir (importlib.test.source.test_file_loader.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/importlib/test/source/test_file_loader.py", line 129, in test_file_from_empty_string_dir
    shutil.rmtree(pycache)
  File "/home/antoine/t/cpython/Lib/shutil.py", line 270, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/t/cpython/Lib/shutil.py", line 268, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '__pycache__'

----------
assignee: brett.cannon
components: Tests
messages: 136299
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_importlib failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:19:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:19:45 +0000
Subject: [New-bugs-announce] [issue12118] test_imp failure
In-Reply-To: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>
Message-ID: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failure under a fresh checkout:

======================================================================
ERROR: test_issue5604 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_imp.py", line 163, in test_issue5604
    temp_mod_name, imp.cache_from_source(temp_mod_name + '.py'))
IOError: [Errno 2] No such file or directory

----------
components: Tests
messages: 136300
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_imp failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:20:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:20:53 +0000
Subject: [New-bugs-announce] [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failure under a fresh checkout:

======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/distutils/tests/test_build_py.py", line 61, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not true

----------
assignee: tarek
components: Distutils, Tests
messages: 136301
nosy: eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:22:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:22:08 +0000
Subject: [New-bugs-announce] [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failure under a fresh checkout:

======================================================================
FAIL: test_package_data (packaging.tests.test_command_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/packaging/tests/test_command_build_py.py", line 64, in test_package_data
    self.assertIn("__init__.pyc", files)
AssertionError: '__init__.pyc' not found in ['README.txt', '__init__.py']

----------
assignee: tarek
components: Distutils2, Tests
messages: 136302
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: test_packaging failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:22:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:22:58 +0000
Subject: [New-bugs-announce] [issue12121] test_packaging failure when ssl is
	not available
In-Reply-To: <1305822178.04.0.171095491628.issue12121@psf.upfronthosting.co.za>
Message-ID: <1305822178.04.0.171095491628.issue12121@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failure when the ssl module is not available:

======================================================================
ERROR: test_https_connection (packaging.tests.test_command_upload_docs.UploadDocsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/packaging/tests/test_command_upload_docs.py", line 151, in test_https_connection
    orig_https = upload_docs_mod.http.client.HTTPSConnection
AttributeError: 'module' object has no attribute 'HTTPSConnection'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136303
nosy: alexis, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging failure when ssl is not available
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:25:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:25:02 +0000
Subject: [New-bugs-announce] [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failures in a fresh checkout:

======================================================================
ERROR: test_explicit_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 283, in test_explicit_relative_import
    self._check_relative_imports(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_main_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 288, in test_main_relative_import
    self._check_relative_imports(depth, "__main__")
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_module (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 273, in test_run_module
    self._check_module(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 177, in _check_module
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_package (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 278, in test_run_package
    self._check_package(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 201, in _check_package
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory


Here is the test output:

test_run_code (test.test_runpy.RunModuleCodeTest) ... ok
test_run_module_code (test.test_runpy.RunModuleCodeTest) ... ok
test_explicit_relative_import (test.test_runpy.RunModuleTest) ... Testing relative imports at depth: 2
  Package tree in: /tmp/tmpmruwyg
  Updated sys.path: /tmp/tmpmruwyg
  Next level in: /tmp/tmpmruwyg/__runpy_pkg__
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__init__.py
  Next level in: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/__init__.py
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/runpy_test.py
  Added sibling module: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/sibling.py
  Added uncle package: /tmp/tmpmruwyg/__runpy_pkg__/uncle
  Added cousin package: /tmp/tmpmruwyg/__runpy_pkg__/uncle/cousin
  Added nephew module: /tmp/tmpmruwyg/__runpy_pkg__/uncle/cousin/nephew.py
Running from source: __runpy_pkg__.__runpy_pkg__.runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_invalid_names (test.test_runpy.RunModuleTest) ... ok
test_library_module (test.test_runpy.RunModuleTest) ... ok
test_main_relative_import (test.test_runpy.RunModuleTest) ... Testing main relative imports at depth: 2
  Package tree in: /tmp/tmp39sx5n
  Updated sys.path: /tmp/tmp39sx5n
  Next level in: /tmp/tmp39sx5n/__runpy_pkg__
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__init__.py
  Next level in: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/__init__.py
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/runpy_test.py
  Added sibling module: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/sibling.py
  Added uncle package: /tmp/tmp39sx5n/__runpy_pkg__/uncle
  Added cousin package: /tmp/tmp39sx5n/__runpy_pkg__/uncle/cousin
  Added nephew module: /tmp/tmp39sx5n/__runpy_pkg__/uncle/cousin/nephew.py
Running from source: __runpy_pkg__.__runpy_pkg__.runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_run_module (test.test_runpy.RunModuleTest) ... Testing package depth: 0
  Package tree in: /tmp/tmpy4y7in
  Updated sys.path: /tmp/tmpy4y7in
  Created: /tmp/tmpy4y7in/runpy_test.py
Running from source: runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_run_package (test.test_runpy.RunModuleTest) ... Testing package depth: 1
  Package tree in: /tmp/tmp_7dx_4
  Updated sys.path: /tmp/tmp_7dx_4
  Next level in: /tmp/tmp_7dx_4/__runpy_pkg__
  Created: /tmp/tmp_7dx_4/__runpy_pkg__/__init__.py
  Created: /tmp/tmp_7dx_4/__runpy_pkg__/__main__.py
Running from source: __runpy_pkg__
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_basic_script (test.test_runpy.RunPathTest) ... ok
test_directory (test.test_runpy.RunPathTest) ... ok
test_directory_compiled (test.test_runpy.RunPathTest) ... ok
test_directory_error (test.test_runpy.RunPathTest) ... ok
test_main_recursion_error (test.test_runpy.RunPathTest) ... ok
test_script_compiled (test.test_runpy.RunPathTest) ... ok
test_zipfile (test.test_runpy.RunPathTest) ... ok
test_zipfile_compiled (test.test_runpy.RunPathTest) ... ok
test_zipfile_error (test.test_runpy.RunPathTest) ... ok

----------
assignee: ncoghlan
components: Tests
messages: 136304
nosy: barry, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_runpy failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 18:26:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:26:48 +0000
Subject: [New-bugs-announce] [issue12123] test_import failures
In-Reply-To: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>
Message-ID: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

I get the following failures under a fresh checkout:

======================================================================
ERROR: test_file_to_source (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 253, in test_file_to_source
    make_legacy_pyc(source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test___cached___legacy_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 584, in test___cached___legacy_pyc
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_missing_source_legacy (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 564, in test_missing_source_legacy
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
FAIL: test_execute_bit_not_copied (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 112, in test_execute_bit_not_copied
    self.fail("__import__ did not result in creation of "
AssertionError: __import__ did not result in creation of either a .pyc or .pyo file

======================================================================
FAIL: test_import_pyc_path (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 531, in test_import_pyc_path
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

======================================================================
FAIL: test_missing_source (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 552, in test_missing_source
    self.assertTrue(os.path.exists(pyc_file))
AssertionError: False is not true

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 543, in test_unwritable_directory
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

----------
components: Tests
messages: 136305
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_import failures
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 19 22:42:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 20:42:05 +0000
Subject: [New-bugs-announce] [issue12124] python -m test test_packaging
	test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>


New submission from STINNER Victor :

"python -m test test_packaging test_zipimport" fails with:

======================================================================
FAIL: testAFakeZlib (test.test_zipimport.CompressedZipImportTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/test_zipimport.py", line 130, in testAFakeZlib
    self.fail("expected test to raise ImportError")
AssertionError: expected test to raise ImportError

The problem is that the zipimport module keeps a reference to zlib.decompress() which "makes zlib.decompress immortal": see get_decompress_func() in zipimport.c.

Attached patch replaces the borrowed reference by a classic reference to allow to unload zlib.

I don't think that it makes zipimport slower: it calls PyImport_ImportModuleNoBlock("io") and PyObject_GetAttrString(zlib, "decompress") each time instead of just once, but PyImport_ImportModuleNoBlock() is just a lookup in a dict (if the zlib module is not unloaded between two calls to get_data()).

----------
components: Extension Modules, Tests
files: zipimport_get_data.patch
keywords: patch
messages: 136334
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: python -m test test_packaging test_zipimport failure
versions: Python 3.3
Added file: http://bugs.python.org/file22033/zipimport_get_data.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 20 02:08:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:08:50 +0000
Subject: [New-bugs-announce] [issue12125] test_sysconfig fails on
	OpenIndiana because of	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>


New submission from STINNER Victor :

It looks like a test of test_packaging removes some data from sysconfig._SCHEMES:

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

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_command_build_ext.py", line 58, in test_build_ext
    cmd.ensure_finalized()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/command/cmd.py", line 104, in ensure_finalized
    self.finalize_options()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/command/build_ext.py", line 159, in finalize_options
    py_include = sysconfig.get_path('include')
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'include'

...



======================================================================
ERROR: test_get_path (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_sysconfig.py", line 110, in test_get_path
    res = get_path(name, scheme)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'confdir'

***

I fixed a cleanup function in Lib/packaging/tests/test_command_install_data.py: commit [6267a4645f5f]. Let see if it does fix the bug or not.

----------
components: Tests
messages: 136342
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: test_sysconfig fails on OpenIndiana because of test_packaging
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 20 02:23:52 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 20 May 2011 00:23:52 +0000
Subject: [New-bugs-announce] [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone :

http://docs.python.org/py3k/howto/sockets.html#non-blocking-sockets

"And if you put a socket in more than one input list, it will only be (at most) in one output list."


>>> import socket
>>> s = socket.socket()
>>> s.connect(('localhost', 22))
>>> import select
>>> select.select([s], [s], [])
([], [], [])
>>>

----------
assignee: docs at python
components: Documentation
messages: 136350
nosy: docs at python, exarkun
priority: normal
severity: normal
status: open
title: incorrect select documentation
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 20 06:19:44 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Fri, 20 May 2011 04:19:44 +0000
Subject: [New-bugs-announce] [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>


New submission from Peter Wentworth :

In Python 3 we no longer have octal literals. The assignment
x = 0050  
gives an invalid token error.

But the assignment
y = int("0050") assigns the value 50 to y.

I would advocate consistency in the two situations, and prefer that leading zeros should be permitted on numbers.

----------
components: Interpreter Core
messages: 136352
nosy: Peter.Wentworth
priority: normal
severity: normal
status: open
title: Inconsistent leading zero treatment
type: compile error
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 20 19:15:03 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 May 2011 17:15:03 +0000
Subject: [New-bugs-announce] [issue12128] Allow `abc.abstractproperty` to be
	overridden by a data	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>


New submission from Ram Rachum :

When you create an `abc.abstractproperty` on a class, any subclass must override it as an actual property in order to be instantiable. But sometimes you want to override it with a data attribute instead, i.e. `self.x = 5` instead of `x = property(...)`. It would be nice if doing `self.x = 5` would satisfy `abc.abstractproperty` and allow the subclass to be instantiable.

----------
components: Library (Lib)
messages: 136388
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow `abc.abstractproperty` to be overridden by a data attribute
type: feature request
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 00:02:11 2011
From: report at bugs.python.org (Kyle Keating)
Date: Fri, 20 May 2011 22:02:11 +0000
Subject: [New-bugs-announce] [issue12129] Document Object Model API -
	validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>


New submission from Kyle Keating :

I was doing some tests on using this library and I noticed xml elements and attribute names could be created with mal-formed xml because special characters which can break validation are not cleaned or converted from their literal forms. Only the attribute values are cleaned, but not the names.

For example

import xml.dom

...
doc.createElement("p>") 
...

will just embed a pair of p tags in the xml result. I thought that the xml spec did not permit <, >, &, \n etc. in the element name or attribute name? Could I get some clarification on this, thanks!

----------
components: Library (Lib)
messages: 136402
nosy: Kyle.Keating
priority: normal
severity: normal
status: open
title: Document Object Model API - validation
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 00:47:52 2011
From: report at bugs.python.org (Julian)
Date: Fri, 20 May 2011 22:47:52 +0000
Subject: [New-bugs-announce] [issue12130] regex 0.1.20110514 findall
	overlapped not working with	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>


New submission from Julian :

Trying to use regex 0.1.2011051 with the overlapped=True feature

It works great, unless I have the 'start of string' (caret) character in my regular expression:


>>> regex.findall(r"a.*b","abadalaba",overlapped=True)
['abadalab', 'adalab', 'alab', 'ab']
>>> regex.findall(r"^a.*b","abadalaba",overlapped=True)
['abadalab']

----------
components: Regular Expressions
messages: 136405
nosy: jcerruti
priority: normal
severity: normal
status: open
title: regex 0.1.20110514 findall overlapped not working with 'start of string' expression
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 05:14:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2011 03:14:11 +0000
Subject: [New-bugs-announce] [issue12131] python built with --prefix fails
	in site.py with no	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>


New submission from Ned Deily :

[reported by Stefan Behnel]

With the "packaging" changes introducing Lib/sysconfig.cfg and corresponding changes to Lib/sysconfig.py to depend on them, builds that use --prefix= to install outside of the build directory fail during startup when site.py calls sysconfig:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/configparser.py", line 842, in items
     d.update(self._sections[section])
KeyError: 'posix_prefix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/site.py", line 537, in 
     main()
   File "/.../python/lib/python3.3/site.py", line 522, in main
     known_paths = addusersitepackages(known_paths)
   File "/.../python/lib/python3.3/site.py", line 263, in addusersitepackages
     user_site = getusersitepackages()
   File "/.../python/lib/python3.3/site.py", line 238, in getusersitepackages
     user_base = getuserbase() # this will also set USER_BASE
   File "/.../python/lib/python3.3/site.py", line 228, in getuserbase
     USER_BASE = get_config_var('userbase')
   File "/.../python/lib/python3.3/sysconfig.py", line 576, in get_config_var
     return get_config_vars().get(name)
   File "/.../python/lib/python3.3/sysconfig.py", line 472, in get_config_vars
     _init_posix(_CONFIG_VARS)
   File "/.../python/lib/python3.3/sysconfig.py", line 324, in _init_posix
     makefile = get_makefile_filename()
   File "/.../python/lib/python3.3/sysconfig.py", line 318, in 
get_makefile_filename
     return os.path.join(get_path('stdlib'), config_dir_name, 'Makefile')
   File "/.../python/lib/python3.3/sysconfig.py", line 436, in get_path
     return get_paths(scheme, vars, expand)[name]
   File "/.../python/lib/python3.3/sysconfig.py", line 426, in get_paths
     return _expand_vars(scheme, vars)
   File "/.../python/lib/python3.3/sysconfig.py", line 142, in _expand_vars
     for key, value in _SCHEMES.items(scheme):
   File "/.../python/lib/python3.3/configparser.py", line 845, in items
     raise NoSectionError(section)
configparser.NoSectionError: No section: 'posix_prefix'

The problem is that sysconfig.py expects sysconfig.cfg to be in the same directory as it but no changes were added to the Makefile to do so.

A simple-minded workaround is something like this:

diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -947,7 +947,7 @@
                else    true; \
                fi; \
        done
-       @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info ; \
+       @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info $(srcdir)/Lib/*.cfg ; \
        do \
                if test -x $$i; then \
                        $(INSTALL_SCRIPT) $$i $(DESTDIR)$(LIBDEST); \

I am not sure if that is a proper long-term fix.  For real Python installations, say, via a binary installer, is the lib/python3.x directory the proper place for a .cfg file?  Is it expected that site admins will modify this file?

----------
assignee: tarek
messages: 136419
nosy: ned.deily, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: python built with --prefix fails in site.py with no section 'posix_prefix'
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 12:42:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 21 May 2011 10:42:51 +0000
Subject: [New-bugs-announce] [issue12132] test_packaging failures when run
	with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>


New submission from Nadeem Vawda :

test_packaging fails when regrtest is run with the -j option (run multiple tests concurrently).


    $ ./python -Wd -E -bb -j0 -v test_packaging

    [snip]

    ======================================================================
    ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_compiler_option (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_ext_fullpath (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_finalize_options (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_get_source_files (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_optional_extension (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_solaris_enable_shared (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_user_site (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'


It seems that these tests assume they are running under the top-level
directory of the checkout (which is not the case when -j is used).

----------
components: Tests
messages: 136428
nosy: nadeem.vawda, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging failures when run with -j
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 14:42:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 12:42:36 +0000
Subject: [New-bugs-announce] [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

In case of error (e.g. timeout error), urllib.request leaves the socket open:

import urllib.request as ur
import socket
s = socket.socket()
s.bind(('localhost', 10000))
s.listen(0)
socket.setdefaulttimeout(5)
ur.urlopen('http://localhost.localdomain:10000')

outputs:

sys:1: ResourceWarning: unclosed 

Traceback (most recent call last):
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1146, in do_open
    r = h.getresponse()  # an HTTPResponse instance
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 308, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/home/wolf/dev/py/py3k/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 369, in open
    response = self._open(req, data)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 387, in _open
    '_open', req)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 347, in _call_chain
    result = func(*args)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1163, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1148, in do_open
    raise URLError(err)
urllib.error.URLError: 
>>>

AFAIU, when urlopen returns or raises, the socket can be closed, so the attached patch adds a "finally" that calls close() on the HTTPConnection object.  The test suite pass (except for a mock that was missing the close method), but I'm not 100% sure that it's always safe to call close().

This ResourceWarning has been exposed by test_packaging.

----------
components: Library (Lib)
files: issue12133.diff
keywords: needs review, patch
messages: 136433
nosy: davide.rizzo, ezio.melotti, jhylton, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: ResourceWarning in urllib.request
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file22047/issue12133.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 15:38:06 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 13:38:06 +0000
Subject: [New-bugs-announce] [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>


New submission from poq :

import json, timeit
obj = [[1,2,3]*10]*10
class writable(object):
	def write(self, buf): pass
w = writable()
print('dumps: %.3f' % timeit.timeit(lambda: json.dumps(obj), number=10000))
print('dump:  %.3f' % timeit.timeit(lambda: json.dump(obj,w), number=10000))

On my machine this outputs:
dumps: 0.391
dump:  4.501

I believe this is mostly caused by dump using JSONEncoder.iterencode without _one_shot=True, resulting in c_make_encoder not being used.

----------
components: Extension Modules
messages: 136439
nosy: poq
priority: normal
severity: normal
status: open
title: json.dump much slower than dumps
type: performance
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 16:26:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:26:03 +0000
Subject: [New-bugs-announce] [issue12135] test_packaging failure under
	Windows
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

Also, *please* provide stderr in the error message when an external command fails. Otherwise, it's impossible to properly debug failure of external commands.


======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\compiler\msvc9compiler.py", line 622, in link
    self.spawn([self.linker] + ld_args)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\compiler\ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\BIN\\link.exe', '/DLL', '/nologo', '/INCREMENTAL:no', '/DEBUG', '/pdb:None', '/LIBPATH:D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\libs', '/LIBPATH:D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild', '/EXPORT:initxx', 'c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xxmodule.obj', '/OUT:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.pyd', '/IMPLIB:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.lib', '/MANIFESTFILE:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.pyd.manifest']' failed with exit status 1120

----------
assignee: tarek
components: Distutils2, Windows
messages: 136441
nosy: alexis, eric.araujo, pitrou, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: test_packaging failure under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 17:41:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 15:41:08 +0000
Subject: [New-bugs-announce] [issue12136] test_logging fails when no ssl
	available
In-Reply-To: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>
Message-ID: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

======================================================================
ERROR: test_output (test.test_logging.HTTPHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_logging.py", line 1529, in test_output
    import ssl
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/ssl.py", line 60, in 
    import _ssl             # if we can't import it, let the error propagate
ImportError: No module named '_ssl'

----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 136453
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging fails when no ssl available
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 18:34:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 16:34:14 +0000
Subject: [New-bugs-announce] [issue12137] EBADF in test_urllibnet
In-Reply-To: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>
Message-ID: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

This is probably a transient failure due to the remote host being unavailable, but the "bad file descriptor" error is not ok:


test test_urllibnet failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_urllibnet.py", line 70, in test_readlines
    self.assertIsInstance(open_url.readlines(), list,
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/http/client.py", line 509, in read
    s = self.fp.read(amt)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
socket.error: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
messages: 136455
nosy: orsenthil, pitrou
priority: normal
severity: normal
status: open
title: EBADF in test_urllibnet
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 18:36:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 16:36:53 +0000
Subject: [New-bugs-announce] [issue12138] buggy use of transient_internet()
	in test_urllibnet
In-Reply-To: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>
Message-ID: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

The code I added in b65f417dd266 is buggy, because it calls __exit__ with (None, None, None) rather than the exception to be tested.

----------
assignee: pitrou
components: Tests
messages: 136456
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: buggy use of transient_internet() in test_urllibnet
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 21 20:09:00 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 May 2011 18:09:00 +0000
Subject: [New-bugs-announce] [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' :

In FTPS, CCC command can be used to switch back to a clear-text control connection.
This can be useful to take advantage of firewalls that know how to handle NAT with non-secure FTP without opening fixed ports.
Patch in attachment includes lib, test and doc changes.

----------
assignee: giampaolo.rodola
files: ftplib-ccc.patch
keywords: patch
messages: 136459
nosy: giampaolo.rodola
priority: normal
severity: normal
stage: patch review
status: open
title: Add CCC command support to ftplib
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22052/ftplib-ccc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 00:19:55 2011
From: report at bugs.python.org (Philip Drew)
Date: Sat, 21 May 2011 22:19:55 +0000
Subject: [New-bugs-announce] [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>


New submission from Philip Drew :

Upon execution of python.exe a command line box appears for a fraction of a second, closes and is followed by nothing. On executing IDLE from the start menu, nothing happens. I have installed python to C:\Python27 using the python windows installer.
I am running win7 64 bit on a toshiba satellite 17X

----------
components: IDLE, Installation
messages: 136481
nosy: Philip.Drew
priority: normal
severity: normal
status: open
title: Crash upon start up
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 00:32:31 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:32:31 +0000
Subject: [New-bugs-announce] [issue12141] --multiprocessing fails
	with	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

this test module looks for sysconfig.get_config_var('srcdir') which in turns uses the sys,executable path.

multiprocess seems to change it in every process, leading to the errors.

To reproduce:

./python Lib/test/regrtest.py -j2 -v test_packaging

A workaround is to skip the test in case the file is not found, but we need to fix it because it boils down to sysconfig being broken in multiprocess

----------
assignee: pitrou
messages: 136483
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: --multiprocessing fails with packaging.tests.test_command_build_ext

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 00:39:48 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 22:39:48 +0000
Subject: [New-bugs-announce] [issue12142] Circular reference when importing
	ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>


New submission from poq :

When importing ctypes after gc.set_debug(gc.DEBUG_LEAK), the garbage collector finds a 'c_int_Array_3' class and some related objects.

The class is created in ctypes/_endian.py:
_array_type = type(c_int * 3)

It seems that this could be avoided with:
_array_type = type(Array)

Of course, I realize this is not a bug because normally it will just get collected. It is just an extremely minor annoyance because this is currently the only thing still found by DEBUG_LEAK for my program ;)

----------
components: ctypes
messages: 136485
nosy: poq
priority: normal
severity: normal
status: open
title: Circular reference when importing ctypes
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 01:24:05 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 23:24:05 +0000
Subject: [New-bugs-announce] [issue12143] packaging extension gcc linking
	fails on Ubuntu Shared
In-Reply-To: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>
Message-ID: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

I can't reproduce this yet, or compare it to distutils. I 

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 255, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['gcc', '-pthread', '-shared', '/tmp/tmpwe7ci9/tmp3v8m7p/tmp/tmpwe7ci9/tmp3v8m7p/xxmodule.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpwe7ci9/tmp3v8m7p/xx.cpython-33dm.so']' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/tests/test_command_build_ext.py", line 59, in test_build_ext
    cmd.run()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 368, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 454, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 675, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 257, in link
    raise LinkError(msg)
packaging.errors.LinkError: command '['gcc', '-pthread', '-shared', '/tmp/tmpwe7ci9/tmp3v8m7p/tmp/tmpwe7ci9/tmp3v8m7p/xxmodule.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpwe7ci9/tmp3v8m7p/xx.cpython-33dm.so']' failed with exit status 1

======================================================================
ERROR: test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 255, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['gcc', '-pthread', '-shared', '/tmp/tmpdfxahd/tmp0m_s9d/tempt/tmp/tmpdfxahd/tmp_cb75f/foo.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpdfxahd/tmpcoi8oo/foo.cpython-33dm.so']' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/tests/test_command_build_ext.py", line 263, in test_get_outputs
    cmd.run()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 368, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 454, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 675, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 257, in link
    raise LinkError(msg)
packaging.errors.LinkError: command '['gcc', '-pthread', '-shared', '/tmp/tmpdfxahd/tmp0m_s9d/tempt/tmp/tmpdfxahd/tmp_cb75f/foo.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpdfxahd/tmpcoi8oo/foo.cpython-33dm.so']' failed with exit status 1

----------
assignee: tarek
components: Distutils2
messages: 136492
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: packaging extension gcc linking fails on Ubuntu Shared

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 04:58:44 2011
From: report at bugs.python.org (Scott Wimer)
Date: Sun, 22 May 2011 02:58:44 +0000
Subject: [New-bugs-announce] [issue12144] cookielib.CookieJar.make_cookies
	fails for cookies with	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>


New submission from Scott Wimer :

When cookielib.CookieJar().make_cookies is used to extract cookies from a urllib2 response, it crashes when it encounters a 'Set-Cookie' header entry that has an 'expires' attribute.

This crash occurs because the expires time is evaluated against the '_now' attribute of the CookieJar instance -- an attribute which is not set unless CookieJar().extract_cookies() was called previously.

Attached is a script that triggers this bug.

----------
components: Library (Lib)
files: cookielib-crash.py
messages: 136497
nosy: Scott.Wimer
priority: normal
severity: normal
status: open
title: cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file22054/cookielib-crash.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 05:10:55 2011
From: report at bugs.python.org (Daniel Lindsley)
Date: Sun, 22 May 2011 03:10:55 +0000
Subject: [New-bugs-announce] [issue12145] distutils2 should support
	README.rst
In-Reply-To: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>
Message-ID: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>


New submission from Daniel Lindsley :

Given that reST is the format all of Python's docs are in, it'd be nice if distutils(2) would support looking for README.rst (in addition to the existing README & README.txt).

----------
assignee: tarek
components: Distutils2
messages: 136500
nosy: alexis, daniellindsley, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 should support README.rst
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 05:43:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 03:43:35 +0000
Subject: [New-bugs-announce] [issue12146] Possible bug in 're' documentation
	example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>


New submission from Eli Bendersky :

>From the docs maillist, by Herman L. Jackson:

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

Hi,

When running the tokenize example at the bottom of http://docs.python.org/py3k/library/re.html#match-objects
I received the following error:

   Traceback (most recent call last):
     File "", line 1, in 
     File "", line 23, in tokenize
   NameError: global name 'val' is not defined

The problem is that val is never assigned to before this line:

   if typ == 'ID' and val in keywords:

Here is a suggested rewrite of the that section:

   elif typ != 'SKIP':
       val = mo.group(typ)
       if typ == 'ID' and val in keywords:
           typ = val
       yield Token(typ, val, line, mo.start()-line_start)

Attached is a complete working example.

----------
assignee: eli.bendersky
components: Documentation
files: tokenize.py
keywords: easy
messages: 136501
nosy: eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Possible bug in 're' documentation example
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22056/tokenize.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 09:54:41 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Sun, 22 May 2011 07:54:41 +0000
Subject: [New-bugs-announce] [issue12147] smtplib.send_message does not
	implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>


New submission from Nicolas Estibals :

smtplib.send_message permits to send messages that are in python Message representation by selecting smtp's "from" and "to" in the message headers. Most of the time the implementation is correct but if the message is bounced (Resent-* headers have to be considered) or if there is a Sender field (this one supersede the From field if present), the current implementation does not select the right addresses (not as specified in rfc 2822).

I have wrote a patch to make the method compliant. This is my first patch to python but I followed the "Lifecycle of a Patch" webpage and hope my code will be usable. Please ask me if some revision of the code is needed.

----------
components: Library (Lib)
files: send_message_rfc2822.patch
keywords: patch
messages: 136508
nosy: Nicolas.Estibals
priority: normal
severity: normal
status: open
title: smtplib.send_message does not implement corectly rfc 2822
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22061/send_message_rfc2822.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 12:09:26 2011
From: report at bugs.python.org (ekorn)
Date: Sun, 22 May 2011 10:09:26 +0000
Subject: [New-bugs-announce] [issue12148] Clarify "or-ing together" doctest
	option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>


New submission from ekorn :

Combining multiple option flags to doctest.testmod(optionflags=...) requires the bitwise or operator |, not plain "or". I therefore suggest rewording "or-ing together individual option flags." to "or-ing together individual option flags, using the 'bitwise or' operator |.", perhaps with a link to http://docs.python.org/reference/expressions.html#binary-bitwise-operations.

Example:

"""
Doctest option flags must be or-ed together with '|', not 'or'.

>>> print "A  B  C"
A B...
"""
import doctest

print "Combining option flags using bitwise '|'..."
doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS)
print "Combining option flags using logical 'or'..."
doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE or doctest.ELLIPSIS)

----------
assignee: docs at python
components: Documentation
messages: 136509
nosy: docs at python, ekorn
priority: normal
severity: normal
status: open
title: Clarify "or-ing together" doctest option flags
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 20:06:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 May 2011 18:06:40 +0000
Subject: [New-bugs-announce] [issue12149] Segfault in
	_PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

The attached patch causes a segfault while running test_urllib:

$ ./python -m test test_urllib
[1/1] test_urllib






Fatal Python error: Segmentation fault

Current thread 0xb77de8d0:
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 451 in close
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1119 in do_open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1166 in http_open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 347 in _call_chain
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 387 in _open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 369 in open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 138 in urlopen
  File "/home/wolf/dev/py/py3k/Lib/test/test_urllib.py", line 184 in test_url_fragment
[...]
Segmentation fault

The failure seems to be fairly random, for example if I uncomment the tests at the bottom of test_urllib, the segfault happens only in non-verbose mode.  Also adding a few print()s to debug the issue or making other unrelated changes changes the behavior (e.g. it fails only in verbose mode but not in normal mode).

gdb shows that the failure is in Objects/object.c, at line 981 in the _PyObject_GenericGetAttrWithDict function.  The problem seems to be that 'descr' is invalid and descr->ob_type results in an error:

$ gdb -args ./python -m test test_urllib
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
[...]
Reading symbols from /home/wolf/dev/py/py3k/python...done.
(gdb) run
Starting program: /home/wolf/dev/py/py3k/python -m test test_urllib
[Thread debugging using libthread_db enabled]
[1/1] test_urllib
[New Thread 0xb77e9b70 (LWP 5227)]


Program received signal SIGSEGV, Segmentation fault.
0x0805c7d8 in _PyObject_GenericGetAttrWithDict (obj=, name='close', dict=0x0) at Objects/object.c:982
982             f = descr->ob_type->tp_descr_get;
(gdb) p *(PyUnicodeObject*)descr
$1 = {ob_base = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348324, ob_type = 0xdbdbdbdb}, length = -606348325, str = 0xdbdbdbdb, 
  hash = -606348325, state = -606348325, defenc = }
(gdb) 

FakeHTTPConnection is a subclass of http.client.HTTPConnection, but I also got segfaults in FakeSocket, which is an io.BytesIO subclass.
FWIW I found this while trying to fix ResourceWarnings.  In #12133 I proposed a patch that fixes a ResourceWarnings (included in segfault.diff), and while trying the same approach in urlretrieve (adding a finally: http_conn.close()) and running test_urllib I got the segfault.
Tested on 3.3 only.

----------
components: Interpreter Core
files: segfault.diff
keywords: patch
messages: 136548
nosy: ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Segfault in _PyObject_GenericGetAttrWithDict
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file22070/segfault.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 22 22:24:56 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 20:24:56 +0000
Subject: [New-bugs-announce] [issue12150] test_sysconfig fails on solaris
In-Reply-To: <1306095896.24.0.236331245159.issue12150@psf.upfronthosting.co.za>
Message-ID: <1306095896.24.0.236331245159.issue12150@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

======================================================================
ERROR: test_get_path (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 110, in test_get_path
    res = get_path(name, scheme)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

======================================================================
ERROR: test_user_similar (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 281, in test_user_similar
    global_path = get_path(name, 'posix_prefix')
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

----------
assignee: tarek
components: Library (Lib)
messages: 136571
nosy: tarek
priority: normal
severity: normal
status: open
title: test_sysconfig fails on solaris

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 01:16:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 23:16:03 +0000
Subject: [New-bugs-announce] [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>


New submission from STINNER Victor :

test_logging does sometimes fail.

A recent example on Windows XP:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4645/steps/test/logs/stdio

test test_logging failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 3599, in test_rollover
    self.assertTrue(found, msg=msg)
AssertionError: False is not true : No rotated files found, went back 300 seconds

----------
messages: 136576
nosy: haypo, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging fails sometimes
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 09:49:58 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 07:49:58 +0000
Subject: [New-bugs-announce] [issue12152] Parser/asdl_c.py relies on
	mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>


New submission from Matthias Klose :

when building without an hg repository present, the build fails with:

./Parser/asdl_c.py -h ../Include ../Parser/Python.asdl
Traceback (most recent call last):
  File "../Parser/asdl_c.py", line 1214, in 
    main(args[0])
  File "../Parser/asdl_c.py", line 1158, in main
    mod.version = get_file_revision(srcfile)
  File "../Parser/asdl_c.py", line 1142, in get_file_revision
    p = subprocess.Popen(args, stdout=subprocess.PIPE)
  File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [../Include/Python-ast.h] Error 1

----------
components: Build
messages: 136591
nosy: doko
priority: normal
severity: normal
status: open
title: Parser/asdl_c.py relies on mercurial repository revision
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 10:31:36 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 08:31:36 +0000
Subject: [New-bugs-announce] [issue12153] Modules/faulthandler.c exports
	`stack_overflow' symbol
In-Reply-To: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>
Message-ID: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>


New submission from Matthias Klose :

the exported symbol should either have a prefix, or defined static.

----------
components: Extension Modules
messages: 136594
nosy: doko
priority: normal
severity: normal
status: open
title: Modules/faulthandler.c exports `stack_overflow' symbol
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 11:15:31 2011
From: report at bugs.python.org (JJeffries)
Date: Mon, 23 May 2011 09:15:31 +0000
Subject: [New-bugs-announce] [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>


New submission from JJeffries :

PyDoc currently does not support partial functions. It currently just outputs the following, treating it as a data member instead of a function.

my_partial_function = 

I think that if the __doc__ it should be treated as a function and the __doc__ read.

----------
components: Library (Lib)
messages: 136596
nosy: JJeffries
priority: normal
severity: normal
status: open
title: PyDoc Partial Functions
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 12:22:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:22:31 +0000
Subject: [New-bugs-announce] [issue12155] queue example doesn't stop worker
	threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The queue doc contains the following example:
------------------
def worker():
    while True:
        item = q.get()
        do_work(item)
        q.task_done()

q = Queue()
for i in range(num_worker_threads):
     t = Thread(target=worker)
     t.daemon = True
     t.start()

for item in source():
    q.put(item)

q.join()       # block until all tasks are done
------------------
http://docs.python.org/library/queue.html

It doesn't define do_work(), num_worker_threads or do_work(), but my concern is that it doesn't stop worker threads.

I consider "t.daemon = True" as an hack to not care about stopping threads.

The example should pass a special value to each worker to stop it. For example:



while True:
  job = queue.get()
  if job is None:
     break
  audio.play(*job)
  queue.task_done()

Main thread:

...
threads = []
for i in range(num_worker_threads):
     t = Thread(target=worker)
     threads.append(t)
     t.start()
...
for i in range(num_worker_threads):
     queue.put(None)
queue.join()
for thread in threads:
    thread.join()

----------
assignee: docs at python
components: Documentation
messages: 136601
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: queue example doesn't stop worker threads
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 12:37:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:37:58 +0000
Subject: [New-bugs-announce] [issue12156] test_multiprocessing
Message-ID: <1306147078.6.0.687476202649.issue12156@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 13:42:46 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Mon, 23 May 2011 11:42:46 +0000
Subject: [New-bugs-announce] [issue12157] join method of multiprocessing
	Pool object hangs if	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>


New submission from G?k?en Eraslan :

When I use map method Pool object with an empty list parameter and then call close and wait methods, join() method hangs. I think this is not intended.

Code to reproduce the bug is attached. 

PS: A similar issue (using map method with an empty list argument) is reported here[1], but it was about the chunksize parameter and it's resolved.

[1] http://bugs.python.org/issue6433

----------
components: Library (Lib)
files: multi.py
messages: 136613
nosy: G?k?en.Eraslan, jnoller
priority: normal
severity: normal
status: open
title: join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22077/multi.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 14:25:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 12:25:26 +0000
Subject: [New-bugs-announce] [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Sometimes, we need to know the version of the Linux kernel. Recent examples: test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux < 2.6.23 *silently* ignores O_CLOEXEC flag of open().

linux_version() is already implemented in test_socket, but it looks like test_posix does also need it.

Attached patch adds platform.linux_version(). It returns (a, b, c) (integers) or None (if not Linux).

It raises an error if the version string cannot be parsed.

----------
components: Library (Lib)
files: platform_linux_version.patch
keywords: patch
messages: 136621
nosy: charles-francois.natali, haypo, lemburg, pitrou
priority: normal
severity: normal
status: open
title: platform: add linux_version()
versions: Python 3.3
Added file: http://bugs.python.org/file22079/platform_linux_version.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 16:24:02 2011
From: report at bugs.python.org (Peter Fankhaenel)
Date: Mon, 23 May 2011 14:24:02 +0000
Subject: [New-bugs-announce] [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>


New submission from Peter Fankhaenel :

An OverflowError is emitted in case the return value of __len__
exceeds 2**31-1.

The following code:

class C (object):
    def __len__ (self):
       return self.l

c = C()
c.l = 2**31

len (c)

# leads to an OverflowError in the last line. It works flawless for

c.__len__ ()

----------
components: Windows
messages: 136644
nosy: peter.fankhaenel
priority: normal
severity: normal
status: open
title: Integer Overflow in __len__
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 17:55:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 15:55:37 +0000
Subject: [New-bugs-announce] [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Codec.encode() and Codec.decode() refer to StreamCode, but I cannot find this class in the doc nor in the code.

I suppose that it should be replaced by IncrementalEncoder and IncrementalDecoder. If I'm correct, see attached patch.

----------
files: codecs_incremental.patch
keywords: patch
messages: 136665
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: codecs doc: what is StreamCodec?
Added file: http://bugs.python.org/file22084/codecs_incremental.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 23 22:02:41 2011
From: report at bugs.python.org (alejandro david weil)
Date: Mon, 23 May 2011 20:02:41 +0000
Subject: [New-bugs-announce] [issue12161] StringIO AttributeError instead of
	ValueError after	close..
In-Reply-To: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>
Message-ID: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>


New submission from alejandro david weil :

python 2.7 documentation: file:///usr/share/doc/python-doc/html/library/stringio.html#StringIO.StringIO.close
(or: http://docs.python.org/library/stringio.html#StringIO.StringIO.close )

says:

"""StringIO.close()

Free the memory buffer. Attempting to do further operations with a closed StringIO object will raise a ValueError."""


But this code:

def string_io_close_exception_test():
    from StringIO import StringIO
    s=StringIO()
    s.write("asdf")
    s.close()
    try:
        # file:///usr/share/doc/python-doc/html/library/stringio.html#StringIO.StringIO.close
        doc = """
        StringIO.close()
Free the memory buffer. Attempting to do further operations with a closed StringIO object will raise a ValueError.
        """
        s.getvalue()
    except ValueError:
        print "this is the expected"
    except Exception, e:
        print 'this is unexpected:',type(e), e
        raise

produces this output:


this is unexpected:  StringIO instance has no attribute 'buf'
Traceback (most recent call last):
  File "problems.py", line 192, in 
    string_io()
  File "problems.py", line 184, in string_io
    s.getvalue()
  File "/usr/lib/python2.7/StringIO.py", line 270, in getvalue
    self.buf += ''.join(self.buflist)
AttributeError: StringIO instance has no attribute 'buf'

----------
components: Library (Lib)
messages: 136692
nosy: tenuki
priority: normal
severity: normal
status: open
title: StringIO AttributeError instead of ValueError after close..
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 02:07:37 2011
From: report at bugs.python.org (Seth Troisi)
Date: Tue, 24 May 2011 00:07:37 +0000
Subject: [New-bugs-announce] [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>


New submission from Seth Troisi :

It would be nice to clarify re documentation on how to use \number.

current documentation lists three half examples:
"(.+) \1 matches 'the the' or '55 55', but not 'the end' (note the space after the group)."

This is rather confusing (at least to me) as it might be assumed that
re.search("(.+) \1", "the the") would return a match, which it does not.

A better example would be re.search("(\w+) \\1", "the the") which does match.

the other confusing portion is the requirement of the second "\" to make it match.

I would think that a quick example below the text would help.

>>> re.search("(\w+) \\1", "can you do the can can?") # \\1 matches the second can at the end of the sentence
<_sre.SRE_Match object at ...>

This is my first python issue and if I have misfiled or left out some information please tell me how to proceed.

----------
assignee: docs at python
components: Documentation
messages: 136708
nosy: Seth.Troisi, docs at python
priority: normal
severity: normal
status: open
title: Documentation about re \number
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 04:10:26 2011
From: report at bugs.python.org (py.user)
Date: Tue, 24 May 2011 02:10:26 +0000
Subject: [New-bugs-announce] [issue12163] str.count
In-Reply-To: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>
Message-ID: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>


New submission from py.user :

specification says
[code]
str.count(sub[, start[, end]])

    Return the number of non-overlapping occurrences of substring sub in the range [start, end]. Optional arguments start and end are interpreted as in slice notation.
[/code]

[code]
>>> ''.count('', None)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: slice indices must be integers or None or have an __index__ method
>>>
[/code]

----------
messages: 136713
nosy: py.user
priority: normal
severity: normal
status: open
title: str.count
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 07:14:44 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 May 2011 05:14:44 +0000
Subject: [New-bugs-announce] [issue12164] str.translate docstring doesn't
	mention that 'table' can	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>


New submission from Mark Dickinson :

In Python 2.6 and 2.7, str.translate accepts None as a first argument.  That's documented in the docs, but not in the str.translate docstring.

----------
assignee: docs at python
components: Documentation
messages: 136720
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: str.translate docstring doesn't mention that 'table' can be None
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 07:57:37 2011
From: report at bugs.python.org (Lukas Petru)
Date: Tue, 24 May 2011 05:57:37 +0000
Subject: [New-bugs-announce] [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>


New submission from Lukas Petru :

Can "nonlocal x" declaration also reference global x? I would assume that global scope automatically encloses all other scopes. But the nonlocal keyword seems to exclude global scope. This seems counter-intuitive. (maybe bug in implementation?)

For example:

x=0

def count(i):
    nonlocal x; x+=i; return x;

Checking this code in IDLE gives: no binding for nonlocal 'x' found. If this is what was intended, maybe it should be more clearly written in the documentation.

I am coming to Python from Lisp, so I am still learning Python's principles.

----------
components: Interpreter Core
messages: 136722
nosy: Lukas.Petru
priority: normal
severity: normal
status: open
title: Does nonlocal include global?
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 11:23:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 24 May 2011 09:23:51 +0000
Subject: [New-bugs-announce] [issue12166] object.__dir__
In-Reply-To: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>
Message-ID: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>


New submission from Michael Foord :

Implementing a custom __dir__ method is fiddly because there is no way of obtaining the standard list of attributes that dir would return.

Moving the relevant parts of the dir implementation into object.__dir__ would allow a custom __dir__ to obtain the "standard list" by calling up to the base class.

See email discussion at:

http://mail.python.org/pipermail/python-ideas/2011-May/010319.html

----------
messages: 136726
nosy: benjamin.peterson, michael.foord
priority: normal
severity: normal
status: open
title: object.__dir__
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 12:07:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 10:07:26 +0000
Subject: [New-bugs-announce] [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

Looks like either packaging or test_packaging forgets to clean up after itself:

results for 9a16fa0c9548 on branch "default"
--------------------------------------------

test_packaging leaked [193, 193, 193] references, sum=579

----------
assignee: tarek
components: Distutils2, Tests
messages: 136729
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging reference leak
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 13:44:13 2011
From: report at bugs.python.org (Carl Crowder)
Date: Tue, 24 May 2011 11:44:13 +0000
Subject: [New-bugs-announce] [issue12168] SysLogHandler incorrectly appents
	\000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>


New submission from Carl Crowder :

logging.handlers.SysLogHandler contains this class variable and comment:

    # curious: when talking to the unix-domain '/dev/log' socket, a
    # zero-terminator seems to be required.  this string is placed
    # into a class variable so that it can be overridden if
    # necessary.
    log_format_string = '<%d>%s\000'

And separately, in emit:

    msg = self.format(record) + '\000'

The assumption here is that a null character must be appended to delimit the syslog message. In RFC5424, there is no mention of a message delimiter, and in fact the previous syslog RFC, RFC3164, specifically states:

>  The MSG part will fill the remainder of the syslog packet.  This will usually contain some additional information of the process that generated the message, and then the text of the message.  There is no ending delimiter to this part.

I believe this comment and behaviour is due to an older version of syslogd. Checking the manpage for an older version of rsyslog for example includes this piece of information [1]:

> There is probably one important consideration when installing rsyslogd. It is dependent on proper formatting of messages by the syslog function. The functioning of the syslog function in the shared libraries changed somewhere in the region of libc.so.4.[2-4].n.   The specific change was to null-terminate the message before transmitting it to the /dev/log socket. Proper functioning of this  version of rsyslogd is dependent on null-termination of the message.

I'm running Ubuntu 11.04 with rsyslogd 4.6.4 (that is, the standard version). In the manpage for this version of rsyslogd, there is no reference to null-terminators. Removing "+ '\000'" from the SysLogHandler results in messages still being received correctly.

Problem behaviour:
1) When running any RFC compliant syslog receiver that handles syslog messages, such as flume[2], this null character is not stripped as it is not expected to be present. Current versions of syslog cope because previously they assumed it existed.
2) The log_format_string class variable is not actually used anywhere, so it cannot be overridden usefully.

Removing the null terminator will cause older typical versions of syslogd to fail to receive messages, however including it causes any normal receiver that does not implement the non-standard behaviour to receive an additional unwanted null.

Suggestion for a fix is either to properly use the log_format_string class variable, or to allow an optional "append_null" argument to the SysLogHandler constructor. By default, this should be True, as it will continue to work with the main use case, which is unix syslog demons. Having the option will allow other use cases to also use the SysLogHandler.

[1] http://manpages.ubuntu.com/manpages/hardy/man8/rsyslogd.8.html#contenttoc8
[2] http://www.cloudera.com/blog/category/flume/

----------
components: Library (Lib)
messages: 136743
nosy: Carl.Crowder
priority: normal
severity: normal
status: open
title: SysLogHandler incorrectly appents \000 to messages
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 18:48:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:48:45 +0000
Subject: [New-bugs-announce] [issue12169] Factor out common code for d2
	commands register, upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

These three commands have different code to do POST requests, using rllib or httplib.  This already made us do more work to fix bugs and to port the code.  upload_docs has a top-level function for multipart encoding; this should be moved to a common module, cleaned up and used by all our code that needs a POST.

----------
assignee: tarek
components: Distutils2
messages: 136770
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Factor out common code for d2 commands register, upload and upload_docs
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 21:49:10 2011
From: report at bugs.python.org (Max)
Date: Tue, 24 May 2011 19:49:10 +0000
Subject: [New-bugs-announce] [issue12170] Bytes objects do not accept
	integers to many functions
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>


New submission from Max :

Bytes objects when indexed provide integers, but do not accept them to many functions, making them inconsistent with other sequences.

Basic example:
>>> test = b'012'
>>> n = test[1]
>>> n
49
>>> n in test
True
>>> test.index(n)
TypeError: expected an object with the buffer interface.

It is certainly unusual for n to be in the sequence, but not to be able to find it.  I would expect the result to be 1.  This set of commands with list, strings, tuples, but not bytes objects.

I suspect, from issue #10616, that all the following functions would be affected:
"bytes methods: partition, rpartition, find, index, rfind, rindex, count, translate, replace, startswith, endswith"

It would make more sense to me that instead of only supporting buffer interface objects, they also accept a single integer, and treat it as if it were provided a length-1 bytes object.

The use case I came across this problem was something like this:

Given seq1 and seq2, sequences of the same type:
[seq1.index(x) for x in seq2]

This works for strings, lists, tuples, but not bytes.

----------
components: Interpreter Core
messages: 136786
nosy: max-alleged
priority: normal
severity: normal
status: open
title: Bytes objects do not accept integers to many functions
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 24 23:30:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 21:30:10 +0000
Subject: [New-bugs-announce] [issue12171] Reset method of the incremental
	encoders of CJK codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>


New submission from STINNER Victor :

HZ and ISO-2022 family codecs may generate an escape sequence at the end of a stream. For example, the HZ codec uses '~{' to switchs from ASCII to GB2312, and '~}' resets the encoding to ASCII. At the end of a stream, the encoding should be reset to ASCII. '\u804a'.encode('hz') returns b'~{AD~}', which is correct.

Incremental encoders generate also the escape sequence if the last call to encode() is done using final=True.

It would be nice to be able to generate the escape sequence without the final flag, because sometimes you don't know which call to encode() is the last one. For example if you write data in a file, you may want to write the escape sequence at the end when the file is closed.

I propose to change the reset() method of incremental encoders: they may return a bytes object to close the stream. For example, the reset() method of the HZ codec may returns b'~}' if the encoder was using GB2312 (if it emited previously b'~{').

So the 3 following code should returns b'~{AD~}':

 * '\u804a'.encode('hz')
 * encoder = codecs.lookup('hz').incrementalencoder(); encoder.encode('\u804a', final=True)
 * encoder = codecs.lookup('hz').incrementalencoder(); encoder.encode('\u804a') + encoder.reset()

For backward compatibility, reset() returns None if there is no pending buffer or any escape sequence.

--

This proposition comes from #12000: Armin Rigo noticed that the reset method of the incremental encoders of CJK codecs calls the decoder reset function. Extract of Modules/cjkcodecs/multibytecodec.c:

static PyObject *
mbiencoder_reset(MultibyteIncrementalEncoderObject *self)
{
    if (self->codec->decreset != NULL &&
        self->codec->decreset(&self->state, self->codec->config) != 0)
        return NULL;
    self->pendingsize = 0;

    Py_RETURN_NONE;
}

I suppose that codec->encreset() is not called here because we need an output buffer, and there is no such buffer. Or it's just a copy-paste failure.

--

I am not sure that it is really useful to emit b'~}' at the end of a HZ stream, but the change is simple and if you don't care of b'~}': just ignore the result of reset() (as everybody does today, so it doesn't hurt).

--

Only HZ and ISO-2022 encodings implement the reset method of their incremental encoder. For example, encodings of the UTF family don't need to emit bytes at reset.

For the maximum length of reset() output: HZ may generates 2 bytes (b'~}') and ISO-2022 may generates 4 bytes (b'\x0F' + b'\x1F(B').

--

See also the issue #12100.

----------
components: Library (Lib), Unicode
files: cjk_reset_result.patch
keywords: patch
messages: 136794
nosy: arigo, gz, haypo, hyeshik.chang, lemburg
priority: normal
severity: normal
status: open
title: Reset method of the incremental encoders of CJK codecs calls the decoder reset function
versions: Python 3.3
Added file: http://bugs.python.org/file22096/cjk_reset_result.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 06:32:40 2011
From: report at bugs.python.org (Kevin)
Date: Wed, 25 May 2011 04:32:40 +0000
Subject: [New-bugs-announce] [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>


New submission from Kevin :

Similar to bug issue 11431, my IDLE crashes (OS 10.6.7) when using F5, but works fine or better when I click run module. However, unlike 11431, I have downloaded, and I believe, correctly installed ActiveTcl 8.5.

Similar to Ned's suggestions in issue: 11431, here are the first two lines when I launch my shell:

Python 3.2 (r32:88452, Feb 20 2011, 11:12:31) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin

Also, here is the response when I run Ned's suggested commands per issue number 11431. First Ned's commands:

import _tkinter, subprocess
print(subprocess.getoutput("otool -L " + _tkinter.__file__))
print(subprocess.getoutput("ls -l /Library/Frameworks/Tk.framework/Versions"))

The responses:

/bin/sh: otool: command not found

total 8
drwxr-xr-x  8 root  admin  272 Feb  4 01:52 8.5
lrwxr-xr-x  1 root  admin    3 May 23 17:45 Current -> 8.5

Also, if it may help, when I click on the ActiveTCL application icon, a comodo dragon icon application named tclvfse, I get a fatal error message of which I took the following screen shot, attached.

My guess is that ActiveTcl 8.5 is partially installed, or flat out incorrectly installed.

Any ideas? Thanks for your help/time.

Kevin

----------
components: IDLE
files: Screen shot 2011-05-23 at 5.56.19 PM.png
messages: 136826
nosy: Kevin Ness
priority: normal
severity: normal
status: open
title: IDLE crashes when I use F5 to run
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file22102/Screen shot 2011-05-23 at 5.56.19 PM.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 09:10:31 2011
From: report at bugs.python.org (Chris Angelico)
Date: Wed, 25 May 2011 07:10:31 +0000
Subject: [New-bugs-announce] [issue12173] PyImport_ImportModuleLevel doesn't
	have 'const' on its	argument
In-Reply-To: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>
Message-ID: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>


New submission from Chris Angelico :

An anomaly in the argument types of similar functions: PyImport_ImportModuleLevel takes char *, while the related functions PyImport_AddModule, PyImport_ImportModule, and PyImport_ImportModuleNoBlock all take const char *. This made a nuisance of itself for me when I tried to compile my code against Python.h (embedding Python). Attached is a relatively trivial patch to add const. Should not impact existing code, as the compiler will happily pass a char* to a const char* (just not the other way).

----------
components: Interpreter Core
files: importconst.patch
keywords: patch
messages: 136829
nosy: Rosuav
priority: normal
severity: normal
status: open
title: PyImport_ImportModuleLevel doesn't have 'const' on its argument
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22103/importconst.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 13:54:07 2011
From: report at bugs.python.org (JJeffries)
Date: Wed, 25 May 2011 11:54:07 +0000
Subject: [New-bugs-announce] [issue12174] Multiprocessing logging levels
	unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>


New submission from JJeffries :

It is unclear without reference to the logging module where the multiprocessing logging levels fit in the normal logging provided by the logging module, even though it says above the table

"The table below illustrates where theses fit in the
normal level hierarchy.

+----------------+----------------+
| Level          | Numeric value  |
+================+================+
| ``SUBWARNING`` | 25             |
+----------------+----------------+
| ``SUBDEBUG``   | 5              |
+----------------+----------------+"

I propose adding further values from the logging module for clarification.

----------
assignee: docs at python
components: Documentation
messages: 136839
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing logging levels unclear
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 14:14:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 12:14:00 +0000
Subject: [New-bugs-announce] [issue12175] FileIO.readall() read the file
	position and size at each	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>


New submission from STINNER Victor :

FileIO.readall() reads the file position and size before each call to read(), to adjust the buffer size.

Moreover FileIO.readall() calls lseek() on Windows: it should use _lseeki64() instead, to handle correctly file bigger than 2 GB (or maybe 4 GB? I don't know).

Attached patch fixes both problems.

--

BufferedReader.read() calls FileIO.read() until FileIO.read() returns an empty byte string. Why not calling FileIO.read() only once?

----------
components: IO
files: fileio_readall.patch
keywords: patch
messages: 136840
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: FileIO.readall() read the file position and size at each read
versions: Python 3.3
Added file: http://bugs.python.org/file22105/fileio_readall.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 18:17:58 2011
From: report at bugs.python.org (Pavel Bogdanovic)
Date: Wed, 25 May 2011 16:17:58 +0000
Subject: [New-bugs-announce] [issue12176] Compiling Python 2.7.1 on Ubuntu
	11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>


New submission from Pavel Bogdanovic :

Compiling of Python does end with an error.

It has to do with changes in Ubuntu: https://wiki.ubuntu.com/MultiarchSpec

I added one line after python's setup.py after line 351
 add_dir_to_list(self.compiler.library_dirs, '/usr/lib/i386-linux-gnu')

and it compiled.
It might be archeticture-dependent. Perhaps it should account
(/lib/i386-linux-gnu
   /lib/x86_64-linux-gnu
   /usr/lib/i386-linux-gnu
   /usr/lib/x86_64-linux-gnu)

----------
components: Build
files: patch_setup.py
messages: 136862
nosy: Pavel.Bogdanovic
priority: normal
severity: normal
status: open
title: Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22111/patch_setup.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 20:04:25 2011
From: report at bugs.python.org (EungJun Yi)
Date: Wed, 25 May 2011 18:04:25 +0000
Subject: [New-bugs-announce] [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>


New submission from EungJun Yi :

re.match raises MemoryError when trying to match r'()+?1' to 'a1', as shown below.

~$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match(r'()+?1', 'a1')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
MemoryError
>>>

~$ python3
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match(r'()+?1', 'a1')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.2/re.py", line 153, in match
    return _compile(pattern, flags).match(string)
MemoryError
>>>

----------
components: Regular Expressions
messages: 136880
nosy: EungJun.Yi
priority: normal
severity: normal
status: open
title: re.match raises MemoryError
type: resource usage
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 20:27:10 2011
From: report at bugs.python.org (Eric Breck)
Date: Wed, 25 May 2011 18:27:10 +0000
Subject: [New-bugs-announce] [issue12178] csv writer doesn't escape
	escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>


New submission from Eric Breck :

Consider the attached two files.  A reader and writer with the same dialect parameters (escapechar \ quotechar " doublequote False) read, then write a CSV cell that looks like "C\\".  It's written "C\".  The problem is, when doublequote=False, the escapechar isn't used to escape itself, and the writer writes something that in the same dialect would be understood differently (\" isn't \ then end of string, it's an escaped quotechar within the string).

Execute python err.py first.csv to see.

----------
components: None
files: pybug.zip
messages: 136881
nosy: ebreck
priority: normal
severity: normal
status: open
title: csv writer doesn't escape escapechar
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22112/pybug.zip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 21:58:14 2011
From: report at bugs.python.org (Sye van der Veen)
Date: Wed, 25 May 2011 19:58:14 +0000
Subject: [New-bugs-announce] [issue12179] Race condition using
	PyGILState_Ensure on a new thread
In-Reply-To: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>
Message-ID: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>


New submission from Sye van der Veen :

I'm wanting to call PyThreadState_SetAsyncExc from a function registered with SetConsoleCtrlHandler.  To do so, I need to call PyGILState_Ensure, which asserts that Python is initialized, so I need to check for that.  However, I noticed a race condition with the code:

  if( Py_IsInitialized( ) ) {
    // XXX What if another thread calls Py_Finalize here?
    gstate = PyGILState_Ensure( );
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
    PyGILState_Release( gstate );
  }

What I need is to be able to hold the GIL around the entire block of code, potentially before Py_Initialize is called for the first time.  Now, 3.2 deprecated PyEval_AcquireLock, and PyEval_InitThreads can no longer be called before Py_Initialize.  Thankfully, I'm on 2.6.4, so I was able to write this code:

  PyEval_AcquireLock( );
  if( Py_IsInitialized( ) ) {
    gstate = PyGILState_Ensure( );
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
    PyGILState_Release( gstate );
  }
  PyEval_ReleaseLock( );

The problem in 2.6.4 is that PyGILState_Ensure deadlocks because the GIL is already held, so that doesn't solve my problem.  (Incidentally, the PyGILState_Ensure docs say it works "regardless of the current state of the GIL", which is incorrect.)

The 3.2 docs say to use PyEval_AcquireThread or PyEval_RestoreThread, which both require an existing PyThreadState.  To get that, I would need to call PyThreadState_New, which needs a PyInterpreterState.  To get _that_ I could use PyInterpreterState_Head, since I know I only use one interpreter.  Now I'm getting into "advanced debugger" territory, but it's no use anyway; it's possible that Py_Finalize could sneak in between the time I get this interpreter and when I acquire the GIL, causing me to access a free'd interpreter.

I believe the best fix for this would be to have a version of PyGILState_Ensure that works even when Python is not initialized.  It would not be able to create a thread, and thus I would not expect to be able to call any Python API, but it would always ensure the GIL is acquired.  This _may_ have to be a new "PyGILState_EnsureEx" function, because existing code expects PyGILState_Ensure to always allow them to call the Python API.  The resulting code would be:

  gstate = PyGILState_EnsureEx( );
  if( Py_IsInitialized( ) ) {
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
  }
  PyGILState_Release( gstate );

This would require that Py_Initialize itself acquires the GIL.

The above problem was found on 2.6.4, but I've consulted the 3.2 docs and 3.3 code (via the online source) and it looks like the situation would be exactly the same.  In the meantime, I'm going to stick with the first piece of code and hope nobody hits CTRL-BREAK during program clean-up.

----------
components: Interpreter Core
messages: 136888
nosy: syeberman
priority: normal
severity: normal
status: open
title: Race condition using PyGILState_Ensure on a new thread
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 22:09:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 20:09:31 +0000
Subject: [New-bugs-announce] [issue12180] test_packaging: failures
	--without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>


New submission from Stefan Krah :

There are still a couple of issues on the Fedora buildbot. Most of
them are caused by the absence of threading.

----------
components: Tests
keywords: buildbot
messages: 136890
nosy: skrah, tarek
priority: normal
severity: normal
status: open
title: test_packaging: failures --without-threads
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed May 25 22:20:02 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 25 May 2011 20:20:02 +0000
Subject: [New-bugs-announce] [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>


New submission from rpointel :

Hello,

on OpenBSD (arch: sparc64), when I run the regress tests, I have a SIGBUS error during the test_kqueue.py:

(gdb) run /tmp/test_kqueue.py
Starting program: /usr/local/bin/python2.7 /tmp/test_kqueue.py
testPair (__main__.TestKQueue) ...
Program received signal SIGBUS, Bus error.
PyMember_GetOne (addr=0x21007b72c "", l=0x211d2e9c8) at Python/structmember.c:128
128             v = PyLong_FromLongLong(*(PY_LONG_LONG *)addr);

I compiled Python 2.7.1 with debug symbols to help you, attached file is the gdb output (backtrace).

Don't hesitate to ask me if you need information.

Thanks.

----------
components: Tests
files: python2.7.1_sigbus_sparc64
messages: 136893
nosy: rpointel
priority: normal
severity: normal
status: open
title: SIGBUS error on OpenBSD (sparc64)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file22115/python2.7.1_sigbus_sparc64

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 01:55:04 2011
From: report at bugs.python.org (Ralf W. Grosse-Kunstleve)
Date: Wed, 25 May 2011 23:55:04 +0000
Subject: [New-bugs-announce] [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>


New submission from Ralf W. Grosse-Kunstleve :

The pydoc.HTMLRepr.multicolumn() method fails when using the Python command-line option -Qnew.
The attached patch inserts two slashes for floor division. (I think the same change was applied to Python 3 already.)

----------
components: Library (Lib)
files: pydoc_patch
messages: 136920
nosy: rwgk
priority: normal
severity: normal
status: open
title: pydoc.py integer division problem
versions: Python 2.7
Added file: http://bugs.python.org/file22120/pydoc_patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 06:42:00 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 26 May 2011 04:42:00 +0000
Subject: [New-bugs-announce] [issue12183] Python does not support lutime()
	function
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>


New submission from ???? ????????? :

see
http://www.linuxquestions.org/questions/programming-9/utime-on-a-symbolic-link-743085/:
----------
Hello,
The API utime() is not available for symbolic links.
However, with kernel 2.6.22 lutimes() API allowed setting times on atime and mtime on symbolic links.
----------

Neither python 2.7 nor 3.4 support lutime() syscall.
So imlpementation of shutil.copy2() and shutil.copystat() under question for symlinks. Also it's not clear in documentation behaviour of these functions on symlinks.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 136928
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: Python does not support lutime() function
type: feature request
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 07:19:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 26 May 2011 05:19:53 +0000
Subject: [New-bugs-announce] [issue12184] socketserver.ForkingMixin
	collect_children routine needs	to collect only it's children
In-Reply-To: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>
Message-ID: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>


New submission from Senthil Kumaran :

socketserver.ForkingMixin class has a collect_children method, that waits for the children to exit.
But, that waits for any child process and not just the ones spawned the socketserver alone.

            try:
                pid, status = os.waitpid(0, 0)
            except os.error:
                pid = None

This is performance lag and can be improved. The collect_children can only wait/collect it's own children.

----------
messages: 136931
nosy: orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: socketserver.ForkingMixin collect_children routine needs to collect only it's children
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 13:59:23 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 26 May 2011 11:59:23 +0000
Subject: [New-bugs-announce] [issue12185] Decimal documentation lists
	"first" and "second"	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>


New submission from Eric V. Smith :

http://docs.python.org/library/decimal.html

In 9.4.2, "Decimal objects", some of the methods mention the first and second parameters, when really it should be "self" and the argument, usually named "other" and sometimes something more specific. These include:

compare_total
copy_sign
next_toward
quantize (argument is exp)
rotate
scaleb
shift

It looks this is left over from where the same-named functions are described in the "Context objects" section.

----------
assignee: docs at python
components: Documentation
messages: 136947
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 14:20:02 2011
From: report at bugs.python.org (stefanholek)
Date: Thu, 26 May 2011 12:20:02 +0000
Subject: [New-bugs-announce] [issue12186] readline.replace_history_item
	still leaks memory
In-Reply-To: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za>
Message-ID: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za>


New submission from stefanholek :

This is a continuation of issue #9450.

The 'data' element of a history entry may point to an undo list for the entry. When freeing the entry the associated undo list must be freed as well, and 'free(data)' alone does not cut it. I have not found any other use of the 'data' element in all of GNU Readline, so it is safe to assume it is either NULL or an undo list.

diff --git a/rl/readline.c b/rl/readline.c
index 26ac1e2..c8efd5b 100644
--- a/rl/readline.c
+++ b/rl/readline.c
@@ -541,8 +541,18 @@
 static void
 _py_free_history_entry(HIST_ENTRY *entry)
 {
-       histdata_t data = free_history_entry(entry);
-       free(data);
+       UNDO_LIST *undo_list;
+       UNDO_LIST *release;
+
+       /* A history entry may have an undo_list attached */
+       undo_list = (UNDO_LIST *)free_history_entry(entry);
+       while (undo_list) {
+               release = undo_list;
+               undo_list = undo_list->next;
+               if (release->what == UNDO_DELETE)
+                       free(release->text);
+               free(release);
+       }
 }

----------
components: Library (Lib)
messages: 136951
nosy: stefanholek
priority: normal
severity: normal
status: open
title: readline.replace_history_item still leaks memory
type: resource usage

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 15:32:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 13:32:21 +0000
Subject: [New-bugs-announce] [issue12187] subprocess.wait() with a timeout
	uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Polling should be avoided when it's possible. For subprocess.wait(), we can do something with signals (SIGCHLD and/or SIGCLD).

sigtimedwait() can be used to wait a the "a child process terminated" with a timeout, but not wait a specific process (so we may use a loop). sigtimedwait() doesn't call the signal handler, and so it changes the behaviour if the parent process has a signal handler for SIGCHLD/SIGCLD.

If sigtimedwait() is not available, we may use a signal handler. For example, we can use the "wakeup fd" tool of the signal module. Problem: the parent program may already have such handler / use "wakeup fd". We should at least restore the previous signal handler when we are done.

----------
assignee: pitrou
components: Library (Lib)
messages: 136958
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: subprocess.wait() with a timeout uses polling on POSIX
type: performance
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 20:19:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2011 18:19:32 +0000
Subject: [New-bugs-announce] [issue12188] PEP 7,
	C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

In response to a discussion of a patch removing 'useless' post-increments, (which issue has apparently come up before)
Guido posted
"> Sorry to butt in here, but I agree with Eric that it was better
> before. There is a common idiom, *pointer++ =, and
> whenever you see that you know that you are appending something to an
> output buffer. Perhaps the most important idea here is that this
> maintains the *invariant* "pointer points just after the last thing in
> the buffer". Always maintaining the invariant is better than trying to
> micro-optimize things so as to avoid updating dead values. The
> compiler is better at that."

A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug.

----------
assignee: docs at python
components: Documentation
messages: 136991
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: PEP 7, C style: add ++ policy and explanation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 20:28:25 2011
From: report at bugs.python.org (Feth AREZKI)
Date: Thu, 26 May 2011 18:28:25 +0000
Subject: [New-bugs-announce] [issue12189] Python 2.6.6 fails to compile a
	source whereas pycompile	1.0 succeeds
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>


New submission from Feth AREZKI :

At least on Linux debian sid, it seems that Python 2.6.6 compile builtin does not like the empty line with only '\r\n' in it.

The following doctest story runs with the attached CRLF'ed file:
"""
>>> fd = open('test_win32.py', 'r')
>>> compile(fd.read(), 'test_win32.py', 'exec')
Traceback (most recent call last):
  File "/usr/lib/python2.6/doctest.py", line 1253, in __run
     compileflags, 1) in test.globs
  File "", line 1, in 
     compile(fd.read(), 'test_win32.py', 'exec')
  File "test_win32.py", line 3
        ^
SyntaxError: invalid syntax
"""

With Python 2.7, everything seems fine.

----------
components: Interpreter Core
files: test_win32.py
messages: 136992
nosy: feth
priority: normal
severity: normal
status: open
title: Python 2.6.6 fails to compile a source whereas pycompile 1.0 succeeds
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file22130/test_win32.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 21:30:13 2011
From: report at bugs.python.org (Mike Solomon)
Date: Thu, 26 May 2011 19:30:13 +0000
Subject: [New-bugs-announce] [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>


New submission from Mike Solomon :

I work on a large app and we noticed that a surprising portion of our heap was filenames embedded the the bytecode.

This one-line patch to intern filenames reduces our on-disk size about ~15% and brings down our heap and in-memory object count by a similar percentage.

----------
components: Interpreter Core
files: codegen.patch
keywords: patch
messages: 136997
nosy: Mike.Solomon
priority: normal
severity: normal
status: open
title: intern filenames in bytecode
type: performance
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22131/codegen.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 22:14:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 26 May 2011 20:14:10 +0000
Subject: [New-bugs-announce] [issue12191] Shutil - add chown() in order to
	allow to use user and	group name (and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Hi, following up the discussion on http://mail.python.org/pipermail/python-dev/2011-May/111642.html here'a patch to introduce shutil.chown() along with doc, tests and a change in os doc to link to the new function (I also took the occasion to rewrap os.chown() doc text). As of now only the one-file function is implemented, let's see at a later time what's about for a recursive one.

The patch was prepared against default, but it probably makes sense to backport it to 2.7?

Any comment/suggestion is welcome!

----------
assignee: sandro.tosi
components: Library (Lib)
files: shutil_chown-default.patch
keywords: patch
messages: 137004
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Shutil - add chown() in order to allow to use user and group name (and not only uid/gid)
type: feature request
Added file: http://bugs.python.org/file22132/shutil_chown-default.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu May 26 23:33:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2011 21:33:10 +0000
Subject: [New-bugs-announce] [issue12192] Doc that collection mutation
	methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

BACKGROUND
One of most common recurring topics on python-list (perhaps monthly) is newbies tripping over a mutation method returning None when they expect the collection. Today's example: "Puzzled by list-appending behavior".
An excerpt from the responses: 

"On 5/26/2011 11:58 AM, MRAB wrote:
> On 26/05/2011 06:17, Chris Rebert wrote:

>> list.remove(), list.sort(), and list.extend() similarly return None
>> rather than the now-modified list.

> I'd just like to point out that it's a convention, not a rigid rule.
> Sometimes it's not followed, for example, dict.setdefault."

In Python 1, I believe it was true that all mutation methods of mutable builtin collections (ie, lists -- I do not think dicts had any and sets did not exist yet) returned None. With the introduction of list.pop, the return-None rule was 'broken', though the meme continues. However, the flip side of that rule, do-not-return-the-collection, continues to be true. And the return_None rule was not really broken, but broadened to "return None or an item from the collection". I believe this should be better documented than it is now.

PROPOSALS

1. State the general rule.

A. Tutorial: At the top of chapter 5, just after "This chapter describes some things you?ve learned about already in more detail, and adds some new things as well.", add something like

"For lists, sets, and dicts, methods that change the contents or order never return the instance. Instead, they return an item from the instance or, more commonly, None."

B. Library Manual: Near the top of 4. Built-in Types, after "The principal built-in types are numerics, sequences, mappings, classes, instances and exceptions.", add something like

"Some collection classes are mutable. The methods that add, subtract, or rearrange their members never return the collection instance itself but instead return an item from the instance or None."

Comment: This rule applies to special methods like __getitem__ and __setitem__. 'lis.append(item)' is equivalent to lis.__setitem__(len(lis):len(lis), item), so it should not be so surprising that it has the same return.

2. Document None returns explicitly.

They are currently documented implicitly, by absence.

A. Docstrings: Compare the relevant parts of the output from 'help(list.append)' and 'help(list.pop)'

   L.append(object) -- append object to end
   L.pop([index]) -> item -- remove and return item at index 

Add ' -> None' to specify return for .append.
   L.append(object) -> None -- append object to end

I expect experienced Python programmers may object that this puts too much emphasis on the unimportant null return, but it is important that Python programmers know about it and experience shows that many newbies *need* that emphasis.

B. Doc entries: Essentially same suggestion -- add 'Return None.' to appropriate entries in tutorial chapter 5. For library manual, possibly add footnote '(9) Returns None' to the method table in 4.6.4. Mutable Sequence Types. For sets and dicts, add 'and return None' to appropriate entries.

----------
assignee: docs at python
components: Documentation
messages: 137009
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Doc that collection mutation methods return item or None
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 00:53:40 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Thu, 26 May 2011 22:53:40 +0000
Subject: [New-bugs-announce] [issue12193] Argparse does not work together
	with gettext and	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>


New submission from Thorsten Kampe :

Error with argparse and UTF-8 non-ASCII help text on Linux (works on Windows and on Linux with optparse):

% LANG=de_De ./script.py --help
Traceback (most recent call last):
  File "./script.py", line 26, in 
    args = cmdlineparser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python2.7/argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python2.7/argparse.py", line 993, in __call__
    parser.print_help()
  File "/usr/lib/python2.7/argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python2.7/argparse.py", line 2317, in _print_message
    file.write(message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 91: ordinal not in range(128)

----------
components: Unicode
files: script.py
messages: 137013
nosy: thorsten
priority: normal
severity: normal
status: open
title: Argparse does not work together with gettext and non-ASCII help text
versions: Python 2.7
Added file: http://bugs.python.org/file22138/script.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 08:31:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 May 2011 06:31:41 +0000
Subject: [New-bugs-announce] [issue12194] Fix LDFLAGS on Ubuntu 11.04+
In-Reply-To: <1306477901.19.0.823016401288.issue12194@psf.upfronthosting.co.za>
Message-ID: <1306477901.19.0.823016401288.issue12194@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

A complete build on Ubuntu currently requires fiddling with LDFLAGS before invoking configure (otherwise the build process fails to find the necessary pieces to build some modules):
http://www.technobits.net/articles/8919/christian-heimes-how-to-compile-python-on-ubuntu-1104/

It would be nice if this just worked from a fresh checkout when the appropriate dev packages have been installed.

----------
messages: 137027
nosy: barry, christian.heimes, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix LDFLAGS on Ubuntu 11.04+
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 14:22:13 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 27 May 2011 12:22:13 +0000
Subject: [New-bugs-announce] [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>


New submission from JJeffries :

There are very few pages relating to annotations in the documentation. Making it very unclear how they work and what they could be used for other than the original PEP.

----------
assignee: docs at python
components: Documentation
messages: 137047
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: Little documentation of annotations
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 16:11:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 14:11:01 +0000
Subject: [New-bugs-announce] [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

pipe2() makes it possible to create a pipe O_CLOEXEC or O_NONBLOCK atomically, which can be quite useful, especially in multi-threaded code. It would be nice to expose it in the os module.
Patch attached.

----------
components: Library (Lib)
files: posix_pipe2.diff
keywords: needs review, patch
messages: 137054
nosy: charles-francois.natali, haypo, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: add pipe2() to the os module
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file22147/posix_pipe2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 20:06:49 2011
From: report at bugs.python.org (David Siroky)
Date: Fri, 27 May 2011 18:06:49 +0000
Subject: [New-bugs-announce] [issue12197] non-blocking SSL write in Windows
	sends large data but	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>


New submission from David Siroky :

Trying to send large bulk of data in MS Windows via non-blocking SSLSocket raises an exception but part of the data is delivered.

E.g.

ssl_socket.write(b"a" * 200000)

raises

ssl.SSLError: [Errno 3] _ssl.c:1126: The operation did not complete (write)

There is no way to get the sent bytes count which is essential in non-blocking communication.

ssl_socket.send() returns 0. This should be unified with posix behavior.

----------
components: Extension Modules, Windows
files: ssl_sock_test.py
messages: 137092
nosy: dsiroky
priority: normal
severity: normal
status: open
title: non-blocking SSL write in Windows sends large data but raises exception
type: behavior
versions: Python 2.6, Python 3.2
Added file: http://bugs.python.org/file22157/ssl_sock_test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 20:44:26 2011
From: report at bugs.python.org (Greg Steuck)
Date: Fri, 27 May 2011 18:44:26 +0000
Subject: [New-bugs-announce] [issue12198] zipfile.py:1047:
	DeprecationWarning: 'H' format requires	0 <= number <= 65535
In-Reply-To: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>
Message-ID: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>


New submission from Greg Steuck :

zipfile.py displays warning when trying to write files timestamped before 1980.

% cat /tmp/a.py
import zipfile
import os

z = zipfile.ZipFile('/tmp/a.zip', 'w')
open("/tmp/a", "w")
os.utime("/tmp/a", (0,0))
z.write("/tmp/a", "a")
% python -V
Python 2.6.5
% uname -mo
x86_64 GNU/Linux
% uname -mor
2.6.32-gg426-generic x86_64 GNU/Linux
% python /tmp/a.py
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: struct integer overflow masking is deprecated
 self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535
 self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: struct integer overflow masking is deprecated
 self.close()
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: 'H' format requires 0 <= number <= 65535
 self.close()

Similar to, but different from http://bugs.python.org/issue1526.

Amaury Forgeot d'Arc says:

The ZIP file format is unable to store dates before 1980.  With version 3.2, your script even raises an exception.  Please file this in a different issue.

----------
components: Library (Lib)
messages: 137093
nosy: gnezdo
priority: normal
severity: normal
status: open
title: zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri May 27 21:55:23 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2011 19:55:23 +0000
Subject: [New-bugs-announce] [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>


New submission from Benjamin Peterson :

You can write them as one compound statement in Python, so there's no point in having two ast classes.

----------
components: Interpreter Core
files: try.patch
keywords: patch
messages: 137097
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: Unify TryExcept and TryFinally
versions: Python 3.3
Added file: http://bugs.python.org/file22158/try.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 28 04:08:47 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 28 May 2011 02:08:47 +0000
Subject: [New-bugs-announce] [issue12200] bdist_wininst install_script not
	run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>


New submission from Mark Hammond :

Probably in all versions, but certainly in 2.7.

If you create an installer with bdist_wininst and specify an install_script, that script is not run on uninstallation.

See attached test case: setup.py specifies an install_script which just appends argv to %TEMP%/uninstall-test.txt.

* Create the installer with "python setup.py bdist_wininst"
* Execute the installer (ie, "dist\hello-0.1.win32.exe")
* Check %TEMP%/uninstall-test.txt - it should have 1 line:
['o:\\src\\python-2.6\\Scripts\\hello-install.py', '-install']
* Uninstall the package.
* Check %TEMP%/uninstall-test.txt - it *should* have a new line reflecting the uninstall.  Instead it is unchanged.

To get more info:
* Reinstall the package.
* Manually uninstall using the cmdline (with adjusted paths)
C:\> "c:\python26\Removehello.exe" -u "c:\python26\hello-wininst.log" > %TEMP%\delme.out 2>&1

Check the contents of %TEMP%\delme.out - you will see:
*** Could not load Python ****** Could not run installation script ***

Digging into the source code of install.c - the problem is that although the Python DLL name is parsed from the log file, this isn't reflected in the global variables python_dir or pythondll - so they remain empty strings and attempting to load the empty string as Python causes the error messages.

----------
assignee: tarek
components: Distutils
files: setup.py
messages: 137105
nosy: eric.araujo, mhammond, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst install_script not run on uninstall
type: behavior
Added file: http://bugs.python.org/file22160/setup.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 28 15:53:46 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 13:53:46 +0000
Subject: [New-bugs-announce] [issue12201] Returning FILETIME is unsupported
	in	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>
Message-ID: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon :

In _msi.c, summary_getproperty() and summary_setproperty() raise an exception if the type being set/got is VT_FILETIME. 

This issue is to track adding support for (or declining to support) FILETIMEs in msilib.SummaryInformation.GetProperty()/SetProperty().

I have included a patch which adds this support (with some basic tests).
Should this function accept/return datetime.datetime - or a timestamp (both require conversion anyway). I have used datetimes in my patch.

----------
components: Windows
files: add_FILETIME_support_to_summary_info.patch
keywords: patch
messages: 137130
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Returning FILETIME is unsupported in msilib.SummaryInformation.GetProperty()
versions: Python 3.2
Added file: http://bugs.python.org/file22163/add_FILETIME_support_to_summary_info.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat May 28 15:59:36 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 13:59:36 +0000
Subject: [New-bugs-announce] [issue12202] Check status returns
	in	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za>
Message-ID: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon :

Per Eric V. Smith's comment issue1104 (msg134976) the return value of the call MsiSummaryInfoGetProperty() in summary_getproperty() (pc\_msi.c) is only checked for the error return ERROR_MORE_DATA.

Other error values should be checked.

----------
messages: 137132
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Check status returns in msilib.SummaryInformation.GetProperty()

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 02:41:34 2011
From: report at bugs.python.org (Joesph)
Date: Sun, 29 May 2011 00:41:34 +0000
Subject: [New-bugs-announce] [issue12203] isinstance not functioning as
	documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>


New submission from Joesph :

#Example:
class a(object):
    pass

b = a()

print([isinstance(a,object), isinstance(b,object)])

'''
outputs: [True, True]
expected: [False, True]

As class a is not instantiated it should return false. As-is isinstance is just a synonym for issubclass.
'''

----------
components: Interpreter Core
messages: 137160
nosy: someone3x7
priority: normal
severity: normal
status: open
title: isinstance not functioning as documented
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 06:49:20 2011
From: report at bugs.python.org (py.user)
Date: Sun, 29 May 2011 04:49:20 +0000
Subject: [New-bugs-announce] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>


New submission from py.user :

specification

1)
str.upper()?

    Return a copy of the string converted to uppercase.

2)
str.isupper()?

    Return true if all cased characters in the string are uppercase and there is at least one cased character, false otherwise. Cased characters are those with general category property being one of ?Lu?, ?Ll?, or ?Lt? and uppercase characters are those with general category property ?Lu?.

>>> '\u1ff3'
'?'
>>> '\u1ff3'.islower()
True
>>> '\u1ff3'.upper()
'?'
>>> '\u1ff3'.upper().isupper()
False
>>>

----------
components: None
messages: 137167
nosy: py.user
priority: normal
severity: normal
status: open
title: str.upper converts to title
type: behavior
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 11:04:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 09:04:42 +0000
Subject: [New-bugs-announce] [issue12205] test_subprocess fails due to
	uninstalled test	subdirectory
In-Reply-To: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>
Message-ID: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>


New submission from Ned Deily :

======================================================================
FAIL: test_wait_when_sigchild_ignored (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_subprocess.py", line 860, in test_wait_when_sigchild_ignored
    " non-zero with this error:\n%s" % stderr)
AssertionError: sigchild_ignore.py exited non-zero with this error:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'subprocessdata/sigchild_ignore.py': [Errno 2] No such file or directory

The Makefile for 3.2 was fixed but not 3.1 nor 2.7.  Fix follows.

----------
assignee: ned.deily
messages: 137173
nosy: benjamin.peterson, gps, ned.deily
priority: normal
severity: normal
status: open
title: test_subprocess fails due to uninstalled test subdirectory
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 12:47:00 2011
From: report at bugs.python.org (Martin Ponweiser)
Date: Sun, 29 May 2011 10:47:00 +0000
Subject: [New-bugs-announce] [issue12206] Documentation Std. Library 15.7.5
	"LogRecord objects":	Parameters: level(currently wrong) ->
	levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>


New submission from Martin Ponweiser :

I hope the title is self-explanatory.

----------
assignee: docs at python
components: Documentation
messages: 137178
nosy: docs at python, mponweiser
priority: normal
severity: normal
status: open
title: Documentation Std. Library 15.7.5 "LogRecord objects": Parameters: level(currently wrong) -> levelno (correct)
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 19:23:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:23:50 +0000
Subject: [New-bugs-announce] [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

Title says it all.

----------
assignee: docs at python
components: Documentation
files: document-pycf-only-ast.diff
keywords: needs review, patch
messages: 137203
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Document ast.PyCF_ONLY_AST
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22175/document-pycf-only-ast.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 19:25:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:25:45 +0000
Subject: [New-bugs-announce] [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

I found a bug in email.policy.rst (Msg instead of msg) and did other touch-ups in the file.  Please review.

----------
assignee: docs at python
components: Documentation
files: email.policy-markup-glitches.diff
keywords: patch
messages: 137204
nosy: docs at python, eric.araujo, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Glitches in email.policy docs
versions: Python 3.3
Added file: http://bugs.python.org/file22176/email.policy-markup-glitches.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 19:30:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:30:03 +0000
Subject: [New-bugs-announce] [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

I made some grammar fixes in faulthandler.rst and tweaked the example to better show what the module does.

I?d like to fix the synopsis too: ?dump the Python traceback? is not very clear to me.  It is the traceback or the stack trace?  Why is it called ?the? traceback?  Something like ?dumping the stack trace on CPython crashes? would be better IMO.

----------
assignee: docs at python
components: Documentation
files: faulthandler-doc.diff
keywords: needs review, patch
messages: 137206
nosy: docs at python, eric.araujo, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Minor edits to faulthandler doc
versions: Python 3.3
Added file: http://bugs.python.org/file22177/faulthandler-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun May 29 22:29:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 May 2011 20:29:38 +0000
Subject: [New-bugs-announce] [issue12210] test_smtplib: intermittent
	failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>


New submission from Stefan Krah :

With Python 2.7, the FreeBSD AMD64 bot has sporadic failures in
test_smtplib. Since these failures don't occur in other branches,
I wonder if the timeout of 3 seconds is too low in 2.7. The timeout
is 15 seconds in 3.3.


test test_smtplib failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/test/test_smtplib.py", line 186, in testNOOP
    smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost', timeout=3)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 242, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 303, in connect
    (code, msg) = self.getreply()
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 352, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
SMTPServerDisconnected: Connection unexpectedly closed

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

test test_smtplib failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/test/test_smtplib.py", line 206, in testVRFY
    smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost', timeout=3)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 242, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 303, in connect
    (code, msg) = self.getreply()
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 352, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
SMTPServerDisconnected: Connection unexpectedly closed

----------
components: Tests
keywords: buildbot
messages: 137217
nosy: r.david.murray, skrah
priority: normal
severity: normal
status: open
title: test_smtplib: intermittent failures on FreeBSD
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 01:02:30 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 29 May 2011 23:02:30 +0000
Subject: [New-bugs-announce] [issue12211] math.copysign must keep object
	type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>


New submission from umedoblock :

I expected return int if I gave x as integer to copysign.

I encounterd two problems.
I'd like to fix this problems.
but I can't come up with nice idea.
therefore I just report for you.

one:
>>> import math
>>> a = [0, 1, 2, 3]
>>> i = 1
>>> i_copysign = math.copysign(i, -1)
>>> a[i_copysign]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list indices must be integers, not float

two:
>>> n = 10 ** 20
>>> math.copysign(n + 1, 1) == n + 1
False

----------
components: Library (Lib)
messages: 137226
nosy: umedoblock
priority: normal
severity: normal
status: open
title: math.copysign must keep object type.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 04:18:37 2011
From: report at bugs.python.org (Mitch Ackermann)
Date: Mon, 30 May 2011 02:18:37 +0000
Subject: [New-bugs-announce] [issue12212] Minor proofreading typo in
	index.rst
In-Reply-To: <1306721917.28.0.135738146271.issue12212@psf.upfronthosting.co.za>
Message-ID: <1306721917.28.0.135738146271.issue12212@psf.upfronthosting.co.za>


New submission from Mitch Ackermann :

-Here are some links that you may find you refererence frequently while
+Here are some links that you may find you reference frequently while

----------
components: Devguide
messages: 137235
nosy: mita
priority: normal
severity: normal
status: open
title: Minor proofreading typo in index.rst

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 04:52:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 02:52:39 +0000
Subject: [New-bugs-announce] [issue12213] BufferedRandom: write();
	read() gives different result using io and _pyio
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The following code displays "Xbc" using io, and "bc" using _pyio (or an unbuffered file, e.g. io.FileIO):
-------------
import _pyio, io

with io.BytesIO(b'abc') as raw:
    #with _pyio.BufferedRandom(raw) as f:
    with io.BufferedRandom(raw) as f:
        f.write(b"X")
        print("pos?", f.tell(), raw.tell())
        print(f.read())
-------------

I expect .write() to change the file position, and so "bc" must be the correct result, not "Wbc".

_pyio.BufferedRandom overrides its write method, whereas io.BufferedRandom doesn't.

I already noticed the implement difference of BufferedRandom.write(), but I don't remember if I reported it or not!?

----------
messages: 137238
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: BufferedRandom: write(); read() gives different result using io and _pyio
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 13:46:20 2011
From: report at bugs.python.org (zhou wei)
Date: Mon, 30 May 2011 11:46:20 +0000
Subject: [New-bugs-announce] [issue12214] platform module can't detect
	archlinux distribution
In-Reply-To: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>
Message-ID: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>


New submission from zhou wei :

platform.py can't detect archlinux distribution.
the fix is to try to detect whether /etc/arch-release exists (archlinux is using a rolling release model, so no version, id here. https://wiki.archlinux.org/index.php/Arch_Linux).

----------
components: Library (Lib)
files: platform.py.patch
keywords: patch
messages: 137258
nosy: lemburg, lilaboc
priority: normal
severity: normal
status: open
title: platform module can't detect archlinux distribution
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22189/platform.py.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 14:38:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 12:38:04 +0000
Subject: [New-bugs-announce] [issue12215] TextIOWrapper: issues with
	interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>


New submission from STINNER Victor :

The following code fails on an assertion error (Python exception for _pyio, C assertion for io):

------------------
with io.BytesIO(b'abcd') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        f.read(1)
        f.write('2')
        f.tell()
------------------

I found this assertion while testing interlaced read-write on TextIOWrapper:
------------------
with io.BytesIO(b'abcd') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        f.write("1")
        # read() must call writer.flush()
        assertEqual(f.read(1), 'b')
        # write() must rewind the raw stream
        f.write('2')
        assertEqual(f.read(), 'd')
        f.flush()
        assertEqual(raw.getvalue(), b'1b2d')

with io.BytesIO(b'abc') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        self.assertEqual(f.read(1), b'a')
        # write() must undo reader readahead
        f.write(b"2")
        assertEqual(f.read(1), b'c')
        f.flush()
        assertEqual(raw.getvalue(), b'a2c')
------------------
These tests fails on "read, write, read" path: write() breaks TextIOWrapper internal state if a read() occured just before. Note that _pyio.TextIOWrapper.write() contains the following comment...

# XXX What if we were just reading?

See also the issue #12213 for BufferedRandom and BufferedRWPair.

----------
components: IO
messages: 137260
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: TextIOWrapper: issues with interlaced read-write
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 16:54:57 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 30 May 2011 14:54:57 +0000
Subject: [New-bugs-announce] [issue12216] future imports change the
	reporting of syntaxerrors
In-Reply-To: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>
Message-ID: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt :

>>> compile('def foo(', '', 'exec')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
    def foo(
          ^
SyntaxError: unexpected EOF while parsing

vs

>>> compile('from __future__ import print_function\ndef foo(', '', 'exec')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2
    def foo(
          ^
SyntaxError: invalid syntax

----------
messages: 137285
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: future imports change the reporting of syntaxerrors
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 17:45:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:45:13 +0000
Subject: [New-bugs-announce] [issue12217] Cross-link docs for faulthandler,
	traceback and pdb
In-Reply-To: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>
Message-ID: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

haypo suggested linking between traceback.print_tb and faulthandler.dump_traceback().  See also links between pdb and faulthandler could also be nice, if they explain briefly how the modules differ.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 137298
nosy: docs at python, eric.araujo, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: Cross-link docs for faulthandler, traceback and pdb
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 18:50:48 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:50:48 +0000
Subject: [New-bugs-announce] [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

I am removing that metadata info, since we're moving to PEP 376

----------
assignee: tarek
components: Library (Lib)
messages: 137306
nosy: tarek
priority: normal
severity: normal
status: open
title: Removing wsgiref.egg-info
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 22:54:41 2011
From: report at bugs.python.org (Herm Fischer)
Date: Mon, 30 May 2011 20:54:41 +0000
Subject: [New-bugs-announce] [issue12219] tkinter.filedialog.askopenfilename
	XT dialog on Windows 7
In-Reply-To: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>
Message-ID: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>


New submission from Herm Fischer :

tkinter.filedialog.askopenfilename works fine on the Windows builds of Python 3.1.

However on Python 3.2 (Windows builds via Active State), this dialog comes up with the old Windows XT style on Windows 7 (missing navigation pane) and the dialog is not resizable (it was resizable in Python 3.1).

Application users are inconvenienced, trouble opening long file names.

Is there a work-around in Python 3.2?

----------
components: Tkinter
files: python31-correct-filedialog.png
messages: 137325
nosy: hfischer
priority: normal
severity: normal
status: open
title: tkinter.filedialog.askopenfilename XT dialog on Windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22201/python31-correct-filedialog.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon May 30 23:06:13 2011
From: report at bugs.python.org (Herm Fischer)
Date: Mon, 30 May 2011 21:06:13 +0000
Subject: [New-bugs-announce] [issue12220] minidom xmlns not handling spaces
	in xmlns attribute	value field
In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>
Message-ID: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>


New submission from Herm Fischer :

Minidom raises an exception if there's a space anywhere in the URI of an xmlns, but it is legal (but terrible practice) to have spaces in URIs.  I think this should work or politely raise a syntax error.  E.g., this fails:  xmlns:abc="http:abc.com/de f g/hi/j k".

The attachment xml file from an end user has this xmlns:

  xmlns:verrels=" http://xbrl.org/2010/versioning-relationship-sets"

which causes minidom to raise a ValueError exception, instead of a sensible syntax error message.  

The relevant python code is expabuilder.py, method _parse_ns_name, which does not have an elif for len(parts) != 2 (to raise a syntax error which identifies the bad construct).

----------
components: XML
files: test.xml
messages: 137329
nosy: hfischer
priority: normal
severity: normal
status: open
title: minidom xmlns not handling spaces in xmlns attribute value field
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file22203/test.xml

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 10:47:43 2011
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 31 May 2011 08:47:43 +0000
Subject: [New-bugs-announce] [issue12221] segfaults with unexpanded
	$Revision$ id's in release	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>


New submission from Matthias Klose :

Modules/pyexpat.c (get_version_string) has:

static PyObject *
get_version_string(void)
{
    static char *rcsid = "$Revision$";
    char *rev = rcsid;
    int i = 0;

    while (!isdigit(Py_CHARMASK(*rev)))
        ++rev;

which segfaults, or has unexpected results. -O2 builds don't show the segfaults, but at least debug builds on sparc, ARM, powerpc, m68k.

>>> pyexpat.__version__
'0\x05'

seen with all the current release candidates for 2.7.2, 3.1.4 and 3.2.1
2.5.6 and 2.6.7 don't have this issue.

other occurrences:

./setup.py:__version__ = "$Revision$"
./Demo/scripts/newslist.py:# Newslist  $Revision$
./Demo/scripts/newslist.py:rcsrev = '$Revision$'
./configure.in:AC_REVISION($Revision$)
./Tools/webchecker/websucker.py:__version__ = "$Revision$"
./Tools/webchecker/webchecker.py:__version__ = "$Revision$"
./Tools/world/world:__version__ = '$Revision$'
./Parser/asdl_c.py:        # Value of version: "$Revision$"
./Parser/Python.asdl:module Python version "$Revision$"
./Modules/pyexpat.c:    static char *rcsid = "$Revision$";
./Lib/tkinter/__init__.py:__version__ = "$Revision$"
./Lib/pickle.py:__version__ = "$Revision$"       # Code version
./Lib/xml/parsers/expat.py:__version__ = '$Revision$'
./Lib/pydoc.py:__version__ = "$Revision$"
./Lib/tarfile.py:__version__ = "$Revision$"

----------
components: Build
messages: 137347
nosy: benjamin.peterson, doko, georg.brandl
priority: release blocker
severity: normal
status: open
title: segfaults with unexpanded $Revision$ id's in release candidate tarballs
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 11:16:13 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 31 May 2011 09:16:13 +0000
Subject: [New-bugs-announce] [issue12222] All pysetup commands should
	respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>


New submission from Tarek Ziad? :

All actions in packaging.run need to respect a basic exit convention 0/1. 

This is important because pysetup will be used in automated scripts so the caller needs to know wether the call failed or succedeed. 

Example: pysetup install project => sys,exit(0 or 1)

----------
assignee: tarek
components: Distutils2
messages: 137348
nosy: alexis, eric.araujo, tarek
priority: high
severity: normal
status: open
title: All pysetup commands should respect exit codes
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 11:42:55 2011
From: report at bugs.python.org (Vladimir M.)
Date: Tue, 31 May 2011 09:42:55 +0000
Subject: [New-bugs-announce] [issue12223] Datamodel documentation page:
	'operator' where 'operand'	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>


New submission from Vladimir M. :

The page at (http://docs.python.org/reference/datamodel.html) says:
"In x * y, if one operator is a sequence that implements sequence repetition".

Obviuosly, it should be changed to:
"In x * y, if one operand is a sequence that implements sequence repetition".

----------
assignee: docs at python
components: Documentation
messages: 137352
nosy: Vladimir.M., docs at python
priority: normal
severity: normal
status: open
title: Datamodel documentation page: 'operator' where 'operand' should be
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 13:23:34 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Tue, 31 May 2011 11:23:34 +0000
Subject: [New-bugs-announce] [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>


New submission from Zhiping Deng :

If socket timeout > 0, then there is no way to automatically
restart some socket calls like recv(). 
Calling siginterrupt(False) is useless, because python calls
internal_select() if socket has timeout, and select returns
error(EINTR) once interrupted by a signal, regardless of the
SA_RESTART flags.

So a user may have to wrap every socket calls in this case.

I found some related discussions in http://bugs.python.org/issue7978

----------
components: Library (Lib)
files: siginterrupt_example.py
messages: 137357
nosy: Zhiping.Deng
priority: normal
severity: normal
status: open
title: problem with siginterrupt
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22207/siginterrupt_example.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 17:16:17 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 15:16:17 +0000
Subject: [New-bugs-announce] [issue12225] current tip doesn't build without
	mercurial installed
In-Reply-To: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
Message-ID: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>


New submission from Ralf Schmitt :

configure works, but make immediately fails:

% make      
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "./Parser/asdl_c.py", line 1214, in 
    main(args[0])
  File "./Parser/asdl_c.py", line 1158, in main
    mod.version = get_file_revision(srcfile)
  File "./Parser/asdl_c.py", line 1142, in get_file_revision
    p = subprocess.Popen(args, stdout=subprocess.PIPE)
  File "/usr/lib/python2.7/subprocess.py", line 672, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1202, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [Include/Python-ast.h] Error 1

----------
messages: 137363
nosy: schmir
priority: normal
severity: normal
status: open
title: current tip doesn't build without mercurial installed
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 18:51:05 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 31 May 2011 16:51:05 +0000
Subject: [New-bugs-announce] [issue12226] use secured channel for uploading
	packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

Before the next version is released, I'd like to push this one line modification to reduce the risk of sniffing Python development password when people upload packages to PyPI by using https:// communication channel by default.

Distutils doesn't validate PyPI server certificate, so this change doesn't prevent from MITM attacks, but at least it makes package submissions over wireless channels and public networks safer.

Taking into account that people still release packages for Python 2.5+ (AppEngine), I'd like to see this fix backported to at least Python 2.6

----------
assignee: tarek
components: Distutils, Distutils2
files: pypy.https.patch
keywords: patch
messages: 137366
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: use secured channel for uploading packages to pypi
type: security
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file22208/pypy.https.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 19:30:31 2011
From: report at bugs.python.org (Graham Cummins)
Date: Tue, 31 May 2011 17:30:31 +0000
Subject: [New-bugs-announce] [issue12227] multiprocessing.Pool
	initialization seems to call	methods it should not (and on
	badly formed objects)
In-Reply-To: <1306863031.61.0.944482531779.issue12227@psf.upfronthosting.co.za>
Message-ID: <1306863031.61.0.944482531779.issue12227@psf.upfronthosting.co.za>


New submission from Graham Cummins :

When attempting to pass instances of a custom class in the argument list
of a multiprocessing.Pool.map call, I encounter an inexplicable AttributeError. A simplified test script that creates the bug is included. It fails for both Python 2.7.1 and 3.2 on my 4-core 64 bit linux machine.

Briefly, the code creates a subclass of "dict" that checks for a "_ro" attribute before handling a "__setitem__". Empty instances of this class
can be passed to Pool.map fine, but if they have any content, I get
that multiprocessing/queues.py, line 378 ("recv()"), calls my custom __setitem__, which fails, due to a missing _ro attribute. 

This is very confusing. For one thing, much of the Traceback seems
missing. recv() is not directly a call to my customized __setitem__, 
and I can't thing why it should ever need to invoke such a call  

For another, the custom class _does_ set the _ro attribute, on __init__. Testing for this attribute, or calling __setitem__, succeeds in every other context I've tested, so it seems that the instance that is 
being used in the multiprocessing context is not the same underlying object that I pass in.

----------
components: Library (Lib)
files: bug.py
messages: 137373
nosy: Graham.Cummins
priority: normal
severity: normal
status: open
title: multiprocessing.Pool initialization seems to call methods it should not (and on badly formed objects)
versions: Python 2.7
Added file: http://bugs.python.org/file22211/bug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 20:01:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 31 May 2011 18:01:42 +0000
Subject: [New-bugs-announce] [issue12228] Stat doc - fix swap of UF_OPAQUE
	and UF_NOUNLINK	description
In-Reply-To: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>
Message-ID: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Following http://mail.python.org/pipermail/docs/2011-May/004429.html, here's a patch that fix the swap of those 2 flags description; it applies cleanly (except for some offset) on 2.7, 3.1, 3.2 and default.

----------
assignee: docs at python
components: Documentation
files: doc_stat_uf_opaque_nounlink-py27.patch
keywords: patch
messages: 137377
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK description
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22212/doc_stat_uf_opaque_nounlink-py27.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue May 31 23:29:28 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 31 May 2011 21:29:28 +0000
Subject: [New-bugs-announce] [issue12229] Remove unused variable in
	bufferedio.c
In-Reply-To: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>
Message-ID: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>


New submission from John O'Connor :

Remove second (unused) argument to _bufferedreader_peek_unlocked()

----------
components: IO
files: bufferedreader_peek.patch
keywords: patch
messages: 137391
nosy: haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: Remove unused variable in bufferedio.c
versions: Python 3.3
Added file: http://bugs.python.org/file22214/bufferedreader_peek.patch

_______________________________________
Python tracker 

_______________________________________

