From report at bugs.python.org  Fri Mar  1 09:16:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Mar 2013 08:16:09 +0000
Subject: [New-bugs-announce] [issue17323] Disable [X refs,
	Y blocks] ouput in debug builds
Message-ID: <1362125769.07.0.506127363333.issue17323@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

I suggest to disable the [X refs, Y blocks] ouput in debug builds by default, and provide an option to enable it if/when necessary.
Most of the time these values are not necessary, and they end up getting in the way while copy/pasting code from the interpreter and/or running tests (we even have a function in test.support to get rid of them).
They are sometimes useful while investigating refleaks, so there should still be an option to enable it.  I'm not sure what would be the best way to do it (a new python flag?).

----------
components: Interpreter Core
messages: 183244
nosy: ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Disable [X refs, Y blocks] ouput in debug builds
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar  1 09:54:06 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 01 Mar 2013 08:54:06 +0000
Subject: [New-bugs-announce] [issue17324] SimpleHTTPServer serves files even
	if the URL has a	trailing slash
Message-ID: <1362128046.23.0.253565985522.issue17324@psf.upfronthosting.co.za>


New submission from Larry Hastings:

To reproduce:

1) Create a file called "foo.txt" in the local directory, put whatever you like in it.
2) Run "python -m SimpleHTTPServer" or "python3 -m http.server".
3) Point your web browser at "http://127.0.0.1:8000/foo.txt/".
4) Note that the server has served the contents of "foo.txt" as "foo.txt/".  It shouldn't do that!

Reproduced with 2.7.3, 3.2.3, and 3.3.0.  I assume it's still there in trunk.

----------
components: Library (Lib)
keywords: easy
messages: 183247
nosy: larry
priority: low
severity: normal
status: open
title: SimpleHTTPServer serves files even if the URL has a trailing slash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar  1 10:51:31 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Mar 2013 09:51:31 +0000
Subject: [New-bugs-announce] [issue17325] improve organization of the PyPI
	distutils docs
Message-ID: <1362131491.68.0.398716399036.issue17325@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to improve the organization of the PyPI section of the Distutils documentation, now that the information has been combined into one page.

A patch is attached.

Improvements include:

(1) Creating a section for command options common to both register and upload.  Previously, this information was confined to the upload section, even though the information was applicable to both commands.
(2) Separating general information about PyPI (e.g. PyPI user permissions and the web interface) from the information about Distutils command usage.
(3) Consolidating information about the .pypirc file in the .pypirc section.  Previously, some of the .pypirc information was spread throughout the upload section, even though the information is equally applicable to the register command.

----------
assignee: eric.araujo
components: Distutils, Documentation
files: issue-pypi-docs.patch
keywords: patch
messages: 183252
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: improve organization of the PyPI distutils docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29281/issue-pypi-docs.patch

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

From report at bugs.python.org  Fri Mar  1 13:58:25 2013
From: report at bugs.python.org (Christoph Zwerschke)
Date: Fri, 01 Mar 2013 12:58:25 +0000
Subject: [New-bugs-announce] [issue17326] Windows build docs still referring
	to VS 2008 in 3.3
Message-ID: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke:

The first paragraph in PCbuild/readme.txt of Python 3.3 still talks about Visual C++ 2008 Express and Visual Studio 2008. It says that VS 2008 is required at the very least (which may be still true, I'm not sure), but then it also says "the official Python releases are built with this [i.e. the 2008] version of VS", while it seems they have been built with VS 2010 in reality (as the title is also indicating).

----------
assignee: docs at python
components: Documentation
messages: 183259
nosy: cito, docs at python
priority: normal
severity: normal
status: open
title: Windows build docs still referring to VS 2008 in 3.3
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  1 14:45:55 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 01 Mar 2013 13:45:55 +0000
Subject: [New-bugs-announce] [issue17327] Add PyDict_GetItemSetDefault() as
	C-API for	dict.setdefault()
Message-ID: <1362145555.76.0.784733003054.issue17327@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The functionality of dict.setdefault() is not currently available through the C-API. Specfically, there is no way to test for a key and insert a fallback value for it without evaluating the hash function twice.

The attached patch adds a new C-API function PyDict_GetItemSetDefault() that makes this feature available. Like all PyDict_Getitem*() functions, it returns a borrowed reference.

I hope I got the update in refcounts.dat right. I have no idea how to express that a function *may* increase the refcounts of its arguments.

----------
components: Interpreter Core
files: pydict_setitemdefault.patch
keywords: patch
messages: 183260
nosy: scoder
priority: normal
severity: normal
status: open
title: Add PyDict_GetItemSetDefault() as C-API for dict.setdefault()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29284/pydict_setitemdefault.patch

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

From report at bugs.python.org  Fri Mar  1 15:03:53 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 01 Mar 2013 14:03:53 +0000
Subject: [New-bugs-announce] [issue17328] Fix reference leak in
	dict_setdefault() in case of	resize failure
Message-ID: <1362146633.78.0.0455037271826.issue17328@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

While writing the patch for issue 17327, I noticed that there is a double reference leak in dict_setdefault() under the rare condition that resizing fails. I'm not 100% sure that it's ok to move the increfs behind the resizing, but considering that the resizing code actually looks safe and shouldn't kill references that are currently in the dict, I don't think it can be a problem. And the caller should always own a reference to these two anyway. Alternatively, decrefing them if the failure occurs would be a less intrusive change.

----------
components: Interpreter Core
files: dict_setdefault_refleak.patch
keywords: patch
messages: 183261
nosy: scoder
priority: normal
severity: normal
status: open
title: Fix reference leak in dict_setdefault() in case of resize failure
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29285/dict_setdefault_refleak.patch

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

From report at bugs.python.org  Fri Mar  1 16:04:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2013 15:04:33 +0000
Subject: [New-bugs-announce] [issue17329] Document unittest.SkipTest
Message-ID: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>


New submission from Brett Cannon:

<EOM>

----------
assignee: docs at python
components: Documentation
messages: 183262
nosy: brett.cannon, docs at python, ezio.melotti, michael.foord, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unittest.SkipTest
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar  1 19:38:11 2013
From: report at bugs.python.org (Erik Bray)
Date: Fri, 01 Mar 2013 18:38:11 +0000
Subject: [New-bugs-announce] [issue17330] Check st_nlink in addition to
	st_mtime to invalidate	FileFinder cache
Message-ID: <1362163091.64.0.598022639655.issue17330@psf.upfronthosting.co.za>


New submission from Erik Bray:

This is vaguely related to issue14067, though the patch suggested there would make this problem worse, not better.

This addresses a problem that cropped up on OSX in which some code that, for Good Reasons, generates a module in a package directory and then expects to be able to import it.  Because HFS+ does not offer sub-second resolution for mtime the generated module is not found. We didn't have this problem on Linux or Windows.

I've attached one possible solution to the issue, which uses a tuple of st_mtime and st_nlink to determine if the cache should be invalidated.  This should pick up most file creation/deletion on such file systems even if the directory's mtime hasn't changed.  This doesn't add any additional system calls so it shouldn't have any significant performance impact.

In the meantime importlib.invalidate_caches() offers a consistent workaround, but it was surprising when this issue was found to be platform dependent.

----------
components: None
hgrepos: 178
messages: 183270
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Check st_nlink in addition to st_mtime to invalidate FileFinder cache
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  1 21:53:40 2013
From: report at bugs.python.org (Mathieu Pasquet)
Date: Fri, 01 Mar 2013 20:53:40 +0000
Subject: [New-bugs-announce] [issue17331] Fix str methods for detecting
	digits with unicode
Message-ID: <1362171220.98.0.881684038408.issue17331@psf.upfronthosting.co.za>


New submission from Mathieu Pasquet:

In py3k, str.isalnum(), str.isdigit(), and str.isdecimal() are broken because they take into account various unicode numbers.

A common case is doing something like that:

num = -1
while num == -1:
    num_in = input('Enter a number> ')
    if num_in.isdigit():
        num = int(num_in)

# do stuff ?

If you enter ?, or any esoteric unicode representation of a number, all the methods referenced above will return True. I believe this is a bug.

It also affects the stdlib, e.g. in collection.namedtuple,
A = namedtuple('A?', 'x y') will return an ugly Syntax Error, because the sanity check uses str.isalnum(), which says it?s ok. (n.b.: of course, no sane person should ever want to do the above, but I find it worth mentionning)

----------
components: Unicode
messages: 183291
nosy: ezio.melotti, mathieui
priority: normal
severity: normal
status: open
title: Fix str methods for detecting digits with unicode
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  1 22:31:03 2013
From: report at bugs.python.org (Ernie Hershey)
Date: Fri, 01 Mar 2013 21:31:03 +0000
Subject: [New-bugs-announce] [issue17332] typo in json docs - "convered"
	should be "converted"
Message-ID: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>


New submission from Ernie Hershey:

Hi,

On these pages:

http://docs.python.org/3.4/library/json.html
http://docs.python.org/3.3/library/json.html
http://docs.python.org/3.2/library/json.html
http://docs.python.org/2/library/json.html
http://docs.python.org/2.6/library/json.html

This line says "convered" but should be "converted."

Note Keys in key/value pairs of JSON are always of the type str. When a dictionary is converted into JSON, all the keys of the dictionary are coerced to strings. As a result of this, if a dictionary is convered into JSON and then back into a dictionary, the dictionary may not equal the original one. That is, loads(dumps(x)) != x if x has non-string keys.

----------
assignee: docs at python
components: Documentation
messages: 183293
nosy: docs at python, ernest
priority: normal
severity: normal
status: open
title: typo in json docs - "convered" should be "converted"
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  1 22:38:20 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 01 Mar 2013 21:38:20 +0000
Subject: [New-bugs-announce] [issue17333] Fix test discovery for
	test_imaplib.py
Message-ID: <1362173900.83.0.151362153333.issue17333@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch for test_imaplib.py that converts test_main into load_tests.

----------
components: Tests
files: test_imaplib_discovery.diff
keywords: patch
messages: 183294
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_imaplib.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29287/test_imaplib_discovery.diff

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

From report at bugs.python.org  Fri Mar  1 23:26:16 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 01 Mar 2013 22:26:16 +0000
Subject: [New-bugs-announce] [issue17334] Fix test discovery for
	test_index.py
Message-ID: <1362176776.61.0.51954698694.issue17334@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Just subclassing issues in this one.

----------
components: Tests
files: test_index_discovery.diff
keywords: patch
messages: 183299
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_index.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29289/test_index_discovery.diff

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

From report at bugs.python.org  Sat Mar  2 01:34:23 2013
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 02 Mar 2013 00:34:23 +0000
Subject: [New-bugs-announce] [issue17335] FieldStorageClass is messed up
Message-ID: <1362184463.11.0.388912351396.issue17335@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

This problem goes back to 2.6 at least.

In Lib/cgi.py

    FieldStorageClass = None

    def read_multi(self, environ, keep_blank_values, strict_parsing):
        """Internal: read a part that is itself multipart."""
        ib = self.innerboundary
        if not valid_boundary(ib):
            raise ValueError, 'Invalid boundary in multipart form: %r' % (ib,)
        self.list = []
        if self.qs_on_post:
            for key, value in urlparse.parse_qsl(self.qs_on_post,
                                self.keep_blank_values, self.strict_parsing):
                self.list.append(MiniFieldStorage(key, value))
            FieldStorageClass = None

The set of FieldStorageClass is to a local variable, so a no-op since it's never read.  The class attribute will always be None unless set outside this class (not sure if it is).  It looks like it should just be removed.

----------
messages: 183308
nosy: Neal.Norwitz
priority: normal
severity: normal
status: open
title: FieldStorageClass is messed up
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Mar  2 12:28:04 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Sat, 02 Mar 2013 11:28:04 +0000
Subject: [New-bugs-announce] [issue17336] Complex number representation
	round-trip doesn't work	with signed zero values
Message-ID: <1362223684.37.0.0348889498791.issue17336@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

When evaluating, signed zero complex numbers aren't recovered correctly.
>>> -0j
(-0-0j)
>>> (-0-0j)
0j
>>> 0j
0j

According to http://docs.python.org/dev/reference/datamodel.html#object.__repr__ the representation can be used to recreate an object with the same value. Shouldn't this also be possible with complex numbers?

When using complex('...'), round-trip works correctly. While this can be used to recover the exact number, i find it confusing that complex('...') isn't the same as eval('...').
>>> complex('-0j')
-0j
>>> complex('(-0-0j)')
(-0-0j)
>>> complex('0j')
0j

----------
messages: 183313
nosy: mjacob
priority: normal
severity: normal
status: open
title: Complex number representation round-trip doesn't work with signed zero values
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Mar  2 16:09:24 2013
From: report at bugs.python.org (mic_e)
Date: Sat, 02 Mar 2013 15:09:24 +0000
Subject: [New-bugs-announce] [issue17337] input() and raw_input() do not
	work correctly with	colored prompts
Message-ID: <1362236964.85.0.134127148195.issue17337@psf.upfronthosting.co.za>


New submission from mic_e:

With a prompt that uses ANSI color escape codes, python3 input() and python2 raw_input() behave incorrectly when it comes to the wrapping of the first line - almost certainly due to the wrong string length calculation.
The line breaking occurs k characters early, where k is the number of characters in the ANSI escape sequence.
Even worse, the line break does not switch to the next line, but instead jumps back to the beginning, overwriting the prompt and the previously written input.

How to reproduce:
Call input() with a color-coded string as argument, and type until you would expect the usual line break.

Example:

mic at mic-nb ~ $ python3
Python 3.3.0 (default, Dec 22 2012, 21:02:07) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> prompt="\x1b[31;1mthis is a bold red prompt> \x1b[m"
>>> len(prompt)
37
>>> input(prompt)
uvwxyzs a bold red prompt> abcdefghijklmnopqrst 
'abcdefghijklmnopqrstuvwxyz'
>>> 
mic at mic-nb ~ $ python2
Python 2.7.3 (default, Dec 22 2012, 21:14:12) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> prompt="\x1b[31;1mthis is a bold red prompt> \x1b[m"
>>> len(prompt)
37
>>> raw_input(prompt)
uvwxyzs a bold red prompt> abcdefghijklmnopqrst 
'abcdefghijklmnopqrstuvwxyz'
>>> 
mic at mic-nb ~ $ tput cols
57

I have typed directly after the prompt the string 'abcdefghijklmnopqrstuvwxyz',
so the expected result would be be
this is a bold red prompt> abcdefghijklmnopqrstuvwxyz
with four more characters of space before the line break

Note that the break occurs exactly 8 characters early, which is the total amount of ANSI escape sequence characters.
Also note that the readline module is impored in my .pyrc file.

----------
components: Library (Lib)
messages: 183323
nosy: mic_e
priority: normal
severity: normal
status: open
title: input() and raw_input() do not work correctly with colored prompts
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Mar  2 18:23:39 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 02 Mar 2013 17:23:39 +0000
Subject: [New-bugs-announce] [issue17338] Add length_hint parameter to list,
	dict, set constructors to allow efficient presizing
Message-ID: <1362245019.42.0.972918137955.issue17338@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Following the length_hint PEP, we should expose this facility to end-python programmers. The semantics would be basically: the list has behavior identical to if you hadn't provided length_hint, except the VM is free to preallocate efficiently.

CPython (and PyPy) use this kind of logic internally all over the place when lists are to be returned (including, but not limited to, list() with a single argument!)

If this is considered to be a good idea I'll whip up a patch.

----------
messages: 183332
nosy: alex
priority: normal
severity: normal
status: open
title: Add length_hint parameter to list, dict, set constructors to allow efficient presizing
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  2 20:58:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Mar 2013 19:58:34 +0000
Subject: [New-bugs-announce] [issue17339] bytes() TypeError message is
	misleadingly narrow
Message-ID: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

If an object ob does not have a __bytes__ method or buffer interface and is not a string, integer, or iterable, bytes(ob) fails with 

TypeError: 'object' object is not iterable

This is misleadingly narror (similar to #17032). We should either list *all* the things that ob is not

'object' object is not a string, integer, or iterable and does not have a __bytes__ method or buffer interface

or simply say

'object' object cannot be converted to bytes

and let the programmer recheck what can be.

----------
components: Interpreter Core
messages: 183345
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: bytes() TypeError message is misleadingly narrow
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  3 12:10:33 2013
From: report at bugs.python.org (keakon)
Date: Sun, 03 Mar 2013 11:10:33 +0000
Subject: [New-bugs-announce] [issue17340] Handle malformed cookie
Message-ID: <1362309033.05.0.860433762185.issue17340@psf.upfronthosting.co.za>


New submission from keakon:

One of my user told me that she couldn't login to my website yesterday. I logged her cookie, and found it began with ',BRIDGE_R=;' which was a malformed cookie.
Tornado uses Cookie.SimpleCookie.load() to parse her cookie, and returns an empty dict when catching an exception such as CookieError.

In that case, Tornado has to treat her as a new user since it believes she didn't provide any cookies.
Even after Tornado tried to set cookie (like user_id) for her, it still couldn't parse her cookie the next time.

I checked Issue2193 and found the patch provided by spookylukey could fix the bug, but it was rejected.
Why not add a default parameter like strict=True, and let users to decide whether to ignore invalid keys or to raise an error?

I believe SimpleCookie is useless for handling malformed cookies right now.
If it's still not acceptable, should I implement my own Cookie class for Tornado like Django did (https://github.com/django/django/blob/master/django/http/cookie.py)?

----------
components: Library (Lib)
messages: 183367
nosy: georg.brandl, keakon, spookylukey
priority: normal
severity: normal
status: open
title: Handle malformed cookie
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  3 14:56:15 2013
From: report at bugs.python.org (Roy Smith)
Date: Sun, 03 Mar 2013 13:56:15 +0000
Subject: [New-bugs-announce] [issue17341] Poor error message when compiling
	invalid regex
Message-ID: <1362318975.95.0.685473127287.issue17341@psf.upfronthosting.co.za>


New submission from Roy Smith:

>>> re.compile('(?P=<foo>)')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/roy/env/python/lib/python2.7/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/home/roy/env/python/lib/python2.7/re.py", line 242, in _compile
    raise error, v # invalid expression
sre_constants.error: bad character in group name


The error here is that I put a "=" where it shouldn't be.  The error message is misleading.  The "group name" is the stuff between the <>'s.  That part's fine.  What's broken is the stuff outside of the <>'s.

Unclear if it's reasonable to expect such precise error reporting here, but this one seems particularly misleading, so opening a ticket to record the observation.

----------
components: Regular Expressions
messages: 183375
nosy: ezio.melotti, mrabarnett, roysmith
priority: normal
severity: normal
status: open
title: Poor error message when compiling invalid regex
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  3 15:25:10 2013
From: report at bugs.python.org (=?utf-8?q?Zbyn=C4=9Bk_Winkler?=)
Date: Sun, 03 Mar 2013 14:25:10 +0000
Subject: [New-bugs-announce] [issue17342] datetime.strptime does not
	implement %z
Message-ID: <1362320710.15.0.670090383938.issue17342@psf.upfronthosting.co.za>


New submission from Zbyn?k Winkler:

According to http://docs.python.org/2/library/datetime.html#strftime-strptime-behavior the %z directive is used to specify the timezone offset  of the form +HHMM or -HHMM. However it is not implemented in datetime.strptime.

I'd prefer to have %z available in strptime but if not having it is a deliberate decision I think it should be mentioned in the documentation as not to confuse users.

----------
components: Library (Lib)
messages: 183379
nosy: zwn
priority: normal
severity: normal
status: open
title: datetime.strptime does not implement %z
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  4 02:04:26 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 04 Mar 2013 01:04:26 +0000
Subject: [New-bugs-announce] [issue17343] Add a version of str.split which
	returns an iterator
Message-ID: <1362359066.58.0.311917237277.issue17343@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

str.split returns a list, which is inefficient when you just want to process items one be one. You could emulate this with str.find and tracking indexes manually, but this should really be a builtin behavior.

----------
messages: 183411
nosy: alex
priority: normal
severity: normal
status: open
title: Add a version of str.split which returns an iterator
type: enhancement

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

From report at bugs.python.org  Mon Mar  4 07:32:04 2013
From: report at bugs.python.org (shilpi)
Date: Mon, 04 Mar 2013 06:32:04 +0000
Subject: [New-bugs-announce] [issue17344] checking size of size_t...
	configure: error:
Message-ID: <1362378724.97.0.818399526609.issue17344@psf.upfronthosting.co.za>


New submission from shilpi:

Hi 
we are facing "checking size of size_t error" in building python2.6
checking size of size_t... configure: error: in `/var/tmp/python_build/Python-2.6.8':
configure: error: cannot compute sizeof (size_t). Is there any fix for this issue or anysolution

----------
messages: 183417
nosy: shilpi
priority: normal
severity: normal
status: open
title: checking size of size_t... configure: error:
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar  4 09:26:17 2013
From: report at bugs.python.org (Nikita Nemkin)
Date: Mon, 04 Mar 2013 08:26:17 +0000
Subject: [New-bugs-announce] [issue17345] Portable and extended type
	specifiers for array module
Message-ID: <1362385577.82.0.862277690656.issue17345@psf.upfronthosting.co.za>


New submission from Nikita Nemkin:

Currently array module only provides platform-dependent type specifiers.
It would be very nice to have platform-independent specifiers in addition to that, matching the struct module.
For example array('<H') -> an array of little-endian 2-byte integers.

This issue crops up every time when I use array(). Binary data usually comes in some predefined format and a manual matching to native format has to be done (assuming I want to write portable code).

A useful extra would be to support multi-element struct specifiers and present an array of tuples in this case.
For example array('iff') -> an array of tuples (int, float, float) with native types.

----------
components: Library (Lib)
messages: 183425
nosy: nnemkin
priority: normal
severity: normal
status: open
title: Portable and extended type specifiers for array module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  4 10:45:52 2013
From: report at bugs.python.org (Marius Gedminas)
Date: Mon, 04 Mar 2013 09:45:52 +0000
Subject: [New-bugs-announce] [issue17346] Pickle tests do not test protocols
	0, 1, and 2 for bytes
Message-ID: <1362390352.97.0.872736532122.issue17346@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

I was reading Lib/test/pickletester.py when I noticed that test_bytes loops over all the protocols but doesn't actually use the loop variable anywhere.

Attached patch should fix this.

----------
components: Tests
files: actually-test-all-protocols.diff
keywords: patch
messages: 183429
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Pickle tests do not test protocols 0, 1, and 2 for bytes
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29302/actually-test-all-protocols.diff

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

From report at bugs.python.org  Mon Mar  4 11:47:56 2013
From: report at bugs.python.org (Florian Weimer)
Date: Mon, 04 Mar 2013 10:47:56 +0000
Subject: [New-bugs-announce] [issue17347] bsddb._openDBEnv() should not
	touch current directory
Message-ID: <1362394076.13.0.84822225356.issue17347@psf.upfronthosting.co.za>


New submission from Florian Weimer:

This code:

def _openDBEnv(cachesize):
    e = db.DBEnv()
    if cachesize is not None:
        if cachesize >= 20480:
            e.set_cachesize(0, cachesize)
        else:
            raise error, "cachesize must be >= 20480"
    e.set_lk_detect(db.DB_LOCK_DEFAULT)
    e.open('.', db.DB_PRIVATE | db.DB_CREATE | db.DB_THREAD | db.DB_INIT_LOCK | db.DB_INIT_MPOOL)
    return e

causes Berkeley DB to read the DB_CONFIG file from the current directory, which may have unexpected side effects.  Unfortunately, Berkeley DB still reads ./DB_CONFIG even if the first argument to DBEnv.open() is None/NULL, so the only way to suppress this behavior seems a non-existing or known-to-by-empty directory (such as "/var/empty").

----------
components: Extension Modules
messages: 183430
nosy: fweimer
priority: normal
severity: normal
status: open
title: bsddb._openDBEnv() should not touch current directory
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  4 11:49:37 2013
From: report at bugs.python.org (Pradyun Gedam)
Date: Mon, 04 Mar 2013 10:49:37 +0000
Subject: [New-bugs-announce] [issue17348] Unicode - encoding seems to be
	lost for inputs of	unicode chars
Message-ID: <1362394177.55.0.407970210278.issue17348@psf.upfronthosting.co.za>


New submission from Pradyun Gedam:

In IDLE, I have spotted a peculiar problem.

I have attached an .png file which is a screen capture of 'session' on IDLE. It seems that the Unicode character that has been input, loses its encoding.

My 'session'
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> c = u'?'
>>> ord(c)
128
>>> c.encode('utf-8')
'\xc2\x80'
>>> c
u'\x80'
>>> print c
?
>>> c = u'\u20ac'
>>> ord(c)
8364
>>> c.encode('utf-8')
'\xe2\x82\xac'
>>> c
u'\u20ac'
>>> print c
?
>>>

----------
components: IDLE
messages: 183431
nosy: Pradyun.Gedam
priority: normal
severity: normal
status: open
title: Unicode - encoding seems to be lost for inputs of unicode chars
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  4 13:27:33 2013
From: report at bugs.python.org (Andrey Lebedev)
Date: Mon, 04 Mar 2013 12:27:33 +0000
Subject: [New-bugs-announce] [issue17349] wsgiref.simple_server.demo_app is
	not PEP-3333 compatible
Message-ID: <1362400053.87.0.0342035983925.issue17349@psf.upfronthosting.co.za>


New submission from Andrey Lebedev:

Under certain circumstances, wsgiref.simple_server.demo_app may return unicode data, but that is prohibited by PEP-3333.

This happens if environ with unicode key is passed to demo_app. Unicode keys are then written to StringIO instance, automatically making its value unicode.

Type of environ keys is not strictly mandated by PEP-3333, however output of WSGI application is:

  "When called by the server, the application object must return an iterable yielding zero or more bytestrings.", see http://www.python.org/dev/peps/pep-3333/#specification-details

Test case is attached.

----------
components: Library (Lib)
files: wsgirefbug.py
messages: 183437
nosy: Andrey.Lebedev
priority: normal
severity: normal
status: open
title: wsgiref.simple_server.demo_app is not PEP-3333 compatible
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29303/wsgirefbug.py

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

From report at bugs.python.org  Mon Mar  4 14:09:24 2013
From: report at bugs.python.org (Tomgu)
Date: Mon, 04 Mar 2013 13:09:24 +0000
Subject: [New-bugs-announce] [issue17350] Use STAF call python script will
	case 1124861 issue in	2.7.2 version
Message-ID: <1362402564.96.0.853290291647.issue17350@psf.upfronthosting.co.za>


New submission from Tomgu:

Here I get one problem use STAF call python and need help. 
In python 2.7.2 version I write a script "test.py" as below
###
import subprocess
fileID=file('test1.log','w')
process_response = subprocess.call('netsh wlan show\ interface',stdout=fileID,shell=True)
fileID.flush()
fileID.close()
###
It run in windows7 os MSDOS console is OK
and I try to run it in STAF command

C:\> STAF local PROCESS START COMMAND python C:\>test.py WAIT STDERRTOSTDOUT RETURNSTDOUT

Response
--------
{
  Return Code: 1
  Key        : <None>
  Files      : [
    {
      Return Code: 0
      Data       : Traceback (most recent call last):
  File "C:\test.py", line 3, in <module>
    process_response = subprocess.call('netsh wlan show interface',stdout=fileID
,shell=True)
  File "C:\Python27\lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\lib\subprocess.py", line 672, in __init__
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)
  File "C:\Python27\lib\subprocess.py", line 784, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\Python27\lib\subprocess.py", line 823, in _make_inheritable
    _subprocess.DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid

    }
  ]

Like known issue 1124861. I just start to learn python, I dont know how to resolve, need help.

----------
messages: 183444
nosy: gwtking
priority: normal
severity: normal
status: open
title: Use STAF call python script will case 1124861 issue in 2.7.2 version
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  4 15:36:39 2013
From: report at bugs.python.org (Phil Elson)
Date: Mon, 04 Mar 2013 14:36:39 +0000
Subject: [New-bugs-announce] [issue17351] Fixed python3 descriptor
	documentation example + removal	of explicit "object"
	inheritance in docs
Message-ID: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>


New submission from Phil Elson:

The example at http://docs.python.org/3.4/howto/descriptor.html#properties does not run due to the old style "raise AttributeError, message" form. 


This patch fixes the problem, and also goes through the docs to remove explicit sub-classing from "object". The only remaining instances of this now are:

$> grep -r -E "class .*\(object\)\:" Doc/*               
Doc/howto/pyporting.rst:   class UnicodeMixin(object):
Doc/reference/compound_stmts.rst:   class Foo(object):
Doc/tools/sphinxext/pyspecific.py:class PyDecoratorMixin(object):
Doc/whatsnew/2.6.rst:    class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   >>> class C(object):


Which are all (minus tools/sphinxext/pyspecific) referring to python2 in some context.

I'm not bound to fixing the explicit object subclassing, so if it is better off not being here, that's fine.

Cheers,

----------
assignee: docs at python
components: Documentation
files: pelson_doc_decorator.diff
keywords: patch
messages: 183458
nosy: docs at python, pelson, rhettinger
priority: normal
severity: normal
status: open
title: Fixed python3 descriptor documentation example + removal of explicit "object" inheritance in docs
versions: Python 3.1
Added file: http://bugs.python.org/file29305/pelson_doc_decorator.diff

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

From report at bugs.python.org  Mon Mar  4 16:11:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Mar 2013 15:11:32 +0000
Subject: [New-bugs-announce] [issue17352] Be clear that __prepare__ must be
	declared as a static	method
Message-ID: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The docs on __prepare__ don't make it clear that it should be a staticmethod, and the error message if you forget is not obvious at all. (This is particularly so, since the examples in PEP 3115 had it as an ordinary method).

----------
messages: 183463
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Be clear that __prepare__ must be declared as a static method

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

From report at bugs.python.org  Mon Mar  4 21:33:35 2013
From: report at bugs.python.org (Jacques Fortier)
Date: Mon, 04 Mar 2013 20:33:35 +0000
Subject: [New-bugs-announce] [issue17353] Plistlib outputs empty data tags
	when deeply nested
Message-ID: <1362429215.6.0.797287296233.issue17353@psf.upfronthosting.co.za>


New submission from Jacques Fortier:

To reproduce:
import plistlib
print plistlib.writePlistToString([[[[[[[[[{'test': plistlib.Data('aaaaaa')}]]]]]]]]])

Compare to:
print plistlib.writePlistToString([[[[[[[[{'test': Data('aaaaaa')}]]]]]]]])

It looks like the max line length calculation in the Data class is causing the output to be empty once you get nested far enough.

----------
components: Library (Lib)
messages: 183496
nosy: jfortier
priority: normal
severity: normal
status: open
title: Plistlib outputs empty data tags when deeply nested
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 10:56:30 2013
From: report at bugs.python.org (Dmitry Shachnev)
Date: Tue, 05 Mar 2013 09:56:30 +0000
Subject: [New-bugs-announce] [issue17354] TypeError when running setup.py
	upload --show-response
Message-ID: <1362477390.5.0.0948217479976.issue17354@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

When running `python3 setup.py sdist upload --show-response`, one may get this exception:

Traceback (most recent call last):
  File "setup.py", line 47, in <module>
    requires=['dbus']
  File "/usr/lib/python3.2/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.2/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.2/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.2/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/lib/python3.2/distutils/command/upload.py", line 201, in upload_file
    msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
TypeError: sequence item 1: expected str instance, bytes found

This happens because r is binary stream, so r.read() returns bytes. A trivial patch that fixes the problem is attached.

----------
components: Library (Lib)
files: distutils-decode-server-response.patch
keywords: patch
messages: 183517
nosy: mitya57
priority: normal
severity: normal
status: open
title: TypeError when running setup.py upload --show-response
versions: Python 3.3
Added file: http://bugs.python.org/file29312/distutils-decode-server-response.patch

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

From report at bugs.python.org  Tue Mar  5 13:21:27 2013
From: report at bugs.python.org (karl)
Date: Tue, 05 Mar 2013 12:21:27 +0000
Subject: [New-bugs-announce] [issue17355] http tests testing more than the
	error code are fragile
Message-ID: <1362486087.71.0.484772154915.issue17355@psf.upfronthosting.co.za>


New submission from karl:

Some of the tests of the HTTP Test suite are checking for the full status-line, instead of just the error code.


Why is it an issue?

1. The only mandatory part in the status-line is the error code. The phrase is optional. For example the response is made of 3 parts.

   HTTP/1.1 400 Bad Request
   ('HTTP/1.1', '400', 'Bad Request')

Only 400 is the mandatory part of the error code and is testing the error.

2. It creates dependencies on how we conceive, modify the construction of the status-line and error messages.

3. Some tests are testing messages with different "optional texts".

http://hg.python.org/cpython/file/3.3/Lib/test/test_httpservers.py#l640
Test for "HTTP/1.1 400 Line Too Long\r\n".
Instead of just testing "400". (A specific message could be put in the body, but that's informational)

http://hg.python.org/cpython/file/3.3/Lib/test/test_httpservers.py#l633
Test for "HTTP/1.1 414 Request-URI Too Long\r\n"
instead of just testing "414", btw the spec says for the optional message "URI Too Long"
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.5.12

Testing the message, IMHO, should be only, for testing the construction of the message. The tests here are made for testing the right error code, but they try to do more.

Hope it helps :)

Threading: related to http://bugs.python.org/issue12921#msg183520

----------
messages: 183521
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: http tests testing more than the error code are fragile
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar  5 19:12:15 2013
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 05 Mar 2013 18:12:15 +0000
Subject: [New-bugs-announce] [issue17356] Invalid link to repr() built-in
	function description
Message-ID: <1362507135.12.0.423032726441.issue17356@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

References to built-in function repr() links to repr module (http://docs.python.org/2/library/repr.html#module-repr), but must link to description in http://docs.python.org/2/library/functions.html.

It can be at least in http://docs.python.org/2/library/functions.html (link in table at page top).

----------
assignee: docs at python
components: Documentation
messages: 183538
nosy: docs at python, vrutsky
priority: normal
severity: normal
status: open
title: Invalid link to repr() built-in function description
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 19:23:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Mar 2013 18:23:49 +0000
Subject: [New-bugs-announce] [issue17357] Add missing verbosity message to
	importlib
Message-ID: <1362507829.49.0.31047461658.issue17357@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Looks like I missed some verbosity messages in importlib. The most obvious one is the "trying" messages under verbosity 2 (-vv or PYTHONVERBOSE=2). Should probably go through import.c again and make sure no other messages are missing (http://hg.python.org/cpython/file/637d7c953b10/Python/import.c).

----------
components: Interpreter Core
keywords: easy
messages: 183539
nosy: brett.cannon, twouters
priority: normal
severity: normal
stage: needs patch
status: open
title: Add missing verbosity message to importlib
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar  5 20:33:05 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Mar 2013 19:33:05 +0000
Subject: [New-bugs-announce] [issue17358] imp.load_module() leads to the
	improper caching of the	'file' argument
Message-ID: <1362511985.74.0.511214026015.issue17358@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As of right now, if you use imp.load_module(), it will store any 'file' argument you give it in a hacked loader. That's a problem when you call imp.reload() on such a module, though, as subsequent calls to __loader__.load_module() will attempt to use the cached file object which was closed on the initial load. What the code should do is use the hacked loader to load the module, but then set an unhacked loader to __loader__ for reloads to work properly.

Traceback below:

======================================================================
ERROR: test_source (test.test_imp.ReloadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/work/cf49a3092a96daebb23bf3c6e0d86ac9/google3/tmp/lib/python3.3/test/test_imp.py", line 248, in test_source
    imp.reload(os)
  File "/build/work/cf49a3092a96daebb23bf3c6e0d86ac9/google3/tmp/lib/python3.3/imp.py", line 252, in reload
    return module.__loader__.load_module(name)
  File "<frozen importlib._bootstrap>", line 586, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1023, in load_module
  File "<frozen importlib._bootstrap>", line 1004, in load_module
  File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 854, in _load_module
  File "<frozen importlib._bootstrap>", line 978, in get_code
  File "/build/work/cf49a3092a96daebb23bf3c6e0d86ac9/google3/tmp/lib/python3.3/imp.py", line 88, in get_data
    with self.file:
ValueError: I/O operation on closed file.

----------
components: Library (Lib)
keywords: easy
messages: 183549
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: imp.load_module() leads to the improper caching of the 'file' argument
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar  5 20:40:25 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Mar 2013 19:40:25 +0000
Subject: [New-bugs-announce] [issue17359] python modules.zip is not
	documented
Message-ID: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The feature to run a ZIP file containing Python modules is not documented.

It was implemented in Python 2.6:

 * http://bugs.python.org/issue1739468

and mentioned in the "What's new":

 * http://docs.python.org/2/whatsnew/2.6.html?highlight=python%20run%20zip%20files#other-language-changes

but searching the documentation for "__main__.py" returns 0 hits in the docs (for Python 2.7 and 3.4).

I guess "python dir" should also be mentioned somewhere...

----------
assignee: docs at python
components: Documentation
messages: 183550
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: python modules.zip is not documented
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  5 22:47:28 2013
From: report at bugs.python.org (Jeremy Archer)
Date: Tue, 05 Mar 2013 21:47:28 +0000
Subject: [New-bugs-announce] [issue17360] Regular expressions on mmap'd
	files can overflow
Message-ID: <1362520048.77.0.430567108666.issue17360@psf.upfronthosting.co.za>


New submission from Jeremy Archer:

I've recently been having problems with the Python regular expressions module when mmap'ing large (> 2^32 bits) on Linux.

Steps to reproduce:

https://gist.github.com/fatlotus/5094575

I've been able to replicate it on Ubuntu Linux (uname -r = 3.5.0-23-generic). Naturally, this is on a 64-bit platform with Python 2.7.3 installed from APT.

----------
components: Library (Lib), Regular Expressions
messages: 183555
nosy: ezio.melotti, fatlotus, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expressions on mmap'd files can overflow
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 23:09:07 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 05 Mar 2013 22:09:07 +0000
Subject: [New-bugs-announce] [issue17361] use CC to test compiler flags in
	setup.py
Message-ID: <1362521347.71.0.11246460086.issue17361@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Version of gcc compiler may differ between build and host system. As result could be activated unsupported options and build of _decimal module will fail.

----------
components: Cross-Build
files: 0003-ORIGIN-use-CC-to-test-compiler-flags-in-setup.py.patch
keywords: patch
messages: 183556
nosy: doko, rpetrov, skrah
priority: normal
severity: normal
status: open
title: use CC to test compiler flags in setup.py
type: compile error
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29316/0003-ORIGIN-use-CC-to-test-compiler-flags-in-setup.py.patch

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

From report at bugs.python.org  Tue Mar  5 23:22:42 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 05 Mar 2013 22:22:42 +0000
Subject: [New-bugs-announce] [issue17362] enable-new-dtags only for GNU ELF
	linker
Message-ID: <1362522162.88.0.5476696865.issue17362@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

GNU binutils properly document that flag --enable-new-dtags is only available on ELF systems.
I would like to propose a simple hack to avoid activation if ELF is not listed in supported emulations.

Comments in unixccompiler.py are not precise : "# GNU ld needs an extra option to get a RUNPATH ..", i.e. ELF is missing. 

Also GNULD is not correct name for flag. What about to change to GNUELFLD ?

You could test on cygwin for instance.

----------
components: Build
files: 0004-ORIGIN-enable-new-dtags-only-for-GNU-ELF-linker.patch
keywords: patch
messages: 183557
nosy: rpetrov
priority: normal
severity: normal
status: open
title: enable-new-dtags only for GNU ELF linker
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file29317/0004-ORIGIN-enable-new-dtags-only-for-GNU-ELF-linker.patch

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

From report at bugs.python.org  Wed Mar  6 01:05:40 2013
From: report at bugs.python.org (Tobias Becker)
Date: Wed, 06 Mar 2013 00:05:40 +0000
Subject: [New-bugs-announce] [issue17363] Argument Mixup in PyState_AddModule
Message-ID: <1362528340.9.0.203037073378.issue17363@psf.upfronthosting.co.za>


New submission from Tobias Becker:

http://docs.python.org/3.3/c-api/module.html?highlight=pymodule#PyState_AddModule

the arguments of PyState_AddModule are in wrong order:
currently: int PyState_AddModule(PyModuleDef *def, PyObject *module)
correct: int PyState_AddModule(PyObject *module,PyModuleDef *def)

----------
assignee: docs at python
components: Documentation
messages: 183564
nosy: Tobias.Becker, docs at python
priority: normal
severity: normal
status: open
title: Argument Mixup in PyState_AddModule
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar  6 01:38:17 2013
From: report at bugs.python.org (Topher Brown)
Date: Wed, 06 Mar 2013 00:38:17 +0000
Subject: [New-bugs-announce] [issue17364] Multiprocessing documentation
	mentions function that	doesn't exist
Message-ID: <1362530297.79.0.346292892341.issue17364@psf.upfronthosting.co.za>


New submission from Topher Brown:

multiprocessing documentation (http://docs.python.org/2/library/multiprocessing.html#pipes-and-queues) for multiprocessing.Queue mentions Queue.get_no_wait() as an alias for Queue.get_nowait(). This function does not seem to exist.

----------
assignee: docs at python
components: Documentation
messages: 183566
nosy: Topher.Brown, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing documentation mentions function that doesn't exist
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  6 08:06:33 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 06 Mar 2013 07:06:33 +0000
Subject: [New-bugs-announce] [issue17365] Remove Python 2 code from
	test_print
Message-ID: <1362553593.04.0.139053683866.issue17365@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Changes:

* Removed Python 2 specific code
* Re-enabled u'' tests (see PEP 414)
* Cosmetic fixes

----------
components: Tests
files: test_print.diff
keywords: patch
messages: 183581
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Remove Python 2 code from test_print
versions: Python 3.4
Added file: http://bugs.python.org/file29322/test_print.diff

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

From report at bugs.python.org  Wed Mar  6 08:20:02 2013
From: report at bugs.python.org (Dave Humphries)
Date: Wed, 06 Mar 2013 07:20:02 +0000
Subject: [New-bugs-announce] [issue17366] os.chdir win32
Message-ID: <1362554402.61.0.445452595453.issue17366@psf.upfronthosting.co.za>


New submission from Dave Humphries:

os.chdir missed a back slash in rewriting a file path see example below (the extra backslash was missing from the trunk directory). 
Modifying the path with an extra slash enabled this to work for some reason. (os windows 8 64 bit Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 :
spyder console output:
>>> os.chdir("C:\Projects\trunk\BusPirate\dangerous-prototypes-open-hardware-read-only\Bus_Pirate\scripts\pyBusPirateLite")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 123] The filename, directory name or volume label syntax is incorrect: 'C:\\Projects\trunk\\BusPirate\\dangerous-prototypes-open-hardware-read-only\\Bus_Pirate\\scripts\\pyBusPirateLite'
>>> os.chdir("C:\Projects\\trunk\BusPirate\dangerous-prototypes-open-hardware-read-only\Bus_Pirate\scripts\pyBusPirateLite")
>>> from pyBusPirateLite.SPI import *

----------
components: Windows
messages: 183582
nosy: DaveH
priority: normal
severity: normal
status: open
title: os.chdir win32
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  6 13:07:50 2013
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 06 Mar 2013 12:07:50 +0000
Subject: [New-bugs-announce] [issue17367] subprocess deadlock when read() is
	interrupted
Message-ID: <1362571670.86.0.392515841687.issue17367@psf.upfronthosting.co.za>


New submission from John Szakmeister:

I discovered this issue while trying to track down why our upcoming release for Nose 1.3.0 was deadlocking under Ubuntu 12.04 with Python 3.3.  It turns out that the read() was being interrupted leaving data in the subprocess's output buffers, which ultimately means the subprocess is blocked.  Since the thread was exiting, and the read was never retried, we were left in deadlock.

The attached patch fixes the issue.  It wraps the read call with _eintr_retry_call() around the read operation in _readerthread().

----------
components: Library (Lib)
files: fix-subprocess-deadlock.patch
keywords: patch
messages: 183584
nosy: jszakmeister
priority: normal
severity: normal
status: open
title: subprocess deadlock when read() is interrupted
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29323/fix-subprocess-deadlock.patch

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

From report at bugs.python.org  Wed Mar  6 17:31:45 2013
From: report at bugs.python.org (Aki)
Date: Wed, 06 Mar 2013 16:31:45 +0000
Subject: [New-bugs-announce] [issue17368] Python version of JSON decoder
	does not work with	object_pairs_hook
Message-ID: <1362587505.92.0.0585396597719.issue17368@psf.upfronthosting.co.za>


New submission from Aki:

Specifying any object_pairs_hook makes JSON decoding break when JSONObject from json/decoder.py is used.

Can be emulated easily by setting c_make_scanner = None at json/scanner.py

Example script:
**
import json
test = '{"key": "value", "empty": {}}'

def hook(pairs):
    return dict(pairs)

print(json.loads(test, object_pairs_hook=hook))
**

This test will fail because the return statement on line 166 in http://hg.python.org/cpython/file/cfc777407b03/Lib/json/decoder.py lacks "+ 1" even though the statement on line 170 has it. Basically, any empty JSON object will cause "ValueError: Extra data: [...]".

----------
components: Library (Lib)
messages: 183600
nosy: Kuukunen
priority: normal
severity: normal
status: open
title: Python version of JSON decoder does not work with object_pairs_hook
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar  6 23:25:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Mar 2013 22:25:40 +0000
Subject: [New-bugs-announce] [issue17369] Message.get_filename produces
	exception if the RFC2231	encoding is ill-formed
Message-ID: <1362608740.33.0.297004510938.issue17369@psf.upfronthosting.co.za>


New submission from R. David Murray:

>>> m = message_from_string("Content-Disposition: attachment; filename*0*="can't decode this filename")
>>> m.get_filename()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/p32/Lib/email/message.py", line 752, in get_filename
    return utils.collapse_rfc2231_value(filename).strip()
  File "/home/rdmurray/python/p32/Lib/email/utils.py", line 303, in collapse_rfc2231_value
    return str(rawbytes, charset, errors)
TypeError: str() argument 2 must be str, not None

----------
keywords: easy
messages: 183619
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Message.get_filename produces exception if the RFC2231 encoding is ill-formed
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 02:13:04 2013
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 07 Mar 2013 01:13:04 +0000
Subject: [New-bugs-announce] [issue17370] PEP should not if it has been
	superseded
Message-ID: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes:

A friend (@theomn on Twitter) was just working off of PEP-333 when I mentioned to him that PEP-3333, and he had never heard of it, and he expressed the wish that PEPs would have a banner or something at the top if there is a more recent version of them. I think his idea is great, and is like the feature of PyPI where if Google lands you on an old version of a package then it is careful to tell you up at the top that a more recent version is available.

This could extend to all sorts of cross-references that we should maintain: some PEPs have been superseded; others have more recent supplements that people should read as well (think of the relationship between packaging PEPs); PEPs that did not wind up being implemented have cousins who were; and so forth.

Is this something that needs to wait until the New Python Web Site appears, and that would be meta-markup somehow maintained along with the PEP texts themselves? Or should there be a ?Related PEPs? paragraph that we open at the top of each relevant PEP and just include the cross-links as raw updates to the PEP's own restructured text? I'm open to a simple implementation here, so long as we can provide more ?community context? when people land on a PEP.

----------
assignee: docs at python
components: Documentation
messages: 183625
nosy: brandon-rhodes, docs at python
priority: normal
severity: normal
status: open
title: PEP should not if it has been superseded

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

From report at bugs.python.org  Thu Mar  7 04:06:46 2013
From: report at bugs.python.org (Hc.Z)
Date: Thu, 07 Mar 2013 03:06:46 +0000
Subject: [New-bugs-announce] [issue17371] Mismatch between Python 3.3 build
	environment and	distutils compiler support
Message-ID: <1362625606.93.0.881246780096.issue17371@psf.upfronthosting.co.za>


New submission from Hc.Z:

My python environment is Python3.3 in Windows 7 32-bit. I was installing Pandas package from source code, through Microsoft Visual C++ 2008 Express is installed in my computer, the installation process still failed and report a "Unable to find vcvarsall.bat" error.
I checked the problem reading the distutils.msvc9compiler.py module. Class method find_vcvarsall() and query_vcvarall() works well, but get_build_version() return the 10.0. There is no mistakes about this, for sys.version print (MSC v. 1600) vs. in latest Python 2.7 it's (MSC v. 1500) which means vc2008. All document I found pointed that Python Windows binary was built through VC 2008 (version 9.0), and there is only msvc9compiler.py module, no msvc10compiler.py module. 
I don't know whether this is a bug, or there is another compatible mechanics I don't know.
After all, I just want to build Pandas correctly.

----------
components: Windows
messages: 183629
nosy: mayaa
priority: normal
severity: normal
status: open
title: Mismatch between Python 3.3 build environment and distutils compiler support
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar  7 08:18:45 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 07 Mar 2013 07:18:45 +0000
Subject: [New-bugs-announce] [issue17372] provide pretty printer for
	xml.etree.ElementTree
Message-ID: <1362640725.41.0.836381435016.issue17372@psf.upfronthosting.co.za>


New submission from Eric Snow:

minidom already has something like this:

http://docs.python.org/3/library/xml.dom.minidom.html#xml.dom.minidom.Node.toprettyxml

This is something that appears to have almost made it in quite a while ago:

http://effbot.org/zone/element-lib.htm#prettyprint
http://svn.effbot.org/public/stuff/sandbox/elementlib/indent.py

A casual search found several similar implementations out there.  For instance:

http://infix.se/2007/02/06/gentlemen-indent-your-xml

----------
components: Library (Lib), XML
messages: 183635
nosy: eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: provide pretty printer for xml.etree.ElementTree
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar  7 08:51:49 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 07 Mar 2013 07:51:49 +0000
Subject: [New-bugs-announce] [issue17373] Add
	inspect.Signature.from_callable()
Message-ID: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za>


New submission from Eric Snow:

While working on a subclass of inspect.Signature, I realized that inspect.signature is treated as the constructor.  So subclassing isn't so simple.  At first I considered adding an extra parameter to inspect.signature allowing different Signature classes.  Not much later it became clear that all that code should simply be in classmethod.  I've called it Signature.from_callable.  Patch attached.

----------
components: Library (Lib)
files: signature-from-callable.diff
keywords: patch
messages: 183636
nosy: eric.snow, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Add inspect.Signature.from_callable()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29333/signature-from-callable.diff

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

From report at bugs.python.org  Thu Mar  7 09:57:52 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2013 08:57:52 +0000
Subject: [New-bugs-announce] [issue17374] Remove restriction against
	Semaphore having a negative	value
Message-ID: <1362646672.1.0.00506550421469.issue17374@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

I was working through the problem sets in The Little Book of Semaphores (http://www.greenteapress.com/semaphores/downey08semaphores.pdf) and ran into an issue because Python's threading.Semaphore has an unnecessary restriction against having negative values.

That precludes use cases such as simple barriers (i.e. wait on five signals before a wait is released).

Various descriptions of Semaphores allow their counts to be set to arbitrary integer values.  Here's one definition:

   1. When you create the semaphore, you can initialize its 
      value to any integer, but after that the only operations 
      you are allowed to perform are increment (increase by one) 
      and decrement (decrease by one). You cannot read the current
      value of the semaphore.
   2. When a thread decrements the semaphore, if the result is negative,
      the thread blocks itself and cannot continue until another 
      thread increments the semaphore.
   3. When a thread increments the semaphore, if there are other 
      threads waiting, one of the waiting threads gets unblocked.

The patch is simple, remove the guard in the initialization and change the value==0 test with value<=0 to trigger blocking.

A bit of demonstration code is attached.

----------
components: Library (Lib)
files: barrier.py
messages: 183642
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Remove restriction against Semaphore having a negative value
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29334/barrier.py

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

From report at bugs.python.org  Thu Mar  7 10:24:15 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2013 09:24:15 +0000
Subject: [New-bugs-announce] [issue17375] Add docstrings to methods in the
	threading module
Message-ID: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It should be an easy task fill-in the missing docstrings using the verbiage in the regular docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 183645
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Add docstrings to methods in the threading module
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 12:36:17 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 07 Mar 2013 11:36:17 +0000
Subject: [New-bugs-announce] [issue17376] TimedRotatingFileHandler
	documentation regarding 'Week	day' lacking
Message-ID: <1362656177.01.0.275089317243.issue17376@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

Usage of 'W' type is not clear from reading the documentation, specifically how to specify what day-of-week: Doc/library/logging.handlers.rst:291.

An example http://stackoverflow.com/q/14304954/321731.

----------
assignee: docs at python
components: Documentation
messages: 183652
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler documentation regarding 'Week day' lacking
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 13:06:14 2013
From: report at bugs.python.org (Sven Slootweg)
Date: Thu, 07 Mar 2013 12:06:14 +0000
Subject: [New-bugs-announce] [issue17377] JSON module in standard library
	behaves incorrectly on	input like a psutil constant
Message-ID: <1362657974.02.0.982838545875.issue17377@psf.upfronthosting.co.za>


New submission from Sven Slootweg:

When faced with a subclass of int like a psutil constant (such as for process status), that actually returns a non-numeric string when used with str(), the JSON module will serialize it as a string without quotes.

An example... Code (Python):

[...] "key": psutil._common.constant(0, "value"), "otherkey": "real string"  [...]

Output (JSON):

[...] "key": value, "otherkey": "real string" [...]

Due to the missing quotes around 'value', the JSON data is corrupted.

The cause appears to be that the JSON module, when faced with an int (or subclass thereof), will use the string representation in the serialized data, which would normally be the integer as a string. This example uses a psutil constant, but this would occur with any int subclass that doesn't return itself as string representation.

I'm not entirely sure how to resolve this issue or whether it can be resolved at all, as all possible solutions appear to have negative side-effects for more common cases. I'd imagine that checking whether the resulting string is numeric, besides being error-prone, would also cause unreasonable overhead during serialization.

----------
components: Library (Lib)
messages: 183653
nosy: joepie91
priority: normal
severity: normal
status: open
title: JSON module in standard library behaves incorrectly on input like a psutil constant
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  7 14:58:47 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 07 Mar 2013 13:58:47 +0000
Subject: [New-bugs-announce] [issue17378] Document that ctypes automatically
	applies byref() when	argtypes declares POINTER
Message-ID: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

While playing with ctypes a bit, I noticed a feature that doesn't appear to be documented. Suppose I import the readdir_r function (assuming DIRENT is a correctly declared ctypes.Structure):

DIR_p = c_void_p
DIRENT_p = POINTER(DIRENT)
DIRENT_pp = POINTER(DIRENT_p)

readdir_r = lib.readdir_r
readdir_r.argtypes = [DIR_p, DIRENT_p, DIRENT_pp]
readdir_r.restype = c_int

It seems that I can then call it as follows:

dirent = DIRENT()
result = DIRENT_p()

readdir_r(dir_fd, dirent, result)

Note that while readdir_r takes DIRENT_p and DIRENT_pp as its second and third args, I pass in just DIRENT and DIRENT_p, accordingly. What I should have done is use byref() on both, but ctypes seems to have some magic applied when argtypes declares pointer types. If I use byref, it still works. However, if I keep the same call and comment out the argtypes declaration, I get a segfault.

This behavior of ctypes should be documented.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 183661
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that ctypes automatically applies byref() when argtypes declares POINTER
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 16:29:39 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Mar 2013 15:29:39 +0000
Subject: [New-bugs-announce] [issue17379] Zen amendment
Message-ID: <1362670179.84.0.620093919889.issue17379@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Tim came up  with a fitting amendment to the Zen of Python. It pretty much sums up our future Code of Conduct in one sentence. But see for yourself! ;)

----------
files: zen_amendment.patch
keywords: patch
messages: 183671
nosy: christian.heimes, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: Zen amendment
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29342/zen_amendment.patch

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

From report at bugs.python.org  Thu Mar  7 18:12:17 2013
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Thu, 07 Mar 2013 17:12:17 +0000
Subject: [New-bugs-announce] [issue17380] initproc return value is unclear
Message-ID: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

initproc is declared to return an int, but what returned values mean is not documented. Noddy_init in http://docs.python.org/3/extending/newtypes.html?highlight=initproc#adding-data-and-methods-to-the-basic-example can be seen to return 0 on success and -1 on error, but that's about it.

Also, when I wrote a function which return 1 on error, on every second invocation the exception would be ignored:
static int Reader_init(Reader *self, PyObject *args, PyObject *keywds)
{
    ...
    if (flags && path) {
            PyErr_SetString(PyExc_ValueError, "cannot use both flags and path");
            return 1;
    }
    ...
}

>>> obj(123, '/tmp')
>>> obj(123, '/tmp')
...
ValueError
>>> obj(123, '/tmp')
>>> obj(123, '/tmp')
...
ValueError

I'm not sure how to interpret this since I couldn't find the documentation for the expected value.

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 183689
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: initproc return value is unclear
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 21:52:32 2013
From: report at bugs.python.org (Chris Adams)
Date: Thu, 07 Mar 2013 20:52:32 +0000
Subject: [New-bugs-announce] [issue17381] IGNORECASE breaks unicode literal
	range matching
Message-ID: <1362689552.47.0.00880933015098.issue17381@psf.upfronthosting.co.za>


New submission from Chris Adams:

I noticed an interesting failure while using re.match / re.sub to look for non-Cyrillic characters in allegedly Russian text:

>>> re.sub(r'[\s\u0400-\u0527]+', ' ', '????????????? ????????', flags=re.IGNORECASE)
'????????????? ????????'
>>> re.sub(r'[\s\u0400-\u0527]+', '', '????????????? ????????', flags=0)
''

The same is true in Python 2.7, although you need to use ur'' patterns for the literals to be expanded:

>>> re.sub(ur'[\s\u0400-\u0527]+', '', u'????????????? ????????', flags=re.IGNORECASE|regex.UNICODE)
u'\u0410\u0440\u0445\u0430\u043d\u0433\u0435\u043b\u044c\u0441\u043a\u0430\u044f\u0433\u0443\u0431\u0435\u0440\u043d\u0438\u044f'


In contrast, the regex module behaves as expected:

>>> regex.sub(ur'[\s\u0400-\u0527]+', '', u'????????????? ????????', flags=regex.IGNORECASE|regex.UNICODE)
u''

(Transcript maintained at https://gist.github.com/acdha/5111687)

----------
components: Regular Expressions
messages: 183705
nosy: acdha, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: IGNORECASE breaks unicode literal range matching
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Mar  8 00:18:38 2013
From: report at bugs.python.org (Dirk Zabel)
Date: Thu, 07 Mar 2013 23:18:38 +0000
Subject: [New-bugs-announce] [issue17382] debugging with idle: current line
	not highlighted
Message-ID: <1362698318.37.0.972993437796.issue17382@psf.upfronthosting.co.za>


New submission from Dirk Zabel:

When debugging with IDLE with checkbox "Source" enabled, the source window highlights the current line only when the source window is activated. If one of the buttons of the IDLE debug window is pressed ("Step", "Over" or "Out"), the source window is no longer active and the highlighting of the current line disappears. This makes stepwise execution quite boring.

This effect seems to be os specific. I found it on Windows XP SP3 and Windows 7 X64 SP1 both with Python 3.2 and Python 3.2.
I tried both Python 3.2 and Python 3.3 on Ubuntu 12.4 LTS, and the problem did not show up.
So it seems to be a windows-only problem.

----------
components: IDLE
messages: 183711
nosy: dzabel
priority: normal
severity: normal
status: open
title: debugging with idle: current line not highlighted
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar  8 00:55:00 2013
From: report at bugs.python.org (Piotr Kuchta)
Date: Thu, 07 Mar 2013 23:55:00 +0000
Subject: [New-bugs-announce] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
Message-ID: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>


New submission from Piotr Kuchta:

In the 2.7 tutorial, chapter on modules:

 http://docs.python.org/2/tutorial/modules.html#more-on-modules 

I think the last sentence in this paragraph is incorrect:

"Modules can import other modules. It is customary but not required to place all import statements at the beginning of a module (or script, for that matter). The imported module names are placed in the importing module?s global symbol table."

This is not true:

>>> def foo(): import sys
... 
>>> foo()
>>> sys.path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sys' is not defined

----------
assignee: docs at python
components: Documentation
messages: 183715
nosy: Piotr.Kuchta, docs at python
priority: normal
severity: normal
status: open
title: Error in documentation /2/tutorial/modules.html#more-on-modules
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  8 06:02:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Mar 2013 05:02:44 +0000
Subject: [New-bugs-announce] [issue17384] test_logging failures on Windows
Message-ID: <1362718964.15.0.969959880572.issue17384@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

test_logging is failing on some buildbots:
     test_logging::AMD64 Windows7 SP1 3.x a0b750 42970c 9aafc0
     test_logging::x86 Windows Server 2003 [SB] 3.x 9aafc0 6b69c1 c261b7
     test_logging::x86 XP-4 3.x 6b69c1 c261b7
     test_logging::x86 XP-5 3.x c261b7 7e8184

Only the Windows buildbots on 3.x seems to be affected.  The failing tests were introduced in #11557.

See e.g.:
http://buildbot.python.org/builders/x86%20XP-5%203.x/builds/1946/steps/test/logs/stdio

======================================================================
ERROR: test_filemode (test.test_logging.BasicConfigTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\unittest\case.py", line 385, in _executeTestPart
    function()
  File "D:\Buildslave\3.x.moore-windows\build\lib\unittest\case.py", line 484, in <lambda>
    part = lambda: function(*args, **kwargs)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'test.log'

======================================================================
ERROR: test_filename (test.test_logging.BasicConfigTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\unittest\case.py", line 385, in _executeTestPart
    function()
  File "D:\Buildslave\3.x.moore-windows\build\lib\unittest\case.py", line 484, in <lambda>
    part = lambda: function(*args, **kwargs)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'test.log'

----------------------------------------------------------------------
Ran 145 tests in 7.234s

FAILED (errors=2, skipped=2)

----------
assignee: vinay.sajip
keywords: buildbot
messages: 183726
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failures on Windows
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar  8 07:16:26 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Mar 2013 06:16:26 +0000
Subject: [New-bugs-announce] [issue17385] Use deque instead of list the
	threading.Condition waiter	queue
Message-ID: <1362723386.92.0.340971682948.issue17385@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Condition variables implement a FIFO queue for waiting threads.  The current implementation uses a regular Python list but could use a deque instead.

A wait() call appends a new waiter.   A notify() call removes the oldest waiter; this is an O(n) operation on list but only an O(1) operation on deques.  A notify_all() call is O(n**2) for a list but only O(n) for a deque.

If there is interest in this patch, I can add slicing support to collections.deque so that this patch won't need itertools.islice()

----------
files: condition.diff
keywords: patch
messages: 183727
nosy: pitrou, rhettinger
priority: normal
severity: normal
status: open
title: Use deque instead of list the threading.Condition waiter queue
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file29348/condition.diff

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

From report at bugs.python.org  Fri Mar  8 23:33:14 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Mar 2013 22:33:14 +0000
Subject: [New-bugs-announce] [issue17386] Bring Doc/make.bat as close to
	Doc/Makefile as possible
Message-ID: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I have found Doc/make.bat to be very useful, but I have hit a few of its limitations now and then.  Thus, I have made extensive modifications to bring it much closer to the way Doc/Makefile works.  Among the things changed in the attached patch:

- Use pushd/popd to make sure everything is done in the Doc directory.

- Allow variables to be set on the command line, e.g.:
       make html "PYTHON2=python"

- Set PYTHON2 and PYTHON3 variables separately; the Sphinx version and associated tools we're currently using want Python 2, which defaults to "py -2".  Other tools, like Tools/scripts/serve.py (the make serve target), expect Python 3; setting the default PYTHON3 searches for python(_d).exe in PCbuild(\amd64), and falls back to "py -3" if not found.

- Set the HTML Help Workshop default path to %ProgramFiles(x86)%\..., if that variable is defined. (If I understand correctly, that variable is only defined on x64 installations, and in cases where it is not defined on x64, %ProgramFiles% silently copies %ProgramFiles(x86)%.)

- Convert target choice to a single for loop, rather than several lines of if.  Anything not in the list falls through to the help message.

- Expand the help message to match the message given by Doc/Makefile

- Add the "clean" target, which does the same as Makefile

- Reimplement "update" to match Makefile (call clean, call checkout.  I do wonder if maybe it should be done the other way around, though; reimplement Makfile's "update" target to simply update the svn checkouts, rather than re-pull them)

- Add separate labels for each target.  The old method of sending everything to :build was very clever and kept the file short, but limited flexibility.  It's also nice to get a message at the end (matching Makefile), which is much easier to do with separate labels.

- Add support for the PAPER environment variable in LaTeX building.

- Add coverage, doctest, pydoc-topics, dist, check, and serve targets.  "dist" cannot be completed in the same way with default tools on Windows, so all it does is build html, text, latex (a4 and letter), and epub and copy them into the dist directory.

- checkout checks for the existence of the checked out packages before checking out

- build calls checkout before building, so you can go right to "make html" instead of having to do "make checkout && make html"

- Add support for SOURCES and SPHINXOPTS environment variables.

Everything seems to work for me, but I've only been able to test on Windows 7 (32 and 64 bit).  I don't believe there's anything in there that doesn't exist in XP, though.  Also, since this version of the file has a lot of labels, this patch does somewhat rely on resolution of issue 17202.  It should probably work without any changes to .hgeol, but that can't be guaranteed.

There are a couple of drawbacks to the patched version; it's a much longer file, and it does lose a good chunk of the elegance of the original solution.  If anyone has any suggestions for regaining some of that elegance without losing any of the functionality, I am of course all ears :). In particular, I'm not a huge fan of having to have "pushd ." at the beginning of every label, but the only other solutions I came up with involved setting and unsetting a "DISALLOW_POPD" variable in several places, and a condition on the popd at :end, or forgetting the pushd/popd thing entirely.

I'm looking forward to hearing what anyone else thinks of this, positive or negative :)

----------
assignee: docs at python
components: Build, Documentation, Windows
files: win_doc_make.diff
keywords: patch
messages: 183768
nosy: christian.heimes, docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Bring Doc/make.bat as close to Doc/Makefile as possible
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29353/win_doc_make.diff

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

From report at bugs.python.org  Sat Mar  9 01:58:30 2013
From: report at bugs.python.org (Alex Orange)
Date: Sat, 09 Mar 2013 00:58:30 +0000
Subject: [New-bugs-announce] [issue17387] Error in C API documentation of
	PySequenceMethods
Message-ID: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>


New submission from Alex Orange:

The documentation at http://docs.python.org/2/c-api/typeobj.html#PySequenceMethods is missing sq_slice between sq_item and sq_ass_item. This will mess up anyone trying to use anything after sq_item (that isn't using designated initializers).

----------
assignee: docs at python
components: Documentation
messages: 183779
nosy: Alex.Orange, docs at python
priority: normal
severity: normal
status: open
title: Error in C API documentation of PySequenceMethods
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar  9 10:07:29 2013
From: report at bugs.python.org (Chris Tandiono)
Date: Sat, 09 Mar 2013 09:07:29 +0000
Subject: [New-bugs-announce] [issue17388] Providing invalid value to
Message-ID: <1362820049.53.0.165756235427.issue17388@psf.upfronthosting.co.za>


New submission from Chris Tandiono:

Currently, random.sample(population, k) raises a ValueError if k is out of the range of [0, len(population)], inclusive. However, the message says "Sample larger than population" even when the real problem is that k < 0. The attached patch fixes that.

The problem exists in all versions of Python that have the random.sample function.

I think I should be adding tests for this, but I don't know in what existing file, if any, this test should go into.

----------
components: Library (Lib)
files: random_sample.patch
keywords: patch
messages: 183808
nosy: Chris.Tandiono
priority: normal
severity: normal
status: open
title: Providing invalid value to
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29354/random_sample.patch

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

From report at bugs.python.org  Sat Mar  9 12:42:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Mar 2013 11:42:27 +0000
Subject: [New-bugs-announce] [issue17389] Optimize Event.wait()
Message-ID: <1362829347.05.0.139700597073.issue17389@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It should be possible to optimize threading.Event.wait() to not acquire the condition when the event is already set. Patch attached.

Without patch:

$ ./python -m timeit -s "import threading; e = threading.Event(); e.set()" "e.wait()"
1000000 loops, best of 3: 0.466 usec per loop

With patch:

$ ./python -m timeit -s "import threading; e = threading.Event(); e.set()" "e.wait()"
10000000 loops, best of 3: 0.19 usec per loop

----------
components: Library (Lib)
files: event_wait.patch
keywords: patch
messages: 183811
nosy: neologix, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize Event.wait()
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file29355/event_wait.patch

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

From report at bugs.python.org  Sun Mar 10 13:56:34 2013
From: report at bugs.python.org (bagrat lazaryan)
Date: Sun, 10 Mar 2013 12:56:34 +0000
Subject: [New-bugs-announce] [issue17390] display python version on idle
	title bar
Message-ID: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za>


New submission from bagrat lazaryan:

useful for those who routinely use different versions of python on idle. as it ships, idle displays "python shell" on its title bar. it would be useful to have there the version displayed as well.

see http://bagratte.blogspot.it/2013/03/display-python-version-on-idle-title-bar_10.html

----------
components: IDLE
messages: 183874
nosy: bagratte
priority: normal
severity: normal
status: open
title: display python version on idle title bar
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 10 15:18:23 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 10 Mar 2013 14:18:23 +0000
Subject: [New-bugs-announce] [issue17391] _cursesmodule Fails to Build on
	GCC 2.95 (static)
Message-ID: <1362925103.81.0.892590106021.issue17391@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

When compiling Modules/_cursesmodule.c as a static module with GCC 2.95.3, an error is encountered on line 2260 in PyCurses_GetWin.  The error occurs because the PyCursesInitialised macro appears prior _Py_IDENTIFIER(read), which is actually a variable declaration.  Switching the order of the statements fixes the issue.

In all other functions within Modules/_cursesmodule.c, PyCursesInitialised always appears after all variable declarations.

This bug was encountered on the platform m68k-atari-mint using Python 3.3.0 and GCC 2.95.3.

----------
components: Build
files: curses.patch
keywords: patch
messages: 183877
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: _cursesmodule Fails to Build on GCC 2.95 (static)
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file29365/curses.patch

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

From report at bugs.python.org  Sun Mar 10 20:36:22 2013
From: report at bugs.python.org (Simon Wagner)
Date: Sun, 10 Mar 2013 19:36:22 +0000
Subject: [New-bugs-announce] [issue17392] Python installer for Windows
	packages wrong zipfile.py
Message-ID: <1362944182.73.0.355827245309.issue17392@psf.upfronthosting.co.za>


New submission from Simon Wagner:

Wrong version of zipfile.py is packaged with the Windows installer for Python 3.2 and 3.3. It seems to be the version from 3.1.

Other files might also be wrong, I did not check.

----------
components: Installation, Windows
messages: 183892
nosy: Simon.Wagner
priority: normal
severity: normal
status: open
title: Python installer for Windows packages wrong zipfile.py
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 10 21:22:54 2013
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 10 Mar 2013 20:22:54 +0000
Subject: [New-bugs-announce] [issue17393] stdlib import mistaken for local
	by import_fixer
Message-ID: <1362946974.63.0.419293411414.issue17393@psf.upfronthosting.co.za>


New submission from Lennart Regebro:

If you have a local folder (without an __init__.py, hence just a normal folder) with the same name as a non local module, the import statements of that module will assumed to be local and transformed from for example ``import datetime`` to ``from . import datetime``.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 183894
nosy: lregebro
priority: normal
severity: normal
status: open
title: stdlib import mistaken for local by import_fixer
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 11 04:20:21 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Mar 2013 03:20:21 +0000
Subject: [New-bugs-announce] [issue17394] Add slicing support to
	collections.deque
Message-ID: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Once added, use it in threading.Condition().

----------
assignee: rhettinger
components: Library (Lib)
messages: 183918
nosy: rhettinger
priority: low
severity: normal
status: open
title: Add slicing support to collections.deque
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 11 07:06:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Mar 2013 06:06:13 +0000
Subject: [New-bugs-announce] [issue17395] Wait for live children in
	test_multiprocessing
Message-ID: <1362981973.71.0.196471056515.issue17395@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

While running test_multiprocessing I get:
[...]
test_wait_return (test.test_multiprocessing.WithManagerTestBarrier) ... ok
Shared objects which still exist at manager shutdown:
  b6b802d4:       refcount=1
    <threading.Barrier object at 0xb6b802d4>
  b6b80ea4:       refcount=1
    <threading.Event object at 0xb6b80ea4>
  b6b83264:       refcount=1
    [True, True, True, True]
  b6b836fc:       refcount=1
    [16092, 16094, 16091, 16096]
  b6b89884:       refcount=2
    <threading.Barrier object at 0xb6b89884>
  b6b89ea4:       refcount=1
    []
  b6b8b7dc:       refcount=1
    <queue.Queue object at 0xb6b8b7dc>
  b6b8bc3c:       refcount=1
    [16092, 16094, 16096, 16091]
test_notify (test.test_multiprocessing.WithManagerTestCondition) ... ok
[...]
test_event (test.test_multiprocessing.WithManagerTestEvent) ... ok
Shared objects which still exist at manager shutdown:
  b6dcc7a4:       refcount=1
    <threading.Event object at 0xb6dcc7a4>
test_lock (test.test_multiprocessing.WithManagerTestLock) ... ok
[...]

This seems to be caused by the fact that when multiprocessing.active_children() is called in test_multiprocessing.ManagerMixin.tearDownClass(), some of them are still marked as active.
I tried to add a sleep before the active_children() call and the output disappeared.  On my machine it takes about half second.

The attached patch checks in loop that there no active children left, waiting up to 5s in increasing time intervals starting from 0.01s (so in the best case scenario it won't wait at all, and in the worst it will wait ~5s and possibly report the shared objects that still exists).

----------
components: Tests
files: slowmulti.diff
keywords: patch
messages: 183935
nosy: ezio.melotti, jnoller, pitrou, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Wait for live children in test_multiprocessing
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29372/slowmulti.diff

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

From report at bugs.python.org  Mon Mar 11 13:03:45 2013
From: report at bugs.python.org (Jan Gosmann)
Date: Mon, 11 Mar 2013 12:03:45 +0000
Subject: [New-bugs-announce] [issue17396] modulefinder fails if module
	contains syntax error
Message-ID: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za>


New submission from Jan Gosmann:

Running modulefinder.ModuleFinder.run_script on a script which has an import statement with a module containing a syntax error will raise a SyntaxError exception. I think, modulefinder should instead continue its analysis and add the module to badmodules. Especially, as there are valid reasons for importing modules with syntax errors like in the following code snippet

if not python3:
    from .exec_py2 import exec_
else:
    from .exec_py3 import exec_

I attached a patch which changes the code to catch potential SyntaxError exceptions and change them to an ImportError.

----------
components: Library (Lib)
files: fix-handling-of-syntax-errors.diff
keywords: patch
messages: 183953
nosy: jgosmann
priority: normal
severity: normal
status: open
title: modulefinder fails if module contains syntax error
versions: Python 2.7
Added file: http://bugs.python.org/file29376/fix-handling-of-syntax-errors.diff

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

From report at bugs.python.org  Mon Mar 11 13:43:17 2013
From: report at bugs.python.org (klappnase)
Date: Mon, 11 Mar 2013 12:43:17 +0000
Subject: [New-bugs-announce] [issue17397] ttk::themes missing form ttk.py
Message-ID: <1363005797.61.0.988966555267.issue17397@psf.upfronthosting.co.za>


New submission from klappnase:

When trying to load third-party themes ttk.Style.theme_names() fails to list available themes. For example if the themes from the tile-themes project are installed one can do:

>>> from tkinter import *
>>> from tkinter import ttk
>>> root=Tk()
>>> s=ttk.Style()
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('classic', 'default', 'clam', 'alt')
>>> root.tk.call('package', 'require', 'tile-themes')
'0.6'
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('keramik', 'plastik', 'clam', 'winxpblue', 'alt', 'Aquativo', 'classic', 'default', 'keramik_alt')
>>> 

This has been discussed in more detail at tkinter-discuss:
http://code.activestate.com/lists/python-tkinter-discuss/3373/

As ttk::themes is described as being part of the Public API inside ttk.tcl and is also documented in the tcl wiki at http://wiki.tcl.tk/14796 resp. http://wiki.tcl.tk/23676 it appears safe to add it to ttk.py.

Considering this I prepared a patch (against b10a9d4f08eb) that adds the following method to ttk.Style():

    def themes(self, pattern=None):
        '''Returns a list of theme names available. It can be passed an
        argument which is used as an lsearch glob pattern while looking
        for the theme names.'''
        return self.tk.splitlist(self.tk.call('ttk::themes', pattern))

----------
components: Tkinter
files: patch_ttk.diff
keywords: patch
messages: 183954
nosy: klappnase
priority: normal
severity: normal
status: open
title: ttk::themes missing form ttk.py
type: enhancement
Added file: http://bugs.python.org/file29377/patch_ttk.diff

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

From report at bugs.python.org  Mon Mar 11 18:22:56 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 11 Mar 2013 17:22:56 +0000
Subject: [New-bugs-announce] [issue17398] document url argument of
	RobotFileParser
Message-ID: <1363022576.74.0.509640263285.issue17398@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

Looking at the documentation, one would think RobotFileParser does not accept any argument, but it does -- "url".

Documenting this would remove the pain of having to call "set_url()".

----------
assignee: docs at python
components: Documentation
messages: 183979
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: document url argument of RobotFileParser
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 12 01:04:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2013 00:04:04 +0000
Subject: [New-bugs-announce] [issue17399] test_multiprocessing hang on
	Windows, non-sockets
Message-ID: <1363046644.27.0.443258211441.issue17399@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

test_multiprocessing is giving multiple errors like
Process Process-21:
Traceback (most recent call last):
  File "F:\Python\dev\py27\lib\multiprocessing\process.py", line 258, in _bootstrap
    self.run()
  File "F:\Python\dev\py27\lib\multiprocessing\process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "F:\Python\dev\py27\lib\test\test_multiprocessing.py", line 1703, in _test
    conn.send('hello')
IOError: [Errno 10038] An operation was attempted on something that is not a socket
...
  File "F:\Python\dev\py27\lib\test\test_multiprocessing.py", line 1419, in _putter
    manager.connect()
  File "F:\Python\dev\py27\lib\multiprocessing\managers.py", line 500, in connect
    conn = Client(self._address, authkey=self._authkey)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 465, in XmlClient
    return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 175, in Client
    answer_challenge(c, authkey)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 420, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10038] An operation was attempted on something that is not a socket

After a few of these, it hangs and I have to either kill multiple processes with TaskManager (or maybe kill-python would work) or kill the console. All tracebacks seem to one of these two. The common factor is 'not a socket'. It seems that something in the test should be skipped on windows. I got similar results running test_multiprocessing by itself. The process numbers are haphazard.

----------
messages: 184000
nosy: ezio.melotti, sbt, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing hang on Windows, non-sockets
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Mar 12 02:36:57 2013
From: report at bugs.python.org (Lei Miao)
Date: Tue, 12 Mar 2013 01:36:57 +0000
Subject: [New-bugs-announce] [issue17400] ipaddress.is_private needs to take
	into account of	rfc6598
Message-ID: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>


New submission from Lei Miao:

Currently: ipaddress.IPv4Network('100.64.1.0/24').is_private == False


Given RFC6598, 100.64.0.0/10 is now approved for use as CGN space, and also for rfc1918-like private usage. Could the code be altered so that is_private will return true for 100.64.0.0/10 as well??

----------
components: Library (Lib)
messages: 184002
nosy: leim
priority: normal
severity: normal
status: open
title: ipaddress.is_private needs to take into account of rfc6598
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 12 04:12:07 2013
From: report at bugs.python.org (Robert Collins)
Date: Tue, 12 Mar 2013 03:12:07 +0000
Subject: [New-bugs-announce] [issue17401] io.FileIO closefd parameter is not
	documented nor shown	in repr
Message-ID: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za>


New submission from Robert Collins:

the docs (http://docs.python.org/3.x/library/io.html#io.FileIO) do not document closefd, and AFAICT it isn't possible to tell if closefd is set after the object is created. Specifically it does not show up in the repr().

>>> import sys
>>> sys.stdout
<_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
>>> sys.stdout.buffer
<_io.BufferedWriter name='<stdout>'>
>>> sys.stdout.buffer.raw
<_io.FileIO name='<stdout>' mode='wb'>

If one wants to reopen sys.std in non-buffered mode, the right thing to do according to a recent thread on python-ideas is to use fdopen - e.g.

mystream = io.open(sys.stdout.fileno(), 'wt', 0) 
but this will set closefd to True in the new object, which results in hilarity when it gets garbage collected. And you cannot tell or compare that to the original stdout because of the lack of exposure of this attribute and it's implications. (Does it close the fd on __del__? After each operation? On close() being called on the FileIO object?)

----------
messages: 184003
nosy: rbcollins
priority: normal
severity: normal
status: open
title: io.FileIO closefd parameter is not documented nor shown in repr
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 12 08:21:15 2013
From: report at bugs.python.org (py.user)
Date: Tue, 12 Mar 2013 07:21:15 +0000
Subject: [New-bugs-announce] [issue17402] In mmap doc examples map() is
	shadowed
Message-ID: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/mmap.html

examples use map as a name for the mmap object

----------
assignee: docs at python
components: Documentation
messages: 184015
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In mmap doc examples map() is shadowed
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 12 11:58:24 2013
From: report at bugs.python.org (Ben Mezger)
Date: Tue, 12 Mar 2013 10:58:24 +0000
Subject: [New-bugs-announce] [issue17403] Robotparser fails to parse some
	robots.txt
Message-ID: <1363085904.54.0.398684856881.issue17403@psf.upfronthosting.co.za>


New submission from Ben Mezger:

I am trying to parse Google's robots.txt (http://google.com/robots.txt) and it fails when checking whether I can crawl the url /catalogs/p? (which it's allowed) but it's returning false, according to my question on stackoverflow -> http://stackoverflow.com/questions/15344253/robotparser-doesnt-seem-to-parse-correctly

Someone has answered it has to do with the line "rllib.quote(urlparse.urlparse(urllib.unquote(url))[2])" in robotparser's module, since it removes the "?" from the end of the url. 

Here is the answer I received -> http://stackoverflow.com/a/15350039/1649067

----------
components: Library (Lib)
messages: 184017
nosy: benmezger
priority: normal
severity: normal
status: open
title: Robotparser fails to parse some robots.txt
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 12 15:42:40 2013
From: report at bugs.python.org (Robert Collins)
Date: Tue, 12 Mar 2013 14:42:40 +0000
Subject: [New-bugs-announce] [issue17404] ValueError: can't have unbuffered
	text I/O for io.open(1, 'wt', 0)
Message-ID: <1363099360.99.0.903638972832.issue17404@psf.upfronthosting.co.za>


New submission from Robert Collins:

The io library rejects unbuffered text I/O, but this is not documented - and in fact can be manually worked around:
    binstdout = io.open(sys.stdout.fileno(), 'wt', 0)
    sys.stdout = io.TextIOWrapper(binstdout, encoding=sys.stdout.encoding)
will get a sys.stdout that is unbuffered.

Note that writing to a pipe doesn't really need to care about buffering anyway, if the user writes 300 characters, the codec will output a single block and the IO made will be one write:

This test script:
import sys
import io
stream = io.TextIOWrapper(io.open(sys.stdout.fileno(), 'wb', 0), encoding='utf8')
for r in range(10):
  stream.write(u'\u1234'*500)

When run under strace -c does exactly 10 writes: so the performance is predictable. IMO it doesn't make sense to prohibit unbuffered text write I/O. readers may be another matter, but that doesn't suffer the same latency issues.

----------
messages: 184025
nosy: rbcollins
priority: normal
severity: normal
status: open
title: ValueError: can't have unbuffered text I/O for io.open(1, 'wt', 0)
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 12 17:54:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 12 Mar 2013 16:54:12 +0000
Subject: [New-bugs-announce] [issue17405] Add _Py_memset_s() to securely
	clear memory
Message-ID: <1363107252.29.0.782882608.issue17405@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Compilers like GCC optimize away code like memset(var, 0, sizeof(var)) if the code occurs at the end of a function and var is not used anymore [1]. But security relevant code like hash and encryption use this to overwrite sensitive data with zeros.

The code in _sha3module.c uses memset() to clear its internal state. The other hash modules don't clear their internal states yet.


There exists a couple of solutions for the problem:

 * C11 [ISO/IEC 9899:2011] has a memset_s() function
 * MSVC has SecureZeroMemory()
 * GCC can disable the optimization with #pragma GCC optimize ("O0") since GCC 4.4
 * [2] contains an example for a custom implementation of memset_s() with volatile.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537

[2] https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data

----------
assignee: christian.heimes
messages: 184032
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add _Py_memset_s() to securely clear memory
type: security
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 13 00:03:04 2013
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Gillibert?=)
Date: Tue, 12 Mar 2013 23:03:04 +0000
Subject: [New-bugs-announce] [issue17406] Upload Windows 9x/NT4 build
Message-ID: <1363129384.27.0.735885871305.issue17406@psf.upfronthosting.co.za>


New submission from Andr? Gillibert:

Since Python 2.6 and 2.7 officially don't support Windows 95/98/Me and Windows NT 3.51/4.0, I created a build running on these Windows versions.

May I upload them so you can show them on your Web site?

----------
components: Build
messages: 184057
nosy: NanoTech
priority: normal
severity: normal
status: open
title: Upload Windows 9x/NT4 build
type: enhancement
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Mar 13 00:57:03 2013
From: report at bugs.python.org (James Kesser)
Date: Tue, 12 Mar 2013 23:57:03 +0000
Subject: [New-bugs-announce] [issue17407] RotatingFileHandler issue when
	using multiple loggers	instances (but one process/thread) to
	the same file
Message-ID: <1363132623.49.0.98073813861.issue17407@psf.upfronthosting.co.za>


New submission from James Kesser:

I believe I have come across a bug with RotatingFileHandler in logging/handlers.py

The attached script shows that when you are logging using RotatingFileHandler pointed at the same file from multiple logger instances, it works at first showing logging events from each. However, after the first rotation occurs, the events seem to be "group" together and do not get logged in order. Instead they are logged in groups according to which instance is performing the logging.

NOTE: While searching for a bug report of this issue I was flooded with issues relating to multiple processes. This is not the case here. I have attached a script and the log files that are generated when running this as a single process / thread.

first log file contains:

a aaa...
b bbb...
a aaa...
b bbb...
a aaa...
b bbb...
a aaa...
b bbb...
a aaa...

subsequent log files contain events all from either a or b only, not intertwined like you would expect.

I first noticed this using v2.4.3 of the logging library, however I was able to reproduce this on 2.7 and 3.3 as well.

----------
components: Library (Lib)
files: rotating_file_handler_test.tar
messages: 184061
nosy: James.Kesser
priority: normal
severity: normal
status: open
title: RotatingFileHandler issue when using multiple loggers instances (but one process/thread) to the same file
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file29393/rotating_file_handler_test.tar

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

From report at bugs.python.org  Wed Mar 13 15:09:54 2013
From: report at bugs.python.org (Vlad)
Date: Wed, 13 Mar 2013 14:09:54 +0000
Subject: [New-bugs-announce] [issue17408] second python execution fails when
	embedding
Message-ID: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za>


New submission from Vlad:

This issue is for Python3.3 and doesn't exist in Python3.2

Detailed description with source code can be found here:
http://stackoverflow.com/questions/15387035/second-python-execution-fails

----------
components: None
messages: 184081
nosy: theDarkBrainer
priority: normal
severity: normal
status: open
title: second python execution fails when embedding
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar 13 16:18:35 2013
From: report at bugs.python.org (Paul Price)
Date: Wed, 13 Mar 2013 15:18:35 +0000
Subject: [New-bugs-announce] [issue17409] resource.setrlimit doesn't respect
	-1
Message-ID: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>


New submission from Paul Price:

The docs for resource.setrlimit (http://docs.python.org/2.7/library/resource.html#resource.setrlimit) state: "The limits argument must be a tuple (soft, hard) of two integers describing the new limits. A value of -1 can be used to specify the maximum possible upper limit."

On Mac OSX (10.7.5) with Python 2.7.3 (built fresh), I get the following behaviour:


$ PATH=$HOME/test/bin:$PATH DYLD_LIBRARY_PATH=$HOME/test/lib:$DYLD_LIBRARY_PATH python
Python 2.7.3 (default, Mar 13 2013, 11:02:56) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import resource
>>> resource.setrlimit(resource.RLIMIT_NOFILE, (10, -1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not allowed to raise maximum limit
>>> resource.setrlimit(resource.RLIMIT_NOFILE, (10, 10))
>>> 


I get the same behaviour for the system python (2.7.3 built with GCC 4.6.3) in Ubuntu 12.04.1.

----------
messages: 184086
nosy: Paul.Price
priority: normal
severity: normal
status: open
title: resource.setrlimit doesn't respect -1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 13 19:09:52 2013
From: report at bugs.python.org (flying sheep)
Date: Wed, 13 Mar 2013 18:09:52 +0000
Subject: [New-bugs-announce] [issue17410] Generator-based HTMLParser
Message-ID: <1363198192.05.0.796177094664.issue17410@psf.upfronthosting.co.za>


New submission from flying sheep:

hi, i have an idea on how to make an internal change to html.parser.HTMLParser, which would expose a token generator interface.

after that, we would be able to do e.g. list(HTMLParser().tokenize(data)) or even

parser = HTMLParser()
for chunk in pipe_in_html():
    yield from parser.tokenize(chunk)

---

the changes affect excluively HTMLParser?s methods and would unfortunately require a behavior change to most (internal) parse_* methods. the changes go as follows:

1. the tokenize(data=None, end=False) method is added. it contains mainly goahead?s body with an prepended snippet to append passed data to raw_data, and all handle_* calls changed to "yield token, data".

2. all parse_* methods which returned an int and called one handle_* method are changed to return an (int, token) tuple (so that tokenize can yield the tokens)

3. goahead is changed to a skeleton implementation based on traversing the list created by tokenize, experiencing no changed behavior.

all changes would only affect the behavior of the parse_* methods, and the addition of the tokenize method: the tokens are discarded if goahead, feed, or close are called. (this can of course be changed if advisable)

---

since this is my first contribution, i?m unsure if i shall already add the patch, unknowing if the changes to the internal parse_* methods are acceptable at all. what do you say?

PS: the tokens are named like the handle_* methods, and the current goahead implementation basically calls getattr(self, 'handle_' + token)(data) for each (token, data) tuple. This can be changed to a token: method dict or a classic ?switch? elif stack.

----------
messages: 184096
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Generator-based HTMLParser

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

From report at bugs.python.org  Wed Mar 13 19:38:59 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 13 Mar 2013 18:38:59 +0000
Subject: [New-bugs-announce] [issue17411] Build failures with non-NDEBUG,
	non-Py_DEBUG builds.
Message-ID: <1363199939.27.0.896431230512.issue17411@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

Similar to http://bugs.python.org/issue14509, Python 3.3 conflates Py_DEBUG and non-NDEBUG builds, creating build failures when building with 'CFLAGS=-UNDEBUG ./configure --without-pydebug'. (assert statements are only compiled out when NDEBUG is set, not when Py_DEBUG is unset.) This patch fixes the two root causes.

----------
components: Build
files: assert_fixes.diff
keywords: patch
messages: 184102
nosy: twouters
priority: normal
severity: normal
status: open
title: Build failures with non-NDEBUG, non-Py_DEBUG builds.
versions: Python 3.3
Added file: http://bugs.python.org/file29400/assert_fixes.diff

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

From report at bugs.python.org  Wed Mar 13 23:10:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Mar 2013 22:10:18 +0000
Subject: [New-bugs-announce] [issue17412] Windows make.bat fails on 2.7
Message-ID: <1363212618.11.0.922529500825.issue17412@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>From Command Prompt
'''
F:\Python\dev\py27\Doc>make html
Running Sphinx v0.6.7

Extension error:
Could not import extension pyspecific (exception: No module named nodes)
'''
Note the old version of Sphinx installed by make checkout. I updated make.bat sphinx download to 1.0.7, the same as all the 3.x make.bats, deleted tools/sphinx (otherwise, svn refuses to redownload), and redid 'make checkout' and 'make html', I got 'build succeeded'. I loaded index.html and the doc files seemed normal (except be being more sprightly due to files being local ;-). I loaded the library manual, followed links, and tested the two indexes.

Was not updating 2.7 make.bat an oversight and is this simple fix the right one? or do 2.7 docs need the old version, albeit with the missing nodes module added?

----------
messages: 184115
nosy: eric.araujo, ezio.melotti, georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows make.bat fails on 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 14 01:56:34 2013
From: report at bugs.python.org (Andreas Kloeckner)
Date: Thu, 14 Mar 2013 00:56:34 +0000
Subject: [New-bugs-announce] [issue17413] format_exception() breask on
	exception tuples from trace	function
Message-ID: <1363222594.63.0.566610526845.issue17413@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner:

traceback.format_exception() used to work properly with the 'arg' value passed to a tracing function set up via sys.settrace for an 'exception' event. In Python 3.x, this is no longer the case. Below you'll find what the attached test produces for a variety of interpreter versions.

If this is not intended to work, I would be much obliged for a hint on how to achieve the desired effect--i.e. get a formatted exception traceback for the exception tuple 'arg' passed to the trace function.

Thanks!

See also: https://github.com/inducer/pudb/issues/61

#####################################################
Python 2.7
#####################################################
ZZ call
ZZ line
ZZ line
ZZ exception
exception (<type 'exceptions.AttributeError'>, "'int' object has no attribute 'invalid'", <traceback object at 0x1951fc8>)
-------------------------------
Traceback (most recent call last):
  File "exc-bug.py", line 20, in f
    x.invalid
AttributeError: 'int' object has no attribute 'invalid'

-------------------------------
ZZ return
Traceback (most recent call last):
  File "exc-bug.py", line 22, in <module>
    f()
  File "exc-bug.py", line 20, in f
    x.invalid
AttributeError: 'int' object has no attribute 'invalid'
ZZ call
ZZ call
#####################################################

#####################################################
Python 3.2
#####################################################
ZZ call
ZZ line
ZZ line
ZZ exception
exception (<class 'AttributeError'>, "'int' object has no attribute 'invalid'", <traceback object at 0x7f4cf42e5f80>)
-------------------------------
Traceback (most recent call last):
  File "exc-bug.py", line 22, in <module>
    f()
  File "exc-bug.py", line 20, in f
    x.invalid
  File "exc-bug.py", line 9, in trace
    print("".join(format_exception(*arg)))
  File "/usr/lib/python3.2/traceback.py", line 180, in format_exception
    for value, tb in values:
  File "/usr/lib/python3.2/traceback.py", line 122, in _iter_chain
    cause = exc.__cause__
AttributeError: 'str' object has no attribute '__cause__'
#####################################################

#####################################################
Python 3.3
#####################################################
ZZ call
ZZ line
ZZ line
ZZ exception
exception (<class 'AttributeError'>, "'int' object has no attribute 'invalid'", <traceback object at 0x7f47383acb00>)
-------------------------------
Traceback (most recent call last):
  File "exc-bug.py", line 22, in <module>
    f()
  File "exc-bug.py", line 20, in f
    x.invalid
  File "exc-bug.py", line 9, in trace
    print("".join(format_exception(*arg)))
  File "/usr/lib/python3.3/traceback.py", line 181, in format_exception
    for value, tb in values:
  File "/usr/lib/python3.3/traceback.py", line 122, in _iter_chain
    context = exc.__context__
AttributeError: 'str' object has no attribute '__context__'
#####################################################

----------
components: Interpreter Core
files: exc-bug.py
messages: 184122
nosy: inducer
priority: normal
severity: normal
status: open
title: format_exception() breask on exception tuples from trace function
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29403/exc-bug.py

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

From report at bugs.python.org  Thu Mar 14 09:14:50 2013
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 14 Mar 2013 08:14:50 +0000
Subject: [New-bugs-announce] [issue17414] timeit.timeit not in __all__ even
	though documented
Message-ID: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>


New submission from Chris Angelico:

The timeit module is commonly used via the convenience function timeit.timeit, which is listed in the documentation as the recommended "Python Interface":
http://docs.python.org/3/library/timeit.html

However, this function is not listed in __all__, meaning that it does not come up in IDLE when Ctrl-Space is pressed. It is also not mentioned in the module docstring, which says "Library usage: see the Timer class.".

Same applies to timeit.repeat(), save that it's not as commonly used. Both are listed in the online docs but not in the docstring or __all__.

----------
components: Library (Lib)
messages: 184147
nosy: Rosuav, terry.reedy
priority: normal
severity: normal
status: open
title: timeit.timeit not in __all__ even though documented
type: enhancement
versions: Python 2.6, Python 3.3

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

From report at bugs.python.org  Thu Mar 14 10:41:24 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 09:41:24 +0000
Subject: [New-bugs-announce] [issue17415] Documentation Ambiguity 1
Message-ID: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

This is the first time I am creating an issue. I may be doing something wrong. I will correct that if you make me aware about it!

Issue with documentation:
Documentation page: http://docs.python.org/3/library/os.path.html
Entry: os.path.normpath(path)
Contention line: "It should be understood that this may change the meaning of the path if it contains symbolic links!"

Ambiguity Source: Contention line immediately follows the line "On Windows, it converts forward slashes to backward slashes." relating contention line to also windows.

Ambiguity: "I think" (i.e. I do not know for sure) that, the contention line should apply to all OS, not just windows. for example, .. after a symlink should, according to me, remove the symlink itself by the normpath function. This would be an incorrect behaviour of the normpath (I consider that incorrect). Hence, should be documented for all OS.

----------
assignee: docs at python
components: Documentation
messages: 184152
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Ambiguity 1
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 10:43:01 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 09:43:01 +0000
Subject: [New-bugs-announce] [issue17416] Documentation Ambiguity 2
Message-ID: <1363254181.3.0.0190813002191.issue17416@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Source page: http://docs.python.org/3/library/os.html
Entry: os.walk(...)

Ambiguity Source: Name of the argument TopDown and / or its description.

The TopDown name is misleading to me. I would suggest BFS or DFS instead. TopDown false would imply to me that the traversal would run bottom up "from" the directory mentioned in the argument list (even though the name of that argument is top, it is confusing indicating a possibility of another naming mistake instead!)

----------
assignee: docs at python
components: Documentation
messages: 184153
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Ambiguity 2
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 11:11:35 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 10:11:35 +0000
Subject: [New-bugs-announce] [issue17417] Documentation Modification
	Suggestion: os.walk, fwalk
Message-ID: <1363255895.31.0.587082771834.issue17417@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Source page: http://docs.python.org/3/library/os.html
Entry: os.walk(...), os.fwalk()

These functions seems to be a generator functions. An expert like yourself may have no trouble to make this out. But for novice (or for people out of touch) like myself would have preferred a starting line of this function as "A generator function that generates file names.... ", rather than currently "Generates file names...."

----------
assignee: docs at python
components: Documentation
messages: 184155
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Modification Suggestion: os.walk, fwalk
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 16:02:41 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 15:02:41 +0000
Subject: [New-bugs-announce] [issue17418] Documentation Bug
Message-ID: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Incompletely explained documentation at 2 places:

1. http://docs.python.org/3/library/functions.html#open

The buffering argument is not correctly explained when setting to a positive argument in binary mode.

2. http://docs.python.org/3/library/os.html#os.open

It is not very clear where to find descriptions of the arguments of this function. Where to find the required information and where to find C run-time documentation could be explained in following preferably:
(Python/C API Reference Manual) http://docs.python.org/3/c-api/index.html and / or 
(The Python Standard Library) http://docs.python.org/3/library and  / or 
(Python Runtime Services) http://docs.python.org/3/library/python.html 

A hyperlink may be added if so felt.

----------
assignee: docs at python
components: Documentation
messages: 184166
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Bug
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 17:58:04 2013
From: report at bugs.python.org (Sergio Callegari)
Date: Thu, 14 Mar 2013 16:58:04 +0000
Subject: [New-bugs-announce] [issue17419] bdist_wininst installer should
	allow install in user	directory
Message-ID: <1363280284.95.0.229024940465.issue17419@psf.upfronthosting.co.za>


New submission from Sergio Callegari:

When installing a package by calling setup you have a --user option to install the package for a single user in his disk area.

E.g.,

python setup.py install --user

A similar possibility should be offered via the windows installer

An exe created by

python setup.py bdist_wininst

when run should offer a tickbox to install in the user disk area rather than globally.

----------
messages: 184171
nosy: Sergio.Callegari
priority: normal
severity: normal
status: open
title: bdist_wininst installer should allow install in user directory
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 14 17:59:41 2013
From: report at bugs.python.org (Sergio Callegari)
Date: Thu, 14 Mar 2013 16:59:41 +0000
Subject: [New-bugs-announce] [issue17420] bdist_wininst does not play well
	with unicode	descriptions
Message-ID: <1363280381.66.0.144650085618.issue17420@psf.upfronthosting.co.za>


New submission from Sergio Callegari:

When creating an installer with bdist_wininst, any unicode characters in the description and long_description fields get mangled when running the installer.

----------
messages: 184172
nosy: Sergio.Callegari
priority: normal
severity: normal
status: open
title: bdist_wininst does not play well with unicode descriptions
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 14 21:20:27 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Mar 2013 20:20:27 +0000
Subject: [New-bugs-announce] [issue17421] Drop restriction that
	meta.__prepare__() must return a	dict (subclass)
Message-ID: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently type_new() in Objects/typeobject.c enforces a restriction that the namespace be a dict or dict subclass.  It does this via the PyArg_ParseTupleAndKeywords() call there.

This means that valid mappings may not be used even though they should work just fine.  A demonstration of the problem is below.

I've attached a patch that relaxes this restriction.  Should we also add a note in the docs that type() will take anything for namespace that dict() will take?

Demonstration
-------------

class Meta(type):
    @classmethod
    def __prepare__(cls, name, bases, **kwargs):
        return ClassMapping()

from collections import MutableMapping
class ClassMapping(MutableMapping):
    def __init__(self, *args, **kwargs):
        self._dict = dict(*args, **kwargs)
    def __len__(self):
      return len(self._dict)
    def __iter__(self):
        return iter(self._dict)
    def __getitem__(self, key):
        return self._dict[key]
    def __setitem__(self, key, value):
        self._dict[key] = value
    def __delitem__(self, key):
        del self._dict[key]

>>> class X(metaclass=Meta):
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() argument 3 must be dict, not ClassMapping

----------
files: type-namespace-restriction.diff
keywords: patch
messages: 184187
nosy: eric.snow, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Drop restriction that meta.__prepare__() must return a dict (subclass)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29408/type-namespace-restriction.diff

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

From report at bugs.python.org  Thu Mar 14 21:33:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Mar 2013 20:33:35 +0000
Subject: [New-bugs-announce] [issue17422] language reference should specify
	restrictions on class	namespace
Message-ID: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>


New submission from Eric Snow:

(related to PEP 422 and issue #17044)

The execution namespace from a class definition is passed as the third argument to the metaclass (see builtin___build_class__() in Python/bltinmodule.c).  When applicable, which is almost always, the subsequent call to type.__new__() copies that namespace into a new dict which is in turn exposed via the class's __dict__.

This matters in the case where a metaclass with __prepare__() gets used (or the PEP 422 equivalent).  The language reference[1] should note that the object returned by __prepare__() is copied into a new dict when the class is finally created via the metaclass.

[1] http://docs.python.org/3.4/reference/datamodel.html#customizing-class-creation

----------
assignee: docs at python
components: Documentation
messages: 184188
nosy: docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: language reference should specify restrictions on class namespace
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 14 22:09:03 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Thu, 14 Mar 2013 21:09:03 +0000
Subject: [New-bugs-announce] [issue17423] libffi on 32bit is broken on linux
Message-ID: <1363295343.27.0.178214767715.issue17423@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

The bug is a little tricky to reproduce. You need a 32bit linux. First compile x.c with:

gcc -O3 -g -shared -o x.so x.c -std=c99 -msse3 -ftree-vectorize -mfpmath=sse

and run x.py. It segfaults because the alignment of stack is not preserved (and it's assumed on a modern linux). Patch attached.

----------
files: x.c
messages: 184193
nosy: fijall
priority: normal
severity: normal
status: open
title: libffi on 32bit is broken on linux
type: crash
Added file: http://bugs.python.org/file29409/x.c

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

From report at bugs.python.org  Thu Mar 14 22:26:30 2013
From: report at bugs.python.org (Sean Reifschneider)
Date: Thu, 14 Mar 2013 21:26:30 +0000
Subject: [New-bugs-announce] [issue17424] help() should use the class
	signature
Message-ID: <1363296390.29.0.253596803628.issue17424@psf.upfronthosting.co.za>


New submission from Sean Reifschneider:

David Beazley in his tutorial pointed out that you could use a metaclass to create function signatures for the common use case of:

class foo:
   def __init__(self, name, value, high, low):
      self.name = name
      self.value = value
      [...]

The signature can be used so that the classes created using an automation metaclass will show a signature of "(*args)".  inspect.signature will use this signature, but "help()" will not use the signature.

This is a stub created during the tutorial, I will flesh it out further during the sprints.

----------
assignee: jafo
components: Interpreter Core
messages: 184194
nosy: jafo
priority: normal
severity: normal
status: open
title: help() should use the class signature
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 14 23:10:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Mar 2013 22:10:17 +0000
Subject: [New-bugs-announce] [issue17425] Update OpenSSL versions in Windows
	builds
Message-ID: <1363299017.8.0.243503203176.issue17425@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

OpenSSL recently issued a security advisory (*). Our bundled OpenSSL versions seem to be vulnerable. They should be updated to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y depending on the version.

(*) http://www.openssl.org/news/secadv_20130205.txt

Apologies if this has already been handled and I've misunderstood Tools/buildbot/external-common.bat.

----------
components: Build, Windows
messages: 184199
nosy: benjamin.peterson, christian.heimes, georg.brandl, larry, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: Update OpenSSL versions in Windows builds
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 15 05:39:02 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 15 Mar 2013 04:39:02 +0000
Subject: [New-bugs-announce] [issue17426] \0 in re.sub substitutes to space
Message-ID: <1363322342.9.0.0075824045544.issue17426@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

According to docs, group 0 is equivalent to the whole match, which is not true for Python.

import re
print( re.sub('aaa', r'__\0__', 'argaaagra') )


arg__ __gra


import re
print( re.sub('(aaa)', r'__\1__', 'argaaagra') )


arg__aaa__gra


See also:
http://www.php.net/manual/en/function.preg-replace.php
http://www.regular-expressions.info/ruby.html

----------
components: Library (Lib)
messages: 184210
nosy: techtonik
priority: normal
severity: normal
status: open
title: \0 in re.sub substitutes to space
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 15 07:07:21 2013
From: report at bugs.python.org (august smith)
Date: Fri, 15 Mar 2013 06:07:21 +0000
Subject: [New-bugs-announce] [issue17427] re
Message-ID: <CAL3V7bv=K0qMc_bT=Tyt8yTE8a7JsQFQyaq1Z4Kx4vzpsDM-rg@mail.gmail.com>


New submission from august smith:

lol

----------
messages: 184215
nosy: JUNO
priority: normal
severity: normal
status: open
title: re

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

From report at bugs.python.org  Fri Mar 15 10:01:41 2013
From: report at bugs.python.org (Rock Li)
Date: Fri, 15 Mar 2013 09:01:41 +0000
Subject: [New-bugs-announce] [issue17428] replace readdir to readdir_r in
	function posix_listdir
Message-ID: <1363338101.3.0.811264304482.issue17428@psf.upfronthosting.co.za>


New submission from Rock Li:

When I'm how glob module is implemented. I found in file posixmodule.c, the function posix_listdir is using readdir to get all the entries under one directory and the context is setted to allow multi threads. But the function readdir is not thread-safe, so I changed this call to use readdir_r instead. 

I'm using the lastest codes in the repo.

----------
components: Extension Modules
files: mywork.patch
keywords: patch
messages: 184224
nosy: Rock
priority: normal
severity: normal
status: open
title: replace readdir to readdir_r in function posix_listdir
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29413/mywork.patch

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

From report at bugs.python.org  Fri Mar 15 16:08:30 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 15 Mar 2013 15:08:30 +0000
Subject: [New-bugs-announce] [issue17429] platform.platform() can throw
	Unicode error
Message-ID: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi:

Tested on python-3.2 and python-3.3.  platform.platform() looks for a file in /etc/ that looks like it will contain the name of the Linux distribution that python3 is running on.  Once found, it reads the contents of the file to have a name for the Linux distribution.  Most Linux distributions do create files inside of /etc/ with a single line which is the distribution name so this is a good heuristic.  However, these files are created by the operating system vendor and so they can have a different encoding than the encoding of the locale the user uses.  This means that if there are non-ascii characters inside the file, user code that invokes platform.platform() may throw a traceback.

Test:

$ LC_ALL=en_US.utf8 sudo echo ' Caf?' >> /etc/fedora-release
$ LC_ALL=C python3
>>> import platform
>>> platform.platform()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/platform.py", line 1538, in platform
    distname,distversion,distid = dist('')
  File "/usr/lib64/python3.2/platform.py", line 358, in dist
    full_distribution_name=0)
  File "/usr/lib64/python3.2/platform.py", line 329, in linux_distribution
    firstline = f.readline()
  File "/usr/lib64/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 22: ordinal not in range(128)

It seems that the standard method of fixing these that we're promoting in python3 is to use surrogateescape.  I'll provide a patch that does that.

----------
messages: 184234
nosy: a.badger
priority: normal
severity: normal
status: open
title: platform.platform() can throw Unicode error
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 15 19:38:41 2013
From: report at bugs.python.org (Neal Norwitz)
Date: Fri, 15 Mar 2013 18:38:41 +0000
Subject: [New-bugs-announce] [issue17430] missed peephole optimization
Message-ID: <1363372721.86.0.440516031889.issue17430@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

>>> def fo():
...   if a:
...     if b:
...      if c:
...        print
... 
>>> dis.dis(fo)
  2           0 LOAD_GLOBAL              0 (a)
              3 POP_JUMP_IF_FALSE       28

  3           6 LOAD_GLOBAL              1 (b)
              9 POP_JUMP_IF_FALSE       28

  4          12 LOAD_GLOBAL              2 (c)
             15 POP_JUMP_IF_FALSE       25

  5          18 PRINT_NEWLINE       
             19 JUMP_ABSOLUTE           25
             22 JUMP_ABSOLUTE           28
        >>   25 JUMP_FORWARD             0 (to 28)
        >>   28 LOAD_CONST               0 (None)
             31 RETURN_VALUE        

The 2 JUMP_ABSOLUTEs should be optimized away since the code is equivalent to: if a and b and c: as in:

>>> dis.dis(fo)
  2           0 LOAD_GLOBAL              0 (a)
              3 POP_JUMP_IF_FALSE       22
              6 LOAD_GLOBAL              1 (b)
              9 POP_JUMP_IF_FALSE       22
             12 LOAD_GLOBAL              2 (c)
             15 POP_JUMP_IF_FALSE       22

  3          18 PRINT_NEWLINE       
             19 JUMP_FORWARD             0 (to 22)
        >>   22 LOAD_CONST               0 (None)
             25 RETURN_VALUE

----------
messages: 184245
nosy: Neal.Norwitz
priority: normal
severity: normal
status: open
title: missed peephole optimization
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 15 19:46:04 2013
From: report at bugs.python.org (Forest Wilkinson)
Date: Fri, 15 Mar 2013 18:46:04 +0000
Subject: [New-bugs-announce] [issue17431] email.parser module has no
	attribute BytesFeedParser
Message-ID: <1363373164.42.0.545347845894.issue17431@psf.upfronthosting.co.za>


New submission from Forest Wilkinson:

The docs claim that email.parser.BytesFeedParser exists, but it doesn't.  Looks like email.feedparser.FeedParser is imported into the email.parser module, but someone forgot to do the same for BytesFeedParser.

----------
components: email
messages: 184247
nosy: barry, forest, r.david.murray
priority: normal
severity: normal
status: open
title: email.parser module has no attribute BytesFeedParser
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 15 23:18:04 2013
From: report at bugs.python.org (Bill Dirks)
Date: Fri, 15 Mar 2013 22:18:04 +0000
Subject: [New-bugs-announce] [issue17432] PyUnicode_ functions not
	accessible in Limited API on	Windows
Message-ID: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za>


New submission from Bill Dirks:

This issue was discovered in 3.3.0 on Windows. Haven't looked at other versions.
Using the Limited API, the PyUnicode_Xxxx() functions are not accessible. A simple demonstration of the problem:

   HMODULE p3 = ::LoadLibraryA("C:\\Python33\\DLLs\\python3.dll");
   FARPROC f;
   f = GetProcAddress(p3, "Py_IsInitialized"); // works
   f = GetProcAddress(p3, "PyImport_AppendInittab"); // works, and so on
   f = GetProcAddress(p3, "PyUnicode_FromString"); // fails
   f = GetProcAddress(p3, "PyUnicode_FromFormat"); // fails
   f = GetProcAddress(p3, "PyUnicode_FromStringAndSize"); // fails, and so on
   ::FreeLibrary(p3);

After some digging I found that python3.dll refers all of its exports on to python33.dll, and the problem exports all have the form:
  PyUnicode_Xxxx -> python33.PyUnicodeUCS2_Xxxx
but python33.dll does not export any PyUnicodeUCS2_ symbols, confirmed by the Dependency Walker tool.

Any Limited API extension using PyUnicode_ functions will compile and link, but fail at runtime. If I understand the problem, the fix is just to correct the .def file.

----------
components: Windows
messages: 184268
nosy: bdirks
priority: normal
severity: normal
status: open
title: PyUnicode_ functions not accessible in Limited API on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 15 23:37:48 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 15 Mar 2013 22:37:48 +0000
Subject: [New-bugs-announce] [issue17433] stdlib generator-like iterators
	don't forward send/throw
Message-ID: <1363387068.19.0.285872476506.issue17433@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

In response to a question asked at Brett Cannon's Python 3.3 talk at PyCon, it occurs to me the iterators in the itertools module should participate in generator sending, so that you can do this:

def report_first_ten(g):
    s = itertools.islice(g, 10)
    yield from s
    print("First 10 done.")
    yield from g

and then send (or throw) into the report_first_ten() generator, it fails (because itertools.islice() has no send method.) Similarly, perhaps itertools.izip() should gain a send method that sends into the iterators it's zipping, etc.

----------
components: Library (Lib)
messages: 184273
nosy: twouters
priority: normal
severity: normal
status: open
title: stdlib generator-like iterators don't forward send/throw
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 16 01:13:57 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 16 Mar 2013 00:13:57 +0000
Subject: [New-bugs-announce] [issue17434] str literals,
	which are not docstrings,
	should not be allowed between __future__ imports
Message-ID: <1363392837.6.0.139657599186.issue17434@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test1.py shows that a str literal before first import from __future__ is a docstring.
test2.py shows that a str literal after first import from __future__ is not a docstring.
test2.py shows that if docstring is absent, then a single str literal between imports from __future__ does not cause SyntaxError, while it should.
test3.py shows that if docstring is present, then a str literal between imports from __future__ causes SyntaxError.
test4.py shows that if docstring is absent, then >=2 str literals between imports from __future__ cause SyntaxError.

$ cat test1.py
"some text"
from __future__ import absolute_import
print(__doc__)
$ cat test2.py
from __future__ import absolute_import
"some text"
from __future__ import print_function
print(__doc__)
$ cat test3.py
"some text 1"
from __future__ import absolute_import
"some text 2"
from __future__ import print_function
$ cat test4.py
from __future__ import absolute_import
"some text 1"
"some text 2"
from __future__ import print_function
$ python3.4 test1.py
some text
$ python3.4 test2.py
None
$ python3.4 test3.py
  File "test3.py", line 4
    from __future__ import print_function
    ^
SyntaxError: from __future__ imports must occur at the beginning of the file
$ python3.4 test4.py
  File "test4.py", line 4
    from __future__ import print_function
    ^
SyntaxError: from __future__ imports must occur at the beginning of the file
$

----------
components: Interpreter Core
messages: 184277
nosy: Arfrever
priority: normal
severity: normal
status: open
title: str literals, which are not docstrings, should not be allowed between __future__ imports
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 16 01:17:20 2013
From: report at bugs.python.org (Denver Coneybeare)
Date: Sat, 16 Mar 2013 00:17:20 +0000
Subject: [New-bugs-announce] [issue17435] threading.Timer.__init__() should
	use immutable argument	defaults for args and kwargs
Message-ID: <1363393040.78.0.569565797708.issue17435@psf.upfronthosting.co.za>


New submission from Denver Coneybeare:

The __init__() method of threading.Timer uses *mutable* default values for the "args" and "kwargs" arguments.  Since the default argument objects are created once and re-used for each instance, this means that changing the args list or kwargs dict of a Timer object that used the argument defaults will specify those arguments to all future Timer objects that use the defaults too.

def __init__(self, interval, function, args=[], kwargs={}):

A fully backwards-compatible way to fix this is to instead use None as the default value for args and kwargs and just create a new list and/or dict inside __init__() if they are None.  That way each new instance of Timer will get its very own args list and kwargs dict object.

def __init__(self, interval, function, args=None, kwargs=None):
    ...
    self.args = args if args is not None else []
    self.kwargs = kwargs if kwargs is not None else {}

Here is a sample script that reproduces the issue:

    import threading

    event = threading.Event()
    def func(*args, **kwargs):
        print("args={!r} kwargs={!r}".format(args, kwargs))
        event.set()

    timer1 = threading.Timer(1, func)
    timer1.args.append("blah")
    timer1.kwargs["foo"] = "bar"

    timer2 = threading.Timer(1, func)
    timer2.start()
    event.wait()

Here is the example output when run before the fix:

c:\dev\cpython>PCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py
args=('blah',) kwargs={'foo': 'bar'}
[44758 refs, 17198 blocks]

And after the fix:

c:\dev\cpython>PCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py
args=() kwargs={}
[47189 refs, 18460 blocks]

As you can see, in the version without the fix, the elements added to timer1's args and kwargs were also given to timer2, which is almost certainly not what a user would expect.

A proposed patch, ThreadingTimerInitDefaultArgsIssueDemo.01.patch, is attached.  This fixes the issue, updates the docs, and adds a unit test.

----------
components: Library (Lib)
files: ThreadingTimerInitDefaultArgsIssueDemo.01.patch
keywords: patch
messages: 184278
nosy: denversc
priority: normal
severity: normal
status: open
title: threading.Timer.__init__() should use immutable argument defaults for args and kwargs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29422/ThreadingTimerInitDefaultArgsIssueDemo.01.patch

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

From report at bugs.python.org  Sat Mar 16 11:11:12 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 16 Mar 2013 10:11:12 +0000
Subject: [New-bugs-announce] [issue17436] pass a string to hashlib.update
Message-ID: <1363428672.22.0.18562351596.issue17436@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/3/library/hashlib#hashlib.hash.update

The hashlib is most useful for big chunks of data, and that means every time you need to create a wrapper for reading from files. It makes sense to allow hashlib.update accept file like object to read from.

----------
components: Library (Lib)
messages: 184301
nosy: techtonik
priority: normal
severity: normal
status: open
title: pass a string to hashlib.update
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 16 11:58:59 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 16 Mar 2013 10:58:59 +0000
Subject: [New-bugs-announce] [issue17437] Difference between open and
	codecs.open
Message-ID: <1363431539.84.0.0934189958093.issue17437@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In Python 2 the distinction between open() and codes.open() was clear because 'encoding' and 'errors' args were provided by codecs.open only.
This is no longer the case in Python 3 since both args are provided also by open().

I'm probably missing something but regardless I think codecs.open doc [1] should be more clear as to when and why (say) codecs.open(file, encoding='utf8', errors='ignore') should be preferred over open(file, encoding='utf8', errors='ignore').

[1] http://docs.python.org/3/library/codecs.html#codecs.open

----------
assignee: docs at python
components: Documentation
messages: 184303
nosy: docs at python, ezio.melotti, giampaolo.rodola
priority: normal
severity: normal
status: open
title: Difference between open and codecs.open
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 16 13:11:45 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 16 Mar 2013 12:11:45 +0000
Subject: [New-bugs-announce] [issue17438] json.load docs should mention that
	it always return	unicode
Message-ID: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Strings returned in the object returned from json.load() seem to be always unicode, but it is not documented. Python 2.7

----------
assignee: docs at python
components: Documentation
messages: 184308
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: json.load docs should mention that it always return unicode
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 16 14:59:34 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 16 Mar 2013 13:59:34 +0000
Subject: [New-bugs-announce] [issue17439] insufficient error message for
	failed unicode conversion
Message-ID: <1363442374.27.0.764896075169.issue17439@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

When Python 2.x compares ordinary string with unicode, it tries to convert the former, and shows an error message if the conversion fails. Attached example with Russian strings gives the following:

russian.py:11: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  print(nonu2 == ustr2)

This message is missing information about what source encoding Python used for the conversion. russian.py is encoded in UTF-8, so this information at least will give a hint what encoding is expected.


A little different question. As you may see, russian.py has a coding header set to UTF-8. When Python parses source files, it reads and stores string literals encountered in this file. Are those literals linked to this source file? And does it store this coding information somewhere? Because if it does, then conversion can be automatically possible without side effects. And the error message above could contain reference to encoding and explanation where this coding information was taken from (i.e. from file header).

When Python evaluates strings from stdin file, they also have some encoding. Is this problem solved for this case? Where Python stores encoding for stdin input?

----------
components: Unicode
files: russian.py
messages: 184315
nosy: ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: insufficient error message for failed unicode conversion
versions: Python 2.7
Added file: http://bugs.python.org/file29424/russian.py

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

From report at bugs.python.org  Sat Mar 16 17:33:23 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 16:33:23 +0000
Subject: [New-bugs-announce] [issue17440] Some IO related problems on x86
	windows
Message-ID: <1363451603.09.0.416265492593.issue17440@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

1. The read mode is not the default mode as mentioned in the docs.python.org. 
In particular see the first Traceback below - "b" does not work (as it does in C though) and 
you are forced to use "rb" instead.

2. io.BufferedReader does not implement read1 (the last lines of trace below)

3. io.FileIO does not implements single OS system call on read() - instead reads a file until EOF i.e. ignores the arguments supplied to read() - larger arguments are slower to execute (see the read calls in the trace below). 

_________________

>>> import io
>>> fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
>>> byt = fl.read()
>>> len(byt)
70934549
>>> fl.close()
>>> fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
>>> byt = fl.read(256)
>>> len(byt)
256
>>> byt = fl.read(512)
>>> len(byt)
512
>>> byt = fl.read(1024)
>>> len(byt)
1024
>>> byt = fl.read(4096)
>>> len(byt)
4096
>>> byt = fl.read(10240)
>>> len(byt)
10240
>>> len(fl.read(40960))
40960
>>> len(fl.read(102400))
102400
>>> len(fl.read(1048576))
1048576
>>> fl.close()
>>> fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
>>> len(fl.read(70934549))
70934549
>>> len(fl.read(70934549))
0
>>> fl.close()
>>> fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
>>> b = bytearray(70934549)
>>> fl.readinto(b)
70934549
>>> fl.close()
>>> fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'b', buffering = 0)
Traceback (most recent call last):
  File "<pyshell#31>", line 1, in <module>
    fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'b', buffering = 0)
ValueError: Must have exactly one of create/read/write/append mode and at most one plus
>>> fl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = 0)
>>> type(fl)
<class '_io.FileIO'>
>>> cfl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'r')
>>> type(cfl)
<class '_io.FileIO'>
>>> cfl.close()
>>> cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
>>> type(cfl)
<class '_io.BufferedReader'>
>>> io.DEFAULT_BUFFER_SIZE
8192
>>> len(fl.read(70934549))
70934549
>>> cfl.close()
>>> cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
>>> len(fl.read1(70934549))
Traceback (most recent call last):
  File "<pyshell#44>", line 1, in <module>
    len(fl.read1(70934549))
AttributeError: '_io.FileIO' object has no attribute 'read1'
>>>

----------
messages: 184330
nosy: gsingh
priority: normal
severity: normal
status: open
title: Some IO related problems on x86 windows

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

From report at bugs.python.org  Sat Mar 16 22:08:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2013 21:08:56 +0000
Subject: [New-bugs-announce] [issue17441] Do not cache re.compile
Message-ID: <1363468136.42.0.6196791543.issue17441@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Ezio proposed in issue16389 to not cache re.compile. Caching of re.compile has no sense and only pollutes the cache.

----------
components: Library (Lib), Regular Expressions
messages: 184354
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Do not cache re.compile
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 16 22:17:44 2013
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 16 Mar 2013 21:17:44 +0000
Subject: [New-bugs-announce] [issue17442] code.InteractiveInterpreter
	doesn't display the	exception cause
Message-ID: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

The code module claims to emulate Python's interactive interpreter but it fails to emulate displaying of the exception cause.

It can utilize traceback._iter_chain to do this (see traceback.print_exception)

----------
components: Library (Lib)
messages: 184355
nosy: pjenvey
priority: normal
severity: normal
status: open
title: code.InteractiveInterpreter doesn't display the exception cause
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 17 06:27:19 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Mar 2013 05:27:19 +0000
Subject: [New-bugs-announce] [issue17443] imaplib.IMAP4_stream subprocess is
	opened unbuffered but	ignores short reads
Message-ID: <1363498039.27.0.436061830807.issue17443@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads

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

From report at bugs.python.org  Sun Mar 17 12:16:10 2013
From: report at bugs.python.org (John Szakmeister)
Date: Sun, 17 Mar 2013 11:16:10 +0000
Subject: [New-bugs-announce] [issue17444] multiprocessing.cpu_count() should
	use hw.availcpu on	Mac OS X
Message-ID: <1363518970.43.0.663033914557.issue17444@psf.upfronthosting.co.za>


New submission from John Szakmeister:

While trying to test a fix for Nose, I discovered that multiprocessing is picking up the CPU count incorrectly.  It should be using hw.availcpu instead of hw.ncpu.  The latter is the number of cpus installed in the system, but the former is the number that are available for processing.  The processor pane let's you adjust the available CPUs, which is handy for testing and troubleshooting.

----------
components: Library (Lib)
files: use-availcpu.patch
keywords: patch
messages: 184367
nosy: jszakmeister
priority: normal
severity: normal
status: open
type: behavior
Added file: http://bugs.python.org/file29430/use-availcpu.patch

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

From report at bugs.python.org  Sun Mar 17 15:42:58 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Mar 2013 14:42:58 +0000
Subject: [New-bugs-announce] [issue17445] Return the type you accept
Message-ID: <1363531378.76.0.0837150963685.issue17445@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

This came up at the Pycon 2013 Python 3 porting clinic.  There are many cases in the stdlib that claim (either explicitly or implicitly) to accept bytes or strings, but that don't return the type of the arguments they accept.  An example is urllib.parse.quote() which accepts bytes or str but always returns str.  A similar example brought up at the clinic was difflib, which accepts both types, and works internally on both, but crashes when joining the results for return.

It should be policy for the stdlib (i.e. codified in an informational PEP and including bug reports, because they *are* bugs, not features or baked-in API) where bytes or str are accepted but the right things are not done (i.e. return the type you accept).

This bug captures the principle, and probably should be closed once such a PEP is accepted, with individual bugs opened for each individual case.

----------
components: Library (Lib)
messages: 184379
nosy: barry
priority: normal
severity: normal
status: open
title: Return the type you accept
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 17 17:08:27 2013
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Sun, 17 Mar 2013 16:08:27 +0000
Subject: [New-bugs-announce] [issue17446] doctest test finder doesnt find
	line numbers of	properties
Message-ID: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt:

examples that are found on a property dont detect the line number

class example(object):
  @property
  def me(self):
   """
   >>> 1/0
   """
   pass

----------
messages: 184384
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: doctest test finder doesnt find line numbers of properties

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

From report at bugs.python.org  Sun Mar 17 19:22:54 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2013 18:22:54 +0000
Subject: [New-bugs-announce] [issue17447] str.identifier shouldn't accept
	Python keywords
Message-ID: <1363544574.75.0.347741161045.issue17447@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

>>> 'def'.isidentifier()
True

----------
components: Interpreter Core
messages: 184389
nosy: rhettinger
priority: normal
severity: normal
status: open
title: str.identifier shouldn't accept Python keywords
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 18 04:40:40 2013
From: report at bugs.python.org (Rafael Santos)
Date: Mon, 18 Mar 2013 03:40:40 +0000
Subject: [New-bugs-announce] [issue17448] test_xml should skip when no xml
	parsers are found
Message-ID: <1363578040.13.0.982812379271.issue17448@psf.upfronthosting.co.za>


New submission from Rafael Santos:

When running test_xml, an exception is thrown if no SAXReader is available, but the test is not skipped.


[1/1] test_sax
test test_sax crashed -- Traceback (most recent call last):
  File "/Users/tucif/Documents/dev/cpython/cpython/Lib/test/test_sax.py", line 7, in <module>
    make_parser()
  File "/Users/tucif/Documents/dev/cpython/cpython/Lib/xml/sax/__init__.py", line 90, in make_parser
    raise SAXReaderNotAvailable("No parsers found", None)
xml.sax._exceptions.SAXReaderNotAvailable: No parsers found

----------
components: Tests
messages: 184419
nosy: tucif
priority: normal
severity: normal
status: open
title: test_xml should skip when no xml parsers are found
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 18 05:08:17 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 18 Mar 2013 04:08:17 +0000
Subject: [New-bugs-announce] [issue17449] dev guide appears not to cover the
	benchmarking suite
Message-ID: <1363579697.14.0.518781563777.issue17449@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

Does the devguide document the benchmarking suite anywhere?  I can't see it anywhere in the index on http://docs.python.org/devguide/ and google doesn't seem to show anything.

suggested content:
  * how to run the benchmarks for a Python 2 implementation
  * how to run the benchmarks for a Python 3 implementation

Sorry if it exists and I missed it

----------
assignee: brett.cannon
components: Devguide
messages: 184421
nosy: brett.cannon, dmalcolm, ezio.melotti
priority: normal
severity: normal
status: open
title: dev guide appears not to cover the benchmarking suite

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

From report at bugs.python.org  Mon Mar 18 06:55:52 2013
From: report at bugs.python.org (Christina Chan)
Date: Mon, 18 Mar 2013 05:55:52 +0000
Subject: [New-bugs-announce] [issue17450] Failed to build _sqlite3
Message-ID: <1363586152.78.0.622740707583.issue17450@psf.upfronthosting.co.za>


New submission from Christina Chan:

Tried to install python 2.7.3 on Linux 2.6.18-194.8.1.el5 x86_64 with the following steps:-

1. after gunzip, did ./configure in Python-2.7.3 directory
2. make

here is the error I ran into when executing make:-

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 imageop         
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_sqlite3                                              

I looked through the README and history and tried the followings but not successful:-

1. yum install libsqlite3-dev or libsqlite3-devel - cannot find either.
2. uncomment the Modules/Setup to build the bsdbb185 but that results in error.

Question:-
1. Is this module _sqlite3 needed? If it is, how to fix this compiler error?

----------
components: Installation
files: make_log.txt
messages: 184426
nosy: cchan_95125
priority: normal
severity: normal
status: open
title: Failed to build _sqlite3
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file29436/make_log.txt

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

From report at bugs.python.org  Mon Mar 18 06:57:59 2013
From: report at bugs.python.org (Matt Bachmann)
Date: Mon, 18 Mar 2013 05:57:59 +0000
Subject: [New-bugs-announce] [issue17451] Test to splitdoc in pydoc.py
Message-ID: <1363586279.07.0.970452184927.issue17451@psf.upfronthosting.co.za>


New submission from Matt Bachmann:

Found a line in splitdoc that was not being exercised.

I added a test for it.

----------
components: Library (Lib)
files: splitdoc_description_test.patch
keywords: patch
messages: 184427
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: Test to splitdoc in pydoc.py
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file29437/splitdoc_description_test.patch

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

From report at bugs.python.org  Mon Mar 18 07:19:28 2013
From: report at bugs.python.org (Russell Kackley)
Date: Mon, 18 Mar 2013 06:19:28 +0000
Subject: [New-bugs-announce] [issue17452] ftplib raises exception if ssl
	module is not available
Message-ID: <1363587568.02.0.896930702803.issue17452@psf.upfronthosting.co.za>


New submission from Russell Kackley:

On a system with no ssl module the following test failure occurs:

======================================================================
ERROR: test_dir (test.test_ftplib.TestFTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rkackley/Code/cpython/Lib/test/test_ftplib.py", line 598, in test_dir
    self.client.dir(lambda x: l.append(x))
  File "/home/rkackley/Code/cpython/Lib/ftplib.py", line 565, in dir
    self.retrlines(cmd, func)
  File "/home/rkackley/Code/cpython/Lib/ftplib.py", line 476, in retrlines
    if isinstance(conn, _SSLSocket):
TypeError: isinstance() arg 2 must be a type or tuple of types

----------
components: Library (Lib)
files: ftplib.diff
keywords: patch
messages: 184429
nosy: giampaolo.rodola, rkackley
priority: normal
severity: normal
status: open
title: ftplib raises exception if ssl module is not available
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29438/ftplib.diff

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

From report at bugs.python.org  Mon Mar 18 08:34:49 2013
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Coatanhay?=)
Date: Mon, 18 Mar 2013 07:34:49 +0000
Subject: [New-bugs-announce] [issue17453] logging.config.fileConfig error
Message-ID: <1363592089.61.0.213350705624.issue17453@psf.upfronthosting.co.za>


New submission from Herv? Coatanhay:

In python 2.7 this code works:

>>> import logging.config
>>> import StringIO
>>> a="""[loggers]
... keys = root
... [logger_root]
... handlers = ""
... [formatters]
... keys = ""
... [handlers]
... keys = ""
... """
>>> logging.config.fileConfig(StringIO.StringIO(a))
>>> 

whereas in python 3.3 it raises an exception:

>>> import logging.config
>>> import io
>>> a="""[loggers]
... keys = root
... [logger_root]
... handlers = ""
... [formatters]
... keys = ""
... [handlers]
... keys = ""
... """
>>> logging.config.fileConfig(io.StringIO(a))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/logging/config.py", line 70, in fileConfig
    formatters = _create_formatters(cp)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/logging/config.py", line 114, in _create_formatters
    class_name = cp[sectname].get("class")
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/configparser.py", line 942, in __getitem__
    raise KeyError(key)
KeyError: 'formatter_""'
>>>

----------
components: Library (Lib)
messages: 184435
nosy: Alzakath
priority: normal
severity: normal
status: open
title: logging.config.fileConfig error
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 18 09:27:28 2013
From: report at bugs.python.org (alef)
Date: Mon, 18 Mar 2013 08:27:28 +0000
Subject: [New-bugs-announce] [issue17454] ld_so_aix not used when linking
	c++ (scipy)
Message-ID: <1363595248.19.0.716647347764.issue17454@psf.upfronthosting.co.za>


New submission from alef:

error: Command "xlC_r xlC_r -bI:/pathp/to/lib/python2.7/config/python.exp ...".

unixccompiler.py at line 251 override linker[0] with self.compiler_cxx[0]. This is not true for AIX that uses the script ld_so_aix, and not xlC_r.

----------
assignee: eric.araujo
components: Distutils
messages: 184437
nosy: alef, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: ld_so_aix not used when linking c++ (scipy)
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 18 12:08:20 2013
From: report at bugs.python.org (Felix Matenaar)
Date: Mon, 18 Mar 2013 11:08:20 +0000
Subject: [New-bugs-announce] [issue17455] ImportError (xml.dom.minidom)
	in	/usr/lib/python2.7/dist-packages/apport/report.py
Message-ID: <1363604900.47.0.735046009631.issue17455@psf.upfronthosting.co.za>


New submission from Felix Matenaar:

We're getting the following exception in a custom testing framework using sqlalchemy. Our process is running several days and the exception seems to occurs unproducably during runtime, sometimes after a day and sometimes after a couple of hours. The same code is executed many times before.

To me it looks like SQLAlchemy crashed which then leads to the import error. Maybe I'll have to issue a bug for this specific project but first wanted to ask you guys.

File "/home/test/research/testing/db.py", line 101, in addException
self.testrun.exceptions.append(exc)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/attributes.py", line 168, in _get_
return self.impl.get(instance_state(instance),dict_)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/attributes.py", line 453, in get
value = self.callable_(state, passive)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/strategies.py", line 563, in _load_for_state
result = q.all()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 1947, in all
return list(self)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2057, in _iter_
return self._execute_and_instances(context)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2070, in _execute_and_instances
close_with_result=True)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2061, in _connection_from_session
**kw)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 719, in connection
close_with_result=close_with_result)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 723, in _connection_for_bind
return self.transaction._connection_for_bind(engine)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 266, in _connection_for_bind
conn = bind.contextual_connect()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2340, in contextual_connect
self.pool.connect(),
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 210, in connect
return _ConnectionFairy(self).checkout()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 371, in _init_
rec = self._connection_record = pool._do_get()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 758, in _do_get
return self._create_connection()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 174, in _create_connection
return _ConnectionRecord(self)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 256, in _init_
self.connection = self.__connect()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 316, in __connect
connection = self.__pool._creator()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line 80, in connect
return dialect.connect(*cargs, **cparams)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 280, in connect
return self.dbapi.connect(*cargs, **cparams)
sqlalchemy.exc.OperationalError: (OperationalError) unable to open database file None None
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in apport_excepthook
from apport.fileutils import likely_packaged, get_recent_crashes
File "/usr/lib/python2.7/dist-packages/apport/_init_.py", line 1, in <module>
from apport.report import Report
File "/usr/lib/python2.7/dist-packages/apport/report.py", line 15, in <module>
import xml.dom, xml.dom.minidom
ImportError: No module named minidom

Original exception was:
Traceback (most recent call last):
File "./test", line 72, in <module>
prog.run()
File "./test", line 67, in run
ts.run(self._getStorageBackend())
File "/home/test/research/testing/testsets.py", line 104, in run
storage.addException(exc)
File "/home/test/research/testing/db.py", line 101, in addException
self.testrun.exceptions.append(exc)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/attributes.py", line 168, in _get_
return self.impl.get(instance_state(instance),dict_)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/attributes.py", line 453, in get
value = self.callable_(state, passive)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/strategies.py", line 563, in _load_for_state
result = q.all()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 1947, in all
return list(self)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2057, in _iter_
return self._execute_and_instances(context)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2070, in _execute_and_instances
close_with_result=True)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 2061, in _connection_from_session
**kw)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 719, in connection
close_with_result=close_with_result)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 723, in _connection_for_bind
return self.transaction._connection_for_bind(engine)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 266, in _connection_for_bind
conn = bind.contextual_connect()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2340, in contextual_connect
self.pool.connect(),
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 210, in connect
return _ConnectionFairy(self).checkout()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 371, in _init_
rec = self._connection_record = pool._do_get()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 758, in _do_get
return self._create_connection()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 174, in _create_connection
return _ConnectionRecord(self)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 256, in _init_
self.connection = self.__connect()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 316, in __connect
connection = self.__pool._creator()
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line 80, in connect
return dialect.connect(*cargs, **cparams)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 280, in connect
return self.dbapi.connect(*cargs, **cparams)
sqlalchemy.exc.OperationalError: (OperationalError) unable to open database file None None

----------
messages: 184443
nosy: Felix.Matenaar
priority: normal
severity: normal
status: open
title: ImportError (xml.dom.minidom) in /usr/lib/python2.7/dist-packages/apport/report.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 18 12:19:05 2013
From: report at bugs.python.org (Corto Nexus)
Date: Mon, 18 Mar 2013 11:19:05 +0000
Subject: [New-bugs-announce] [issue17456] os.py (unexpected character)
Message-ID: <1363605545.76.0.413275928498.issue17456@psf.upfronthosting.co.za>


New submission from Corto Nexus:

In Python 3.3 (Windows 32bits) the lib os.py start with an uncommented letter 'r'.

----------
messages: 184446
nosy: corto.nexus
priority: normal
severity: normal
status: open
title: os.py (unexpected character)
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 18 13:15:30 2013
From: report at bugs.python.org (Popa Claudiu)
Date: Mon, 18 Mar 2013 12:15:30 +0000
Subject: [New-bugs-announce] [issue17457] Unittest discover fails with
	namespace packages and	builtin modules
Message-ID: <1363608930.16.0.788491274205.issue17457@psf.upfronthosting.co.za>


New submission from Popa Claudiu:

There is a problem with unittest discovering and namespace packages. Given the following folder structure, where a namespace package X lies, the following command fails with the following error:

-testbug
   - flufl (namespace package with some tests in it, importable with __import__)
      - test_a.py
      - test_b.py


C:\>py -3 -m unittest discover flufl
Traceback (most recent call last):
  File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python33\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Python33\lib\unittest\__main__.py", line 12, in <module>
    main(module=None)
  File "C:\Python33\lib\unittest\main.py", line 124, in __init__
    self.parseArgs(argv)
  File "C:\Python33\lib\unittest\main.py", line 144, in parseArgs
    self._do_discovery(argv[2:])
  File "C:\Python33\lib\unittest\main.py", line 242, in _do_discovery
    self.test = loader.discover(start_dir, pattern, top_level_dir)
  File "C:\Python33\lib\unittest\loader.py", line 205, in discover
    start_dir = os.path.abspath(os.path.dirname((the_module.__file__)))
AttributeError: 'module' object has no attribute '__file__'

This happens because TestLoader.discover assumes that the given dotted package name has the attribute __file__, which seems to not be true in the case of namespace packages. The same error occurs when giving to `discover` a builtin module.
The attached patch tries naively to solve this issue, but it assume in TestLoader._find_tests that it should iterate over all subfolders (the commented line from the patch), unlike the previous way of checking the presence of __init__.py file.
Thanks in advance for your response.

----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 184450
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Unittest discover fails with namespace packages and builtin modules
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29441/unittest.patch

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

From report at bugs.python.org  Mon Mar 18 13:53:43 2013
From: report at bugs.python.org (Jose Antonio Martin H)
Date: Mon, 18 Mar 2013 12:53:43 +0000
Subject: [New-bugs-announce] [issue17458] Automatic type conversion from set
	to frozenset
Message-ID: <1363611223.63.0.126698662762.issue17458@psf.upfronthosting.co.za>


New submission from Jose Antonio Martin H:

Is it possible to consider the automatic type conversion from set to frozenset whenever a set is declared inside a set, as the key of a Counter and as the key of a Dict? Tha is, the case when a set is used but a hashable object is requested.

Having to deal with typing frozenset every time is very uncomfortable and it is quite natural to work with sets of sets.

If you get an exception when trying to create a set of set then why not deferring such exception to the case of trying to modify an immutable set?

----------
components: Library (Lib)
messages: 184451
nosy: jamartinh
priority: normal
severity: normal
status: open
title: Automatic type conversion from set to frozenset
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 18 14:48:28 2013
From: report at bugs.python.org (Matthijs van der Vleuten)
Date: Mon, 18 Mar 2013 13:48:28 +0000
Subject: [New-bugs-announce] [issue17459] unittest.assertItemsEqual reports
	wrong order
Message-ID: <1363614508.19.0.767230609984.issue17459@psf.upfronthosting.co.za>


New submission from Matthijs van der Vleuten:

When calling assertItemsEqual(first,second), if the items in a and b differ, the AssertionError treats second as the first sequence and first as the second sequence.

Repro code:

>>> from unittest.case import TestCase
>>> class Foo(TestCase):
...     def runTest(self):
...             self.assertItemsEqual([1],[])
... 
>>> Foo().runTest()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in runTest
  File "/usr/lib/python2.7/unittest/case.py", line 899, in assertItemsEqual
    self.fail(msg)
  File "/usr/lib/python2.7/unittest/case.py", line 408, in fail
    raise self.failureException(msg)
AssertionError: Element counts were not equal:
First has 0, Second has 1:  1

This happens because of this code in unittest/case.py:

def assertItemsEqual(self, expected_seq, actual_seq, msg=None):
    # (skip docstring)
    first_seq, second_seq = list(actual_seq), list(expected_seq)

list(actual_seq) is assigned to first_seq, even though it's actually the second argument.

This would be fixed either by swapping expected_seq and actual_seq in the function's arguments, or swapping the assignment of first_seq and second_seq.

----------
components: Library (Lib)
messages: 184452
nosy: Zr40
priority: normal
severity: normal
status: open
title: unittest.assertItemsEqual reports wrong order
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 18 16:01:04 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Mar 2013 15:01:04 +0000
Subject: [New-bugs-announce] [issue17460] Remove the strict and related
	params completely removing	the 0.9 support
Message-ID: <1363618864.34.0.693275947596.issue17460@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

issue10711 Removed the HTTP 0.9 support in 3.2 and deprecated strict and related params in 3.2. It is time to remove those in 3.4.

----------
assignee: orsenthil
messages: 184458
nosy: orsenthil, pitrou
priority: normal
severity: normal
status: open
title: Remove the strict and related params completely removing the 0.9 support

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

From report at bugs.python.org  Mon Mar 18 16:49:13 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 18 Mar 2013 15:49:13 +0000
Subject: [New-bugs-announce] [issue17461] Carole should be Carol in PEP 396
Message-ID: <1363621753.03.0.68925704704.issue17461@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In here, "now get it from the Cheeseshop.

Carole maintains several namespace packages,"

----------
messages: 184462
nosy: Ramchandra Apte
priority: normal
severity: normal
status: open
title: Carole should be Carol in PEP 396

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

From report at bugs.python.org  Mon Mar 18 17:42:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Mar 2013 16:42:28 +0000
Subject: [New-bugs-announce] [issue17462] argparse FAQ: how it is different
	from optparse
Message-ID: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://stackoverflow.com/questions/3217673/why-use-argparse-rather-than-optparse

Too many votes. This should be confirmed by the official documentation.

----------
assignee: docs at python
components: Documentation
messages: 184468
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: argparse FAQ: how it is different from optparse

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

From report at bugs.python.org  Mon Mar 18 18:04:01 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 18 Mar 2013 17:04:01 +0000
Subject: [New-bugs-announce] [issue17463] Fix test discovery for test_pdb.py
Message-ID: <1363626241.39.0.317385354183.issue17463@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Fix test discovery for test_pdb.py
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 18 19:37:26 2013
From: report at bugs.python.org (Matt Bachmann)
Date: Mon, 18 Mar 2013 18:37:26 +0000
Subject: [New-bugs-announce] [issue17464] Improve Test Coverage Of Pydoc
Message-ID: <1363631846.77.0.422543713509.issue17464@psf.upfronthosting.co.za>


New submission from Matt Bachmann:

Adds some test coverage to pydoc.

----------
files: pydoctests.patch
keywords: patch
messages: 184486
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: Improve Test Coverage Of Pydoc
versions: Python 3.5
Added file: http://bugs.python.org/file29448/pydoctests.patch

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

From report at bugs.python.org  Mon Mar 18 19:46:06 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Mar 2013 18:46:06 +0000
Subject: [New-bugs-announce] [issue17465] Gut devinabox
Message-ID: <1363632366.54.0.638197438199.issue17465@psf.upfronthosting.co.za>


New submission from Brett Cannon:

While devinabox was originally designed such that anyone running a core dev sprint could have an easy way to grab everything, it has turned out only core devs end up using it. That makes having a script to do checkouts, builds, etc. is overkill.

What devinabox should become instead is a README listing what people should checkout/download and build. Probably the only other file should be a shell script to do the thorough coverage.py run as found at http://docs.python.org/devguide/coverage.html#coverage-results-for-modules-imported-early-on since it's the most touchy. This would also allow for ripping out the details from the devguide and just point to the shell script at hg.python.org.

----------
assignee: brett.cannon
messages: 184489
nosy: brett.cannon, ncoghlan, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: Gut devinabox

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

From report at bugs.python.org  Mon Mar 18 20:36:40 2013
From: report at bugs.python.org (Georgiy Treyvus)
Date: Mon, 18 Mar 2013 19:36:40 +0000
Subject: [New-bugs-announce] [issue17466] I can't make assignments to a list.
Message-ID: <1363635400.77.0.251623355934.issue17466@psf.upfronthosting.co.za>


New submission from Georgiy Treyvus:

The conditions under which this bug occurs I can't explain. I will provide as much other information as I can.

This is an issue with both Python2 and Python3. More specifically Python 2.7.3 and Python 3.2.3 as those are what come with the Fedora 17 repositories. Not that it matters I made sure my program is written portably and so works on both. This involved stunts like:

if sys.version_info[0]==2:
    input=raw_input

Getting back to the point since strings in Python are immutable I instead have code that tries to assign a character string to a list of one character strings at a given index in that list. Now normally this works quite splendidly. For example:

[georgiy at PANTHER mess]$ python
Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> l=list('test')
>>> l
['t', 'e', 's', 't']
>>> l[0]='b'
>>> l
['b', 'e', 's', 't']
>>> 
[georgiy at PANTHER mess]$ python3
Python 3.2.3 (default, Jun  8 2012, 05:36:09) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> l=list('test')
>>> l
['t', 'e', 's', 't']
>>> l[0]='b'
>>> l
['b', 'e', 's', 't']
>>> 
[georgiy at PANTHER mess]$ 

See all is well.

However when I attempt to do the same exact thing namely assign a one character string to a list of one character strings at a given index in that list I get an error.

Here's what happens when I run my program:

[georgiy at PANTHER mess]$ python gcipher.py

Enter a command. Valid ones are "encrypt", "decrypt", and "exit".
command: encrypt

Enter plaintext. Only alphabetic characters allowed.
plaintext: secretmessagehere

Enter the encryption key. Only alphabetic characters allowed.
key: secretkeyhere

The encrypted version of your input with the given key is:
Traceback (most recent call last):
  File "gcipher.py", line 214, in <module>
    print(encrypt(inText,encryptionKey))
  File "gcipher.py", line 127, in encrypt
    letters[index]=letterAdd(letters[index],keystream[index])
TypeError: 'str' object does not support item assignment
[georgiy at PANTHER mess]$ python3 gcipher.py

Enter a command. Valid ones are "encrypt", "decrypt", and "exit".
command: encrypt

Enter plaintext. Only alphabetic characters allowed.
plaintext: secretmessagehere

Enter the encryption key. Only alphabetic characters allowed.
key: secretkeyhere

The encrypted version of your input with the given key is:
Traceback (most recent call last):
  File "gcipher.py", line 214, in <module>
    print(encrypt(inText,encryptionKey))
  File "gcipher.py", line 127, in encrypt
    letters[index]=letterAdd(letters[index],keystream[index])
TypeError: 'str' object does not support item assignment
[georgiy at PANTHER mess]$ 


Anyway here is the final proof that we have a bug here and that I am not a complete moron that assigned to a string. It says there's a problem on line 127. Well here are are few very relevant lines 120-126 right before 127 you might want to take a look at:

	assert(type(plaintext)==str)
	letters=list(plaintext)	
	assert(type(letters)==list)
	assert(type(letters[0])==str)
	assert(len(letters[0])==1)
	for roundNumber in range(17):
		for index in range(plaintextLength):

The point is that all the assertions in the above assert statements held true. No AssertionErrors were raised. What was instead raised is a TypeError because Python thought I was assigning to an index in a string. Yet clearly right before that we have asserted that the variable "letters" is bound to a list type. And in line 127 I was assigning a one character string to an index in "letters" which again is a list and not a string.

Please look into this. If you need more information let me know and I will do my best to provide it. If you want I can also provide you folks with the complete source code if you feel it will help you. (I do warn in advance that it is quite messy/hacky/unPythonic to the point of me quite possibly becoming the laughingstock of the Python developer community. Of course considering the rather complicated nature of the transformations made on text during (en|de)cryption I'd like to see any critics do it better. Please do not laugh too hard when I show it.)

----------
components: Interpreter Core
messages: 184501
nosy: wfatp
priority: normal
severity: normal
status: open
title: I can't make assignments to a list.

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

From report at bugs.python.org  Mon Mar 18 21:09:13 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 18 Mar 2013 20:09:13 +0000
Subject: [New-bugs-announce] [issue17467] Enhancement: give mock_open
	readline() and readlines()	methods
Message-ID: <1363637353.75.0.10594649772.issue17467@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi:

unittest.mock provides a mock_open convenience function[1].  The convenience function handled file.read() but does not handle file.readline() or file.readlines().  I'll attach a patch that adds support for both of these methods.

[1]: http://docs.python.org/3/library/unittest.mock.html#mock-open

----------
files: python3-mock_open-methods.patch
keywords: patch
messages: 184512
nosy: a.badger
priority: normal
severity: normal
status: open
title: Enhancement: give mock_open readline() and readlines() methods
versions: Python 3.3
Added file: http://bugs.python.org/file29454/python3-mock_open-methods.patch

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

From report at bugs.python.org  Mon Mar 18 21:34:25 2013
From: report at bugs.python.org (=?utf-8?b?QW5zc2kgS8Okw6RyacOkaW5lbg==?=)
Date: Mon, 18 Mar 2013 20:34:25 +0000
Subject: [New-bugs-announce] [issue17468] Generator memory leak
Message-ID: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>


New submission from Anssi K??ri?inen:

A generator is leaked to gc.garbage in a situation where `__del__` isn't defined. See the attached file for as-minimalistic test case as I could make. Tested on Python 3.3.0, 3.2.3 and 2.7.3.

Note that if the try-except is removed from iterator(), then there is no leak.

This is related to Django bug #19895 (https://code.djangoproject.com/ticket/19895).

----------
files: test.py
messages: 184515
nosy: Anssi.K??ri?inen
priority: normal
severity: normal
status: open
title: Generator memory leak
type: resource usage
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file29455/test.py

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

From report at bugs.python.org  Mon Mar 18 21:45:08 2013
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Mon, 18 Mar 2013 20:45:08 +0000
Subject: [New-bugs-announce] [issue17469] Fix sys.getallocatedblocks() when
	running on valgrind
Message-ID: <1363639508.69.0.910213848497.issue17469@psf.upfronthosting.co.za>


New submission from Piotr O?arowski:

[Forwarding patch from Julien Cristau <julien.cristau at logilab.fr>]

_Py_AllocatedBlocks was never incremented in PyObject_Malloc(), but
would still be decremented on failure or in PyObject_Free().

----------
components: Interpreter Core
files: obmalloc.patch
keywords: patch
messages: 184517
nosy: piotr
priority: normal
severity: normal
status: open
title: Fix sys.getallocatedblocks() when running on valgrind
Added file: http://bugs.python.org/file29456/obmalloc.patch

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

From report at bugs.python.org  Mon Mar 18 22:47:12 2013
From: report at bugs.python.org (Mohammad Akram)
Date: Mon, 18 Mar 2013 21:47:12 +0000
Subject: [New-bugs-announce] [issue17470] random.choice should accept a set
	as input
Message-ID: <1363643232.74.0.469965121668.issue17470@psf.upfronthosting.co.za>


New submission from Mohammad Akram:

I think the random.choice function should support sets. The random.sample function already supports sets and therefore the API should be consistent in this regard.

This is how it's done in the sample method (line 295):

        if isinstance(population, _Set):
            population = tuple(population)

----------
components: Library (Lib)
messages: 184532
nosy: Mohammad.Akram
priority: normal
severity: normal
status: open
title: random.choice should accept a set as input
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 19 00:38:12 2013
From: report at bugs.python.org (Daniel Wozniak)
Date: Mon, 18 Mar 2013 23:38:12 +0000
Subject: [New-bugs-announce] [issue17471] Patch for Additional Test Coverage
	for urllib.error
Message-ID: <1363649892.85.0.895729297472.issue17471@psf.upfronthosting.co.za>


New submission from Daniel Wozniak:

Adding test to get 100% coverage in urllib.error.

----------
components: Tests
files: patch.diff
keywords: patch
messages: 184554
nosy: dwoz
priority: normal
severity: normal
status: open
title: Patch for Additional Test Coverage for urllib.error
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29465/patch.diff

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

From report at bugs.python.org  Tue Mar 19 00:55:54 2013
From: report at bugs.python.org (Daniel Wozniak)
Date: Mon, 18 Mar 2013 23:55:54 +0000
Subject: [New-bugs-announce] [issue17472] Patch for Additional Test Coverage
	in urllib.parse
Message-ID: <1363650954.41.0.872815127355.issue17472@psf.upfronthosting.co.za>


New submission from Daniel Wozniak:

Adding additional tests to get 100% coverage in urllib.parse module. It should be noted that line 598 technically has coverage but it does not appear that way due to an peephole optimization, at least we think that is the case.

----------
components: Tests
files: patch.diff
keywords: patch
messages: 184559
nosy: dwoz
priority: normal
severity: normal
status: open
title: Patch for Additional Test Coverage in urllib.parse
versions: Python 3.4
Added file: http://bugs.python.org/file29467/patch.diff

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

From report at bugs.python.org  Tue Mar 19 01:14:07 2013
From: report at bugs.python.org (Devin Jeanpierre)
Date: Tue, 19 Mar 2013 00:14:07 +0000
Subject: [New-bugs-announce] [issue17473] -m is not universally applicable
Message-ID: <1363652047.27.0.660639170602.issue17473@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

Many executables in python are meant to be run on python scripts, but can't run python scripts that are part of a package. For example, one can do `python -m pdb foo.py`, but not `python -m pdb package.foo`. This makes it more difficult to interact with executable scripts within a package. In particular, the following will NOT work in general: `python -m pdb package/foo.py`

It would be easier if these modules gained their own `-m` argument to specify import paths instead of files. For example, the third party coverage module does this, and can be run using the command `python -m coverage run -m package.foo`.

What follows is a small list of scripts present as modules in the Python stdlib that involve manipulating other scripts, and so could benefit from a -m option.

pdb
profile
doctest
trace
modulefinder
tabnanny
pyclbr
dis

In the case of pydoc, unittest (unittest discover, etc.) -- these are special cases, as they interpret input as either a path OR a module via guessing. There may not be any benefit to adding a -m option.

----------
messages: 184564
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: -m is not universally applicable
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 19 01:16:16 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Mar 2013 00:16:16 +0000
Subject: [New-bugs-announce] [issue17474] Remove the deprecated methods of
	Request class
Message-ID: <1363652176.25.0.00819837131924.issue17474@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

Number of methods of Request class were deprecated in 3.3 #10050
This issue to to track their removal in 3.4.

----------
assignee: orsenthil
messages: 184565
nosy: orsenthil
priority: normal
severity: normal
status: open
title: Remove the deprecated methods of Request class
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 19 01:58:48 2013
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 19 Mar 2013 00:58:48 +0000
Subject: [New-bugs-announce] [issue17475] Better doc on using python-gdb.py
Message-ID: <1363654728.46.0.181604306018.issue17475@psf.upfronthosting.co.za>


New submission from Cherniavsky Beni:

recent gdb versions by default won't auto-load python-gdb.py.
issue15043 fixed this in test_gdb, but manual action is still needed to when a developer actually wants to run gdb.

Attached devguide patch.
After writing this I noticed it's already explained in faq.txt, but I think it's important to also explain it in the devguide's GDB section.

Should this also be mentioned inside python-gdb.py?
And why does that file have a Tools/gdb/libpython.py doppleganger?

----------
components: Devguide
files: python-gdb-how-to-load.diff
keywords: patch
messages: 184574
nosy: cben, ezio.melotti, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: Better doc on using python-gdb.py
versions: Python 3.4
Added file: http://bugs.python.org/file29469/python-gdb-how-to-load.diff

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

From report at bugs.python.org  Tue Mar 19 05:24:08 2013
From: report at bugs.python.org (Matt Bachmann)
Date: Tue, 19 Mar 2013 04:24:08 +0000
Subject: [New-bugs-announce] [issue17476] Pydoc allmethods does not return
	all methods
Message-ID: <1363667048.07.0.0667508648134.issue17476@psf.upfronthosting.co.za>


New submission from Matt Bachmann:

Somewhere between python 2.7 and now the definition of a method changed causing this helper method in pydoc to break. This was discovered in http://bugs.python.org/issue17464 by r.david.murray when he found it curious that a test I wrote was passing. I had assumed the implemented behavior was correct.

Attached is a patch that ads in an updated version of that test with a fix to the bug. The method updated is only used in that one place as is indicated as private. So it only gets in classes. I went ahead and updated the param to reflect this.

----------
components: Library (Lib)
files: pydoc_tests_v3.patch
keywords: patch
messages: 184590
nosy: Matt.Bachmann, r.david.murray
priority: normal
severity: normal
status: open
title: Pydoc allmethods does not return all methods
versions: Python 3.5
Added file: http://bugs.python.org/file29472/pydoc_tests_v3.patch

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

From report at bugs.python.org  Tue Mar 19 06:34:55 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 19 Mar 2013 05:34:55 +0000
Subject: [New-bugs-announce] [issue17477] update the bsddb module do build
	with db 5.x versions
Message-ID: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the bsddb module is still supported in 2.7, however only builds using db versions up to 4.8, which at least some Linux distributions ship anymore.  Proposing to update the bsddb module to pybsddb 5.3.0, which supports to build using db up to 5.3.0.

The downside is that this pybsddb version drops support to build using db 4.1 and 4.2 (requires db 4.3 as a minimum). However checking at least seven year old Ubuntu 6.10 (Hardy Heron) reveals that 4.3 is already supported by this version.

I'd like to have some input/tests how the tests do go with this patch with different db versions. please report test results into this issue.

----------
assignee: doko
components: Build
messages: 184598
nosy: doko
priority: high
severity: normal
stage: patch review
status: open
title: update the bsddb module do build with db 5.x versions
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 19 09:58:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Mar 2013 08:58:39 +0000
Subject: [New-bugs-announce] [issue17478] Tkinter's split() inconsistent for
	bytes and unicode	strings
Message-ID: <1363683519.76.0.514671428108.issue17478@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tkinter's split() recursive splits bytes but not unicode strings.

>>> from tkinter import *
>>> t = Tcl()
>>> t.tk.split((b'a 2',))
(('a', '2'),)
>>> t.tk.split(('a 2',))
('a 2',)

----------
components: Tkinter, Unicode
messages: 184622
nosy: ezio.melotti, gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tkinter's split() inconsistent for bytes and unicode strings
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 19 16:05:26 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Mar 2013 15:05:26 +0000
Subject: [New-bugs-announce] [issue17479] Fix test discovery for test_io.py
Message-ID: <1363705526.06.0.447966488633.issue17479@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch converts test_main() to load_tests(*args) due to test_main doing a lot of namespace manipulation on all the test classes.  There are a lot of subclassing issues that discovery doesn't like, hence throwing away the second argument passed to load_tests and just creating the tests the way test_main did.

----------
components: Tests
files: test_io_discovery.diff
keywords: patch
messages: 184636
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_io.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29478/test_io_discovery.diff

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

From report at bugs.python.org  Tue Mar 19 18:29:30 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 19 Mar 2013 17:29:30 +0000
Subject: [New-bugs-announce] [issue17480] pyvenv should be installed
	someplace more obvious on	Windows
Message-ID: <1363714170.98.0.299571294884.issue17480@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

On Windows, pyvenv.py is installed to PythonNN\Tools\Scripts, which I would generally recommend not be added to the system's or user's PATH.

It would be nice if there were a Windows-friendly launcher that's available similar to what's available on Unix. For example, on Unix, a script is created in /usr/bin/pyvenv-3.3 for Python 3.3 environments.

Perhaps Windows installs should include (alongside Python.exe) a pyvenv.exe that invokes venv for the Python environment in which it's executed. Then, if that Python.exe appears in the path, then invoking 'pyvenv' would be invoked for that Python. That approach would better fit my expectations.

Note, though, that one can always use 'py' to invoke venv as so:

py -3 -m venv

However, this mode of invocation is slightly clumsy and probably quite incongruent with the Unix style invocation (complicating a documentation author's "how to" for installing envs).

----------
components: Windows
messages: 184645
nosy: jason.coombs
priority: low
severity: normal
status: open
title: pyvenv should be installed someplace more obvious on Windows
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 19 18:31:32 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 19 Mar 2013 17:31:32 +0000
Subject: [New-bugs-announce] [issue17481] inspect.getfullargspec could use
	__signature__
Message-ID: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za>


New submission from Michael Foord:

inspect.getfullargspec (and potentially getargspec?) could *use* function.__signature__ if set. This allows functions that lie about their signature with the new introspection tool (Signature) to still work with older code.

----------
components: Library (Lib)
messages: 184646
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: inspect.getfullargspec could use __signature__
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 19 18:35:42 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Mar 2013 17:35:42 +0000
Subject: [New-bugs-announce] [issue17482] functools.update_wrapper doesn't
	overwrite attributes	correctly
Message-ID: <1363714542.8.0.838364934538.issue17482@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

functools.update_wrapper inadvertently overwrites the just set __wrapped__ attribute when it updates the contents of __dict__.

This means the intended __wrapped__ chain is never created - instead, for every function in a wrapper stack, __wrapped__ will always refer to the innermost function.

This means that using __wrapped__ to bypass functools.lru_cache doesn't work correctly if the decorated function already has __wrapped__ set.

Explicitly setting __signature__ fortunately still works correctly, since that is checked before recursing down through __wrapped__ in inspect.signature.

----------
messages: 184648
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: functools.update_wrapper doesn't overwrite attributes correctly
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 19 18:55:31 2013
From: report at bugs.python.org (Daniel Wozniak)
Date: Tue, 19 Mar 2013 17:55:31 +0000
Subject: [New-bugs-announce] [issue17483] In urlopen the check_hostname
	variable can never be	False.
Message-ID: <1363715731.1.0.258453337852.issue17483@psf.upfronthosting.co.za>


New submission from Daniel Wozniak:

In the urllib.request.urlopen on line 154 the code path that sets check_hostname to False will never run. I'm not sure what the desired behavior is. If we want to have a way to tell urlopen not to check the hostname for https connections it looks as though there needs to be some re-factoring.

----------
components: Library (Lib)
files: comments.diff
keywords: patch
messages: 184650
nosy: dwoz, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: In urlopen the check_hostname variable can never be False.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29482/comments.diff

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

From report at bugs.python.org  Tue Mar 19 21:00:39 2013
From: report at bugs.python.org (Thomas Fenzl)
Date: Tue, 19 Mar 2013 20:00:39 +0000
Subject: [New-bugs-announce] [issue17484] add tests for getpass
Message-ID: <1363723239.26.0.473131907274.issue17484@psf.upfronthosting.co.za>


Changes by Thomas Fenzl <thomas.fenzl at gmx.net>:


----------
components: Tests
nosy: Thomas Fenzl
priority: normal
severity: normal
status: open
title: add tests for getpass
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 19 21:25:50 2013
From: report at bugs.python.org (Daniel Wozniak)
Date: Tue, 19 Mar 2013 20:25:50 +0000
Subject: [New-bugs-announce] [issue17485] Deleting Request data does not
	update Content-length	header.
Message-ID: <1363724750.93.0.788897828966.issue17485@psf.upfronthosting.co.za>


New submission from Daniel Wozniak:

The patch to fix issue http://bugs.python.org/issue16464 neglects the deleter method of the Request.data property. This allows Request._data to get updated without removing the Content-length header.

----------
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 184668
nosy: dwoz, orsenthil
priority: normal
severity: normal
status: open
title: Deleting Request data does not update Content-length header.
versions: Python 3.4
Added file: http://bugs.python.org/file29485/patch.diff

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

From report at bugs.python.org  Tue Mar 19 21:36:00 2013
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 19 Mar 2013 20:36:00 +0000
Subject: [New-bugs-announce] [issue17486] datetime.timezone returns the
	wrong tzname()
Message-ID: <1363725360.78.0.545184964359.issue17486@psf.upfronthosting.co.za>


New submission from Lennart Regebro:

When calling tzname() on a timezone object it will return "UTC" + the offset.

>>> from datetime import timezone, timedelta, datetime
>>> tz = timezone(timedelta(hours=3))
>>> dt = datetime(2013, 3, 14, 12, 30, tzinfo=tz)
>>> dt.tzname()
'UTC+03:00'

But this breaks strftime:

>>> dt.strftime("%Z%z")
'UTC+03:00+0300'

I think that tzname() should never return an offset, and that for the static offset "timezone" class should always return 'GMT' for any offset, unless a name was explicitly set when creating the timezone instance.

The timezone.utc timezone instance should have the name set to 'UTC'.

This is consistent with how time.tzname works, and hence provides Least Surprise:

>>> import time
>>> time.timezone
86400
>>> time.tzname
('PST', 'PDT')

>>> import os
>>> os.environ['TZ'] = 'GMT-3'
>>> time.tzset()
>>> time.timezone
-10800
>>> time.tzname
('GMT', 'GMT')

>>> os.environ['TZ'] = 'UTC'
>>> time.tzset()
>>> time.timezone
0
>>> time.tzname
('UTC', 'UTC')

----------
components: Library (Lib)
messages: 184673
nosy: lregebro
priority: normal
severity: normal
status: open
title: datetime.timezone returns the wrong tzname()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 19 21:59:09 2013
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 19 Mar 2013 20:59:09 +0000
Subject: [New-bugs-announce] [issue17487] wave.Wave_read.getparams should be
	more user friendly
Message-ID: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za>


New submission from Popa Claudiu:

wave.Wave_read/Wave_write.getparams returns a tuple with various info about the wav file, when it could return a namedtuple, that can be manipulated in a richer way. I attached a patch. It doesn't have any tests, mainly because .getparams isn't tested at all in the original test_wave.py.

----------
components: Library (Lib)
files: wave.patch
keywords: patch
messages: 184680
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: wave.Wave_read.getparams should be more user friendly
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29488/wave.patch

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

From report at bugs.python.org  Wed Mar 20 02:29:46 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 20 Mar 2013 01:29:46 +0000
Subject: [New-bugs-announce] [issue17488] subprocess.Popen bufsize=0
	parameter behaves differently	in Python 3 than in 2
Message-ID: <1363742986.45.0.357278360182.issue17488@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The subprocess module in Python 3 uses io.open(file_descriptor, mode, bufsize) to create its Popen stdout, stderr and stdin file objects.

In Python 2, it used the old os.fdopen which created an old-style python 2 file object that simply wraps libc's FILE* interface.

This results in a behavior difference between Python 2 and Python 3 subprocesses as the bufsize=0 on io.open()ed files results in a RawIOBase file object whos read() or write() methods map directly to a single underlying system call.  ie: In Python 3 if you Popen.read(30000) and there are only 12345 bytes in the pipe from the child, it will return 12345 bytes rather than blocking while it makes further read() syscalls until it gets enough data or EOF as it would with the libc backed file objects in Python 2.

This tripped up the imaplib module in Issue17443.  (since fixed by explicitly enabling buffered I/O).

This behavior difference will make porting code to work on both Python 2 and 3 a bit more painful as bufsize=non-zero must be specified by the user for consistent behavior.

I'd like to fix this by changing the default bufsize=0 to bufsize=io.DEFAULT_BUFFER_SIZE, but only if I can do that in 3.2 and 3.3 .  If I can't, it _does_ seem like an API change, I'll just make a documentation update to mention the issue and the best practice for 2.x and 3.x compatibility.

[note: this issue does not apply to my subprocess32 backport running on python 2.x because that uses python2's the old style file os.fdopen]

marking release blocker to ask for comments from the 3.2 and 3.3 release managers on if i can consider changing the default subprocess.Popen bufsize parameter value or not.

----------
assignee: gregory.p.smith
messages: 184718
nosy: georg.brandl, gregory.p.smith, larry
priority: release blocker
severity: normal
status: open
title: subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 20 02:49:12 2013
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Wed, 20 Mar 2013 01:49:12 +0000
Subject: [New-bugs-announce] [issue17489] random.Random implements
	__getstate__() and __reduce__()
Message-ID: <1363744152.72.0.512816356839.issue17489@psf.upfronthosting.co.za>


New submission from V?ctor Terr?n:

The random.Random class implements both the __getstate__() and __reduce__() methods. My knowledge of the pickle module is very limited, but apparently this causes __getstate__() never to get called. Maybe this is a remnant from earlier code, or are both methods actually needed?

----------
components: Library (Lib)
messages: 184721
nosy: mark.dickinson, rhettinger, vterron
priority: normal
severity: normal
status: open
title: random.Random implements __getstate__() and __reduce__()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 20 03:34:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Mar 2013 02:34:35 +0000
Subject: [New-bugs-announce] [issue17490] Use converter functions to
	implement ast.literal_eval
Message-ID: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, ast.literal_eval uses a long if/elif chain to implement the limited parsing of the AST. This issue proposes changing the implementation to make it easy to extend to cover some of the implementation details of PEP 436 (Argument Clinic).

----------
files: ast_literal_eval_converter_functions.diff
keywords: patch
messages: 184722
nosy: ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Use converter functions to implement ast.literal_eval
type: enhancement
Added file: http://bugs.python.org/file29496/ast_literal_eval_converter_functions.diff

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

From report at bugs.python.org  Wed Mar 20 03:48:57 2013
From: report at bugs.python.org (Radu Voicilas)
Date: Wed, 20 Mar 2013 02:48:57 +0000
Subject: [New-bugs-announce] [issue17491] Consolidate traceback.format_tb
	and traceback.print_tb
Message-ID: <1363747737.23.0.181460448728.issue17491@psf.upfronthosting.co.za>


New submission from Radu Voicilas:

This is a patch that consolidates the implementation of traceback.format_tb and traceback.print_tb into one common internal function traceback._get_tb. The current implementations are almost identical, except that the print_tb() ones also prints to a file ...

Now, I don't really know what the Python developers feel about this kind of cleanups which doesn't really add any value for the end user. I've seen projects where this kind of patches are not accepted because of this. IMHO, making code more readable and reducing duplication is always a good thing.

----------
components: Library (Lib)
files: consolidate_tb_functions.diff
keywords: patch
messages: 184725
nosy: raduv
priority: normal
severity: normal
status: open
title: Consolidate traceback.format_tb and traceback.print_tb
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29497/consolidate_tb_functions.diff

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

From report at bugs.python.org  Wed Mar 20 04:02:50 2013
From: report at bugs.python.org (=?utf-8?b?VsOtY3RvciBUZXJyw7Nu?=)
Date: Wed, 20 Mar 2013 03:02:50 +0000
Subject: [New-bugs-announce] [issue17492] Increase test coverage for random
	(up to 99%)
Message-ID: <1363748570.23.0.662961868349.issue17492@psf.upfronthosting.co.za>


New submission from V?ctor Terr?n:

I'm attaching a patch to increase the code coverage of the random module to 99% (only one line missing, see issue #17489; it's reported as 89%, however, because of the _test(N=2000) function, which is not executed when the unit tests are run). Many of the new tests, especially gammavariate(), involve mocking Random.random() so that it returns a series of fixed values that guarantee that all the branches of the algorithm are executed ? hopefully this has been a good idea!

----------
components: Library (Lib)
files: test_random.diff
keywords: patch
messages: 184728
nosy: mark.dickinson, rhettinger, vterron
priority: normal
severity: normal
status: open
title: Increase test coverage for random (up to 99%)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29498/test_random.diff

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

From report at bugs.python.org  Wed Mar 20 15:49:16 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Mar 2013 14:49:16 +0000
Subject: [New-bugs-announce] [issue17493] Unskip
	SysModuleTest.test_recursionlimit_fatalerror on	Windows
Message-ID: <1363790956.56.0.816338130717.issue17493@psf.upfronthosting.co.za>


New submission from Zachary Ware:

With support.suppress_crash_popup(), we can stop skipping test_sys.SysModuleTest.test_recursionlimit_fatalerror on Windows.

----------
components: Tests
files: test_sys_unskip.diff
keywords: patch
messages: 184765
nosy: ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Unskip SysModuleTest.test_recursionlimit_fatalerror on Windows
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29504/test_sys_unskip.diff

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

From report at bugs.python.org  Wed Mar 20 17:28:29 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 20 Mar 2013 16:28:29 +0000
Subject: [New-bugs-announce] [issue17494] References to stack bottom are
	confusing
Message-ID: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

If stack is saved in list and printed to the screen, it will be printed as:
[
  root,
  second,
  last
]

And the last elements is the bottom element. The documentation at http://docs.python.org/3/reference/datamodel.html#frame-objects refers "bottom element" to be the first one. That's confusing. It is better to avoid top/bottom and use first/last or root/terminal.

----------
assignee: docs at python
components: Documentation
messages: 184771
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: References to stack bottom are confusing
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 20 19:15:36 2013
From: report at bugs.python.org (Ross Patterson)
Date: Wed, 20 Mar 2013 18:15:36 +0000
Subject: [New-bugs-announce] [issue17495] email.quoprimime.body_encode can't
	handle characters	that encodings.quopri_codec can
Message-ID: <1363803336.58.0.787199828624.issue17495@psf.upfronthosting.co.za>


New submission from Ross Patterson:

When using email.charset.Charset to encode MIME bodie as quoted-printable, some characters that are encodable with the quopri_codec cause a KeyError in email.quoprimime:

Python 3.3.0 (default, Oct  7 2012, 14:43:21) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> text_encoded = b'mo \xe2\x82\xac'
>>> text = text_encoded.decode('utf-8')
>>> print(text)
mo ?
>>> import codecs
>>> codecs.getencoder('quopri_codec')(text_encoded)[0]
b'mo=20=E2=82=AC'
>>> from email import charset
>>> c = charset.Charset('utf-8')
>>> c.header_encoding = charset.QP
>>> c.body_encoding = charset.QP
>>> c.header_encode(text)
'=?utf-8?q?mo_=E2=82=AC?='
>>> c.body_encode(text)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/email/charset.py", line 395, in body_encode
    return email.quoprimime.body_encode(string)
  File "/usr/lib/python3.3/email/quoprimime.py", line 240, in body_encode
    if body_check(ord(c)):
  File "/usr/lib/python3.3/email/quoprimime.py", line 81, in body_check
    return chr(octet) != _QUOPRI_BODY_MAP[octet]
KeyError: 8364

----------
components: email
messages: 184772
nosy: barry, r.david.murray, rpatterson
priority: normal
severity: normal
status: open
title: email.quoprimime.body_encode can't handle characters that encodings.quopri_codec can
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar 20 20:50:05 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 20 Mar 2013 19:50:05 +0000
Subject: [New-bugs-announce] [issue17496] OS X test for Tk availability in
	runtktests.py doesn't	work
Message-ID: <1363809005.08.0.908370147082.issue17496@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

If I run:

$ python -mtest.test_tk

I get a skip, after speaking with people familiar with OS X, it appears that the condition for the skip uses old Carbon APIs, which are totally deprecated under 64-bit. Attached is a patch which should work.

----------
files: tk-cond.diff
keywords: patch
messages: 184784
nosy: alex
priority: normal
severity: normal
status: open
title: OS X test for Tk availability in runtktests.py doesn't work
versions: Python 2.7
Added file: http://bugs.python.org/file29510/tk-cond.diff

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

From report at bugs.python.org  Wed Mar 20 21:47:36 2013
From: report at bugs.python.org (Matt Tierney)
Date: Wed, 20 Mar 2013 20:47:36 +0000
Subject: [New-bugs-announce] [issue17497] Unicode support for HTTP headers
	in http.client
Message-ID: <1363812456.89.0.0460717303906.issue17497@psf.upfronthosting.co.za>


New submission from Matt Tierney:

Changed the headers string charset to utf-8 since a header field may contain non-iso-8859-1 characters. For instance, a Location header field may contain Cyrillic characters.

----------
components: Library (Lib)
files: tierney.patch
keywords: patch
messages: 184792
nosy: tierney
priority: normal
severity: normal
status: open
title: Unicode support for HTTP headers in http.client
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29512/tierney.patch

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

From report at bugs.python.org  Wed Mar 20 21:48:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Mar 2013 20:48:30 +0000
Subject: [New-bugs-announce] [issue17498] error responses from server are
	masked in smtplib when	server closes connection
Message-ID: <1363812510.09.0.989538319205.issue17498@psf.upfronthosting.co.za>


New submission from R. David Murray:

If an SMTP server returns an error code and then closes the connection, smtplib will attempt to send an RSET command, which will then raise a socket error, which smtplib turns into a ServerDisconnectedError, thereby loosing the information about what error code the server actually returned.  While (except for code 421, as noted in issue 5713) a server doing this is technically out of spec with the RFC, it is a reality of the internet that it happens, and smtplib should handle it correctly.
  
Since the RSET is just to get the protocol back to a known starting state after an error, I believe the fix is to have an internal _rset method that wraps the RSET call in a try/except and just ignores any ServerDiscoonected error.  The library would then call this internally instead of the public API method.  If the library client continues on after the error code it gets back from calling an smtplib method that results in the server closing the connection, it will get the ServerDisconnected error the next time it tries to send a command to the server.  Thus the behavior change introduced here is just to allow commands that end with server disconnects to return an error code instead of an (otherwise mysterious and quite possibly currently-mishandled) ServerDisconnected error.  Since any existing code will already need to handle errors from commands sent to servers that *don't* disconnect, I believe that this is a safe fix from a backward compatibility standpoint.

----------
messages: 184793
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: error responses from server are masked in smtplib when server closes connection
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 20 22:09:19 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 20 Mar 2013 21:09:19 +0000
Subject: [New-bugs-announce] [issue17499] inspect.Signature and
	inspect.Parameter objects are	mutable
Message-ID: <1363813759.44.0.759244724725.issue17499@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The documentation for Inspect.Signature and Inspect.Parameter states that the objects are immutable.  And they go to great lengths to provide a convenient interface allowing you to "replace" members.

However, the objects make only a pathetic effort at being immutable.  They hide their public API members (e.g. "name") behind a property, which they store internally in a member prefixed with an underscore (e.g. "_name").  BUT THE INTERNAL MEMBER IS EXTERNALLY MUTABLE.

Example code:

    >>> def foo(i=3): pass
    >>> sig = inspect.signature(foo)
    >>> str(sig)
    '(i=3)'
    >>> sig.parameters['i']._name ='silly'
    >>> str(sig)
    '(silly3)'

----------
components: Library (Lib)
messages: 184796
nosy: brett.cannon, larry
priority: low
severity: normal
stage: test needed
status: open
title: inspect.Signature and inspect.Parameter objects are mutable
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 20 23:53:22 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 20 Mar 2013 22:53:22 +0000
Subject: [New-bugs-announce] [issue17500] move PC/icons/source.xar
	to	http://www.python.org/community/logos/
Message-ID: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za>


New submission from Matthias Klose:

This is a proposal to move the PC/icons/source.xar from the core distribution to the python website. Afaics currently the derived file PC/icons/baselogo is only used, and http://www.python.org/community/logos/ has even other recommended svg files for the logo.

The logo files were added in issue1490384, and source.xar explained (http://bugs.python.org/issue1490384#msg50276) as:

   > source.xar; not sure either

   This is the primary vector graphics source of the icons -
   the other SVG and PNG files are just there because other
   people requested them.

   It's in Xara format, a previously proprietary graphics
   application which has now gone open-source and is heading
   rapidly towards being usable on Linux, but isn't quite there
   yet.

However Xara was never open-source and shipped with pre-built binaries afaicr, and today you can't download even that anymore. Besides not being used for the (windows) build, Debian cannot even distribute this file, because it cannot be modified in it's current form with free software, and therefore has to be removed for the upstream tarball for each Debian upload.  So it would help Debian to ship the unmodified upstream tarball.

The source.xar could be kept available on the python website together with the other logo files.

----------
assignee: doko
messages: 184811
nosy: doko, loewis
priority: normal
severity: normal
status: open
title: move PC/icons/source.xar to http://www.python.org/community/logos/
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 21 01:29:05 2013
From: report at bugs.python.org (Thomas Fenzl)
Date: Thu, 21 Mar 2013 00:29:05 +0000
Subject: [New-bugs-announce] [issue17501] cannot create a raw string ending
	in backslash
Message-ID: <1363825745.66.0.69064999294.issue17501@psf.upfronthosting.co.za>


New submission from Thomas Fenzl:

r'\' and r"\" cannot be parsed, because the backslash escapes the quotation ending the string, leading to a syntax error

----------
messages: 184815
nosy: Thomas Fenzl
priority: normal
severity: normal
status: open
title: cannot create a raw string ending in backslash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 21 04:05:40 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Mar 2013 03:05:40 +0000
Subject: [New-bugs-announce] [issue17502] unittest.mock: side_effect
	iterators ignore DEFAULT
Message-ID: <1363835140.97.0.987850111396.issue17502@psf.upfronthosting.co.za>


New submission from Michael Foord:

An iterator set as a mock side_effect should be able to include mock.DEFAULT to use the standard return value.


    def test_side_effect_iterator_default(self):
        mock = Mock(return_value=2)
        mock.side_effect = [1, DEFAULT]
        result = mock(), mock()
        self.assertEqual(result, (1, 2))

----------
assignee: michael.foord
keywords: easy
messages: 184836
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock: side_effect iterators ignore DEFAULT
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 21 07:48:11 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Mar 2013 06:48:11 +0000
Subject: [New-bugs-announce] [issue17503] replace mode is always on in
	console
Message-ID: <1363848491.99.0.913021954161.issue17503@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

It is very annoying behavior of Python 3.3.0 that when you type in the console, replace mode is always on, and even after you press insert to go insert mode, it resets after every executed line.

Windows Vista 32.
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32

----------
components: Interpreter Core, Windows
messages: 184848
nosy: techtonik
priority: normal
severity: normal
status: open
title: replace mode is always on in console
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 21 07:48:34 2013
From: report at bugs.python.org (Radu Voicilas)
Date: Thu, 21 Mar 2013 06:48:34 +0000
Subject: [New-bugs-announce] [issue17504] Dropping duplicated docstring
	explanation of what Mocks'	side_effect does.
Message-ID: <1363848514.23.0.175887812295.issue17504@psf.upfronthosting.co.za>


New submission from Radu Voicilas:

Seems like there's a duplicated explanation in unittest.mock.Mock's docstring of what side_effect does. The attached patch should take care of that, if I'm not interpreting it wrong and it's actually on purpose there.

----------
components: Library (Lib)
files: drop_side_effect_docstring_duplicate.diff
keywords: patch
messages: 184849
nosy: michael.foord, raduv
priority: normal
severity: normal
status: open
title: Dropping duplicated docstring explanation of what Mocks' side_effect does.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29526/drop_side_effect_docstring_duplicate.diff

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

From report at bugs.python.org  Thu Mar 21 08:46:53 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Thu, 21 Mar 2013 07:46:53 +0000
Subject: [New-bugs-announce] [issue17505] email.header.Header.__unicode__
	does not decode header
Message-ID: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

The __unicode__ method is documented to "return the header as a Unicode string". For this to be useful, I would expect it to decode a string such as "=?gb2312?b?1eLKx9bQzsSy4srUo6E=?=" into a Unicode string that can be displayed to the user, in this case u'\u8fd9\u662f\u4e2d\u6587\u6d4b\u8bd5\uff01'.

However, unicode(header) returns the not so useful u"=?gb2312?b?1eLKx9bQzsSy4srUo6E=?=". Looking at the code of __unicode__, it appears that the code does attempt to decode the header into Unicode, but this fails for Headers initialized from a single MIME-quoted string, as is done by the message parser. In other words, __unicode__ is failing to call decode_header.

Here is a minimal example demonstrating the problem:

>>> msg = email.message_from_string('Subject: =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\nfoo\n')
>>> unicode(msg['subject'])
u'=?gb2312?b?1eLKx9bQzsSy4srUo6E=?='

Expected output of the last line:
u'\u8fd9\u662f\u4e2d\u6587\u6d4b\u8bd5\uff01'

To get the fully decoded Unicode string, one must use something like:
>>> u''.join(unicode(s, c) for s, c in email.header.decode_header(msg['subject']))

which is unintuitive and hard to teach to new users of the email package. (And looking at the source of __unicode__ it's not even obvious that it's correct ? it appears that a space must be added before us-ascii-coded chunks. The joining is non-trivial.)

The same problem occurs in Python 3.3 with str(msg['subject']).

----------
components: email
messages: 184856
nosy: barry, hniksic, r.david.murray
priority: normal
severity: normal
status: open
title: email.header.Header.__unicode__ does not decode header
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 21 08:58:43 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2013 07:58:43 +0000
Subject: [New-bugs-announce] [issue17506] Improve IDLE news handling
Message-ID: <1363852723.03.0.237286956936.issue17506@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Idle news items should be collected together in one place and released both in an IDLE section of each Misc/NEWS and in each idlelib/NEWS.txt. Once a decision is made where to collect them originally, a script should be written to make appropriate copies. If someone volunteers, scattered entries in current Misc/NEWS could be collected together.

----------
assignee: terry.reedy
messages: 184858
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve IDLE news handling
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 21 10:59:43 2013
From: report at bugs.python.org (Zulu)
Date: Thu, 21 Mar 2013 09:59:43 +0000
Subject: [New-bugs-announce] [issue17507] To add history time format in
	readline
Message-ID: <1363859983.51.0.876342279361.issue17507@psf.upfronthosting.co.za>


New submission from Zulu:

I'm using readline library, and would like to add date information in "readline.write_history_file" method without override it.

I think the best way is to add a argument for a strftime string. By default it should be simply ''.

----------
components: Build
messages: 184860
nosy: Zulu
priority: normal
severity: normal
status: open
title: To add history time format in readline
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 21 13:34:27 2013
From: report at bugs.python.org (Pierre Le Marre)
Date: Thu, 21 Mar 2013 12:34:27 +0000
Subject: [New-bugs-announce] [issue17508] logging.config.ConvertingDict
	issue with MemoryHandler
Message-ID: <1363869267.93.0.47675906919.issue17508@psf.upfronthosting.co.za>


New submission from Pierre Le Marre:

Hi, I use Python 3.2.3 and Python 3.3.0 on Windows 7 64 bits.
I have an issue with the short script enclosed.
I use the module logging to get a log file with logging.FileHandler. There were some issues about the file access on Windows, so I added a buffer with logging.handlers.MemoryHandler. I configure the logging using logging.config.dictConfig.
The issue appears when it comes to flush the MemoryHandler, either by reaching the capacity or by calling logging.shutdown(). Please find hereinbelow the traceback:

Traceback (most recent call last):
  File "C:\temp\bug-logging.py", line 38, in <module>
    logger.info(n)
  File "C:\Python32\lib\logging\__init__.py", line 1232, in info
    self._log(INFO, msg, args, **kwargs)
  File "C:\Python32\lib\logging\__init__.py", line 1364, in _log
    self.handle(record)
  File "C:\Python32\lib\logging\__init__.py", line 1374, in handle
    self.callHandlers(record)
  File "C:\Python32\lib\logging\__init__.py", line 1436, in callHandlers
    hdlr.handle(record)
  File "C:\Python32\lib\logging\__init__.py", line 835, in handle
    self.emit(record)
  File "C:\Python32\lib\logging\handlers.py", line 1090, in emit
    self.flush()
  File "C:\Python32\lib\logging\handlers.py", line 1150, in flush
    self.target.handle(record)
AttributeError: 'ConvertingDict' object has no attribute 'handle'

----------
components: Library (Lib)
files: bug-logging.py
messages: 184866
nosy: plemarre
priority: normal
severity: normal
status: open
title: logging.config.ConvertingDict issue with MemoryHandler
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file29527/bug-logging.py

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

From report at bugs.python.org  Thu Mar 21 14:47:20 2013
From: report at bugs.python.org (ILja Orlovs)
Date: Thu, 21 Mar 2013 13:47:20 +0000
Subject: [New-bugs-announce] [issue17509] Incorrect package version
	predicate parsing by distutils
Message-ID: <1363873640.53.0.825391664952.issue17509@psf.upfronthosting.co.za>


New submission from ILja Orlovs:

When `requires` list is present in the `distutils.core.setup` object, each element of that list is being parsed by `VersionPredicate` object (located in the `distutils/versionpredicate.py` file).

In its `__init__` method, the VersionPredicate uses `re_validPackage` regexp object (line 105 in my local `distutils/versionpredicate.py` file) to separate package name from its version postfix.

The `re_validPackage` regexp is declared as "(?i)^\s*([a-z_]\w*(?:\.[a-z_]\w*)*)(.*)".

AFAICU, this regexp is meant to separate package name (possibly dot-separated).

However, in some Linux'es (e.g. CentOs) some packages are actually dash-separated (e.g. "rpm-build". Technically that's minus sign, of course.). This mismatch leads to the following error when "rpm-build" is listed in "requires" section of a `setup` object:
{{{

$ python setup.py bdist
Traceback (most recent call last):
  File "setup.py", line 14, in <module>
    package_dir = {...}
  File "/usr/lib64/python2.6/distutils/core.py", line 113, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/lib64/python2.6/distutils/dist.py", line 258, in __init__
    getattr(self.metadata, "set_" + key)(val)
  File "/usr/lib64/python2.6/distutils/dist.py", line 1196, in set_requires
    distutils.versionpredicate.VersionPredicate(v)
  File "/usr/lib64/python2.6/distutils/versionpredicate.py", line 112, in __init__
    raise ValueError("expected parenthesized list: %r" % paren)
ValueError: expected parenthesized list: '-build'
}}}

Is suggest that `re_validPackage` regexp is changed to the "(?i)^\s*([a-z_]\w*(?:[.-][a-z_]\w*)*)(.*)" to accommodate for such package names.

----------
assignee: eric.araujo
components: Distutils
messages: 184869
nosy: eric.araujo, ilja_o, tarek
priority: normal
severity: normal
status: open
title: Incorrect package version predicate parsing by distutils
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 21 21:45:15 2013
From: report at bugs.python.org (Daniel Black)
Date: Thu, 21 Mar 2013 20:45:15 +0000
Subject: [New-bugs-announce] [issue17510] assertEquals deprecated in
	test_program.py (unittest)
Message-ID: <1363898715.94.0.418394016948.issue17510@psf.upfronthosting.co.za>


New submission from Daniel Black:

Following #9424 here's a patch that changes assertEquals -> assertEqual for Lib/unittest/test/test_program.py

against hg tip as of now

----------
components: Tests
files: unittest.patch
keywords: patch
messages: 184906
nosy: grooverdan
priority: normal
severity: normal
status: open
title: assertEquals deprecated in test_program.py (unittest)
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29533/unittest.patch

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

From report at bugs.python.org  Thu Mar 21 22:47:32 2013
From: report at bugs.python.org (Sarah)
Date: Thu, 21 Mar 2013 21:47:32 +0000
Subject: [New-bugs-announce] [issue17511] Idle find function closes after
	each find operation
Message-ID: <1363902452.43.0.911749750934.issue17511@psf.upfronthosting.co.za>


New submission from Sarah:

When I use the 'find' function in Idle, the dialogue closes after the first instance is found.

To find the next instance, one must then use the 'find again' function, rather than the 'find' function. One can also use Ctrl+G, but that may not be intuitive for new users, who may not frequently use keyboard shortcuts.

It would be nice to have a persistent box so that users can simply click 'find' repeatedly to iterate the 'find again' function. We would then have to alter when highlighting happens, as it currently happens only after the box is closed. 

I think the relevant code is located in the SearchDialog.py file on line 55.

Unfortunately, I can't figure out how to adjust this myself, as I am a n00b. 

Note: I am working on Windows 7 with python ver 2.7.3

----------
components: IDLE
messages: 184915
nosy: Kuchinsky
priority: normal
severity: normal
status: open
title: Idle find function closes after each find operation
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 21 23:56:23 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 21 Mar 2013 22:56:23 +0000
Subject: [New-bugs-announce] [issue17512] backport of the _sysconfigdata.py
	module (issue 13150)	breaks the build on darwin
Message-ID: <1363906583.54.0.309011739776.issue17512@psf.upfronthosting.co.za>


New submission from Matthias Klose:

The backport of #13150 to the 2.7 branch breaks the build on darwin. There is a special case for providing the _sysconfigdata module in _generate_posix_vars before get_platform is called (darwin only) and before the module is actually written.

However get_platform is called before, in site.addbuilddir(). Wondering if this call can either be avoided, or worked around.

options:

- backport issue586680 too (http://hg.python.org/cpython/rev/4742e7aea2f5/)
- fall back to generic values for osname, release, machine

any other options?

----------
assignee: doko
components: Build
messages: 184919
nosy: benjamin.peterson, doko, ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: backport of the _sysconfigdata.py module (issue 13150) breaks the build on darwin
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 22 00:12:40 2013
From: report at bugs.python.org (Amin)
Date: Thu, 21 Mar 2013 23:12:40 +0000
Subject: [New-bugs-announce] [issue17513] astrike(*) in argv
Message-ID: <1363907560.02.0.627372427517.issue17513@psf.upfronthosting.co.za>


New submission from Amin:

suppose the the following simple program argvtest.py:

import sys
print sys.argv[1]

in my Python 2.6.6. if I run it with the following parameters:
$ python argvtest.py tc*
it returns:
tc2 (or the first result of ls tc*) 
but it should return 
tc*

----------
components: Library (Lib)
files: argvtest.py
messages: 184921
nosy: Amin
priority: normal
severity: normal
status: open
title: astrike(*) in argv
versions: Python 2.6
Added file: http://bugs.python.org/file29536/argvtest.py

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

From report at bugs.python.org  Fri Mar 22 01:22:12 2013
From: report at bugs.python.org (David James)
Date: Fri, 22 Mar 2013 00:22:12 +0000
Subject: [New-bugs-announce] [issue17514] Add the license to argparse.py
Message-ID: <1363911732.52.0.330096157772.issue17514@psf.upfronthosting.co.za>


New submission from David James:

Lib/argparse.py [1] doesn't mention a license in it. Could you please add a license to it?

According to the argparse project [2], argparse is licensed under the Python license. Chromium OS uses argparse. If you would add information about the license to argparse, we'd appreciate it.

Here's an example license string that passes the Debian licensecheck [3] script:

# Licensed under the Python Software Foundation License version 2.7


In case you don't understand why Chromium wants include a license in argparse.py, rather than just consulting the global LICENSE file, here's a bit more detail: Chromium includes many files from different authors in its distribution. Many projects contain LICENSE files, but this doesn't mean that every file under the project is licensed under that license. So it's helpful if each file has a quick note that mentions what license it uses. This helps us ensure that we understand the license of all files we include. We automate this check using  Debian's licensecheck.pl script.


[1]: http://hg.python.org/cpython/file/62a988b3bf2e/Lib/argparse.py
[2]: https://code.google.com/p/argparse/source/browse/LICENSE.txt
[3]: http://ftp.de.debian.org/debian/pool/main/d/devscripts/devscripts_2.12.6.tar.gz or http://src.chromium.org/viewvc/chrome/trunk/src/third_party/devscripts/licensecheck.pl

----------
components: Library (Lib)
messages: 184929
nosy: David.James
priority: normal
severity: normal
status: open
title: Add the license to argparse.py
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 22 01:58:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2013 00:58:11 +0000
Subject: [New-bugs-announce] [issue17515] Add sys.setasthook() to allow to
	use a custom AST	optimizer
Message-ID: <1363913891.37.0.731570464343.issue17515@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I wrote an optimizer rewriting the AST to implement various optimizatoions:
https://bitbucket.org/haypo/astoptimizer

To be able to use it, or use any other kind of AST transformation, I propose to add a new sys.setasthook() function to set a custom AST hook.

Attached patch is a proof-of-concept. The patch should be improved: document the function and add write unit tests.

Prototype of the hook:

def asthook(ast, filename):
   # ...
   return new_ast

I don't know if we need to add a compiler option (like _ast.PyCF_ONLY_AST) to skip the hook.

----------
files: setasthook.patch
keywords: patch
messages: 184932
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Add sys.setasthook() to allow to use a custom AST optimizer
versions: Python 3.4
Added file: http://bugs.python.org/file29539/setasthook.patch

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

From report at bugs.python.org  Fri Mar 22 02:03:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2013 01:03:52 +0000
Subject: [New-bugs-announce] [issue17516] Dead code should be removed
Message-ID: <1363914232.35.0.997527694246.issue17516@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Using my astoptimizer project and the hook proposed in the issue #17515, I found the following dead code.
https://bitbucket.org/haypo/astoptimizer

Some code is not dead or unreachable in the general case, but only on a specific platform. I ran astoptimizer with all optimizations enabled, so os.name is replaced with "posix" for example. So "return os.name" is seen as dead code in the following function:

def _get_default_scheme():
    if os.name == 'posix':
        # the default scheme for posix is posix_prefix
        return 'posix_prefix'
    return os.name


Unreachable
===========

Lib/_pyio.py:2057: Assign(targets=[Name(id='initial_value', ctx=Store())], value=Call(func=Name(id='str', ctx=Load()), ...
Lib/sre_compile.py:68: Expr(value=Call(func=Name(id='emit', ctx=Load()), args=[Subscript(value=Name(id='OPCODES', ctx=Load(...
Lib/sre_compile.py:69: Assign(targets=[Name(id='skip', ctx=Store())], value=Call(func=Name(id='_len', ctx=Load()), args=[Na...
Lib/sre_compile.py:69: Expr(value=Call(func=Name(id='emit', ctx=Load()), args=[Num(n=0)], keywords=[], starargs=None, kwarg...
Lib/sre_compile.py:70: Expr(value=Call(func=Name(id='emit', ctx=Load()), args=[Subscript(value=Name(id='av', ctx=Load()), s...
Lib/sre_compile.py:71: Expr(value=Call(func=Name(id='emit', ctx=Load()), args=[Subscript(value=Name(id='av', ctx=Load()), s...
Lib/sre_compile.py:72: Expr(value=Call(func=Name(id='_compile', ctx=Load()), args=[Name(id='code', ctx=Load()), Subscript(v...
Lib/sre_compile.py:73: Expr(value=Call(func=Name(id='emit', ctx=Load()), args=[Subscript(value=Name(id='OPCODES', ctx=Load(...
Lib/sre_compile.py:74: Assign(targets=[Subscript(value=Name(id='code', ctx=Load()), slice=Index(value=Name(id='skip', ctx=L...
Lib/sysconfig.py:185: Return(value=Str(s='posix'))
Lib/test/test_posix.py:682: FunctionDef(name='_create_and_do_getcwd', args=arguments(args=[arg(arg='dirname', annotation=None), ...
Lib/test/test_posix.py:697: Expr(value=Call(func=Name(id='_create_and_do_getcwd', ctx=Load()), args=[Name(id='dirname', ctx=Load...
Lib/test/test_unicode.py:1938: Expr(value=Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertRaises', ctx=Load()), ...


Dead code
=========

Lib/datetime.py:2128: Expr(value=Str(s='\nSome time zone algebra.  For a datetime x, let\n    x.n = x stripped of its time...
Lib/email/_header_value_parser.py:1337: Expr(value=Str(s="Parse strings according to RFC822/2047/2822/5322 rules.\n\nThis is a stateless par...
Lib/pickletools.py:148: Expr(value=Str(s='\n"A pickle" is a program for a virtual pickle machine (PM, but more accurately\nc...
Tools/scripts/reindent.py:56: Expr(value=Str(s='A specified newline to be used in the output (set by --newline option)'))


Almost Dead code
================

Lib/sqlite3/test/dump.py:44: Expr(value=ListComp(elt=Call(func=Attribute(value=Attribute(value=Name(id='self', ctx=Load()), attr=...
Lib/sqlite3/test/dump.py:49: Expr(value=ListComp(elt=Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertEqual', c...
Lib/test/test_grammar.py:369: Expr(value=Num(n=1))
Lib/test/test_grammar.py:370: Expr(value=Tuple(elts=[Num(n=1), Num(n=2), Num(n=3)], ctx=Load()))
Lib/test/test_grammar.py:474: Expr(value=Tuple(elts=[Num(n=1), Yield(value=Num(n=1))], ctx=Load()))
Lib/test/test_grammar.py:475: Expr(value=Tuple(elts=[Num(n=1), YieldFrom(value=Tuple(elts=[], ctx=Load()))], ctx=Load()))
Lib/test/test_optparse.py:731: Expr(value=Tuple(elts=[Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertParseOK', ...
Lib/test/test_optparse.py:741: Expr(value=Tuple(elts=[Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertParseOK', ...
Lib/test/test_optparse.py:746: Expr(value=Tuple(elts=[Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertParseOK', ...
Lib/test/test_optparse.py:749: Expr(value=Tuple(elts=[Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertParseOK', ...
Lib/test/test_optparse.py:754: Expr(value=Tuple(elts=[Call(func=Attribute(value=Name(id='self', ctx=Load()), attr='assertParseOK', ...
Lib/test/test_peepholer.py:116: Expr(value=Tuple(elts=[UnaryOp(op=Invert(), operand=List(elts=[Num(n=0), Num(n=1), Num(n=2), Num(n=3...
Lib/test/test_peepholer.py:50: Expr(value=NameConstant(value=None))
Lib/test/test_peepholer.py:51: Expr(value=NameConstant(value=None))
Lib/test/test_peepholer.py:54: Expr(value=NameConstant(value=True))
Lib/test/test_peepholer.py:57: Expr(value=NameConstant(value=False))
Lib/test/test_posix.py:1046: Expr(value=Attribute(value=Name(id='posix', ctx=Load()), attr='RTLD_LAZY', ctx=Load()))
Lib/test/test_posix.py:1047: Expr(value=Attribute(value=Name(id='posix', ctx=Load()), attr='RTLD_NOW', ctx=Load()))
Lib/test/test_posix.py:1048: Expr(value=Attribute(value=Name(id='posix', ctx=Load()), attr='RTLD_GLOBAL', ctx=Load()))
Lib/test/test_posix.py:1049: Expr(value=Attribute(value=Name(id='posix', ctx=Load()), attr='RTLD_LOCAL', ctx=Load()))
Lib/test/test_pow.py:102: Expr(value=BinOp(left=NameConstant(value=None), op=Pow(), right=Call(func=Name(id='TestRpow', ctx=Lo...
Lib/test/test_raise.py:320: Expr(value=Name(id='xyzzy', ctx=Load()))
Lib/test/test_richcmp.py:218: Expr(value=UnaryOp(op=Not(), operand=Name(id='bad', ctx=Load())))
Lib/test/test_scope.py:578: Expr(value=ListComp(elt=Name(id='bad', ctx=Load()), generators=[comprehension(target=Name(id='s', ct...
Lib/test/test_scope.py:590: Expr(value=Name(id='x', ctx=Load()))
Lib/test/test_set.py:613: Expr(value=Compare(left=Name(id='myset', ctx=Load()), ops=[Lt()], comparators=[Name(id='myobj', ctx=...
Lib/test/test_set.py:617: Expr(value=Compare(left=Name(id='myset', ctx=Load()), ops=[Gt()], comparators=[Name(id='myobj', ctx=...
Lib/test/test_set.py:621: Expr(value=Compare(left=Name(id='myset', ctx=Load()), ops=[LtE()], comparators=[Name(id='myobj', ctx...
Lib/test/test_set.py:625: Expr(value=Compare(left=Name(id='myset', ctx=Load()), ops=[GtE()], comparators=[Name(id='myobj', ctx...
Lib/test/test_socket.py:1316: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='AF_CAN', ctx=Load()))
Lib/test/test_socket.py:1317: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='PF_CAN', ctx=Load()))
Lib/test/test_socket.py:1318: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_RAW', ctx=Load()))
Lib/test/test_socket.py:1323: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM', ctx=Load()))
Lib/test/test_socket.py:1326: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_SETUP', ctx=Load()))
Lib/test/test_socket.py:1327: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_DELETE', ctx=Load()))
Lib/test/test_socket.py:1328: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_READ', ctx=Load()))
Lib/test/test_socket.py:1329: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_SEND', ctx=Load()))
Lib/test/test_socket.py:1330: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_SETUP', ctx=Load()))
Lib/test/test_socket.py:1331: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_DELETE', ctx=Load()))
Lib/test/test_socket.py:1332: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_READ', ctx=Load()))
Lib/test/test_socket.py:1333: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_STATUS', ctx=Load()))
Lib/test/test_socket.py:1334: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_TX_EXPIRED', ctx=Load()))
Lib/test/test_socket.py:1335: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_STATUS', ctx=Load()))
Lib/test/test_socket.py:1336: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_TIMEOUT', ctx=Load()))
Lib/test/test_socket.py:1337: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='CAN_BCM_RX_CHANGED', ctx=Load()))
Lib/test/test_socket.py:1476: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='AF_RDS', ctx=Load()))
Lib/test/test_socket.py:1477: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='PF_RDS', ctx=Load()))
Lib/test/test_socket.py:727: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='AF_INET', ctx=Load()))
Lib/test/test_socket.py:728: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOCK_STREAM', ctx=Load()))
Lib/test/test_socket.py:729: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOCK_DGRAM', ctx=Load()))
Lib/test/test_socket.py:730: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOCK_RAW', ctx=Load()))
Lib/test/test_socket.py:731: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOCK_RDM', ctx=Load()))
Lib/test/test_socket.py:732: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOCK_SEQPACKET', ctx=Load()))
Lib/test/test_socket.py:733: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SOL_SOCKET', ctx=Load()))
Lib/test/test_socket.py:734: Expr(value=Attribute(value=Name(id='socket', ctx=Load()), attr='SO_REUSEADDR', ctx=Load()))
Lib/test/test_ssl.py:105: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='PROTOCOL_SSLv23', ctx=Load()))
Lib/test/test_ssl.py:106: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='PROTOCOL_SSLv3', ctx=Load()))
Lib/test/test_ssl.py:107: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='PROTOCOL_TLSv1', ctx=Load()))
Lib/test/test_ssl.py:108: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='CERT_NONE', ctx=Load()))
Lib/test/test_ssl.py:109: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='CERT_OPTIONAL', ctx=Load()))
Lib/test/test_ssl.py:110: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='CERT_REQUIRED', ctx=Load()))
Lib/test/test_ssl.py:111: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='OP_CIPHER_SERVER_PREFERENCE', ctx=Load(...
Lib/test/test_ssl.py:112: Expr(value=Attribute(value=Name(id='ssl', ctx=Load()), attr='OP_SINGLE_DH_USE', ctx=Load()))
Lib/test/test_string.py:10: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='ascii_uppercase', ctx=Load()))
Lib/test/test_string.py:11: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='ascii_letters', ctx=Load()))
Lib/test/test_string.py:12: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='digits', ctx=Load()))
Lib/test/test_string.py:13: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='hexdigits', ctx=Load()))
Lib/test/test_string.py:14: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='octdigits', ctx=Load()))
Lib/test/test_string.py:15: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='punctuation', ctx=Load()))
Lib/test/test_string.py:16: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='printable', ctx=Load()))
Lib/test/test_string.py:8: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='whitespace', ctx=Load()))
Lib/test/test_string.py:9: Expr(value=Attribute(value=Name(id='string', ctx=Load()), attr='ascii_lowercase', ctx=Load()))
Lib/test/test_super.py:79: Expr(value=Name(id='self', ctx=Load()))
Lib/test/test_sys_settrace.py:243: Expr(value=GeneratorExp(elt=Name(id='o', ctx=Load()), generators=[comprehension(target=Name(id='o', ...
Lib/test/test_time.py:25: Expr(value=Attribute(value=Name(id='time', ctx=Load()), attr='altzone', ctx=Load()))
Lib/test/test_time.py:26: Expr(value=Attribute(value=Name(id='time', ctx=Load()), attr='daylight', ctx=Load()))
Lib/test/test_time.py:27: Expr(value=Attribute(value=Name(id='time', ctx=Load()), attr='timezone', ctx=Load()))
Lib/test/test_time.py:28: Expr(value=Attribute(value=Name(id='time', ctx=Load()), attr='tzname', ctx=Load()))
Lib/test/test_weakref.py:129: Expr(value=Attribute(value=Name(id='proxy', ctx=Load()), attr='bar', ctx=Load()))
Lib/test/test_weakref.py:461: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='J', ctx=Load()))
Lib/test/test_weakref.py:513: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='J', ctx=Load()))
Lib/test/test_weakref.py:533: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='me', ctx=Load()))
Lib/test/test_weakref.py:534: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='c1', ctx=Load()))
Lib/test/test_weakref.py:535: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='wr', ctx=Load()))
Lib/test/test_weakref.py:558: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='me', ctx=Load()))
Lib/test/test_weakref.py:559: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='c1', ctx=Load()))
Lib/test/test_weakref.py:560: Expr(value=Attribute(value=Name(id='self', ctx=Load()), attr='wr', ctx=Load()))
Lib/test/test_xml_etree.py:168: Expr(value=Subscript(value=Name(id='string', ctx=Load()), slice=Slice(lower=None, upper=Num(n=0), st...

----------
messages: 184934
nosy: haypo
priority: normal
severity: normal
status: open
title: Dead code should be removed
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 22 02:50:42 2013
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 22 Mar 2013 01:50:42 +0000
Subject: [New-bugs-announce] [issue17517] StringIO() does not behave like
	cStringIO() when given	an array object
Message-ID: <1363917042.32.0.869450839469.issue17517@psf.upfronthosting.co.za>


New submission from Santoso Wijaya:

Python 2.7.3 (default, Sep 26 2012, 21:51:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import array, cStringIO, StringIO
>>> a = array.array('B', [1,2,3])
>>> cStringIO.StringIO(a).getvalue()
'\x01\x02\x03'
>>> StringIO.StringIO(a).getvalue()
"array('B', [1, 2, 3])"
>>>

----------
components: Library (Lib)
messages: 184939
nosy: santa4nt
priority: normal
severity: normal
status: open
title: StringIO() does not behave like cStringIO() when given an array object
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 22 12:18:20 2013
From: report at bugs.python.org (masato)
Date: Fri, 22 Mar 2013 11:18:20 +0000
Subject: [New-bugs-announce] [issue17518] urllib2 cannnot handle https and
	BasicAuth via Proxy.
Message-ID: <1363951100.05.0.959443247001.issue17518@psf.upfronthosting.co.za>


New submission from masato:

When urllib2 module is used, https connections to servers that BasicAuth is required, via proxies, can not be established properly.

Sample code:
import urllib2

def main():
    url = "https://example.com/aplication/rpc"
    
    proxy_support = urllib2.ProxyHandler({'http': 'http://proxy.server.com:8080/','https': 'http://proxy.server.com:8080/'})

    pass_mngr = urllib2.HTTPPasswordMgrWithDefaultRealm()
    pass_mngr.add_password(None, url, 'user', 'password')
    auth_handler = urllib2.HTTPBasicAuthHandler(pass_mngr)
    
    opener = urllib2.build_opener(proxy_support,auth_handler)
    req = urllib2.Request(url)
    f = opener.open(req)
    print f.read()


"opener.open" method throws an exception.

I found a similar case at http://bugs.python.org/issue7291. However, this issue indicates a case of authentication at a proxy server. In my case, the origin server uses basic authentication.

The origin server address is not set in Request URI in the https request in case of using proxy servers, because https request gets encripted with SSL when it passes through proxies.

urllib2 works well for the first on-going request and in-comming return. However, after the first in-comming return (401 code), urllib2 module sends a worng request that includes the origin server URL.

I suggest modification for set_proxy method in Request class.

Original code:
def set_proxy(self, host, type):
        if self.type == 'https' and not self._tunnel_host:
            self._tunnel_host = self.host
        else:
            self.type = type
            self.__r_host = self.__original

        self.host = host

As a value is already set to tunnel_host when the second out-going request is sent, "self.type == 'https' and not self._tunnel_host" is false.

Code suggested:
def set_proxy(self, host, type):
        if self.type == 'https' and not self._tunnel_host:
            self._tunnel_host = self.host
        else:
            self.type = type
            if self.type != 'https':
                self.__r_host = self.__original

        self.host = host


regards.

----------
components: Library (Lib)
messages: 184958
nosy: masato kawamura
priority: normal
severity: normal
status: open
title: urllib2 cannnot handle https and BasicAuth via Proxy.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 22 12:24:26 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Piel?=)
Date: Fri, 22 Mar 2013 11:24:26 +0000
Subject: [New-bugs-announce] [issue17519] unittest should not try to run
	abstract classes
Message-ID: <1363951466.19.0.505441528041.issue17519@psf.upfronthosting.co.za>


New submission from ?ric Piel:

Since Python 2.6 there is the notion if abstract class (ABC). It could be useful to use it for test cases, but unittest doesn't support it. Typically, I'd like to test a bunch of classes which all should behave similarly (at least for some cases). So I'd like to have one abstract class containing many test cases, and a separate real tests classes which inherit from this abstract class.

Unfortunately, for now unittest tries to instantiate the abstract class, which fails. 

Note that I'm not the only one thinking of this, here is a mention of the same idea on stack overflow:
http://stackoverflow.com/questions/4566910/abstract-test-case-using-python-unittest

Attached are two small examples of test cases. test_abs.py shows what I think is a good usage of ABC, with unittest. It fails to run with this error:
TypeError: Can't instantiate abstract class VirtualTest with abstract methods important_num
fake_abc.py is typically what people end up doing for using abstract classes with unittests (that's what people used to do before ABC exists). It does work, but it's not really beautiful as VirtualTest uses self.assertGreater() and self.important_num which are not explicitly part of the class.

My guess is that the following patch to Lib/unittest/loader.py should be enough (but it's untested):
diff -r a2128cb22372 Lib/unittest/loader.py
--- a/Lib/unittest/loader.py	Thu Mar 21 23:04:45 2013 -0500
+++ b/Lib/unittest/loader.py	Fri Mar 22 12:22:46 2013 +0100
@@ -6,6 +6,7 @@
 import traceback
 import types
 import functools
+import inspect
 
 from fnmatch import fnmatch
 
@@ -74,7 +75,8 @@
         tests = []
         for name in dir(module):
             obj = getattr(module, name)
-            if isinstance(obj, type) and issubclass(obj, case.TestCase):
+            if (isinstance(obj, type) and issubclass(obj, case.TestCase) and
+                not inspect.isabstract(test_class)):
                 tests.append(self.loadTestsFromTestCase(obj))
 
         load_tests = getattr(module, 'load_tests', None)

----------
components: Library (Lib)
files: test_abc.py
messages: 184959
nosy: ?ric.Piel
priority: normal
severity: normal
status: open
title: unittest should not try to run abstract classes
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29544/test_abc.py

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

From report at bugs.python.org  Fri Mar 22 17:05:18 2013
From: report at bugs.python.org (Rabcor)
Date: Fri, 22 Mar 2013 16:05:18 +0000
Subject: [New-bugs-announce] [issue17520] Except(ValueError) on Integer
	returns the input value as	1
Message-ID: <1363968318.73.0.616072040287.issue17520@psf.upfronthosting.co.za>


New submission from Rabcor:

I'm an amateur at best, but the issue is that if i do this.
---
try:
    num = int(input('Write a number-->'))
except(ValueError) as noint:
    print('You did not write an integer')
---
num will become 1 if i write an invalid value (like a) on the input line.

In that example code i made it will show you that. the code should be readable even if the language of what is going to be printed is not english, it converts 999 to 1 fhr bill, 4 hr coins, 1 fty coin, 4 ten coins, 1 fiv coin and 4 coins

If you need context.

I commented out my temporary solution to it (turning num into 0.1 as that's not a valid integer and i'm only working with integers.)

----------
components: Tkinter
files: Heimaverkefni5.py
messages: 184979
nosy: rabcor
priority: normal
severity: normal
status: open
title: Except(ValueError) on Integer returns the input value as 1
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29546/Heimaverkefni5.py

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

From report at bugs.python.org  Fri Mar 22 17:45:50 2013
From: report at bugs.python.org (Bob Igo)
Date: Fri, 22 Mar 2013 16:45:50 +0000
Subject: [New-bugs-announce] [issue17521] fileConfig() disables any
	previously-used "named"	loggers,
	even when getLogger() is called again.
Message-ID: <1363970750.56.0.602997594582.issue17521@psf.upfronthosting.co.za>


New submission from Bob Igo:

I am aware of the described behavior of fileConfig() when disable_existing_loggers is True, but what I am seeing happens whether disable_existing_loggers is True or False, and it also affects loggers obtained via future, fresh calls to getLogger(name).

Here's an example where disable_existing_loggers is True, but as I said, the same happens when it's False:

>>> import logging.config
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger("foo")
>>> logger.critical("test")
2013-03-21 23:33:04,621    foo    CRITICAL    test
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger("foo")
>>> logger.critical("test")
>>>

Note that the final logging attempt silently fails. The thing that appears to break logging for ever is the second fileConfig() call, and not the following getLogger() call.

I can get a fresh logger with a different name and use it. (Continued from the above session):

>>> logger = logging.getLogger("bar")
>>> logger.critical("test")
2013-03-21 23:38:35,613    bar    CRITICAL    test


This issue does not affect the root logger, when no name is given to getLogger():

>>> import logging.config
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger()
>>> logger.critical("test")
2013-03-22 11:49:29,957    root    CRITICAL    test
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger()
>>> logger.critical("test")
2013-03-22 11:49:44,966    root    CRITICAL    test?


However, it _does_ affect the root logger when "root" is given as the name to getLogger():

>>> import logging.config
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger("root")
>>> logger.critical("test")
2013-03-22 12:42:49,742	root	CRITICAL	test
>>> logging.config.fileConfig('unit_test_logging.conf')
>>> logger = logging.getLogger("root")
>>> logger.critical("test")
>>> 

I can attach the logging config file if desired, but it looks like the issue is unrelated. I will say that I'm relying on the root logger for all my logging, but that I use a different name to differentiate how the log is written.

----------
components: Library (Lib)
messages: 184982
nosy: Bob.Igo
priority: normal
severity: normal
status: open
title: fileConfig() disables any previously-used "named" loggers, even when getLogger() is called again.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 22 18:04:10 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 22 Mar 2013 17:04:10 +0000
Subject: [New-bugs-announce] [issue17522] Add api PyGILState_Check
Message-ID: <1363971850.69.0.260738118944.issue17522@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

Here is a function that is used by specialized part of our code.  Often it is useful for e.g. IO callbacks or memory hooks to know if the GIL is in place in order to know if certain things can be done or not.
Putting this here to see if anyone has strong opinions against adding this.

----------
components: Interpreter Core
files: gilcheck.patch
keywords: patch
messages: 184985
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Add api PyGILState_Check
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29547/gilcheck.patch

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

From report at bugs.python.org  Fri Mar 22 18:40:46 2013
From: report at bugs.python.org (Will Weaver)
Date: Fri, 22 Mar 2013 17:40:46 +0000
Subject: [New-bugs-announce] [issue17523] Additional tests for the os module.
Message-ID: <1363974046.41.0.0636521792098.issue17523@psf.upfronthosting.co.za>


New submission from Will Weaver:

I've reorganized and added some os module tests.

I split the makedirs tests into additional test methods that test one thing instead of a lot of different things. I added additional test coverage for a trailing '/'.

I've also added the same test for removedirs.

I reorganized the walk tests so that they actually run. Before there was only a setUp and a tearDown but no actual tests so the tests would not actually run.

Lastly, I added tests for renames as there weren't any before.

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 184992
nosy: willweaver
priority: normal
severity: normal
status: open
title: Additional tests for the os module.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29549/mywork.patch

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

From report at bugs.python.org  Fri Mar 22 20:19:06 2013
From: report at bugs.python.org (Ali Massah Kiani)
Date: Fri, 22 Mar 2013 19:19:06 +0000
Subject: [New-bugs-announce] [issue17524] Problem to run a method
Message-ID: <1363979946.22.0.495062863997.issue17524@psf.upfronthosting.co.za>


New submission from Ali Massah Kiani:

when i run attached code python.exe exit with code:
<terminated,exitvalue:1>
when i trace this code problem was the this method :
mat = cv.GetMat(AviFile)

and problem is, not error or exeption rises
this problem is for python or opencv?
thanks.

----------
components: Library (Lib)
files: form.py
messages: 184998
nosy: aligoglos
priority: normal
severity: normal
status: open
title: Problem to run a method
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file29550/form.py

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

From report at bugs.python.org  Fri Mar 22 23:12:07 2013
From: report at bugs.python.org (David Cuddihy)
Date: Fri, 22 Mar 2013 22:12:07 +0000
Subject: [New-bugs-announce] [issue17525] os.getcwd() fails on cifs share
Message-ID: <1363990327.07.0.260090776617.issue17525@psf.upfronthosting.co.za>


New submission from David Cuddihy:

Calls to os.getcwd() can fail if issued from a cifs-mounted directory once any of the files or subdirectories have been changed remotely.  To recreate this: on Linux, mount a windows share using the mount.cifs command.  cd to the share and run python.   

Python 2.7.3 (default, Jul 24 2012, 10:05:38)
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license for more information.
>>> import os
>>> print os.getcwd()
 /home/user/share
>>> exit()

That works.  Now, on the host machine, change a file in the current directory and save it.  The unix 'pwd' still works.  But now:
>>> import os
>>> print os.getcwd()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file or directory
>>>

Even though the unix 'pwd' and 'ls' commands still work, so I know my share is still accessible.

If I umount and then remount the share, the problem goes away until a file is changed remotely.

I'm running this on Fedora 17.

----------
messages: 185014
nosy: dcuddihy
priority: normal
severity: normal
status: open
title: os.getcwd() fails on cifs share
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 23 03:03:59 2013
From: report at bugs.python.org (Nils Bruin)
Date: Sat, 23 Mar 2013 02:03:59 +0000
Subject: [New-bugs-announce] [issue17526] inspect.findsource raises
	undocumented error for code	objects with empty filename
Message-ID: <1364004239.34.0.135236485776.issue17526@psf.upfronthosting.co.za>


New submission from Nils Bruin:

It would seem reasonable that an empty filename would be a legitimate way of indicating that a code object does not have a corresponding source file. However, if one does that then inspect.findsource raises an unexpected IndexError rather than the documented IOError.

This seems due to the fix introduced on issue9284

Python 3.2.3 (default, Jun  8 2012, 05:40:07) 
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> C=compile("print(1)","<string>","single")
>>> D=compile("print(1)","","single")
>>> inspect.findsource(C)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/inspect.py", line 547, in findsource
    raise IOError('could not get source code')
IOError: could not get source code
>>> inspect.findsource(D)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/inspect.py", line 537, in findsource
    if not sourcefile and file[0] + file[-1] != '<>':
IndexError: string index out of range

----------
components: Library (Lib)
messages: 185025
nosy: Nils.Bruin
priority: normal
severity: normal
status: open
title: inspect.findsource raises undocumented error for code objects with empty filename
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Mar 23 11:23:37 2013
From: report at bugs.python.org (Luca Sbardella)
Date: Sat, 23 Mar 2013 10:23:37 +0000
Subject: [New-bugs-announce] [issue17527] PATCH as valid request method in
	wsgiref.validator
Message-ID: <1364034217.66.0.106174829986.issue17527@psf.upfronthosting.co.za>


New submission from Luca Sbardella:

http://tools.ietf.org/html/rfc5789

----------
components: Library (Lib)
files: validate.patch
keywords: patch
messages: 185031
nosy: lsbardel
priority: normal
severity: normal
status: open
title: PATCH as valid request method in wsgiref.validator
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29552/validate.patch

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

From report at bugs.python.org  Sat Mar 23 11:59:41 2013
From: report at bugs.python.org (Francesco Frassinelli)
Date: Sat, 23 Mar 2013 10:59:41 +0000
Subject: [New-bugs-announce] [issue17528] Implement dumps/loads for lru_cache
Message-ID: <1364036381.48.0.635559042513.issue17528@psf.upfronthosting.co.za>


New submission from Francesco Frassinelli:

Hi,
I propose to change the public API of functools.lru_cache in order to make the cache persistent when the program is restarted.
It could be implemented using two different functions (dumps/loads), where the cached is exported into a classical dictionary and restored in the same way.
A third argument could be also added to provide the initial cache (calling the loads function internally after the initialization).

I think this could be an important enhancement because lru_cache will probably implemented in C and try to export cache contents it will be not possible (see: http://bugs.python.org/issue14373).

----------
messages: 185036
nosy: frafra
priority: normal
severity: normal
status: open
title: Implement dumps/loads for lru_cache
type: enhancement

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

From report at bugs.python.org  Sat Mar 23 13:14:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Mar 2013 12:14:47 +0000
Subject: [New-bugs-announce] [issue17529] fix os.senfile() documentation
	regarding the type of	file descriptor
Message-ID: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

os.sendfile() documentation states:
"""
On Solaris, out may be the file descriptor of a regular file or the file descriptor of a socket. On all other platforms, out must be the file descriptor of an open socket.
"""

This isn't true for Linux anymore (changed somewhere around 2.6.33), so it would probably be better to rephrase to something like "all platforms support sockets as out file descriptor, and some platforms allow other types (e.g. regular files) as well".

----------
assignee: docs at python
components: Documentation
messages: 185040
nosy: docs at python, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: fix os.senfile() documentation regarding the type of file descriptor
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 23 20:39:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Mar 2013 19:39:37 +0000
Subject: [New-bugs-announce] [issue17530] pprint could use line continuation
	for long bytes	literals
Message-ID: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Same as issue #17150: 

>>> pprint.pprint({"a": b"\x00\xff" * 20})
{'a': b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff'}

... could be better formatted as:

>>> pprint.pprint({"a": b"\x00\xff" * 20})
{'a': b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00'
      b'\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff'
      b'\x00\xff\x00\xff\x00\xff'}

----------
components: Library (Lib)
messages: 185078
nosy: fdrake, pitrou
priority: low
severity: normal
status: open
title: pprint could use line continuation for long bytes literals
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 23 21:00:15 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 23 Mar 2013 20:00:15 +0000
Subject: [New-bugs-announce] [issue17531] test_grp and test_pwd fail with
	32-bit builds on OS X	systems
Message-ID: <1364068815.59.0.52154944753.issue17531@psf.upfronthosting.co.za>


New submission from Ned Deily:

With the changes introduced for Issue4591, test_grp and test_pwd now fail on OS X systems when Python is run in 32-bit mode.

Previously, using a 64-bit/32-bit universal build of 2.7.3:

$ arch -i386 /usr/local/bin/python2.7 -c 'import grp; g=grp.getgrnam("nobody").gr_gid; print(g,type(g))'
(-2, <type 'int'>)
$ arch -x86_64 /usr/local/bin/python2.7 -c 'import grp; g=grp.getgrnam("nobody").gr_gid; print(g,type(g))'
(4294967294, <type 'int'>)

Now, with 2.7.4rc1:

$ arch -i386 /usr/local/bin/python2.7 -c 'import grp; g=grp.getgrnam("nobody").gr_gid; print(g,type(g))'
(4294967294L, <type 'long'>)
$ arch -x86_64 /usr/local/bin/python2.7 -c 'import grp; g=grp.getgrnam("nobody").gr_gid; print(g,type(g))'
(4294967294, <type 'int'>)

This results in test failures in both test_grp and test_pwd:

======================================================================
FAIL: test_values (test.test_grp.GroupDatabaseTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_grp.py", line 27, in test_values
    self.check_value(e)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_grp.py", line 19, in check_value
    self.assertIsInstance(value.gr_gid, int)
AssertionError: 4294967294L is not an instance of <type 'int'>

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

======================================================================
FAIL: test_values (test.test_pwd.PwdTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_pwd.py", line 23, in test_values
    self.assertIsInstance(e.pw_gid, int)
AssertionError: 4294967294L is not an instance of <type 'int'>

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

----------
components: Tests
messages: 185081
nosy: benjamin.peterson, ned.deily, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_grp and test_pwd fail with 32-bit builds on OS X systems
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 23 22:41:30 2013
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 23 Mar 2013 21:41:30 +0000
Subject: [New-bugs-announce] [issue17532] IDLE: Always include "Options"
	menu on MacOSX
Message-ID: <1364074890.28.0.799485456817.issue17532@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Presently, the "Options" menu gets eliminated if IDLE runs as an OSX app. This behavior was introduced in 2006 in revision 654c380cf8b9. 

I guess that the original motivation for eliminating the Options menu since it usually only contained the "Configure IDLE" option, and the Lib/idlelib/macosxSupport.py code supports using the Preferences menu item to open the configuration dialog. (The only other item would be the Code Context toggle.)

Extensions that rely on the Options menu being present will not function properly, especially when the menu item involves a queried boolean variable for its checkmark status.

----------
components: IDLE
keywords: easy
messages: 185098
nosy: Todd.Rovito, ned.deily, roger.serwy
priority: normal
severity: normal
status: open
title: IDLE: Always include "Options" menu on MacOSX
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 23 23:03:09 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 23 Mar 2013 22:03:09 +0000
Subject: [New-bugs-announce] [issue17533] test_xpickle fails on OS X 10.5
	with "cannot import name	precisionbigmemtest"
Message-ID: <1364076189.44.0.308602234194.issue17533@psf.upfronthosting.co.za>


New submission from Ned Deily:

When running the OS X 32-bit-only installer 2.7.4rc1 on OS X 10.5, test_xpickle has many test failures all in CPicklePython25Compat.  Note, there is an Apple-supplied system Python 2.5 shipped on OS X 10.5. (There is also an Apple-supplied system Python 2.5 shipped on OS X 10.8, too, but for some reason, the test doesn't report a failure there.)  The use of precisionbigmemtest appears to have been added by 680959a3ae2e for Issue13555.

======================================================================
ERROR: test_attribute_name_interning (test.test_xpickle.CPicklePython25Compat)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/pickletester.py", line 983, in test_attribute_name_interning
    s = self.dumps(x, proto)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_xpickle.py", line 115, in dumps
    return self.send_to_worker(self.python, arg, proto)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_xpickle.py", line 111, in send_to_worker
    raise RuntimeError(stderr)
RuntimeError: Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_xpickle.py", line 28, in <module>
    exec compile(open(mod_path).read(), mod_path, 'exec') in pickletester.__dict__
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/pickletester.py", line 9, in <module>
    from test.test_support import (TestFailed, have_unicode, TESTFN, _2G, _1M,
ImportError: cannot import name precisionbigmemtest

[...]
----------------------------------------------------------------------
Ran 180 tests in 5.033s

FAILED (errors=67)

----------
components: Tests
messages: 185099
nosy: benjamin.peterson, ned.deily, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_xpickle fails on OS X 10.5 with "cannot import name precisionbigmemtest"
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 23 23:06:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Mar 2013 22:06:48 +0000
Subject: [New-bugs-announce] [issue17534] unittest keeps references to test
	cases alive
Message-ID: <1364076408.77.0.0522248566775.issue17534@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

After the subtests commit (5c09e1c57200/#16997), test_queue started showing the following warning:
Warning -- threading._dangling was modified by test_queue
1 test altered the execution environment:
    test_queue

The warning was caused by the fact that the TestCase subclasses in test_queue kept references to the thread, but before 5c09e1c57200 these subclasses (and hence the references to the thread) were destroyed before the regrtest check for threading._dangling, whereas now they are kept alive (due to Lib/unittest/case.py:72, that adds a reference to the TestCase even in case of success).  I now fixed the warning in test_queue (1747e50fca55), however unittest should probably avoid keeping alive TestCases when they are not needed anymore.

See also #9815.

(Thanks to Antoine for the help while I was debugging the issue.)

----------
components: Library (Lib)
messages: 185100
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest keeps references to test cases alive
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 24 06:13:33 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 24 Mar 2013 05:13:33 +0000
Subject: [New-bugs-announce] [issue17535] IDLE: Add an option to show line
	numbers along the left	side of the editor window,
	and have it enabled by default.
Message-ID: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za>


New submission from Todd Rovito:

I think it could be very helpful to add line numbers along the left side of the editor window.  The feature could be toggled on/off easily enough.  This was mentioned in the "Invent with Python" blog about IDLE so obviously other people would like the feature.

----------
components: IDLE
messages: 185115
nosy: Todd.Rovito
priority: normal
severity: normal
status: open
title: IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 24 18:42:08 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 24 Mar 2013 17:42:08 +0000
Subject: [New-bugs-announce] [issue17536] update browser list with
	additional browser names
Message-ID: <1364146928.84.0.219994349931.issue17536@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Add some browser names supported on Debian systems:

 - www-browser, x-www-browser are browser names handled by
   the alternatives system, which should be preferred over
   specific browser names. Inserted with lower priority
   than the browsers for specific desktop environments.

 - iceweasel, iceape are used in Debian for the Mozilla
   browser for trademark reasons.

will backport for 2.7 after the 2.7.4 release.

----------
assignee: doko
components: Library (Lib)
files: webbrowser.diff
keywords: patch
messages: 185145
nosy: doko
priority: normal
severity: normal
status: open
title: update browser list with additional browser names
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file29565/webbrowser.diff

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

From report at bugs.python.org  Sun Mar 24 22:11:53 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 24 Mar 2013 21:11:53 +0000
Subject: [New-bugs-announce] [issue17537] sv.DictReader should fail if >1
	column has the same name
Message-ID: <1364159513.65.0.538891965028.issue17537@psf.upfronthosting.co.za>


New submission from Matthias Klose:

forwarded from Debian http://bugs.debian.org/699463

The csv.DictReader object doesn't handle multiple columns with the
same name very well - it simply over-writes the first
column-with-same-name with the contents of the second
column-with-same-name e.g.:

foo,bar,foo
1,2,3

on reading this file, ["foo"] would contain 3.

IMO, the correct behaviour is for csv.DictReader to emit an error if
the header contains more than one column with the same name.

----------
components: Library (Lib)
messages: 185158
nosy: doko
priority: normal
severity: normal
status: open
title: sv.DictReader should fail if >1 column has the same name
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 25 03:41:26 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 25 Mar 2013 02:41:26 +0000
Subject: [New-bugs-announce] [issue17538] Document XML Vulnerabilties
Message-ID: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Here's a documentation patch (Made against the 2.7 branch) that adds warning to the various xml modules to warn about the insecurity and points towards defusedxml/defusedexpat.

----------
components: Library (Lib), XML
files: xmldocs.diff
keywords: patch
messages: 185176
nosy: christian.heimes, dstufft
priority: normal
severity: normal
status: open
title: Document XML Vulnerabilties
versions: Python 2.7
Added file: http://bugs.python.org/file29569/xmldocs.diff

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

From report at bugs.python.org  Mon Mar 25 07:13:04 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Mar 2013 06:13:04 +0000
Subject: [New-bugs-announce] [issue17539] Use the builtins module in the
	unittest.mock.patch	example
Message-ID: <1364191984.35.0.104161135895.issue17539@psf.upfronthosting.co.za>


New submission from Berker Peksag:

(initially reported at http://mail.python.org/pipermail/docs/2013-February/013331.html )

----------
assignee: docs at python
components: Documentation
files: unittest-mock-example.diff
keywords: patch
messages: 185187
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Use the builtins module in the unittest.mock.patch example
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29570/unittest-mock-example.diff

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

From report at bugs.python.org  Mon Mar 25 07:31:27 2013
From: report at bugs.python.org (monson)
Date: Mon, 25 Mar 2013 06:31:27 +0000
Subject: [New-bugs-announce] [issue17540] logging formatter support 'style'
	key in dictionary	config
Message-ID: <1364193087.51.0.734621936911.issue17540@psf.upfronthosting.co.za>


New submission from monson:

Since from version 3.2 ``style`` parameter was added in class logging.Formatter, it should be availably configured in configuration dictionary or file.

----------
components: Library (Lib)
files: add-logging-config-key-style.patch
keywords: patch
messages: 185188
nosy: monson
priority: normal
severity: normal
status: open
title: logging formatter support 'style' key in dictionary config
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file29571/add-logging-config-key-style.patch

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

From report at bugs.python.org  Mon Mar 25 12:22:24 2013
From: report at bugs.python.org (Aditya)
Date: Mon, 25 Mar 2013 11:22:24 +0000
Subject: [New-bugs-announce] [issue17541] Importing `webbrowser` module
	gives NameError in Python	2.7.4rc1
Message-ID: <1364210544.82.0.514800055281.issue17541@psf.upfronthosting.co.za>


New submission from Aditya:

Python 2.7.4rc1 (default, Mar 25 2013, 00:32:18) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/webbrowser.py", line 505, in <module>
    register_X_browsers()
  File "/usr/lib/python2.7/webbrowser.py", line 489, in register_X_browsers
    register(browser, None, Chrome(browser))
NameError: global name 'Chrome' is not defined
>>>

----------
components: Library (Lib)
messages: 185194
nosy: codeaditya
priority: normal
severity: normal
status: open
title: Importing `webbrowser` module gives NameError in Python 2.7.4rc1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 25 16:27:28 2013
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Mon, 25 Mar 2013 15:27:28 +0000
Subject: [New-bugs-announce] [issue17544] regex code re-raises exceptions on
	success
Message-ID: <1364225248.29.0.538486263378.issue17544@psf.upfronthosting.co.za>


New submission from Zden?k Pavlas:

<documentation>
There is a global indicator (per thread) of the last error that occurred. Most functions do not clear this on success, but will set it to indicate the cause of the error on failure. Most functions also return an error indicator, usually NULL if they are supposed to return a pointer, or -1 if they return an integer.
</documentation>

AIUI, the last error global variable should be ignored, unless function fails.  This is not the case.  To reproduce:

1. call a C function that sets TypeError, but does not return NULL.
2. run a lot of python code, do some I/O.. everything runs fine.
3. run a regexp match, or import the re module.  TypeError is raised.

----------
components: Regular Expressions
messages: 185205
nosy: Zden?k.Pavlas, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: regex code re-raises exceptions on success
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 25 17:26:53 2013
From: report at bugs.python.org (Bernard Lang)
Date: Mon, 25 Mar 2013 16:26:53 +0000
Subject: [New-bugs-announce] [issue17545] os.listdir and os.path.join
	inconsistent on empty path
Message-ID: <1364228813.43.0.916487849633.issue17545@psf.upfronthosting.co.za>


New submission from Bernard Lang:

The empty path '' is considered as an acceptable path in os.path.join, and works as a neutral prefix:
print os.path.join('','aaa')  ===>  aaa
which seems rather natural.
But it raises an exception when used as a parameter to os.listdir.
Logically, it should then list the current directory.
(the alternative would be to raise an exception when os.path.join gets an empty argument).

The inconsistency became clear to me when I had to write the following function :

def listdirs(path,flist): # Appends to "flist" all paths to files that
            # start with "path". Argument "path" can be empty string ''.
    if path=='' : localist=os.listdir('.')
    else : localist=os.listdir(path)
    for f in localist :
        p=os.path.join(path,f)
        flist.append(p)
        if os.path.isdir(p) :
            listdirs(p,flist)
    return flist

The conditionnal is needed only to avoid the exception, while the code is unique afterwards.

This is related to Issue818059, but I did not see how that issue was resolved.

Furthermore, the case of the empty path as argument to os.listdir should be documented in http://docs.python.org/2/library/os.html

----------
components: Library (Lib)
messages: 185207
nosy: babou
priority: normal
severity: normal
status: open
title: os.listdir and os.path.join inconsistent on empty path
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 25 18:20:11 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 25 Mar 2013 17:20:11 +0000
Subject: [New-bugs-announce] [issue17546] rename type returned by locals()
	to livedict
Message-ID: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

-locals() returns object that does't walk like a duck.
+locals() returns object that does't work like a dict.

Much of the confusion with locals() comes from the fact that returned object is labelled a dict, but this heisendict changes its behavior when you're trying to introspect it. So, to give users a hint that this object is different, I propose to rename it to a different type and supply an appropriate help() for it.

----------
components: Library (Lib)
messages: 185213
nosy: techtonik
priority: normal
severity: normal
status: open
title: rename type returned by locals() to livedict
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 25 20:33:56 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Mar 2013 19:33:56 +0000
Subject: [New-bugs-announce] [issue17547] "checking whether gcc supports
	ParseTuple __format__...	" erroneously returns yes with gcc 4.8
Message-ID: <1364240036.0.0.495843553762.issue17547@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

It appears that gcc's -Wformat warning changed from being on by default in gcc 4.7 and earlier to being off by default in gcc 4.8, needing to be enabled with -Wformat (or -Wall), if I'm reading:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193304
correctly

This breaks CPython's configure.ac test:
  "Check whether GCC supports PyArg_ParseTuple format"
in that the warning the test is supposed to emit is guarded by -Wformat, hence with gcc 4.8 this test always emits:
  checking whether gcc supports ParseTuple __format__... yes
despite the fact that gcc doesn't.

This leads to the pyconfig.h defining HAVE_ATTRIBUTE_FORMAT_PARSETUPLE, and thus we get this error when trying later use the python build to build a C extension module where -Wformat (or -Wall) *is* supplied:
In file included from /usr/include/python2.7/Python.h:126:0,
                 from isys.c:20:
/usr/include/python2.7/modsupport.h:28:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=]
 PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);

Am attaching a work-in-progress patch to supply the missing argument at configure time

Note to self: am tracking this downstream as https://bugzilla.redhat.com/show_bug.cgi?id=927358

----------
components: Build
files: 00175-fix-configure-Wformat.patch
keywords: patch
messages: 185226
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29574/00175-fix-configure-Wformat.patch

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

From report at bugs.python.org  Tue Mar 26 00:58:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2013 23:58:28 +0000
Subject: [New-bugs-announce] [issue17548] unittest.mock:
	test_create_autospec_unbound_methods is	skipped
Message-ID: <1364255908.36.0.236092443385.issue17548@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While working on #17516, I saw that test_create_autospec_unbound_methods() of Lib/unittest/test/testmock/testhelpers.py is skipped:

    def test_create_autospec_unbound_methods(self):
        # see mock issue 128
        # this is expected to fail until the issue is fixed
        return

Related entry in mock bug tracker:
http://code.google.com/p/mock/issues/detail?id=128

If it is not necessary to duplicate the issue here, please just close it.

----------
components: Library (Lib), Tests
messages: 185249
nosy: haypo, michael.foord
priority: normal
severity: normal
status: open
title: unittest.mock: test_create_autospec_unbound_methods is skipped
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 26 10:05:13 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 26 Mar 2013 09:05:13 +0000
Subject: [New-bugs-announce] [issue17549] Some exceptions not highlighted in
	exceptions	documentation.
Message-ID: <1364288713.27.0.682070443394.issue17549@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/3/library/exceptions.html#exception-hierarchy , some exception are not highlighted correctly.

----------
messages: 185262
nosy: Ramchandra Apte
priority: normal
severity: normal
status: open
title: Some exceptions not highlighted in exceptions documentation.
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 26 13:12:16 2013
From: report at bugs.python.org (=?utf-8?q?Gerg=C3=B6_Barany?=)
Date: Tue, 26 Mar 2013 12:12:16 +0000
Subject: [New-bugs-announce] [issue17550] --enable-profiling does nothing
	(shell syntax bug in	configure.ac)
Message-ID: <1364299936.4.0.197182554792.issue17550@psf.upfronthosting.co.za>


New submission from Gerg? Barany:

Trying to configure Python (3.3 and 3.4 prerelease from Mercurial) with --enable-profiling doesn't work because the configure script contains a syntax error that causes it to conclude that the C compiler does not accept the -pg flag:

$ ../cpython/configure --enable-profiling | grep prof
configure: WARNING:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.
  
../cpython/configure: line 5537: CC: command not found
checking for --enable-profiling... no

Everything (configure/build/running Python) continues as if --enable-profiling had not been passed.

This is due to using $(CC) rather than the correct syntax $CC at the specified place in the configure script. The attached patch to configure.ac fixes this.

----------
files: enable-profiling.patch
keywords: patch
messages: 185269
nosy: gergo
priority: normal
severity: normal
status: open
title: --enable-profiling does nothing (shell syntax bug in configure.ac)
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29580/enable-profiling.patch

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

From report at bugs.python.org  Tue Mar 26 18:26:44 2013
From: report at bugs.python.org (Bob Alexander)
Date: Tue, 26 Mar 2013 17:26:44 +0000
Subject: [New-bugs-announce] [issue17551] Windows - accessing drive with
	nothing mounted forces	user interaction
Message-ID: <1364318804.06.0.966349277982.issue17551@psf.upfronthosting.co.za>


New submission from Bob Alexander:

Attempting to use os.path.exists on a Windows drive that is a mobile device mount point with nothing mounted pops up a dialog asking to insert a device. This makes it impossible to search a set of drives for a specific file without the possibility of unnecessary user interaction -- for example looking for the drive that has a specific flash drive inserted.

This behavior is likely related to bug 9035 regarding "os.path.ismount" behavior on Windows.

The more correct behavior (IMO) would be to quietly return exists=False for drives with nothing mounted. In fact, I tried the same operation with Java and Ruby programs, and both simply return false with no popup.

----------
components: Library (Lib)
messages: 185281
nosy: bobjalex
priority: normal
severity: normal
status: open
title: Windows - accessing drive with nothing mounted forces user interaction
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Mar 26 20:27:53 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 26 Mar 2013 19:27:53 +0000
Subject: [New-bugs-announce] [issue17552] socket.sendfile()
Message-ID: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is based on progress made in issue 13564 and aims to provide a new sendfile() method for the socket class taking advantage of high-performance "zero-copy" os.sendfile() available on most POSIX platforms.
A wrapper on top of os.sendfile() appears to be convenient because getting everything right is a bit tricky. Also we can avoid code duplication in case we want to add sendfile() support to ftplib (issue 13564) and httplib.

=== THE API ===

Attached is a draft patch proposing an API which:

- uses os.sendfile() whenever available and usable (a mmap-like file is required)
- if not falls back on using plain socket.sendall()
- returns a tuple of two elements which indicates whether sendfile() was used and an exception instance in case it wasn't on account of an internal error, if any 
- does not support non-blocking sockets (will raise ValueError)


=== ALTERNATE API === 

1) In case the transfer is interrupted halfway because of an error the user has no clue on how many bytes were sent (and file.tell() won't tell =)). As such it probably makes sense to provide a custom socket.SendfileError exception encapsulating the original exception and the bytes sent as arguments.

2) For the same reason the returned tuple should probably include the number of bytes transmitted.

=== WINDOWS SUPPORT ===

Further development may include Windows support by using TransmitFile (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).aspx). Once we agree on an API I might start looking into Windows code (which appears to be quite tricky btw).

Any feedback is very welcome.

----------
components: Library (Lib)
files: socket-sendfile.patch
keywords: needs review, patch
messages: 185292
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: socket.sendfile()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29583/socket-sendfile.patch

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

From report at bugs.python.org  Tue Mar 26 21:28:37 2013
From: report at bugs.python.org (Sean Carolan)
Date: Tue, 26 Mar 2013 20:28:37 +0000
Subject: [New-bugs-announce] [issue17553] python setup.py bdist_rpm is broken
Message-ID: <1364329717.96.0.312657268888.issue17553@psf.upfronthosting.co.za>


New submission from Sean Carolan:

I'm attempting to build a Python 2.7.3 RPM but the build command from the documentation fails.  My platform is RHEL 5.9, x86_64

http://docs.python.org/2/distutils/builtdist.html#creating-rpm-packages

Steps to reproduce:

1.  Download latest Python tarball to home directory.
wget http://www.python.org/ftp/python/2.7.3/Python-2.7.3.tgz

2.  Unpack it, configure and install it:
[scarolan at titania:~/Python-2.7.3]$ make clean; ./configure --with-zlib=/usr/include; make; sudo make install

3.  Attempt to run command in the documentation, build fails.

[scarolan at titania:~/Python-2.7.3]$ python -V
Python 2.7.3

[scarolan at titania:~/Python-2.7.3]$ python setup.py bdist_rpm
running bdist_rpm
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/rpm
creating build/bdist.linux-x86_64/rpm/SOURCES
creating build/bdist.linux-x86_64/rpm/SPECS
creating build/bdist.linux-x86_64/rpm/BUILD
creating build/bdist.linux-x86_64/rpm/RPMS
creating build/bdist.linux-x86_64/rpm/SRPMS
writing 'build/bdist.linux-x86_64/rpm/SPECS/Python.spec'
running sdist
running check
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

writing manifest file 'MANIFEST'
creating Python-2.7.3
creating Python-2.7.3/Lib
creating Python-2.7.3/Tools
creating Python-2.7.3/Tools/scripts
making hard links in Python-2.7.3...
hard linking README -> Python-2.7.3
'_struct.c' not a regular file -- skipping
hard linking setup.py -> Python-2.7.3
hard linking Lib/smtpd.py -> Python-2.7.3/Lib
hard linking Tools/scripts/2to3 -> Python-2.7.3/Tools/scripts
hard linking Tools/scripts/idle -> Python-2.7.3/Tools/scripts
hard linking Tools/scripts/pydoc -> Python-2.7.3/Tools/scripts
creating dist
Creating tar archive
removing 'Python-2.7.3' (and everything under it)
copying dist/Python-2.7.3.tar.gz -> build/bdist.linux-x86_64/rpm/SOURCES
building RPMs
rpmbuild -ba --define _topdir /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm --clean build/bdist.linux-x86_64/rpm/SPECS/Python.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.64365
+ umask 022
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ rm -rf Python-2.7.3
+ /bin/gzip -dc /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/SOURCES/Python-2.7.3.tar.gz
+ tar -xvvf -
drwxrwxr-x scarolan/scarolan 0 2013-03-26 15:26:01 Python-2.7.3/
-rw-rw-r-- scarolan/scarolan 1524 2013-03-26 15:26:01 Python-2.7.3/PKG-INFO
-rw-r--r-- scarolan/scarolan 90350 2012-04-09 18:07:36 Python-2.7.3/setup.py
-rw-r--r-- scarolan/scarolan 53744 2012-04-09 18:07:35 Python-2.7.3/README
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:26:01 Python-2.7.3/Tools/
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:26:01 Python-2.7.3/Tools/scripts/
-rwxr-xr-x scarolan/scarolan    79 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/pydoc
-rwxr-xr-x scarolan/scarolan    95 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/idle
-rwxr-xr-x scarolan/scarolan    96 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/2to3
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:26:01 Python-2.7.3/Lib/
-rwxr-xr-x scarolan/scarolan 18543 2012-04-09 18:07:31 Python-2.7.3/Lib/smtpd.py
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Python-2.7.3
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.64365
+ umask 022
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ cd Python-2.7.3
+ env 'CFLAGS=-O2 -g -m64 -mtune=generic' python setup.py build
running build
running build_ext
error: pyconfig.h: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.64365 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.64365 (%build)
error: command 'rpmbuild' failed with exit status 1


If I hard-code the location of pyconfig.h into setup.py, it still fails:

data = open('/home/scarolan/Python-2.7.3/pyconfig.h').read()

[scarolan at titania:~/Python-2.7.3]$ python setup.py bdist_rpm
running bdist_rpm
writing 'build/bdist.linux-x86_64/rpm/SPECS/Python.spec'
running sdist
running check
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

writing manifest file 'MANIFEST'
creating Python-2.7.3
creating Python-2.7.3/Lib
creating Python-2.7.3/Tools
creating Python-2.7.3/Tools/scripts
making hard links in Python-2.7.3...
hard linking README -> Python-2.7.3
'_struct.c' not a regular file -- skipping
hard linking setup.py -> Python-2.7.3
hard linking Lib/smtpd.py -> Python-2.7.3/Lib
hard linking Tools/scripts/2to3 -> Python-2.7.3/Tools/scripts
hard linking Tools/scripts/idle -> Python-2.7.3/Tools/scripts
hard linking Tools/scripts/pydoc -> Python-2.7.3/Tools/scripts
Creating tar archive
removing 'Python-2.7.3' (and everything under it)
copying dist/Python-2.7.3.tar.gz -> build/bdist.linux-x86_64/rpm/SOURCES
building RPMs
rpmbuild -ba --define _topdir /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm --clean build/bdist.linux-x86_64/rpm/SPECS/Python.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.43579
+ umask 022
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ rm -rf Python-2.7.3
+ /bin/gzip -dc /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/SOURCES/Python-2.7.3.tar.gz
+ tar -xvvf -
drwxrwxr-x scarolan/scarolan 0 2013-03-26 15:28:15 Python-2.7.3/
-rw-rw-r-- scarolan/scarolan 1524 2013-03-26 15:28:15 Python-2.7.3/PKG-INFO
-rw-r--r-- scarolan/scarolan 90378 2013-03-26 15:27:30 Python-2.7.3/setup.py
-rw-r--r-- scarolan/scarolan 53744 2012-04-09 18:07:35 Python-2.7.3/README
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:28:15 Python-2.7.3/Tools/
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:28:15 Python-2.7.3/Tools/scripts/
-rwxr-xr-x scarolan/scarolan    79 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/pydoc
-rwxr-xr-x scarolan/scarolan    95 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/idle
-rwxr-xr-x scarolan/scarolan    96 2012-04-09 18:07:35 Python-2.7.3/Tools/scripts/2to3
drwxrwxr-x scarolan/scarolan     0 2013-03-26 15:28:15 Python-2.7.3/Lib/
-rwxr-xr-x scarolan/scarolan 18543 2012-04-09 18:07:31 Python-2.7.3/Lib/smtpd.py
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Python-2.7.3
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.43579
+ umask 022
+ cd /home/scarolan/Python-2.7.3/build/bdist.linux-x86_64/rpm/BUILD
+ cd Python-2.7.3
+ env 'CFLAGS=-O2 -g -m64 -mtune=generic' python setup.py build
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
error: Modules/Setup: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.43579 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.43579 (%build)
error: command 'rpmbuild' failed with exit status 1

----------
components: Build
messages: 185298
nosy: Sean.Carolan
priority: normal
severity: normal
status: open
title: python setup.py bdist_rpm is broken
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 26 22:02:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Mar 2013 21:02:15 +0000
Subject: [New-bugs-announce] [issue17554] Compact output for regrtest
Message-ID: <1364331735.49.0.0652208703783.issue17554@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached patch is a proof of concept that changes the output of regrtest so that the "[xxx/yyy] test_zzzzzz" is updated in place instead of printing each test on a separate line.  Failures, skips, and the final report are printed normally, making it easier to find what failed without having to scroll for 400+ lines of output.
The patch works with and without -j, but I haven't tested it with other flags.

If people like the idea, this could be the default behavior, otherwise a new flag to enable the feature could be added (or it could be enabled with the already existing -q/--quiet).

Also attached a sample output of a full test run.

----------
components: Tests
files: regr.diff
keywords: patch
messages: 185302
nosy: brett.cannon, chris.jerdonek, ezio.melotti, haypo, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Compact output for regrtest
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29585/regr.diff

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

From report at bugs.python.org  Wed Mar 27 04:22:55 2013
From: report at bugs.python.org (=?utf-8?q?Marc_Br=C3=BCnink?=)
Date: Wed, 27 Mar 2013 03:22:55 +0000
Subject: [New-bugs-announce] [issue17555] Creating new processes after
	importing	multiprocessing.managers consumes more and more memory
Message-ID: <1364354575.82.0.702442791552.issue17555@psf.upfronthosting.co.za>


New submission from Marc Br?nink:

Importing multiprocessing.managers and creating new processes recursively is not a good idea. You will run out of memory very fast.  On my
machine with 8GB it only takes about 20 forks until I start swapping.

----------
components: Library (Lib)
files: test_fork_02.py
messages: 185315
nosy: Marc.Br?nink
priority: normal
severity: normal
status: open
title: Creating new processes after importing multiprocessing.managers consumes more and more memory
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file29590/test_fork_02.py

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

From report at bugs.python.org  Wed Mar 27 08:05:17 2013
From: report at bugs.python.org (Muhammad Hallaj Subery)
Date: Wed, 27 Mar 2013 07:05:17 +0000
Subject: [New-bugs-announce] [issue17556] os.path.join() converts None to ''
	by default
Message-ID: <1364367917.65.0.452140902839.issue17556@psf.upfronthosting.co.za>


New submission from Muhammad Hallaj Subery:

I think the default behavior of os.path.join() when None is passed as the first argument should be to translate it to '' by default.

>>> import os
>>> os.path.join(None, 'somewhere')
'somewhere'

vs the current

>>> import os
>>> os.path.join(None, 'somewhere')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/posixpath.py", line 68, in join
    elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'

----------
components: Library (Lib)
messages: 185316
nosy: hallaj
priority: normal
severity: normal
status: open
title: os.path.join() converts None to '' by default
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 27 10:55:41 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 27 Mar 2013 09:55:41 +0000
Subject: [New-bugs-announce] [issue17557] test_getgroups of test_posix can
	fail on OS X 10.8 if	more than 16 groups
Message-ID: <1364378141.47.0.183536890409.issue17557@psf.upfronthosting.co.za>


New submission from Ned Deily:

Due to a change in behavior for OS X 10.8 (seen with 10.8.3), the code added to posixmodule.c in Issue7900 to handle an unlimited number of groups no longer works.  The code depends on the documented behavior of getgroups(2) failing with EINVAL when the grouplist array in the call is too small to hold all groups.  This works correctly for 10.6 and 10.7.  Currently in 10.8, such a call succeeds and truncates to the first grouplist-size groups.  The getgroups function could probably be modified to always call getgroups(0) first to get the real length.  But it seems to be a clear regression in 10.8 and breaks existing code.  I've opened a bug report with Apple about it.  I'll plan to keep this incident open until I hear something back from them.

----------
assignee: ned.deily
components: Macintosh
messages: 185319
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 27 15:32:18 2013
From: report at bugs.python.org (Marcus Cobden)
Date: Wed, 27 Mar 2013 14:32:18 +0000
Subject: [New-bugs-announce] [issue17558] gdb debugging python frames in
	optimised interpreters
Message-ID: <1364394738.16.0.265916302461.issue17558@psf.upfronthosting.co.za>


New submission from Marcus Cobden:

I've made some tweaks to the libpython.py util functions to better pick up python frames when using a normal python interpreter.

It's not by any means perfect, but it works on my ubuntu-shipped python interpreter (with debugging symbols installed, but not running the debug interpreter).

It works by finding the top frame via the thread state struct, and then going up the frame stack, comparing the stack pointer to a stack pointer in the C context.

I'd appreciate some feedback/advice :)

https://gist.github.com/leth/5254239/revisions

----------
components: Demos and Tools
messages: 185337
nosy: mcobden
priority: normal
severity: normal
status: open
title: gdb debugging python frames in optimised interpreters
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 27 15:41:09 2013
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Wed, 27 Mar 2013 14:41:09 +0000
Subject: [New-bugs-announce] [issue17559] str.is* implementation seem
	suboptimal for single	character strings
Message-ID: <1364395269.34.0.903596007794.issue17559@psf.upfronthosting.co.za>


New submission from Ga?tan de Menten:

In isspace, isalpha, isalnum and isdigit, I see code like:

/* Shortcut for single character strings */
if (PyString_GET_SIZE(self) == 1 &&
    isspace(*p))
    return PyBool_FromLong(1);

Is it intentional to not use:

if (PyString_GET_SIZE(self) == 1))
    return PyBool_FromLong(isspace(*p) != 0);

which would be faster when the result is False (but a tad slower when it is True because of the extra comparison).

Also, is there a reason (other than historical) why the macros Py_RETURN_TRUE and Py_RETURN_FALSE are not used instead of their equivalent functions PyBool_FromLong(1) and PyBool_FromLong(0)?

See:
http://hg.python.org/cpython/file/e87364449954/Objects/stringobject.c#l3324

----------
components: Interpreter Core
messages: 185338
nosy: gdementen
priority: normal
severity: normal
status: open
title: str.is* implementation seem suboptimal for single character strings
type: performance

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

From report at bugs.python.org  Wed Mar 27 16:52:01 2013
From: report at bugs.python.org (mrjbq7)
Date: Wed, 27 Mar 2013 15:52:01 +0000
Subject: [New-bugs-announce] [issue17560] problem using multiprocessing with
	really big objects?
Message-ID: <1364399521.2.0.696890688109.issue17560@psf.upfronthosting.co.za>


New submission from mrjbq7:

I ran into a problem using multiprocessing to create large data objects (in this case numpy float64 arrays with 90,000 columns and 5,000 rows) and return them to the original python process.

It breaks in both Python 2.7 and 3.3, using numpy 1.7.0 (but with different error messages).

It is possible the array is too large to be serialized (450 million 64-bit numbers exceeds a 32-bit limit)?


Python 2.7
==========

Process PoolWorker-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 99, in worker
    put((job, i, result))
  File "/usr/lib/python2.7/multiprocessing/queues.py", line 390, in put
    return send(obj)
SystemError: NULL result without error in PyObject_Call


Python 3.3
==========

Traceback (most recent call last):
  File "multi.py", line 18, in <module>
    results = pool.map_async(make_data, range(5)).get(9999999)
  File "/usr/lib/python3.3/multiprocessing/pool.py", line 562, in get
    raise self._value
multiprocessing.pool.MaybeEncodingError: Error sending result: '[array([[ 0.74628629,  0.36130663, -0.65984794, ..., -0.70921838,
         0.34389663, -1.7135126 ],
       [ 0.60266867, -0.40652402, -1.31590562, ...,  1.44896246,
        -0.3922366 , -0.85012842],
       [ 0.59629641, -0.00623001, -0.12914128, ...,  0.99925511,
        -2.30418136,  1.73414009],
       ..., 
       [ 0.24246639,  0.87519509,  0.24109069, ..., -0.48870107,
        -0.20910332,  0.11749621],
       [ 0.62108937, -0.86217542, -0.47357384, ...,  1.59872243,
         0.76639995, -0.56711461],
       [ 0.90976471,  1.73566475, -0.18191821, ...,  0.19784432,
        -0.29741643, -1.46375835]])]'. Reason: 'error("'i' format requires -2147483648 <= number <= 2147483647",)'

----------
files: multi.py
messages: 185344
nosy: mrjbq7
priority: normal
severity: normal
status: open
title: problem using multiprocessing with really big objects?
versions: Python 3.3
Added file: http://bugs.python.org/file29595/multi.py

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

From report at bugs.python.org  Wed Mar 27 17:48:29 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Mar 2013 16:48:29 +0000
Subject: [New-bugs-announce] [issue17561] Add socket.create_server_sock()
	convenience function
Message-ID: <1364402909.97.0.467946240817.issue17561@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

Here's a function similar to socket.create_connection() which addresses all the repetitive tasks needed to order to create an IPv4/IPv6 agnostic server socket.

----------
components: Library (Lib)
files: socket.patch
keywords: easy, needs review, patch
messages: 185348
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Add socket.create_server_sock() convenience function
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29596/socket.patch

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

From report at bugs.python.org  Wed Mar 27 21:52:35 2013
From: report at bugs.python.org (Konstantin)
Date: Wed, 27 Mar 2013 20:52:35 +0000
Subject: [New-bugs-announce] [issue17562] Invitation to connect on LinkedIn
Message-ID: <820047649.6497366.1364417552812.JavaMail.app@ela4-app2308.prod>


New submission from Konstantin:

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

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

- Konstantin

Konstantin Aslanidi
Author of opentradingsystem.com
Greater New York City Area

Confirm that you know Konstantin Aslanidi:
https://www.linkedin.com/e/-3qcne3-hesyzdls-6z/isd/11993347706/dmPEJwhm/?hs=false&tok=1F_d-YPz94_lE1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hesyzdls-6z/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3977399171_1/?hs=false&tok=3pdPq6KFR4_lE1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 185376
nosy: Aslanidi
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed Mar 27 22:33:59 2013
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 27 Mar 2013 21:33:59 +0000
Subject: [New-bugs-announce] [issue17563] Excessive resizing of dicts when
	used as a cache
Message-ID: <1364420039.63.0.203772094216.issue17563@psf.upfronthosting.co.za>


New submission from Mark Shannon:

If a dict is used a cache, e.g. in functools.lru_cache, 
the reduced resize factor in 3.3 can cause excessive resizing.
This can lead to a significant performance regression.

When the the number of deletions and insertions is roughly in balance
the reduced head room in the dict (compare to 3.2) causes a large increase in the number of resizes.

The reason for this above-linear increase is that with fewer dummy keys, the chance of a dummy being overwritten is reduced *and* is there is less overhead as well.
A dictionary with 128 items will have a capacity of 256 and only 43 dummy keys. If it had a capacity of 512 (as it would have done in 3.2) then it will have 214 keys, making a resize at least 10 times less frequent.

Changing the growth function from round_up_to_power_2(used*2) to
round_up_to_power_2(used*2+capacity/2) the desirable property of only doubling in size when growing can be preserved, yet ensuring sufficient overhead when used as a cache.

Consider a dict which grows to n items and then remains that size, with frequent deletions and insertions, using the proposed growth function:

Items    Capacity         Steady state     Capacity
         on reaching n    capacity         under 3.2
  2        8                  8               8
  4        8                  16              16 
  6        16                 32              32 
  8        16                 32              32 
  10       16                 64              64 
  12       32                 64              64 
  15       32                 64              64 
  20       32                 128             128
  30       64                 128             128
  50       128                256             256
  80       128                512             512
  128      256                512             512


Thanks to Raymond Hettinger for bringing this to my attention.

Patch attached.

----------
components: Interpreter Core
files: resize.patch
keywords: patch
messages: 185378
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Excessive resizing of dicts when used as a cache
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file29598/resize.patch

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

From report at bugs.python.org  Wed Mar 27 22:46:34 2013
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 27 Mar 2013 21:46:34 +0000
Subject: [New-bugs-announce] [issue17564] test_urllib2_localnet fails
Message-ID: <1364420794.5.0.601329646357.issue17564@psf.upfronthosting.co.za>


New submission from Mark Shannon:

The test_urllib2_localnet test fails when run with a clean build from a clean checkout.

Machine:
Ubuntu 12.04 LTS, 64 bit
Intel  i3-2370M CPU @ 2.40GHz ? 4 

Test output:

$ ./python -m test -v test_urllib2_localnet
== CPython 3.4.0a0 (default:53cc3dbb1918, Mar 27 2013, 21:05:11) [GCC 4.6.3]
==   Linux-3.2.0-29-generic-x86_64-with-debian-wheezy-sid little-endian
==   /home/mark/repositories/cpython/build/test_python_4588
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_urllib2_localnet
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... FAIL
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_chunked (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_https (test.test_urllib2_localnet.TestUrlopen) ... stopping HTTPS server
joining HTTPS thread
ok
test_https_sni (test.test_urllib2_localnet.TestUrlopen) ... stopping HTTPS server
joining HTTPS thread
ok
test_https_with_cadefault (test.test_urllib2_localnet.TestUrlopen) ... stopping HTTPS server
Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:555)
joining HTTPS thread
ok
test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen) ... Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:555)
stopping HTTPS server
joining HTTPS thread
stopping HTTPS server
joining HTTPS thread
ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_iteration (test.test_urllib2_localnet.TestUrlopen) ... ok
test_line_iteration (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
FAIL: test_bad_address (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mark/repositories/cpython/Lib/test/test_urllib2_localnet.py", line 568, in test_bad_address
    "http://sadflkjsasf.i.nvali.d./")
AssertionError: OSError not raised by urlopen

----------------------------------------------------------------------
Ran 20 tests in 1.080s

FAILED (failures=1)
Warning -- threading._dangling was modified by test_urllib2_localnet
test test_urllib2_localnet failed
1 test failed:
    test_urllib2_localnet

----------
components: Tests
messages: 185379
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_urllib2_localnet fails
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 28 00:34:55 2013
From: report at bugs.python.org (Daniele Raimondi)
Date: Wed, 27 Mar 2013 23:34:55 +0000
Subject: [New-bugs-announce] [issue17565] segfaults during serialization
Message-ID: <1364427295.89.0.0369789736711.issue17565@psf.upfronthosting.co.za>


New submission from Daniele Raimondi:

pickle and cPickle cause really often segfaults when dumping or loading user defined classes. It happens with python 2.7.3 on 64bits architecture, with any protocol (0,1,2).
I attach an example of class afflicted by this problem.
Solutions anyone?

----------
components: Extension Modules
files: ModelSettings.py
messages: 185389
nosy: eddiewrc
priority: normal
severity: normal
status: open
title: segfaults during serialization
versions: Python 2.7
Added file: http://bugs.python.org/file29599/ModelSettings.py

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

From report at bugs.python.org  Thu Mar 28 17:00:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2013 16:00:22 +0000
Subject: [New-bugs-announce] [issue17566] Document that
	importlib.abc.Loader.module_repr is	abstract and thus needed
	by various other ABCs
Message-ID: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Various places list explicitly what abstractmethods are needed to make an ABC work in importlib.abc. Unfortunately when module_repr() came into existence it was made abstract but no other documentation was updated to point out this fact.

----------
assignee: docs at python
components: Documentation
messages: 185453
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that importlib.abc.Loader.module_repr is abstract and thus needed by various other ABCs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 28 17:04:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2013 16:04:11 +0000
Subject: [New-bugs-announce] [issue17567] Clarify
	importlib.abc.PathEntryFinder.find_loader() docs
Message-ID: <1364486651.54.0.521676412907.issue17567@psf.upfronthosting.co.za>


New submission from Brett Cannon:

"An empty list can be used for portion to signify the loader is not part of a package" should have a "namespace" mention in there at least. Links to the namespace loader or namespace package docs would also help.

----------
assignee: docs at python
components: Documentation
messages: 185454
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify importlib.abc.PathEntryFinder.find_loader() docs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 29 00:50:02 2013
From: report at bugs.python.org (Eric Promislow)
Date: Thu, 28 Mar 2013 23:50:02 +0000
Subject: [New-bugs-announce] [issue17568] re: Infinite loop with repeated
	empty alternative
Message-ID: <1364514602.25.0.0249156897876.issue17568@psf.upfronthosting.co.za>


New submission from Eric Promislow:

>>> import re
>>> p = re.compile(r'^(?:\\"|.|)*?"', re.S|re.M)
>>> s = 'sub foo {\n\tprint "\n\t\tbar\n\t\t";\n}\n'
>>> m = p.findall(s)

Python doesn't return.

Dropping the last "|" in the pattern fixes this.

Regex engines in Perl, PHP, JS, and Ruby all handle
this regex.  Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98268

----------
messages: 185474
nosy: ericp
priority: normal
severity: normal
status: open
title: re: Infinite loop with repeated empty alternative
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Fri Mar 29 01:15:50 2013
From: report at bugs.python.org (J Porter)
Date: Fri, 29 Mar 2013 00:15:50 +0000
Subject: [New-bugs-announce] [issue17569] urllib2 urlopen truncates https
	pages after 32768	characters
Message-ID: <1364516150.61.0.364872176062.issue17569@psf.upfronthosting.co.za>


New submission from J Porter:

When using urllib2 to fetch page data from an https server, I found that only the first 32768 characters of the download were retrieved. Other browsers returned the full documents, so it does not appear to be a server issue. If http, rather than https is used on the same server, the full document is retrieved. No problems with shorter documents (<32768 characters). They were not truncated.

----------
components: Library (Lib)
messages: 185476
nosy: jhp7e
priority: normal
severity: normal
status: open
title: urllib2 urlopen truncates https pages after 32768 characters
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 29 03:13:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Mar 2013 02:13:34 +0000
Subject: [New-bugs-announce] [issue17570] Improve devguide Windows
	instructions
Message-ID: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

This is a follow up of #14468, and in particular of msg183031.

The instructions in the "committing" page of the devguide are unix-centric, in particular:
  1) on Windows ~/.hgrc is $HOME$/mercurial.ini;
  2) the "Settings dialogs" of TortoiseHG can/should be used to edit mercurial.ini;
  3) the devguide suggests "./python.exe Tools/scripts/patchcheck.py", but ./ doesn't work on Windows.

----------
components: Devguide
keywords: easy
messages: 185482
nosy: chris.jerdonek, ezio.melotti, pitrou, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve devguide Windows instructions
type: enhancement

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

From report at bugs.python.org  Fri Mar 29 08:54:26 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 29 Mar 2013 07:54:26 +0000
Subject: [New-bugs-announce] [issue17571] broken links on Lib/datetime.py
	docstring
Message-ID: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

There are 2 broken links at the beginning of Lib/datetime.py.

One other thing, maybe "prototype implemented in Python" is an outdated and/or needless statement?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 185494
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: broken links on Lib/datetime.py docstring
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 29 11:48:04 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 29 Mar 2013 10:48:04 +0000
Subject: [New-bugs-announce] [issue17572] strptime exception context
Message-ID: <1364554084.0.0.791831324367.issue17572@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

When using a directive that is not recognised by time.strptime, the following occurs in Python 3:

>>> time.strptime("", "%D")
Traceback (most recent call last):
  File "C:\Python33\lib\_strptime.py", line 320, in _strptime
    format_regex = _TimeRE_cache.compile(format)
  File "C:\Python33\lib\_strptime.py", line 268, in compile
    return re_compile(self.pattern(format), IGNORECASE)
  File "C:\Python33\lib\_strptime.py", line 262, in pattern
    self[format[directive_index]])
KeyError: 'D'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python33\lib\_strptime.py", line 494, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python33\lib\_strptime.py", line 329, in _strptime
    (bad_directive, format))
ValueError: 'D' is a bad directive in format '%D'
>>>

Probably the KeyError should be supressed when raising the ValueError. The attached patch tries to fix this issue, by suppressing the context.

----------
components: Library (Lib)
files: strptime.patch
keywords: patch
messages: 185495
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: strptime exception context
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29602/strptime.patch

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

From report at bugs.python.org  Fri Mar 29 12:36:44 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 29 Mar 2013 11:36:44 +0000
Subject: [New-bugs-announce] [issue17573] add ElementTree XML processing
	benchmark to benchmark	suite
Message-ID: <1364557004.09.0.303350319351.issue17573@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

Here is an artificial but pretty broad ElementTree benchmark, testing the modules xml.etree.ElementTree, xml.etree.cElementTree and lxml.etree (if importable). Please add it to the benchmark suite.

----------
components: Benchmarks, XML
files: add_et_benchmark.patch
keywords: patch
messages: 185496
nosy: scoder
priority: normal
severity: normal
status: open
title: add ElementTree XML processing benchmark to benchmark suite
type: enhancement
Added file: http://bugs.python.org/file29603/add_et_benchmark.patch

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

From report at bugs.python.org  Fri Mar 29 17:21:50 2013
From: report at bugs.python.org (Valentin Lab)
Date: Fri, 29 Mar 2013 16:21:50 +0000
Subject: [New-bugs-announce] [issue17574] pysetup failing with "OSError:
	[Errno 18] Invalid	cross-device link".
Message-ID: <1364574110.48.0.0858877849425.issue17574@psf.upfronthosting.co.za>


New submission from Valentin Lab:

running::

  $ pysetup remove shyaml
  'shyaml' cannot be removed.
  Error: [Errno 18] Invalid cross-device link

Same happens when using::

  $ pysetup install shyaml==0.1.3

Besides, I've no idea of the state of distutils2 which was promising and is working as far as I'm concerned (except for trivial bugs as this one).

I'm using it for several small project, and I would be glad to know that it is still maintained regarding such easily-corrected bugs.

Correction of this bug is trivial here because ``distutils2/install.py`` line 57 should use ``shutil.move()`` instead of ``os.rename()``. I've tested it, and this does the job.

Thank you for your attention.

----------
assignee: eric.araujo
components: Distutils2
messages: 185500
nosy: alexis, eric.araujo, tarek, vaab
priority: normal
severity: normal
status: open
title: pysetup failing with "OSError: [Errno 18] Invalid cross-device link".
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 29 17:25:03 2013
From: report at bugs.python.org (dspublic@freemail.hu)
Date: Fri, 29 Mar 2013 16:25:03 +0000
Subject: [New-bugs-announce] [issue17575] HTTPConnection.send
Message-ID: <1364574303.8.0.198870267113.issue17575@psf.upfronthosting.co.za>


New submission from dspublic at freemail.hu:

http.client modul, HTTPConnection object, send method

Missing an "else" for self.sock.sendall(data) try block.


...
if hasattr(data, "read") : 
            if self.debuglevel > 0: 
                print("sendIng a read()able") 
            encode = False 
            try: 
                mode = data.mode 
            except AttributeError: 
                # io.BytesIO and other file-like objects don't have a `mode` 
                # attribute. 
                pass 
            else: 
                if "b" not in mode: 
                    encode = True 
                    if self.debuglevel > 0: 
                        print("encoding file using iso-8859-1") 
            while 1: 
                datablock = data.read(blocksize) 
                if not datablock: 
                    break 
                if encode: 
                    datablock = datablock.encode("iso-8859-1") 
                self.sock.sendall(datablock) 
        else: #missing else
          try: 
              self.sock.sendall(data) 
          except TypeError: 
              if isinstance(data, collections.Iterable): 
                    for d in data: 
                        self.sock.sendall(d) 
              else: 
                  raise TypeError("data should be a bytes-like object " 
                                "or an iterable, got %r" % type(data))

----------
messages: 185501
nosy: dspublic at freemail.hu
priority: normal
severity: normal
status: open
title: HTTPConnection.send
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 29 23:25:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Mar 2013 22:25:11 +0000
Subject: [New-bugs-announce] [issue17576] PyNumber_Index() is not
	int-subclass friendly
Message-ID: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

operator.index() is just a thin wrapper around PyNumber_Index().  The documentation for operator.index() claims that it is equivalent to calling obj.__index__() but for subclasses of int, this is not true.  In fact, PyNumber_Index() first does (e.g. in Python 3.3) a PyLong_Check() and if that succeeds, the original object is returned *without* doing the moral equivalent in C of calling obj.__index__().  An example:

class myint(int):
    def __index__(self):
        return int(self) + 1

>>> x = myint(7)
>>> x.__index__()
8
>>> from operator import index
>>> index(x)
7

The C API documents PyNumber_Index() as: "Returns the o converted to a Python int on success or NULL with a TypeError exception raised on failure."

Because this has been the behavior of PyNumber_Index() since at least 2.7 (I didn't check farther back), this probably cannot be classified as a bug deserving to be fixed in the code for older Pythons.  It might be worth fixing for Python 3.4, i.e. by moving the index check before the type check.  In the meantime, this is probably a documentation bug.

The C API implies, but should be clearer that if o is an int subtype (int and long in Python 2), it is returned unchanged.  The operator.index() documentation should be amended to describe this behavior for int/long subclasses.

A different alternative would be to leave PyNumber_Index() unchanged, but with the doco fix, and to augment operator.index() to do the PyIndex_Check() first, before calling PyNumber_Index().  That's a little more redundant, but would provide the documented behavior without changing the C API.

----------
assignee: docs at python
components: Documentation
messages: 185522
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: PyNumber_Index() is not int-subclass friendly
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 30 00:37:54 2013
From: report at bugs.python.org (Phil Connell)
Date: Fri, 29 Mar 2013 23:37:54 +0000
Subject: [New-bugs-announce] [issue17577] Add lookahead/peek wrapper to
	itertools
Message-ID: <1364600274.74.0.549757857069.issue17577@psf.upfronthosting.co.za>


New submission from Phil Connell:

A recipe often requested on the likes of stackoverflow and activestate is a way to look 'ahead' in an iterator, without altering the values returned for subsequent next() calls.

Last time this came up on python-ideas, it got a reasonable reception:
  http://code.activestate.com/lists/python-ideas/19509/

So, having wanted (and implemented) this again, I thought it was worth a formal proposal.

Is this an idea worth pursuing?


I've attached a quick pure Python implementation, that adds a 'peek' method, used like this:

>>> it = lookahead(range(10))
>>> next(it)
0
>>> it.peek()
1
>>> next(it)
1
>>> it.peek(index=1)
3
>>> it.peek()
2
>>> next(it)
2

----------
components: Library (Lib)
files: lookahead.py
messages: 185527
nosy: pconnell, rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: Add lookahead/peek wrapper to itertools
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29606/lookahead.py

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

From report at bugs.python.org  Sat Mar 30 07:31:41 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 30 Mar 2013 06:31:41 +0000
Subject: [New-bugs-announce] [issue17578] Update devguide for 3.2 in
	security-fix-only mode
Message-ID: <1364625101.22.0.730828988878.issue17578@psf.upfronthosting.co.za>


New submission from Ned Deily:

The attached patch updates the Developer's Guide to reflect the changes in the development process now that the 3.2 branch has closed for bug fixes and has moved to security-fix-only status.

----------
components: Devguide
files: devguide_32_to_security_mode.patch
keywords: patch
messages: 185548
nosy: ezio.melotti, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Update devguide for 3.2 in security-fix-only mode
Added file: http://bugs.python.org/file29611/devguide_32_to_security_mode.patch

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

From report at bugs.python.org  Sat Mar 30 13:26:50 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 30 Mar 2013 12:26:50 +0000
Subject: [New-bugs-announce] [issue17579] socket module in 2.7.4 raises
	error instead of gaierror	in 2.7.3
Message-ID: <1364646410.74.0.12025948597.issue17579@psf.upfronthosting.co.za>


New submission from Matthias Klose:

forwarded from https://launchpad.net/bugs/+bug/1154599

this seems to be changed behavior in 2.7.4. is it intended?

$ cat lookup.py 
#!/usr/bin/python
import sys, socket
names = ["slashdot.org", "foooooooooowhizzzzzzzz.com"]
if len(sys.argv) > 1:
   names = sys.argv[1:]
for iname in names:
    try:
        result = socket.getaddrinfo(iname, None, 0, 0, socket.SOCK_STREAM,
                                    socket.AI_CANONNAME)
        for (fam, stype, proto, cname, sockaddr) in result:
            sys.stdout.write("cname=%s, sockaddr=%s\n" % (cname, sockaddr))
    except socket.gaierror as error:
        sys.stderr.write("%s failed lookup" % iname)

$ python lookup.py # 2.7.3
cname=slashdot.org, sockaddr=('216.34.181.45', 0)
foooooooooowhizzzzzzzz.com failed lookup

$ python lookup.py # 2.7.4
cname=slashdot.org, sockaddr=('216.34.181.45', 0)
Traceback (most recent call last):
  File "lookup.py", line 9, in <module>
    socket.AI_CANONNAME)
socket.error: [Errno 2] No such file or directory

----------
components: Library (Lib)
messages: 185553
nosy: benjamin.peterson, doko
priority: release blocker
severity: normal
status: open
title: socket module in 2.7.4 raises error instead of gaierror in 2.7.3
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 30 14:47:30 2013
From: report at bugs.python.org (David Schneider)
Date: Sat, 30 Mar 2013 13:47:30 +0000
Subject: [New-bugs-announce] [issue17580] ctypes: ARM hardfloat argument
	corruption calling	functions with many float arguments
Message-ID: <1364651250.44.0.538707073215.issue17580@psf.upfronthosting.co.za>


New submission from David Schneider:

This issue affects C functions with many float/double arguments called through ctypes on ARM using the hardfloat ABI (i.e. the standard distribution for the raspberry pi uses hard-float).

Calling a C function using ctypes on ARM hard-float that takes a large number of float arguments (more than 16 floats or more than 8 doubles) corrupts the first float/double arguments passed on the stack to the called function. 

To check the issue run the following commands on an ARM hard-float system:
make
python bug.py

A patch for this issue has been accepted into libffi.

----------
components: ctypes
files: ctypes_arm.tar
messages: 185557
nosy: bivab
priority: normal
severity: normal
status: open
title: ctypes: ARM hardfloat argument corruption calling functions with many float arguments
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file29613/ctypes_arm.tar

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

From report at bugs.python.org  Sat Mar 30 16:17:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Mar 2013 15:17:37 +0000
Subject: [New-bugs-announce] [issue17581] _ssl fails building on OS X Tiger
Message-ID: <1364656657.55.0.505646365517.issue17581@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The _ssl module has failed building (on 3.4) on OS X Tiger for a long time:
http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6075/steps/test/logs/stdio

Given the error messages, and given how old OS X Tiger is (according to Google, the system OpenSSL is 0.9.7), I'm inclined to think it is because of missing features on the system OpenSSL.

Is there any point in supporting OS X Tiger in 3.4? Should the _ssl module be updated to use conditionals for "new" (i.e. < 7 years old) OpenSSL features?

----------
components: Build, Extension Modules
messages: 185566
nosy: hynek, ned.deily, pitrou, ronaldoussoren
priority: normal
severity: normal
status: open
title: _ssl fails building on OS X Tiger
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 30 17:26:34 2013
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sat, 30 Mar 2013 16:26:34 +0000
Subject: [New-bugs-announce] [issue17582] xml.etree.ElementTree does not
	preserve whitespaces in	attributes
Message-ID: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

XML defines the following chars as whitespace [1]::

    S ::= (#x20 | #x9 | #xD | #xA)+

However the chars are not properly escaped into attributes, so they are converted into spaces as per attribute-value normalization [2]

    >>> data = '\x09\x0a\x0d\x20'
    >>> data
    '\t\n\r '

    >>> import  xml.etree.ElementTree as ET
    >>> e = ET.Element('x', attr=data)
    >>> s = ET.tostring(e)
    >>> s
    '<x attr="\t&#10;\r " />'

    >>> e1 = ET.fromstring(s)
    >>> data1 = e1.attrib['attr']
    >>> data1 == data
    False

    >>> data1
    ' \n  '

cElementTree suffers of the same bug::

    >>> import  xml.etree.cElementTree as cET
    >>> cET.fromstring(cET.tostring(cET.Element('a', attr=data))).attrib['attr']
    ' \n  '

but not the external library lxml.etree::

    >>> import lxml.etree as LET
    >>> LET.fromstring(LET.tostring(LET.Element('a', attr=data))).attrib['attr']
    '\t\n\r '

The bug is analogous to #5752 but it refers to a different and independent module. Proper escaping should be added to the _escape_attrib() function into /xml/etree/ElementTree.py (and equivalent for cElementTree).

[1] http://www.w3.org/TR/REC-xml/#white
[2] http://www.w3.org/TR/REC-xml/#AVNormalize

----------
components: Library (Lib), XML
messages: 185574
nosy: piro
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree does not preserve whitespaces in attributes
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Mar 31 00:12:36 2013
From: report at bugs.python.org (Amit Saha)
Date: Sat, 30 Mar 2013 23:12:36 +0000
Subject: [New-bugs-announce] [issue17583] IDLE HOWTO
Message-ID: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>


New submission from Amit Saha:

I would like to propose a new HOWTO discussing IDLE from a user's perspective. I feel that the current documentation at http://docs.python.org/3/library/idle.html is not sufficient to be pointed to a newbie programmer or someone who wants to teach his/her students to IDLE. For example, being an experienced person myself, I didn't know how to start IDLE on Linux! Whether it was a separate package, or whether it was already installed (That may be my own shortcoming, but never the less).

I started a document this morning which can be seen here [1]. The source is here[2]

[1] http://amitsaha.github.com/site/notes/articles/idle/article.html
[2] http://amitsaha.github.com/site/notes/_sources/articles/idle/article.txt

I am putting up my hand to write the HOWTO and maintain it for 2.7 and 3.3+. 

Comments?

----------
components: IDLE
messages: 185600
nosy: Amit.Saha
priority: normal
severity: normal
status: open
title: IDLE HOWTO
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar 31 04:31:06 2013
From: report at bugs.python.org (Byron Ruth)
Date: Sun, 31 Mar 2013 02:31:06 +0000
Subject: [New-bugs-announce] [issue17584] collections.Iterator
	__subclasshook__ does not check if	next() is callable
Message-ID: <1364697066.21.0.714647117005.issue17584@psf.upfronthosting.co.za>


Changes by Byron Ruth <b at devel.io>:


----------
components: Library (Lib)
nosy: bruth
priority: normal
severity: normal
status: open
title: collections.Iterator __subclasshook__ does not check if next() is callable
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 31 09:45:00 2013
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 31 Mar 2013 07:45:00 +0000
Subject: [New-bugs-announce] [issue17585] IDLE - regression with exit() and
	quit()
Message-ID: <1364715900.07.0.37447718586.issue17585@psf.upfronthosting.co.za>


New submission from Roger Serwy:

This issue is a split from #5492, where Terry noticed a serious regression that "quit()" and "exit()" no longer work in IDLE.

Before #9290, the PyShell object itself was stdin and it didn't have a "fileno" method. The code in site.py would skip over the call to fileno, leaving fd == -1, which then called close() on stdin, effectively the close() method of PyShell. 

The application of #9290 introduced PseudoFile as a subclass of io.TextIOBase which has a "fileno" method. The site.py code find it, calls it, but an error gets raised so that the close() method doesn't get called. Even if you subclass fileno(), you still need to subclass close() so that it calls the original close function in PyShell.

The attached patch, fileno_close.patch, fixes that issue. I would argue that this patch should be applied to all the release candidates as it corrects a serious regression.

I would like to hear your thoughts before applying the patch.

----------
assignee: roger.serwy
components: IDLE
files: fileno_close.patch
keywords: patch
messages: 185619
nosy: roger.serwy, terry.reedy
priority: critical
severity: normal
stage: patch review
status: open
title: IDLE - regression with exit() and quit()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29618/fileno_close.patch

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

From report at bugs.python.org  Sun Mar 31 12:17:35 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 31 Mar 2013 10:17:35 +0000
Subject: [New-bugs-announce] [issue17586] fix typo in contextlib.rst
Message-ID: <1364725055.74.0.0927098228903.issue17586@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: typo.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix typo in contextlib.rst
versions: Python 3.4
Added file: http://bugs.python.org/file29619/typo.diff

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

From report at bugs.python.org  Sun Mar 31 18:55:03 2013
From: report at bugs.python.org (Daniel Ellis)
Date: Sun, 31 Mar 2013 16:55:03 +0000
Subject: [New-bugs-announce] [issue17587] Have all core library modules
	imported by default
Message-ID: <1364748903.2.0.666469840535.issue17587@psf.upfronthosting.co.za>


New submission from Daniel Ellis:

The other day I was trying to make a script to import a CSV file but for the life of me couldn't remember what the name of the csv library was (turns out it was csv).  So I started thinking "hey, what if all the standard library were just *there* by default"?  We all know doing imports is really boring, so why don't we deal with the elephant in the room?  This is what I love about PHP: once something's imported (or required?  included?  required_once?) you don't have to think about it anymore.  It's very "set it and forget it".  And then you simply remember it later when necessary.  For this, I use pen and paper.

Holy crap, I just had an even better idea.  What if all third-party modules were imported as well?  This may be a bit more challenging, but I truly believe you guys can do it.  There are system settings I've heard about (Krons) that let you basically do anything over and over again.  We could have Python automatically download all pips or whatever and import them without thinking.  Boom!  The Zen of Python.

And can we put an & and a $ somewhere in Python?  I think these feel very cool to use, and are easily one of the best things I miss from more advanced languages like C and PHP.  Let's be honest, doesn't this:

    $item->method();

Look a lot more professional than:

    item.method()

It certainly justifies my salary a bit better.

I don't have a patch for this because, let's be honest, I wouldn't know where to begin.  But I can't imagine it being that hard.  Is there a line or two we could change somewhere?  Maybe just throw an "import *" into a header file somewhere?

Finally, I propose replacing meaningful whitespace with meaningful random unicode characters.  This would look like the matrix and once you "got it" it would feel really cool.  With all of these changes I think we have the potential to turn this toy language into a powerhouse that could even be used for stuff like forum software.

Let me know what you guys think of this.  Also, I offer consulting work for a modest fee (though I don't do any programming myself, I'm more of a people person).

----------
messages: 185630
nosy: Daniel.Ellis, gvanrossum
priority: normal
severity: normal
status: open
title: Have all core library modules imported by default
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 31 20:08:50 2013
From: report at bugs.python.org (Drekin)
Date: Sun, 31 Mar 2013 18:08:50 +0000
Subject: [New-bugs-announce] [issue17588] runpy cannot run Unicode path on
	Windows
Message-ID: <1364753330.76.0.973974217823.issue17588@psf.upfronthosting.co.za>


New submission from Drekin:

runpy.run_path("\u222b.py") raises UnicodeEncodeError when trying to use mbcs codec on Windows. However opening the file using open() is ok. So why is runpy trying to encode the name using mbcs encoding when it's not necessary or even correct? See http://bpaste.net/show/aOqQLMyYAAFTJ8pQnkli/ .

----------
components: Library (Lib), Unicode, Windows
messages: 185634
nosy: Drekin, ezio.melotti
priority: normal
severity: normal
status: open
title: runpy cannot run Unicode path on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar 31 21:39:15 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 31 Mar 2013 19:39:15 +0000
Subject: [New-bugs-announce] [issue17589] Make documentation about macros in
	C API explicit about	rvalue vs statement
Message-ID: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>


New submission from Larry Hastings:

CPython API "functions" implemented as macros can expand into either
rvalues or statements.  Most expand into statements (often using the
do {} while (0) syntactic sugar trick), but occasionally they're legal
as rvalues.

As of this writing Py_INCREF works as an rvalue.  But discussion on
another tracker issue (#17206) proposes changing the implementation
in such a way that it will only be usable as a statement.  Although
it's mildly unlikely, it's certainly possible that this will break
somebody's code.

I propose that the documentation make an explicit ruling on whether
macros are usable as rvalues or as statements.  Perhaps a blanket
statement would suffice, "all macros are only supported for use as
statements except where explicitly noted", then annotate specific
macros that are supported for use as rvalues.  Though that raises the
question of acknowledging in the documentation that some things are
macros--I think the documentation glosses over that fact right now.

Note: I added you three (Georg, Mark, Martin) as I thought you might
have an opinion on this one way or the other.  If you're not interested,
my apologies.

----------
assignee: docs at python
components: Documentation
messages: 185646
nosy: Mark.Shannon, docs at python, georg.brandl, larry, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: Make documentation about  macros in C API explicit about rvalue vs statement
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 31 21:39:59 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:39:59 +0000
Subject: [New-bugs-announce] [issue17590] mingw: translate gcc internal
	defines to python platform	specific defines
Message-ID: <1364758799.57.0.261822298653.issue17590@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Build, Cross-Build
files: 0002-MINGW-translate-gcc-internal-defines-to-python-platf.patch
keywords: patch
messages: 185647
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: translate gcc internal defines to python platform specific defines
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29624/0002-MINGW-translate-gcc-internal-defines-to-python-platf.patch

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

From report at bugs.python.org  Sun Mar 31 21:42:11 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:42:11 +0000
Subject: [New-bugs-announce] [issue17591] mingw: use header in lowercase
Message-ID: <1364758931.6.0.420672856483.issue17591@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Cross-Build
files: 0003-MINGW-use-header-in-lowercase.patch
keywords: patch
messages: 185648
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: use header in lowercase
versions: Python 3.4
Added file: http://bugs.python.org/file29625/0003-MINGW-use-header-in-lowercase.patch

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

From report at bugs.python.org  Sun Mar 31 21:43:30 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:43:30 +0000
Subject: [New-bugs-announce] [issue17592] mingw: configure MACHDEP and
	platform for build
Message-ID: <1364759010.97.0.879569753757.issue17592@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Build, Cross-Build
files: 0004-MINGW-configure-MACHDEP-and-platform-for-build.patch
keywords: patch
messages: 185650
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: configure MACHDEP and platform for build
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29626/0004-MINGW-configure-MACHDEP-and-platform-for-build.patch

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

From report at bugs.python.org  Sun Mar 31 21:44:31 2013
From: report at bugs.python.org (Dominik Stadler)
Date: Sun, 31 Mar 2013 19:44:31 +0000
Subject: [New-bugs-announce] [issue17593] mailbox.py tries to link even on
	filesystem wihch does	not support symbolic links
Message-ID: <1364759071.81.0.0901608465156.issue17593@psf.upfronthosting.co.za>


New submission from Dominik Stadler:

I tried to use NoPriv (https://github.com/RaymiiOrg/NoPriv/) to backup emails to an USB Disk which is formatted for Windows compatibility, i.e. FAT-type filesystem, but got the error below. Seems mailbox.py still tries to create a symbolic link, which is not possible on this filesystem.

Running on ext3 file system works fine. This is on Ubuntu Precise 12.04 with latest updates installed. Python is 2.7.3-0ubuntu3.1

Getting messages from server from folder: [Gmail]/Sent Mail.
Saving message 1.
Traceback (most recent call last):
  File "./nopriv.py", line 783, in <module>
    get_messages_to_local_maildir(folder, mail)    
  File "./nopriv.py", line 236, in get_messages_to_local_maildir
    saveToMaildir(raw_email, maildir_folder)
  File "./nopriv.py", line 155, in saveToMaildir
    message_key = folder.add(msg)
  File "/usr/lib/python2.7/mailbox.py", line 276, in add
    os.link(tmp_file.name, dest)
OSError: [Errno 1] Operation not permitted

----------
components: Library (Lib)
messages: 185652
nosy: dominik-stadler
priority: normal
severity: normal
status: open
title: mailbox.py tries to link even on filesystem wihch does not support symbolic links
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 31 21:46:49 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:46:49 +0000
Subject: [New-bugs-announce] [issue17594] mingw: preset configure defaults
Message-ID: <1364759209.12.0.183871965153.issue17594@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871, but implement ed differently - externalize some configure defaults instead to update configure script for each check

----------
components: Build, Cross-Build
files: 0005-MINGW-preset-configure-defaults.patch
keywords: patch
messages: 185653
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: preset configure defaults
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29627/0005-MINGW-preset-configure-defaults.patch

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

From report at bugs.python.org  Sun Mar 31 21:51:09 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:51:09 +0000
Subject: [New-bugs-announce] [issue17595] mingw: configure largefile support
	for windows builds
Message-ID: <1364759469.4.0.971782294906.issue17595@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Build, Cross-Build
files: 0006-MINGW-configure-largefile-support-for-windows-builds.patch
keywords: patch
messages: 185655
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: configure largefile support for windows builds
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29628/0006-MINGW-configure-largefile-support-for-windows-builds.patch

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

From report at bugs.python.org  Sun Mar 31 21:52:30 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:52:30 +0000
Subject: [New-bugs-announce] [issue17596] mingw: add wincrypt.h in
	Python/random.c
Message-ID: <1364759550.1.0.784816138904.issue17596@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Build, Cross-Build
files: 0007-MINGW-add-wincrypt.h-in-Python-random.c.patch
keywords: patch
messages: 185656
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: add wincrypt.h in Python/random.c
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29629/0007-MINGW-add-wincrypt.h-in-Python-random.c.patch

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

From report at bugs.python.org  Sun Mar 31 21:56:39 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:56:39 +0000
Subject: [New-bugs-announce] [issue17597] mingw: add $srcdir/PC to CPPFLAGS
Message-ID: <1364759799.81.0.998386094022.issue17597@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871.

May be best solution is to move "errmap.h" from PC/ to Objects/ and to use platform specific filename.

----------
components: Build, Cross-Build
files: 0008-MINGW-add-srcdir-PC-to-CPPFLAGS.patch
keywords: patch
messages: 185657
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: add $srcdir/PC to CPPFLAGS
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29630/0008-MINGW-add-srcdir-PC-to-CPPFLAGS.patch

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

From report at bugs.python.org  Sun Mar 31 21:58:05 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:58:05 +0000
Subject: [New-bugs-announce] [issue17598] mingw: init system calls
Message-ID: <1364759885.17.0.0266392857932.issue17598@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871.

----------
components: Build, Cross-Build
files: 0009-MINGW-init-system-calls.patch
keywords: patch
messages: 185659
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: init system calls
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29631/0009-MINGW-init-system-calls.patch

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

From report at bugs.python.org  Sun Mar 31 21:59:37 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 19:59:37 +0000
Subject: [New-bugs-announce] [issue17599] mingw: detect REPARSE_DATA_BUFFER
Message-ID: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871.

----------
components: Build, Cross-Build
files: 0010-MINGW-detect-REPARSE_DATA_BUFFER.patch
keywords: patch
messages: 185660
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: detect REPARSE_DATA_BUFFER
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29632/0010-MINGW-detect-REPARSE_DATA_BUFFER.patch

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

From report at bugs.python.org  Sun Mar 31 22:01:07 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:01:07 +0000
Subject: [New-bugs-announce] [issue17600] mingw: build-in windows modules
	(winreg)
Message-ID: <1364760067.55.0.47312643971.issue17600@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871.

----------
components: Build, Cross-Build
files: 0011-MINGW-build-in-windows-modules-winreg.patch
keywords: patch
messages: 185661
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: build-in windows modules (winreg)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29633/0011-MINGW-build-in-windows-modules-winreg.patch

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

From report at bugs.python.org  Sun Mar 31 22:04:28 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:04:28 +0000
Subject: [New-bugs-announce] [issue17601] mingw: determine if pwdmodule
	should be used
Message-ID: <1364760268.61.0.961516146376.issue17601@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871.
(now without to impact other platforms - it will remain build-in module)

----------
components: Interpreter Core
files: 0012-MINGW-determine-if-pwdmodule-should-be-used.patch
keywords: patch
messages: 185663
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: determine if pwdmodule should be used
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29634/0012-MINGW-determine-if-pwdmodule-should-be-used.patch

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

From report at bugs.python.org  Sun Mar 31 22:10:13 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:10:13 +0000
Subject: [New-bugs-announce] [issue17602] mingw: default sys.path
	calculations for windows	platforms
Message-ID: <1364760613.75.0.604084743865.issue17602@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Part is split of issue3871.
Based of feedback to issue3871 users prefer to use posix installation scheme and this is implementation of 'relative' posix prefix.

----------
components: Interpreter Core
files: 0013-MINGW-default-sys.path-calculations-for-windows-plat.patch
keywords: patch
messages: 185664
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: default sys.path calculations for windows  platforms
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29635/0013-MINGW-default-sys.path-calculations-for-windows-plat.patch

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

From report at bugs.python.org  Sun Mar 31 22:13:39 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:13:39 +0000
Subject: [New-bugs-announce] [issue17603] AC_LIBOBJ replacement of fileblocks
Message-ID: <1364760819.41.0.900154328327.issue17603@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871 - actually this is not mingw* specific - it is for all platforms without fileblocks

----------
components: Build, Cross-Build
files: 0014-MINGW-AC_LIBOBJ-replacement-of-fileblocks.patch
keywords: patch
messages: 185665
nosy: rpetrov
priority: normal
severity: normal
status: open
title: AC_LIBOBJ replacement of fileblocks
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29636/0014-MINGW-AC_LIBOBJ-replacement-of-fileblocks.patch

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

From report at bugs.python.org  Sun Mar 31 22:16:13 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:16:13 +0000
Subject: [New-bugs-announce] [issue17604] mingw: use main() to start
	execution
Message-ID: <1364760973.75.0.319025813954.issue17604@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871

----------
components: Interpreter Core
files: 0015-MINGW-use-main-to-start-execution.patch
keywords: patch
messages: 185666
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: use main() to start execution
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29637/0015-MINGW-use-main-to-start-execution.patch

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

From report at bugs.python.org  Sun Mar 31 22:42:04 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Mar 2013 20:42:04 +0000
Subject: [New-bugs-announce] [issue17605] mingw-meta: build interpeter core
Message-ID: <1364762524.12.0.901415822586.issue17605@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871 - this is meta issue only for part related to build interpreter core.
Goal is statically linked python executable (python.exe).
Patch set consist of :
- 01 Issue17148 : nt thread model detection
- 02 issue17590 : translate gcc internal defines to python platform specific defines
- 03 issue17591 : use header in lowercase
- 04 issue17592 : configure MACHDEP and platform for build
- 05 issue17594 : preset configure defaults
- 06 issue17595 : configure largefile support for windows builds
- 07 issue17596 : add wincrypt.h in Python/random.c
- 08 issue17597 : add $srcdir/PC to CPPFLAGS
- 09 issue17598 : init system calls
- 10 issue17599 : detect REPARSE_DATA_BUFFER
- 11 issue17600 : build-in windows modules (winreg)
- 12 issue17601 : determine if pwdmodule should be used
- 13 issue17602 : default sys.path calculations for windows  platforms
- 14 issue17603 : AC_LIBOBJ replacement of fileblocks
- 15 issue17604 : use main() to start execution

After above patches user must regenerate configure script.

Hints:
a) at configure time define CPPFLAGS with minimum supported version like this   "-DWINVER=0x501 -D_WIN32_WINNT=0x501", i.e XP is now minimum
b) use --without-libm 
c) do not use yet --enable-shared

Notes:
a) previous mingw patch (issue3871 posted in 2008) contain code that define w2k as minimum . Now python evolve and minimum is xp. 
b) previous patch nos not define libm in configure script . Instead to updated configure use tis flag
c) will be included in additional patch-set related to build of standard extensions.

----------
components: Interpreter Core
messages: 185669
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw-meta: build interpeter core
type: enhancement
versions: Python 3.4

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