From report at bugs.python.org  Sat Mar  1 04:31:37 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 01 Mar 2014 03:31:37 +0000
Subject: [New-bugs-announce] [issue20812] Explicitly cover application
	migration in the 2->3 guide
Message-ID: <1393644697.6.0.827817573791.issue20812@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

A thread on python-ideas made me realised the migration guide is currently missing a section: migrating integrated applications.

This needs to cover:

- "caniusepython3" to check dependencies for compatibility
- if dependencies are ready, and Python 2 compatibility can be dropped completely, the 2to3 based migration path
- if dependencies aren't ready yet, the Python 2 -> 2/3 source on Python 2 -> 2/3 source on Python 3 -> Python 3 migration path
- if dependencies are ready but Python 2 compatibility is still needed, the Python 2 only -> 2/3 source on Python 2 or 3 -> Python 3 only migration path

----------
messages: 212485
nosy: brett.cannon, ncoghlan
priority: high
severity: normal
stage: needs patch
status: open
title: Explicitly cover application migration in the 2->3 guide
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  1 04:42:13 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 01 Mar 2014 03:42:13 +0000
Subject: [New-bugs-announce] [issue20813] Backport revised 2to3 guide to
	older branches
Message-ID: <1393645333.55.0.319338278634.issue20813@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Brett's updated 2to3 guide is currently only on the default branch. This means that the /3/ web docs won't be updated until 3.4 is released later this month and the /2/ web docs and the compiled help files shipped with the Windows installers for 2.7.x and 3.3.x won't be updated at all.

I don't see a good reason to leave it that way, so I think we should backport the updated version wholesale both to get the revised guide available ASAP, and also to ensure the /2/ web docs and the shipped compiled HTML docs are updated.

----------
keywords: easy
messages: 212486
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Backport revised 2to3 guide to older branches
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Mar  1 10:06:39 2014
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 01 Mar 2014 09:06:39 +0000
Subject: [New-bugs-announce] [issue20814] tracemalloc example
Message-ID: <1393664799.77.0.847113430877.issue20814@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee:

Running the Pretty top example (http://docs.python.org/dev/library/tracemalloc.html#pretty-top) in the tracemalloc module documentation causes a ValueError.


    Traceback (most recent call last):
      File "t.py", line 32, in <module>
        display_top(snapshot, 10)
      File "t.py", line 9, in display_top
        top_stats = snapshot.statistics(group_by)
      File "/home/falsetru/h/cpython/Lib/tracemalloc.py", line 449, in statistics
        grouped = self._group_by(key_type, cumulative)
      File "/home/falsetru/h/cpython/Lib/tracemalloc.py", line 395, in _group_by
        raise ValueError("unknown key_type: %r" % (key_type,))
    ValueError: unknown key_type: 10

The last line of the example should be:

    display_top(snapshot, limit=10)

or:

    display_top(snapshop)

----------
assignee: docs at python
components: Documentation
messages: 212493
nosy: Jeong-Min.Lee, docs at python
priority: normal
severity: normal
status: open
title: tracemalloc example
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar  1 13:01:32 2014
From: report at bugs.python.org (Michel Albert)
Date: Sat, 01 Mar 2014 12:01:32 +0000
Subject: [New-bugs-announce] [issue20815] ipaddress unit tests PEP8
Message-ID: <1393675292.33.0.0800271368289.issue20815@psf.upfronthosting.co.za>


New submission from Michel Albert:

While I was looking at the source of the ipaddress unit-tests, I noticed a couple of PEP8 violations. This patch fixes these (verified using the ``pep8`` tool).

There are no behavioural changes. Only white-space.

Test-cases ran successfully before, and after the change was made.

----------
components: Tests
files: test_ipaddress_pep8.patch
keywords: patch
messages: 212497
nosy: exhuma, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: ipaddress unit tests PEP8
versions: Python 3.5
Added file: http://bugs.python.org/file34257/test_ipaddress_pep8.patch

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

From report at bugs.python.org  Sat Mar  1 17:00:50 2014
From: report at bugs.python.org (Jeremiah Lowin)
Date: Sat, 01 Mar 2014 16:00:50 +0000
Subject: [New-bugs-announce] [issue20816] inspect.getcallargs() attempts to
	iterate over None
Message-ID: <1393689650.85.0.777698851793.issue20816@psf.upfronthosting.co.za>


New submission from Jeremiah Lowin:

Tested in Python 3.3 and Python 3.4.0rc1 5e05d7d3db9c

If a function has keyword-only arguments but no keyword-only defaults, then calling inspect.getcallargs with no arguments results in the wrong TypeError being raised.

Example:

>>> import inspect
>>> def fn(*, a): 
>>>    pass
>>> inspect.getcallargs(fn)

Result: 
    TypeError: argument of type 'NoneType' is not iterable

Expected Result: 
    TypeError: fn() missing 1 required keyword-only argument: 'a'

----------
components: Library (Lib)
messages: 212509
nosy: jlowin
priority: normal
severity: normal
status: open
title: inspect.getcallargs() attempts to iterate over None
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar  1 17:35:04 2014
From: report at bugs.python.org (Jeremiah Lowin)
Date: Sat, 01 Mar 2014 16:35:04 +0000
Subject: [New-bugs-announce] [issue20817] inspect.getcallargs() raises the
	wrong error if 3+	arguments are missing
Message-ID: <1393691704.85.0.0636600891648.issue20817@psf.upfronthosting.co.za>


New submission from Jeremiah Lowin:

If inspect.getcallargs() is called on a function and three or more arguments are missing, an IndexError is raised instead of the expected TypeError.

This bug is present in Python 3.3 and 3.4.0 rc1 (5e05d7d3db9c). However, it worked as expected in Python 2.7.6.

Example:

>>> import inspect
>>> def fn(a, b, c):
>>>     pass
>>> inspect.getcallargs(fn)

Result: 
    IndexError: tuple index out of range
Expected:
    TypeError: fn() missing 3 required positional arguments: 'a', 'b' and 'c'

----------
components: Library (Lib)
messages: 212514
nosy: jlowin
priority: normal
severity: normal
status: open
title: inspect.getcallargs() raises the wrong error if 3+ arguments are missing
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar  1 23:20:14 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Mar 2014 22:20:14 +0000
Subject: [New-bugs-announce] [issue20818] 3.4 cherry pick: 5fa3f6d82d61 and
	a8470f88e7b4 - OS X	installer use SQLite 3.8.3.1
Message-ID: <1393712414.04.0.397159568355.issue20818@psf.upfronthosting.co.za>


New submission from Ned Deily:

Update the OS X installer build to use SQLite 3.8.3.1 instead of 3.8.3 (see Issue20465).

----------
assignee: larry
components: Build
messages: 212524
nosy: larry, ned.deily
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry pick: 5fa3f6d82d61 and a8470f88e7b4 - OS X installer use SQLite 3.8.3.1
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 01:28:56 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 02 Mar 2014 00:28:56 +0000
Subject: [New-bugs-announce] [issue20819] reinitialize_command doesn't clear
	install_lib on	install and install_lib commands
Message-ID: <1393720136.29.0.00108856788876.issue20819@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

The setuptools source references a "distutils bug" here: https://bitbucket.org/pypa/setuptools/src/85760c42740829000a19ebf708d0a9cd565bb0eb/setuptools/command/bdist_wininst.py?at=default#cl-7

>From what I infer from that message, the bug is that 'reinitialize_command' doesn't clear the 'install_lib' property on the 'install' or 'install_lib' commands.

I'm actually skeptical that setuptools even needs to clear the 'install_lib' property on the 'install_lib' command, for as best as I can tell, the install_lib command only ever sets install_dir.

Nevertheless, I wanted to log a ticket to reference in the code to ultimately find a solution rather than a workaround.

----------
components: Distutils
messages: 212530
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: reinitialize_command doesn't clear install_lib on install and install_lib commands
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/issue20819>
_______________________________________

From report at bugs.python.org  Sun Mar  2 01:40:18 2014
From: report at bugs.python.org (Nick Timkovich)
Date: Sun, 02 Mar 2014 00:40:18 +0000
Subject: [New-bugs-announce] [issue20820] HTML being escaped on some release
	pages
Message-ID: <1393720818.97.0.338117784807.issue20820@psf.upfronthosting.co.za>


New submission from Nick Timkovich:

On a random trip through Python's past I noticed the new site is escaping HTML on some older version release notes:

* http://www.python.org/download/releases/1.6/
* http://www.python.org/download/releases/2.0/
* http://www.python.org/download/releases/2.1/
* http://www.python.org/download/releases/2.1.[1-3]/ (2.1.1, 2.1.2, 2.1.3)
* http://www.python.org/download/releases/2.2/
* http://www.python.org/download/releases/2.2.[1-2]/
* http://www.python.org/download/releases/2.3/
* http://www.python.org/download/releases/2.3.[1-5]/

I was pointed here from the pydotorg-www list, but None of the components seem to fit with website maintenance.

----------
messages: 212531
nosy: nicktimko
priority: normal
severity: normal
status: open
title: HTML being escaped on some release pages
type: behavior

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

From report at bugs.python.org  Sun Mar  2 02:50:04 2014
From: report at bugs.python.org (Ryan Govostes)
Date: Sun, 02 Mar 2014 01:50:04 +0000
Subject: [New-bugs-announce] [issue20821] Should be able to break long
	numbers across lines
Message-ID: <1393725004.96.0.132470805093.issue20821@psf.upfronthosting.co.za>


New submission from Ryan Govostes:

I cannot find a way to break a long number across multiple lines, other than to write the number as a string, take advantage of string literal concatenation, and then convert the string to an integer.

I'd like to be able to write, for example,

N = 17976931348623159077293051907890247336179769789423065727343008115 \
    77326758055056206869853794492129829595855013875371640157101398586 \
    47833778606925583497541085196591615128057575940752635007475935288 \
    71082364994994077189561705436114947486504671101510156394068052754 \
    0071584560878577663743040086340742855278549092581

To support this, adjacent integer literals should be concatenated also.

I don't think this would introduce any backwards-compatibility issues.

My preference would be to require each literal be written with its prefix, e.g., '0xDEAD 0xBEEF'. It strikes me as poor style to mix different bases, e.g., '0xa 5'.

----------
components: Interpreter Core
messages: 212533
nosy: rgov
priority: normal
severity: normal
status: open
title: Should be able to break long numbers across lines
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  2 06:56:04 2014
From: report at bugs.python.org (Nemo Neminibus)
Date: Sun, 02 Mar 2014 05:56:04 +0000
Subject: [New-bugs-announce] [issue20822] WINhelp file loads Table of
	Contents, but not contents: "Navigation to webpage cancelled"
Message-ID: <1393739764.99.0.927427060131.issue20822@psf.upfronthosting.co.za>


New submission from Nemo Neminibus:

File: python334.chm
Downloads, md5sum correct.
MS help executable opens a page with Table of Contents, but also displays a box with following message: "Navigation to the webpage was canceled"
Clicking on any page icon in Table of Contents list produces no result.

----------
components: Windows
messages: 212535
nosy: Nemo.Neminibus
priority: normal
severity: normal
status: open
title: WINhelp file loads Table of Contents, but not contents: "Navigation to webpage cancelled"
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 09:46:06 2014
From: report at bugs.python.org (Peter Otten)
Date: Sun, 02 Mar 2014 08:46:06 +0000
Subject: [New-bugs-announce] [issue20823] Clarify copyreg.pickle()
	documentation
Message-ID: <1393749966.08.0.529137298895.issue20823@psf.upfronthosting.co.za>


New submission from Peter Otten:

The documentation for 

copyreg.pickle(type, function, constructor=None)

has the sentence

"TypeError will be raised if *object* is a class or *constructor* is not callable."

It's not clear to me what "object" refers to. I believe it refers to the first arg (called ob_type in 2.x) and classic classes which were handled with

def pickle(ob_type, pickle_function, constructor_ob=None):
    if type(ob_type) is _ClassType:
        raise TypeError("copy_reg is not intended for use with classes")

in 2.x If I'm right the above sentence should become.

"A TypeError will be raised if *constructor* is not callable."

in 3.x. If I'm wrong please think of way to express the intended meaning more clearly.

Another minor change: class C need not inherit from object explicitly in  3.x.

----------
assignee: docs at python
components: Documentation
messages: 212541
nosy: docs at python, peter.otten
priority: normal
severity: normal
status: open
title: Clarify copyreg.pickle() documentation
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar  2 14:01:16 2014
From: report at bugs.python.org (Alexandru Gheorghe)
Date: Sun, 02 Mar 2014 13:01:16 +0000
Subject: [New-bugs-announce] [issue20824] setup.py install doesn't parse
	spaces in path
Message-ID: <1393765276.38.0.208615952915.issue20824@psf.upfronthosting.co.za>


New submission from Alexandru Gheorghe:

When having spaces in the path which represents the root for the build on going, rpmbuild from bdist_rpm will fail:


----------------------------------------------------
+ python setup.py install -O1 --root=/home/lex/Development/4. Test/11. ARTA/build/src/rpm/BUILDROOT/efw-arta-3.0.1_0.test0-0.x86_64 --record=INSTALLED_FILES
invalid command name 'Test/11.'
error: Bad exit status from /var/tmp/rpm-tmp.cbEEZl (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.cbEEZl (%install)
error: command 'rpmbuild' failed with exit status 1
----------------------------------------------------

With this patch it will work:

--- bdist_rpm-BAK.py	2014-03-02 14:52:31.501744617 +0200
+++ bdist_rpm.py	2014-03-02 14:53:10.705746243 +0200
@@ -512,8 +512,8 @@
         # that we open and interpolate into the spec file, but the defaults
         # are just text that we drop in as-is.  Hmmm.
 
-        install_cmd = ('%s install -O1 --root=$RPM_BUILD_ROOT '
-                       '--record=INSTALLED_FILES') % def_setup_call
+        install_cmd = ('%s install -O1 --root="$RPM_BUILD_ROOT" '
+                       '--record="INSTALLED_FILES"') % def_setup_call
 
         script_options = [
             ('prep', 'prep_script', "%setup -n %{name}-%{unmangled_version}"),


but then another roadblock is hit:


+ cp -pr CHANGELOG /home/lex/Development/4. Test/11. ARTA/build/src/rpm/BUILDROOT/efw-safi-3.0.1_0.test0-0.x86_64/usr/share/doc/efw-arta-3.0.1_0.test0
cp: cannot stat `CHANGELOG': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.1tO2OV (%doc)
error: File not found: /home/lex/Development/4. Test/11. ARTA/build/src/rpm/BUILDROOT/efw-arta-3.0.1_0.test0-0.x86_64/usr/share/doc/efw-arta-3.0.1_0.test0


seems stat also needs quoted path:

lex at hemvi:~/Development/4. Test/11. ARTA/build$ stat --format="%a" /home/lex/Development/4. Test/11. ARTA/build/CHANGELOG ; echo $?
755
stat: cannot stat `Test/11.': No such file or directory
stat: cannot stat `ARTA/build/CHANGELOG': No such file or directory
1

lex at hemvi:~/Development/4. Test/11. ARTA/build$ stat --format="%a" "/home/lex/Development/4. Test/11. ARTA/build/CHANGELOG" ; echo $?
644
0


I guess all the calls need to be rewritten to take into account spaces in the path. This would be too laborious, thus perhaps we should warn in documentation packagers/developers not to use spaces in path when building?

----------
components: Distutils
messages: 212548
nosy: drunax
priority: normal
severity: normal
status: open
title: setup.py install doesn't parse spaces in path
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  2 14:18:19 2014
From: report at bugs.python.org (Michel Albert)
Date: Sun, 02 Mar 2014 13:18:19 +0000
Subject: [New-bugs-announce] [issue20825] containment test for "ip_network
	in ip_network"
Message-ID: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>


New submission from Michel Albert:

The ipaddress module always returns ``False`` when testing if a network is contained in another network. However, I feel this should be a valid test. No? Is there any reason why this is fixed to ``False``?

In case not, here's a patch which implements this test.

Note that by design, IP addresses networks can never overlap "half-way". In cases where this should return ``False``, you either have a network that lies completely "to the left", or completely "to the right". In the case it should return ``True`` the smaller network is always completely bounded by the larger network's network- and broadcast address.

I needed to change two containment tests as they were in conflict with this change. These tests were ``self.v6net not in self.v6net`` and ``self.v4net not in self.v4net``. The reason these two failed is that the new containment test checks the target range *including* broadcast and network address. So ``a in a`` always returns true.

This could be changed by excluding one of the two boundaries, and by that forcing the "containee" to be smaller than the "container". But it would make the check a bit more complex, as you would need to add an exception for the case that both are identical.

Backwards compatibility is a good question. Strictly put, this would break it. However, I can't think of any reason why anyone would expect ``a in a`` to be false in the case of IP-Addresses.

Just as a side-note, I currently work at our national network provider and am currently implementing a tool dealing with a lot of IP-Addresses. We have run into the need to test ``net in net`` a couple of times and ran into bugs because the stdlib returns ``False`` where you technically expect it to be ``True``.

----------
components: Library (Lib)
files: net-in-net.patch
keywords: patch
messages: 212550
nosy: exhuma, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: containment test for "ip_network in ip_network"
versions: Python 3.5
Added file: http://bugs.python.org/file34266/net-in-net.patch

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

From report at bugs.python.org  Sun Mar  2 15:39:00 2014
From: report at bugs.python.org (Michel Albert)
Date: Sun, 02 Mar 2014 14:39:00 +0000
Subject: [New-bugs-announce] [issue20826] Faster implementation to collapse
	consecutive ip-networks
Message-ID: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za>


New submission from Michel Albert:

This alternative implementation runs over the ``addresses`` collection only once, and "backtracks" only if necessary. Inspired by a "shift-reduce" approach.

Technically both are O(n), so the best case is always the same. But the old implementation runs over the *complete* list multiple times until it cannot make any more optimisations. The new implementation only repeats the optimisation on elements which require reconciliation.

Tests on a local machine have shown a considerable increase in speed on large collections of elements (iirc about twice as fast on average).

----------
components: Library (Lib)
files: faster-collapse-addresses.patch
keywords: patch
messages: 212553
nosy: exhuma, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: Faster implementation to collapse consecutive ip-networks
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file34267/faster-collapse-addresses.patch

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

From report at bugs.python.org  Sun Mar  2 16:05:24 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 02 Mar 2014 15:05:24 +0000
Subject: [New-bugs-announce] [issue20827] IDLE : Display function argument
	list in ClassBrowser
Message-ID: <1393772724.12.0.548840750027.issue20827@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

The proposed patch 
1.implements a TODO for ClassBrowser . it was (sic)show function argument list? (have to do pattern matching on source).my patch does not do pattern matching in the real sense of the phrase.it uses "imp" to import the module source and "inspect.getargspec" to get the function argument list.a new function called FormatArgumentList() is used to beautify and display only the relevant arguments.
in short,it displays the arguments for that function.previously, it was
def foo(...)
now it is,
def foo(bar1,bar2,*spam,**spam2,defaults=(5,))

2.Adds a human test dialog for ClassBrowser.

Currently there are no specific tests for ClassBrowser.
hence,i have also created test stubs for ClassBrowser.(ns:it is NOT present in this patch).
One way or another, will send in the patch which will add tests.(i'm waiting to know whether we go forward on 1 and 2).

----------
components: IDLE
files: classbrowser-improvments.patch
keywords: patch
messages: 212555
nosy: Todd.Rovito, sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE : Display function argument list in ClassBrowser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file34268/classbrowser-improvments.patch

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

From report at bugs.python.org  Sun Mar  2 16:10:47 2014
From: report at bugs.python.org (mike bayer)
Date: Sun, 02 Mar 2014 15:10:47 +0000
Subject: [New-bugs-announce] [issue20828] inspect.getargspec() returns wrong
	answer with	datetime.today.__call__()
Message-ID: <1393773047.92.0.816306226616.issue20828@psf.upfronthosting.co.za>


New submission from mike bayer:

this appears like it may be related to http://bugs.python.org/issue20786, at least in terms of inspect.getargspec() seems to be returning answers in 3.4 where it used to raise TypeError, however like in 20786 it's again returning the wrong answer.  I'm a little concerned that some change was made to allow inspection of lots of builtins that wasn't before, but the argument lists haven't been checked.

test case:

import inspect
import datetime

try:
    insp = inspect.getargspec(datetime.datetime.today.__call__)
except TypeError:
    pass
else:
    print(insp)
    assert insp == (["self"], "args", "kwargs", None)

    # claims to accept "args" and "kwargs", ok let's try...
    datetime.datetime.today.__call__(1, 2, foo='bar')

    # raises:
    # TypeError: today() takes no keyword arguments

----------
components: Library (Lib)
messages: 212556
nosy: zzzeek
priority: normal
severity: normal
status: open
title: inspect.getargspec() returns wrong answer with datetime.today.__call__()
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 18:29:35 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 02 Mar 2014 17:29:35 +0000
Subject: [New-bugs-announce] [issue20829] 3.4 cherry pick: c9861ec8754c Fix
	signatures for	dict.__delitem__ and property.__delete__
Message-ID: <1393781375.16.0.60912214559.issue20829@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

http://hg.python.org/cpython/rev/c9861ec8754c
changeset:   89461:c9861ec8754c
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Sun Mar 02 12:25:27 2014 -0500
summary:
  Issue #20786: Fix signatures for dict.__delitem__ and property.__delete__

----------
assignee: larry
keywords: 3.4regression
messages: 212565
nosy: larry, yselivanov
priority: release blocker
severity: normal
status: open
title: 3.4 cherry pick: c9861ec8754c Fix signatures for dict.__delitem__ and property.__delete__
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 19:18:04 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Mar 2014 18:18:04 +0000
Subject: [New-bugs-announce] [issue20830] 3.4 cherry-pick: 16f91d87ff39
Message-ID: <1393784284.55.0.532524988163.issue20830@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

New changeset 16f91d87ff39 by Martin v. L?wis in branch 'default':
Issue #20568: Fix typo in pip option.
http://hg.python.org/cpython/rev/16f91d87ff39

----------
messages: 212570
nosy: larry, loewis
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 16f91d87ff39
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 19:30:47 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Mar 2014 18:30:47 +0000
Subject: [New-bugs-announce] [issue20831] 3.4 cherry-pick: 7b3c40510a08
Message-ID: <1393785047.46.0.0103591323389.issue20831@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

New changeset 7b3c40510a08 by Martin v. L?wis in branch 'default':
Issue #20748: Uninstalling pip does not leave behind the pyc of
http://hg.python.org/cpython/rev/7b3c40510a08

----------
assignee: larry
messages: 212573
nosy: larry, loewis
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 7b3c40510a08
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 19:44:41 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Mar 2014 18:44:41 +0000
Subject: [New-bugs-announce] [issue20832] 3.4 cherry-pick: 9459f517d854
Message-ID: <1393785881.28.0.74461270782.issue20832@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

New changeset 9459f517d854 by Martin v. L?wis in branch 'default':
Issue #20465: Update Windows installer to SQLite 3.8.3.1.
http://hg.python.org/cpython/rev/9459f517d854

----------
assignee: larry
messages: 212576
nosy: larry, loewis
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 9459f517d854
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 20:14:14 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Mar 2014 19:14:14 +0000
Subject: [New-bugs-announce] [issue20833] scripts\pydocgui.pyw out of date
Message-ID: <1393787654.65.0.406806459442.issue20833@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

The script pydocgui.pyw uses pydoc.gui(), which no longer exists. Anybody removing the script also needs to remove it from msi.py (and possibly other places where it is still used).

----------
messages: 212579
nosy: loewis
priority: normal
severity: normal
status: open
title: scripts\pydocgui.pyw out of date

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

From report at bugs.python.org  Sun Mar  2 20:32:22 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Mar 2014 19:32:22 +0000
Subject: [New-bugs-announce] [issue20834] 3.4 cherry-pick: de81e0fe4905
Message-ID: <1393788742.46.0.574574677928.issue20834@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

New changeset de81e0fe4905 by Martin v. L?wis in branch 'default':
Issue #14512: Launch pydoc -b instead of pydocgui.pyw on Windows.
http://hg.python.org/cpython/rev/de81e0fe4905

----------
assignee: larry
messages: 212583
nosy: larry, loewis
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: de81e0fe4905
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  2 21:57:34 2014
From: report at bugs.python.org (gcx11)
Date: Sun, 02 Mar 2014 20:57:34 +0000
Subject: [New-bugs-announce] [issue20835] (9-(9%2)
Message-ID: <1393793854.12.0.0752069736174.issue20835@psf.upfronthosting.co.za>


New submission from gcx11:

Hello!
Is it error?
Write into console:
(9-(9%2)

----------
messages: 212589
nosy: gcx11
priority: normal
severity: normal
status: open
title: (9-(9%2)
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar  2 23:50:19 2014
From: report at bugs.python.org (Hans Polak)
Date: Sun, 02 Mar 2014 22:50:19 +0000
Subject: [New-bugs-announce] [issue20836] Pickle Nonetype
Message-ID: <1393800619.38.0.666577692495.issue20836@psf.upfronthosting.co.za>


New submission from Hans Polak:

This simple code works, but I have two 'import pickle' lines.

The none working code has one 'import pickle' outside the class definition. This raises a Nonetype error in the pickle module, in the __del__ method. I'd like to know why and I think it's a bug, or is it?

class Login():
    users = {}
    
    def __init__(self):
        try:
            with open('user.data','rb') as f:
                import pickle
                self.users = pickle.load(f)
#                print('init: {}'.format(self.users))
        except Exception:
            #'user.data' file doesn't exist
            pass

    def __del__(self):
        try:
            with open('user.data','wb') as f:
#                print('del: {}'.format(self.users))
#                print(type(self.users))
#                print(type(f))
                import pickle
                pickle.dump(self.users, f, pickle.HIGHEST_PROTOCOL)
        except Exception as e:
            print('__del__ Shit happened: {}'.format(e))

----------
assignee: docs at python
components: Documentation
messages: 212598
nosy: Hans.Polak, docs at python
priority: normal
severity: normal
status: open
title: Pickle Nonetype
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Mar  3 00:38:20 2014
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 02 Mar 2014 23:38:20 +0000
Subject: [New-bugs-announce] [issue20837] Ambiguity words in base64
	documentation
Message-ID: <1393803500.52.0.641070246037.issue20837@psf.upfronthosting.co.za>


New submission from INADA Naoki:

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

> The modern interface supports encoding and decoding ASCII byte string objects using all three alphabets.

What "all three alphabets" means?
I think it is about *altchars*. But the sentence is too ambiguous to translate it in Japanese.

----------
assignee: docs at python
components: Documentation
messages: 212604
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Ambiguity words in base64 documentation
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar  3 03:36:23 2014
From: report at bugs.python.org (Christian Clauss)
Date: Mon, 03 Mar 2014 02:36:23 +0000
Subject: [New-bugs-announce] [issue20838] Documents disagree about release
	state of Python 3.3.5
Message-ID: <1393814183.86.0.154129689303.issue20838@psf.upfronthosting.co.za>


New submission from Christian Clauss:

http://python.org/download/releases/3.3.5 says that 3.3.5rc1 is current but

http://docs.python.org/3.3/whatsnew/changelog.html says that 3.3.5rc2 is current and

http://legacy.python.org/dev/peps/pep-0398/#id5 says that 3.3.5 should have been released two days ago.

----------
assignee: docs at python
components: Documentation
messages: 212608
nosy: Christian.Clauss, docs at python
priority: normal
severity: normal
status: open
title: Documents disagree about release state of Python 3.3.5
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar  3 08:43:56 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 03 Mar 2014 07:43:56 +0000
Subject: [New-bugs-announce] [issue20839] pkgutil.get_loader throws
	deprecation warning due to	internal deprecation
Message-ID: <1393832636.13.0.907958415798.issue20839@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

pkgutil.get_loader calls
pkgutil.find_loader which calls
importlib.find_loader

The latter logs a deprecation warning about it being replaced by importlib.util.find_spec.

This is a regression in 3.4 as far as I can see.

----------
keywords: 3.4regression
messages: 212615
nosy: aronacher
priority: normal
severity: normal
status: open
title: pkgutil.get_loader throws deprecation warning due to internal deprecation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  3 10:05:48 2014
From: report at bugs.python.org (bsduni)
Date: Mon, 03 Mar 2014 09:05:48 +0000
Subject: [New-bugs-announce] [issue20840] AttributeError: 'module' object
	has no attribute	'ArgumentParser'
Message-ID: <1393837548.4.0.445191461545.issue20840@psf.upfronthosting.co.za>


New submission from bsduni:

Hi!

I have installed Python 2.7.6 fully (all the modules selected). I attempted run some Python codes that were developed by a past staff, and am stuck with an issue with argparse. 

For ease of explanation I am using the example given in this website at http://docs.python.org/2/howto/argparse.html.

When I create a simple program prog.py with codes below:

import argparse
parser = argparse.ArgumentParser()
parser.parse_args()

and execute with $ python prog.py, the following is the error message I receive:
Traceback (most recent call last):
  File "prog.py", line 2, in <module>
    parser = argparse.ArgumentParser()
AttributeError: 'module' object has no attribute 'ArgumentParser'

I also tried to add argparse additionally using pip install and the problem remains the same.

Would be grateful if someone could help to overcome this AttributeError.

----------
components: Extension Modules
messages: 212620
nosy: bsduni
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'ArgumentParser'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  3 11:05:08 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Mon, 03 Mar 2014 10:05:08 +0000
Subject: [New-bugs-announce] [issue20841] asyncio.StreamReader.readline()
	lack lines limit	optional parameter
Message-ID: <1393841108.46.0.21574549974.issue20841@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

This prevent using StreamReader as a normal file object in some circumstances (like http header parsing)

----------
components: Library (Lib)
messages: 212624
nosy: ajaborsk
priority: normal
severity: normal
status: open
title: asyncio.StreamReader.readline() lack lines limit optional parameter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  3 12:33:20 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 03 Mar 2014 11:33:20 +0000
Subject: [New-bugs-announce] [issue20842] pkgutil docs should reference
	glossary terms not PEP 302
Message-ID: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The pkgutil docs still point at PEP 302 when mentioning loaders, importers, etc. They should reference the glossary terms (:term:`loader`, etc) instead.

----------
assignee: docs at python
components: Documentation
messages: 212630
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: pkgutil docs should reference glossary terms not PEP 302
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  3 14:04:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Mar 2014 13:04:52 +0000
Subject: [New-bugs-announce] [issue20843] 3.4 cherry-pick: a9058b772807 fix
	tracemalloc doc
Message-ID: <1393851892.85.0.162516395458.issue20843@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Please pick a9058b772807 into Python 3.4 final: it fixes a typo in tracemalloc documentation (in the "Pretty Top" example).

Related issue: #20814.

----------
assignee: larry
messages: 212634
nosy: haypo, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: a9058b772807 fix tracemalloc doc
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  3 14:54:42 2014
From: report at bugs.python.org (Musashi Tamura)
Date: Mon, 03 Mar 2014 13:54:42 +0000
Subject: [New-bugs-announce] [issue20844] coding bug remains in 3.3.5rc2
Message-ID: <1393854882.06.0.561987523346.issue20844@psf.upfronthosting.co.za>


New submission from Musashi Tamura:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\bug>python
Python 3.3.5rc2 (v3.3.5rc2:ca5635efe090, Mar  2 2014, 18:18:29) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

C:\bug>python test2.py
  File "test2.py", line 1
SyntaxError: encoding problem: iso-8859-1

----------
components: Windows
files: test2.py
messages: 212637
nosy: miwa
priority: normal
severity: normal
status: open
title: coding bug remains in 3.3.5rc2
versions: Python 3.3
Added file: http://bugs.python.org/file34276/test2.py

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

From report at bugs.python.org  Mon Mar  3 19:14:53 2014
From: report at bugs.python.org (Michael JasonSmith)
Date: Mon, 03 Mar 2014 18:14:53 +0000
Subject: [New-bugs-announce] [issue20845] email.utils.formataddr encodes
	incorrectly
Message-ID: <1393870493.46.0.373030769514.issue20845@psf.upfronthosting.co.za>


New submission from Michael JasonSmith:

The email.utils.formataddr function is used to encode a name-address 2-tuple for use as an email message. If the name contains a non-ASCII character it needs to be encoded. This happens correctly in Python 3.3.2, but incorrectly in Python 2.7.5. Ideally Python 2 would acquire the Python 3 behaviour, as this should make porting easier.

In the following Python 3.3.2 example the name is encoded because of the non-ASCII ? character:
>>> import email.utils
>>> name = 'Me ?'
>>> addr = 'mpj17 at onlinegroups.net'
>>> email.utils.formataddr((name, addr))
'=?utf-8?b?TWUg4pii?= <mpj17 at onlinegroups.net>'

In Python 2.7.5 the same name is incorrectly left unaltered:
>>> import email.utils
>>> name = u'Me ?'
>>> addr = 'mpj17 at onlinegroups.net'
>>> email.utils.formataddr((name, addr))
u'Me \u2622 <mpj17 at onlinegroups.net>'

However, calling the email.header.Header.encode method works around this issue in Python 2:
>>> import email.utils
>>> import email.header
>>> name = u'Me ?'
>>> addr = 'mpj17 at onlinegroups.net'
>>> h = email.header.Header(name)
>>> email.utils.formataddr((h.encode(), addr))
'=?utf-8?b?TWUg4pii?= <mpj17 at onlinegroups.net>'

The example code immediately above also works in Python 3; it is the current work-around in GroupServer. However, ideally instances of Unicode objects passed to email.utils.formataddr will work the same in both Python 2 and Python 3.

----------
components: Library (Lib)
messages: 212648
nosy: Michael.JasonSmith
priority: normal
severity: normal
status: open
title: email.utils.formataddr encodes incorrectly
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Mar  3 20:08:37 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 03 Mar 2014 19:08:37 +0000
Subject: [New-bugs-announce] [issue20846] pip can fail on windows but gives
	success message
Message-ID: <1393873717.15.0.572598787495.issue20846@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

Trying to install pyttsx you get "Successfully installed pyttsx" despite the syntax errors and you can't actually do an import.

c:\Users\Mark\CrossCode>c:\Python34\Scripts\pip3.4.exe install pyttsx
Downloading/unpacking pyttsx
  Downloading pyttsx-1.1.tar.gz
  Running setup.py (path:C:\Users\Mark\AppData\Local\Temp\pip_build_Mark\pyttsx\setup.py) egg_info for package pyttsx

Installing collected packages: pyttsx
  Running setup.py install for pyttsx
      File "C:\Python34\Lib\site-packages\pyttsx\driver.py", line 105
        except Exception, e:
                        ^
    SyntaxError: invalid syntax

[other syntax errors snipped]

Successfully installed pyttsx
Cleaning up...

c:\Users\Mark\CrossCode>py -3.4
Python 3.4.0rc2 (v3.4.0rc2:a300712ed38c, Feb 23 2014, 10:49:04) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyttsx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\site-packages\pyttsx\__init__.py", line 18, in <module>
    from engine import Engine

Running 2to3 sorts this out.  Can this be done automatically by pip?  If not, can we please have this documented?

----------
messages: 212655
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: pip can fail on windows but gives success message
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  3 21:12:20 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Mar 2014 20:12:20 +0000
Subject: [New-bugs-announce] [issue20847] asyncio docs should call out that
	network logging is a	no-no
Message-ID: <1393877540.32.0.826428021059.issue20847@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The asyncio package uses the logging module. We should remind users that they should always configure their logs to go to a file on the local filesystem -- using any kind of network logging will block the event loop.

----------
assignee: haypo
messages: 212664
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: asyncio docs should call out that network logging is a no-no
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar  3 21:49:42 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Mar 2014 20:49:42 +0000
Subject: [New-bugs-announce] [issue20848] 3.4 cherry-pick: b637064cc696
	Improve enum subclass	behavior
Message-ID: <1393879782.25.0.979559826633.issue20848@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Two minor code changes addressing the "more pythonic" comments.  Major doc enhancement addressing the functional API.  Not sure about the markup as I can no longer create the docs on my system.

----------
assignee: larry
messages: 212670
nosy: ethan.furman, larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: b637064cc696  Improve enum subclass behavior
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  4 05:55:22 2014
From: report at bugs.python.org (Alexander Mohr)
Date: Tue, 04 Mar 2014 04:55:22 +0000
Subject: [New-bugs-announce] [issue20849] add exist_ok to shutil.copytree
Message-ID: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za>


New submission from Alexander Mohr:

it would be REALLY nice (and REALLY easy) to add a parameter: exist_ok and pass this to os.makedirs with the same parameter name so you can use copytree to append a src dir to an existing dst dir.

----------
components: Library (Lib)
messages: 212691
nosy: thehesiod
priority: normal
severity: normal
status: open
title: add exist_ok to shutil.copytree
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  4 11:42:48 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Mar 2014 10:42:48 +0000
Subject: [New-bugs-announce] [issue20850] 3.4 cherry pick: ea827c809765 fix
	pkgutil.find_loader
Message-ID: <1393929768.59.0.296328133341.issue20850@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Cherry pick request for the fix to issue 20839: http://hg.python.org/cpython/rev/ea827c809765

This updates pkgutil.find_loader to use importlib.util.find_spec, rather than the deprecated importlib.find_loader.

----------
keywords: 3.4regression
messages: 212710
nosy: brett.cannon, eric.snow, ncoghlan
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry pick: ea827c809765 fix pkgutil.find_loader
type: behavior

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

From report at bugs.python.org  Tue Mar  4 15:47:12 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 04 Mar 2014 14:47:12 +0000
Subject: [New-bugs-announce] [issue20851] Update devguide to cover testing
	from a tarball
Message-ID: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Nick Coghlan brought up the fact that with Larry Hastings doing periodic tarball dumps for the 3.4.0 release it would be good to make sure instructions on how to actually test from a tarball were in the devguide.

----------
components: Devguide
messages: 212722
nosy: brett.cannon, ezio.melotti
priority: normal
severity: normal
status: open
title: Update devguide to cover testing from a tarball
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  4 23:33:30 2014
From: report at bugs.python.org (Andrey Antsut)
Date: Tue, 04 Mar 2014 22:33:30 +0000
Subject: [New-bugs-announce] [issue20852] Embedding with zipped standard
	library is broken in	3.3.4 (Windows)
Message-ID: <1393972410.33.0.320365155079.issue20852@psf.upfronthosting.co.za>


New submission from Andrey Antsut:

When embedding Python into C++, Py_Initialize() crashes with following errors if the standard library (python33\lib) is in a zip archive (e.g. python33.zip):

Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

This seems to be specific to Python 3.3.4: works fine with 3.3.2 and 3.3.3, not tested with other versions. Tested only on Windows.

More details with code examples can be found here:

http://stackoverflow.com/questions/22174760/embedding-python-3-3-in-c-from-zipped-standard-library-on-windows-xp

----------
messages: 212744
nosy: Andrey.Antsut
priority: normal
severity: normal
status: open
title: Embedding with zipped standard library is broken in 3.3.4 (Windows)
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar  5 11:45:57 2014
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Wed, 05 Mar 2014 10:45:57 +0000
Subject: [New-bugs-announce] [issue20853] pdb "args" crashes when an arg is
	not printable
Message-ID: <1394016357.17.0.646134871451.issue20853@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

The "args" command in pdb crashes when an argument cannot be printed.
Fortunately, this is easy to fix.

For version 3.3.3:
In function Pdb.do_args (lib/pdb.py, line 1120)
Change line 1131
  self.message('%s = %r' % (name, dict[name]))
to
  try: r = repr(dict[name])
  except: r = "(Cannot print object)"
  self.message('%s = %s' % (name, r))

----------
components: Library (Lib)
messages: 212759
nosy: jneb
priority: normal
severity: normal
status: open
title: pdb "args" crashes when an arg is not printable
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Mar  5 17:03:30 2014
From: report at bugs.python.org (Allis Tauri)
Date: Wed, 05 Mar 2014 16:03:30 +0000
Subject: [New-bugs-announce] [issue20854] multiprocessing.managers.Server:
	problem with returning	proxy of registered object
Message-ID: <1394035410.32.0.813669524051.issue20854@psf.upfronthosting.co.za>


New submission from Allis Tauri:

1. I have a tree-like recursive class MyClass. It's method 'get_child(i)' returns an instanse of that same class.
2. I register this class with BaseManager as follows:

class MyManager(BaseManager): pass
MyManager.register('MyClass', MyClass, method_to_typeid={'get_child':'MyClass'})

3. When I call 'get_child' method of AutoProxy[MyClass] object, the exception is raised in the '__init__' method of MyClass: it is called with a single argument which is the instance of MyClass returned by 'get_child'. This happens in the following code of multiprocessing.managers.Server.create method:

373 def create(self, c, typeid, *args, **kwds):
...
382         if callable is None:
383             assert len(args) == 1 and not kwds
384             obj = args[0]
385         else:
386             obj = callable(*args, **kwds) <-This line raises the exception

This means that if ANY method registered with a Manager should return a proxy for a registered typeid, for which a callable is provided, it will fail, unless the callable is capable to handle such unexpected arguments.

----------
components: Library (Lib)
messages: 212763
nosy: allista
priority: normal
severity: normal
status: open
title: multiprocessing.managers.Server: problem with returning proxy of registered object
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Mar  5 23:50:10 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 Mar 2014 22:50:10 +0000
Subject: [New-bugs-announce] [issue20855] RFE: change bool(0.0) to evaluate
	as True
Message-ID: <1394059810.09.0.454278014303.issue20855@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

The rationale for making this change is that the current behaviour converts a stylistic problem in checking values against a sentinel via "bool(value)" instead of "value is not None" into a subtle data driven behavioural bug that only occurs exactly at 0x0.0p+0.

If someone wants to write the patch to deprecate this behaviour in Python 3.5 (reporting a deprecation warning whenever midnight is interpreted as False, perhaps suggesting the use of "is" or "is not" instead), and then actually change the behaviour in 3.6, I don't believe we should actively oppose them from doing so.

See also issue #13936.

----------
components: Interpreter Core
keywords: easy
messages: 212772
nosy: belopolsky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: RFE: change bool(0.0) to evaluate as True
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar  6 09:56:39 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 06 Mar 2014 08:56:39 +0000
Subject: [New-bugs-announce] [issue20856] bz2.peek always peeks all the
	remaining bytes ignoring n	argument
Message-ID: <1394096199.33.0.0844376758582.issue20856@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

# Bug demo
TEXT_LINES = [
    b'cutecat\n',
    b'promiscuousbonobo\n',
]
TEXT = b''.join(TEXT_LINES)
import bz2
filename = '/tmp/demo.bz2'
with open(filename, 'wb') as f:
    f.write(bz2.compress(TEXT))

with bz2.BZ2File(filename) as bz2f:
    pdata = bz2f.peek(n=7)
    print(pdata)

It outputs b'cutecat\npromiscuousbonobo\n', not b'cutecat'.

Here is the patch to fix the bug.

----------
components: Library (Lib)
files: use_n_argument_in_peek_bz2.patch
keywords: patch
messages: 212796
nosy: nadeem.vawda, vajrasky
priority: normal
severity: normal
status: open
title: bz2.peek always peeks all the remaining bytes ignoring n argument
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34291/use_n_argument_in_peek_bz2.patch

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

From report at bugs.python.org  Thu Mar  6 17:20:35 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Mar 2014 16:20:35 +0000
Subject: [New-bugs-announce] [issue20857] ipaddress "is_private" and
	"is_global" are	insufficiently documented and is_global
	probably has a bug
Message-ID: <1394122835.87.0.0307404764075.issue20857@psf.upfronthosting.co.za>


New submission from R. David Murray:

The 'is_private' and 'is_global' properties refer to the iana registries, but the terms 'private network' and 'public network' do no appear in the registry documentation.  There is no way to know what these methods are going to return other than examining the source code.

In particular, without looking at the source code a best-guess interpretation of the documentation would lead one to expect that is_private would return true only for RFC1918 addresses, since that is the one place the term 'private' appears.  Similarly, the naive interpretation of is_global would be that it would return False for all addresses listed in the ipv4 registry *except* 192.88.99.0/24, which is the only one whose global routing flag is True in the table.

I would submit that the fact that the latter is not true is a bug.

It is really not at all clear what 'is_private' means (see also issue 17400, which introduced is_global), so I am completely unclear how to rewrite the documentation to fully specify it, other than to list out the address ranges that it considers private.

----------
messages: 212812
nosy: ncoghlan, pmoody, r.david.murray
priority: normal
severity: normal
status: open
title: ipaddress "is_private" and "is_global" are insufficiently documented and is_global probably has a bug
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar  6 19:37:38 2014
From: report at bugs.python.org (Brian Kearns)
Date: Thu, 06 Mar 2014 18:37:38 +0000
Subject: [New-bugs-announce] [issue20858] Enhancements/fixes to pure-python
	datetime module
Message-ID: <1394131058.9.0.404670194335.issue20858@psf.upfronthosting.co.za>


New submission from Brian Kearns:

This patch brings the pure-python datetime more in-line with the C module. We have been running these modifications in PyPy2 stdlib for more than a year with no issue.

Includes:
- General PEP8/cleanups
- Better testing of argument types passed to constructors
- Removal of duplicate operations (in some paths values were checked twice for validity)
- Optimization of timedelta creation (brings it from 8-9usec to ~6 usec on CPython 3.3 on local machine)
- Enhancements/bug fixes in tests

----------
files: datetime-py34.patch
keywords: patch
messages: 212832
nosy: bdkearns
priority: normal
severity: normal
status: open
title: Enhancements/fixes to pure-python datetime module
type: behavior
Added file: http://bugs.python.org/file34293/datetime-py34.patch

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

From report at bugs.python.org  Thu Mar  6 19:48:00 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Mar 2014 18:48:00 +0000
Subject: [New-bugs-announce] [issue20859] Context of documentation for
	conditional expressions
Message-ID: <1394131680.82.0.565875959506.issue20859@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The documentation for conditional expressions (c_exps)
http://docs.python.org/3/reference/expressions.html#conditional-expressions
and the later sections on evaluation order and operator precedence have 3 inconsistencies with each other. I believe the latter (the 'context' of the title) were not properly adjusted with the addition of the former to match the exceptional behavior of c_exps.


1. Associativily-grouping: I believe the grammar line
  conditional_expression ::=  or_test ["if" or_test "else" expression]
makes c_exps group right to left, as in C.  Something like
  conditional_expression ::=  expression ["if" or_test "else" or_test]
would have the opposite effect. The following examples posted on python-list by 'candide' illustrate and verify.

>>> 0 if 1 else 0 if 0 else 1
0
>>> 0 if 1 else (0 if 0 else 1)
0
>>> (0 if 1 else 0) if 0 else 1
1

This sentence in the Operator Precedence section
http://docs.python.org/3/reference/expressions.html#operator-precedence

"Operators in the same box group left to right (except for comparisons, including tests, which all have the same precedence and chain from left to right ? see section Comparisons ? and exponentiation, which groups from right to left)."

should have the last part revised to

"and exponentiation and conditional expressions, which group from right to left".

Perhaps a sentence and example should also be added to the C-E section also.


2. Evaluation Order: Condition expressions evaluate the middle subexpession first, making 
"Python evaluates expressions from left to right."
http://docs.python.org/3/reference/expressions.html#evaluation-order
wrong as is, without noting the exception of c_exps.

I think "Except for conditional expressions, python evaluates expressions from left to right." gives too much weight to the exception.

"Python evaluates expressions from left to right (except for conditional expressions)." is a bit more awkward, but, appropriately, makes the exception more like a footnote.


3. Precedence: "Conditional expressions (sometimes called a ?ternary operator?) have the lowest priority of all Python operations." versus the table, which lists lambda as lowest priority.  Should 'except for lambda' be added to the end of the sentence?  Should the top two lines of the table be reversed?  I do not know which is true, or perhaps neither. I get the impression from the grammar and the discussion in PEP308 that there are sort-of at the same level. Raymond, I add you as a PEP author particularly for this question.

----------
messages: 212835
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Context of documentation for conditional expressions
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  6 19:53:27 2014
From: report at bugs.python.org (Warren Turkal)
Date: Thu, 06 Mar 2014 18:53:27 +0000
Subject: [New-bugs-announce] [issue20860] ipaddress network subnets() method
	should return object	with __getitem__
Message-ID: <1394132007.23.0.255663589608.issue20860@psf.upfronthosting.co.za>


New submission from Warren Turkal:

It would be very useful to be able to not only iterate through subnets, but also index a subnet. For example, I would really like to be able to do the following:

>>> import ipaddress as ipa
>>> net = ipa.ip_network('10.0.0.0/8')
>>> print(net.subnets(prefixlen_diff=2)[2])
"10.128.0.0/10"

As it stands now, I have to write something like the following to get the same result:

>>> import ipaddress as ipa
>>> net = ipa.ip_network('10.0.0.0/8')
>>> subnets = net.subnets(prefixlen_diff=2)
>>> for _ in xrange(0, 3):
...     subnet = subnets.next()
...
>>> print(subnet)
"10.128.0.0/10"


The simplest way I can come up with to add this feature is by wrapping the current body of that method in a nested generator function, creating an instance of that generator, adding a appropriate __getitem__ method to that object, and returning that object instead of the bare generator. What do you all think of that?

Also, it'd be nice to see this added to the ipaddress module on pypi for python 2.x also. :)

----------
components: Library (Lib)
messages: 212836
nosy: Warren.Turkal
priority: normal
severity: normal
status: open
title: ipaddress network subnets() method should return object with __getitem__
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar  7 00:46:53 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 06 Mar 2014 23:46:53 +0000
Subject: [New-bugs-announce] [issue20861] datetime argument handling
	inconsistent; should accept logical integers, not coercible values
Message-ID: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Per my comments on #20858, datetime's argument handling is inconsistent. By using the 'i' format code, non-integer types are being coerced to int, even as other equivalent non-integer types are accepted (sometimes in a lossy fashion).

Example:

    >>> from decimal import Decimal as d
    >>> from datetime import datetime
    >>> datetime(d("2000.5"), 1, 2)
    datetime.datetime(2000, 1, 2, 0, 0)
    >>> datetime(2000.0, 1, 2)
    Traceback (most recent call last):
       ...
    TypeError: integer argument expected, got float

Note that the latter case would not lose data by coercion to int, yet it raises an error anyway, while the former is losing data silently.

Similar discrepancies would occur between passing a str argument vs. a user-defined string type (the latter would need to implement __int__ to get the coercion that str gets through a special case in the int constructor, making int(x) and x.__int__() subtly different, since there is no str.__int__).

For consistency, it seems like we should primarily be using typecode 'n', not 'i', so logical integers are properly converted, while anything else (including float/Decimal/str/user-string) must be cast by the caller to avoid the risk of silent data loss.

I suspect tons of modules make similar "mistakes" in the interface (until today, I didn't realize PyLong_AsLong, and by extension, the 'i' type code would coerce non-integral types). I'm looking to start contributing to Python, and at least for time being I think I'll keep the bug targeted.

I haven't tested, but I suspect this bug is in all versions of Python. Clearly it's not a bug or security issue worth a backport prior to 3.4 though.

I'd happily create and submit a patch if this is a desired fix; I'd appreciate any pointers on how to get started (to date, all my Python C extension development has been for organization internal modules).

----------
components: Extension Modules, Library (Lib)
messages: 212853
nosy: ShadowRanger
priority: normal
severity: normal
status: open
title: datetime argument handling inconsistent; should accept logical integers, not coercible values
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  7 07:25:23 2014
From: report at bugs.python.org (Romil Agrawal)
Date: Fri, 07 Mar 2014 06:25:23 +0000
Subject: [New-bugs-announce] [issue20862] Problems running python 3.3
Message-ID: <1394173523.99.0.589731163218.issue20862@psf.upfronthosting.co.za>


New submission from Romil Agrawal:

I just installed python 3.3.4 on os mavericks. When I changed the python excutable in wing ide and restarted it, a dialog box appeared that said the interpreter for python 3.3 might not exist. Can anyone help regarding this?

----------
components: Library (Lib)
messages: 212861
nosy: romilagr06
priority: normal
severity: normal
status: open
title: Problems running python 3.3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  7 09:00:48 2014
From: report at bugs.python.org (Chester Burns)
Date: Fri, 07 Mar 2014 08:00:48 +0000
Subject: [New-bugs-announce] [issue20863] IDLE not opening
Message-ID: <1394179248.04.0.683216794284.issue20863@psf.upfronthosting.co.za>


New submission from Chester Burns:

I installed python 3.3.3 and it was working fine for the moment, however the next day when I tried to open it, the idle app showed on the dock for a second and straight away quit.  I am using a macbook pro on osx version 10.9.1

----------
messages: 212863
nosy: chester.burns
priority: normal
severity: normal
status: open
title: IDLE not opening
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  7 13:46:12 2014
From: report at bugs.python.org (Martin Thurau)
Date: Fri, 07 Mar 2014 12:46:12 +0000
Subject: [New-bugs-announce] [issue20864] getattr does not work well with
	descriptor
Message-ID: <1394196372.69.0.347625630871.issue20864@psf.upfronthosting.co.za>


New submission from Martin Thurau:

If you have a descriptor (in my case it was an SQLAlchemy column) on an instance and this descriptor returns None for a call to __get__ then getattr with a given default value, will not return the default, but None.

I have no knowledge on the implementation details of getattr but I guess the logic is something like this:
- getattr looks at the given object and sees that the attribute in question is not None (since it is the descriptor object)
- getattr returns the descriptor
- the descriptors __get__ method is called
- __get__ return None

Maybe it should be more like this:
- getattr looks at the given object and sees that the attribute in question is not None (since it is the descriptor object)
- getattr sees that the attribute has __get__
- getattr calls __get__ method and looks if the return value is None

I'm not sure if this is really a bug but it's highly confusing and somewhat un-pythonic. I really should not care of an attribute of an object is a value or a descriptor. This is especially true since this problem also applies to @property. Effectively this means that if you call getattr you have *know* if the name in question is a property or not and one can't simply swap out an objects value for a property without risking to break calling code.

If this is actually *not* a bug, we should at least update the documentation to getattr, to mention this fact. Because currently it states that "getattr(x, 'foobar') is equivalent to x.foobar" which is obviously not true.

----------
components: Interpreter Core
files: python_descriptor_bug.py
messages: 212876
nosy: Martin.Thurau
priority: normal
severity: normal
status: open
title: getattr does not work well with descriptor
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34299/python_descriptor_bug.py

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

From report at bugs.python.org  Fri Mar  7 16:38:04 2014
From: report at bugs.python.org (NexusRAwesome1995 .)
Date: Fri, 07 Mar 2014 15:38:04 +0000
Subject: [New-bugs-announce] [issue20865] A run has overwrite my code save
Message-ID: <1394206684.22.0.214888473452.issue20865@psf.upfronthosting.co.za>


New submission from NexusRAwesome1995 .:

I am making a text based aventure game for my assignment and a friends test run has somehow saved over the entire code file and now im using an earlier version of the code. I have 0 idea if there is anyway to look at the code using the IDLE and i need to do it to see how i fixed the fatal error left behind by a friend. My on computer backup has not worked and the backup on my memory stick also has the same problem.
If anyone knows of a way to get my code back i will be grateful as this is my 1st project and i'm not that used to the syntax

----------
messages: 212885
nosy: NexusRAwesome1995..
priority: normal
severity: normal
status: open
title: A run has overwrite my code save
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  7 19:22:29 2014
From: report at bugs.python.org (Hanno Boeck)
Date: Fri, 07 Mar 2014 18:22:29 +0000
Subject: [New-bugs-announce] [issue20866] segfailt with os.popen and SIGPIPE
Message-ID: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za>


New submission from Hanno Boeck:

I experience a segmentation fault with python 2.7 (both 2.7.5 and 2.7.6 tested on Ubuntu and Gentoo) when a large file is piped, the pipe is passed to os.popen and the process sends a SIGPIPE signal.

To create an easy to reproduce testcase grep can be used. See example attached.

To test first create a dummy file containing zeros, around 1 megabyte is enough:
for i in `seq 1 100000`; do echo "0123456789" >> dummy.txt; done

Then pipe it to the script attached like this:
cat dummy.txt | python2 minimal.py

Result is a Segmentation fault. The same code doesn't segfault with python 3.

----------
components: Interpreter Core
files: sigpipe_crash.py
messages: 212897
nosy: hanno
priority: normal
severity: normal
status: open
title: segfailt with os.popen and SIGPIPE
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file34301/sigpipe_crash.py

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

From report at bugs.python.org  Fri Mar  7 22:14:30 2014
From: report at bugs.python.org (Claudio Canepa)
Date: Fri, 07 Mar 2014 21:14:30 +0000
Subject: [New-bugs-announce] [issue20867] fix_import in 2to3 adds spurious
	relative import	(windows)
Message-ID: <1394226870.23.0.999785649945.issue20867@psf.upfronthosting.co.za>


New submission from Claudio Canepa:

0. windows specific

i. In the pyglet library, written for py2 and officially running in 3 after the stock installation that does the 2to3 conversion

ii. Omitting files which are unimportant for the issue, the package dir looks as

pyglet
   image
      codecs
         pil.py
(each package - subpackage has a proper __init__.py)

iii. In the pyglet repository checkout, near the begining of pil.py theres the block

try:
    import Image
except ImportError:
    from PIL import Image

That PIL refers to the pillow package (fork of PIL, and yes it its the recommended import line in pillow's doc)

iv. after installing with
   cd working_copy
   py -3.3 setup.py install

the same block looks as

try:
    import Image
except ImportError:
    from .PIL import Image

which is wrong, and precludes pyglet to import Pillow.

v. I tracked the problem to (CPython) LIB/lib2to3/fixes/fix_import.py

In  method FixImport.probably_a_local_import the heuristic is
"if 'import name' is seen, look if theres a sibling file with that name, and if exists assume it needs to be a relative import"

The problem is that the implementation uses os.path.exists to check sibling existence, but that has false positive cases due to Windows case-insensivity for filenames.

Module names are case-sensitive.

So, the import machinery would never match PIL to pil, but the code in fix_import.py will merrily match.

vi. To verify the issue I patched fix_import.py, deleted the old pyglet install under 3, reinstalled: Now the block is unmolested.
Attached the diff with the fixed code (diff obtained with the GNU C utils)

vii. This was seen in python 3.3.1 , on Windows xp sp3.
I see in the cpython repo the same issue will happen in the default branch (the offending lines in fix_import.py are unchanged, so I assume 3.4 will show the same defect)

viii. as a reference, the original issue in pyglet can be found at
http://code.google.com/p/pyglet/issues/detail?id=707

ix. Anyone can suggest a workaround, a change in the problematic block in pyglet that would tell 2to3 to not change the block ?

----------
components: 2to3 (2.x to 3.x conversion tool)
files: fix_import.diff
keywords: patch
messages: 212899
nosy: ccanepa
priority: normal
severity: normal
status: open
title: fix_import in 2to3 adds spurious relative import (windows)
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file34302/fix_import.diff

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

From report at bugs.python.org  Fri Mar  7 23:57:22 2014
From: report at bugs.python.org (Steap)
Date: Fri, 07 Mar 2014 22:57:22 +0000
Subject: [New-bugs-announce] [issue20868] Lib/test/test_socket.py: skip
	testGetServBy if	/etc/services is not found
Message-ID: <1394233042.66.0.931126122313.issue20868@psf.upfronthosting.co.za>


New submission from Steap:

In Lib/test/test_socket.py, testGetServBy calls socket.getservbyname(), which needs /etc/services (see "man getservbyname"). If this file is not found, the test fails instead of being skipped.

The attached patch was written against the latest revision of the Mercurial repository. It might be worth applying it for every currently supported version of Python.

----------
files: skip_testGetServBy.patch
keywords: patch
messages: 212910
nosy: Steap
priority: normal
severity: normal
status: open
title: Lib/test/test_socket.py: skip testGetServBy if /etc/services is not found
Added file: http://bugs.python.org/file34304/skip_testGetServBy.patch

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

From report at bugs.python.org  Sat Mar  8 10:54:45 2014
From: report at bugs.python.org (Domenico Mustara)
Date: Sat, 08 Mar 2014 09:54:45 +0000
Subject: [New-bugs-announce] [issue20869] IDLE lib error in IOBinding.py
Message-ID: <1394272485.83.0.657701795003.issue20869@psf.upfronthosting.co.za>


New submission from Domenico Mustara:

Not a new issue, many Python users have already written about this error. In line 128 of IOBinding.py file, please change 'str = str.split("\n", 2)[:2]" to "lst = str.split("\n", 2)[:2]". This error prevents IDLE from working correctly when a .py file is loaded. I use IDLE on Ubuntu 13.10. At every new update, I need to manually modify IOBinding.py file in /usr/lib/python2.7/idlelib directory. Please fix it. Thanks

----------
components: IDLE
messages: 212925
nosy: Domenico.Mustara
priority: normal
severity: normal
status: open
title: IDLE lib error in IOBinding.py
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar  8 11:19:11 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Sat, 08 Mar 2014 10:19:11 +0000
Subject: [New-bugs-announce] [issue20870] how to import json file in mongodb
	using pymongo
Message-ID: <1394273951.75.0.167518280392.issue20870@psf.upfronthosting.co.za>


Changes by Pramod Jadhav <jadhavpamu2020 at gmail.com>:


----------
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: how to import json file in mongodb using pymongo
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar  8 14:49:12 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Sat, 08 Mar 2014 13:49:12 +0000
Subject: [New-bugs-announce] [issue20871] Testing: Push email/policy.py line
	coverage to 100%.
Message-ID: <1394286552.45.0.827702132835.issue20871@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

Accorcing to coveragepy there was only one line missing for full line coverage in Lib/email/policy.py so I added an test to cover it.

It checks that the function email.policy.EmailPolicy.header raises an ValueError if the second parameter includes newlines or linefeeds. This is the documented behavior of the function, so testing it seems to be a good idea.

----------
components: Tests
files: policyTest.patch
keywords: patch
messages: 212929
nosy: zvyn
priority: normal
severity: normal
status: open
title: Testing: Push email/policy.py line coverage to 100%.
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34306/policyTest.patch

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

From report at bugs.python.org  Sat Mar  8 17:57:59 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Mar 2014 16:57:59 +0000
Subject: [New-bugs-announce] [issue20872] dbm/gdbm/ndbm close methods are
	not document
Message-ID: <1394297879.28.0.882591650164.issue20872@psf.upfronthosting.co.za>


New submission from R. David Murray:

We just added context manager support to dbm to close the object automatically, but the 'close' method that gets called is not documented for any of the dbm objects.  Since it is part of the public API (it is shown in the example), I think it should be.

----------
messages: 212935
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: dbm/gdbm/ndbm close methods are not document
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  9 03:53:08 2014
From: report at bugs.python.org (=?utf-8?b?bcOpbG9tYW5l?=)
Date: Sun, 09 Mar 2014 02:53:08 +0000
Subject: [New-bugs-announce] [issue20873] ID
Message-ID: <1394333588.1.0.130592480571.issue20873@psf.upfronthosting.co.za>


Changes by m?lomane <knorman008 at gmail.com>:


----------
nosy: m?lomane
priority: normal
severity: normal
status: open
title: ID
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar  9 16:45:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Mar 2014 15:45:32 +0000
Subject: [New-bugs-announce] [issue20874] Tutorial section on starting
	python is out of date
Message-ID: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za>


New submission from R. David Murray:

http://docs.python.org/dev/tutorial/interpreter.html does not talk about the fact that completion and history are now enabled by default on systems that support readline, and instead says that the command line editing features are "usually not very sophisticated".  This is no longer true.

----------
assignee: docs at python
components: Documentation
messages: 212962
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Tutorial section on starting python is out of date
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  9 20:40:15 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 09 Mar 2014 19:40:15 +0000
Subject: [New-bugs-announce] [issue20875] Typo in gzip._PaddedFile
Message-ID: <1394394015.57.0.429435192094.issue20875@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

There's a typo in gzip._PaddedFile.prepend. Here's a snippet to reproduce it.

>>> import gzip
>>> x=gzip.open("a.gz")
>>> x.fileobj.prepend()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/gzip.py", line 99, in prepend
    self._buffer = self._buffer[read:] + prepend
NameError: name 'read' is not defined
>>>

----------
components: Library (Lib)
messages: 212978
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Typo in gzip._PaddedFile
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  9 20:58:36 2014
From: report at bugs.python.org (Jey Narasimhan)
Date: Sun, 09 Mar 2014 19:58:36 +0000
Subject: [New-bugs-announce] [issue20876] python -m test test_pathlib fails
Message-ID: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>


New submission from Jey Narasimhan:

I was using Ubuntu 11.04 and Python 2.7.1+. The dev code was checkout from hg clone http://hg.python.org/cpython. 

Here is the full traceback of the crash report:

== CPython 3.4.0rc1+ (default:3ae2cd85a908, Mar 9 2014, 10:38:52) [GCC 4.5.2]
==   Linux-2.6.38-8-generic-x86_64-with-debian-squeeze-sid little-endian
==   hash algorithm: siphash24 64bit
==   /net/files/home/jey/cpython/build/test_python_8784
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, isolated=0)
[1/1] test_pathlib
test_parse_parts (test.test_pathlib.NTFlavourTest) ... ok
test_parse_parts_common (test.test_pathlib.NTFlavourTest) ... ok
test_splitroot (test.test_pathlib.NTFlavourTest) ... ok
test_chmod (test.test_pathlib.PathTest) ... ok
test_complex_symlinks_absolute (test.test_pathlib.PathTest) ... ok
test_complex_symlinks_relative (test.test_pathlib.PathTest) ... ok
test_complex_symlinks_relative_dot_dot (test.test_pathlib.PathTest) ... ok
test_concrete_class (test.test_pathlib.PathTest) ... ok
test_cwd (test.test_pathlib.PathTest) ... ok
test_empty_path (test.test_pathlib.PathTest) ... ok
test_exists (test.test_pathlib.PathTest) ... ok
test_glob_common (test.test_pathlib.PathTest) ... ok
test_glob_dotdot (test.test_pathlib.PathTest) ... ok
test_group (test.test_pathlib.PathTest) ... ok
test_is_block_device_false (test.test_pathlib.PathTest) ... ok
test_is_char_device_false (test.test_pathlib.PathTest) ... ok
test_is_char_device_true (test.test_pathlib.PathTest) ... ok
test_is_dir (test.test_pathlib.PathTest) ... ok
test_is_fifo_false (test.test_pathlib.PathTest) ... ok
test_is_fifo_true (test.test_pathlib.PathTest) ... ok
test_is_file (test.test_pathlib.PathTest) ... ok
test_is_socket_false (test.test_pathlib.PathTest) ... ok
test_is_socket_true (test.test_pathlib.PathTest) ... ok
test_is_symlink (test.test_pathlib.PathTest) ... ok
test_iterdir (test.test_pathlib.PathTest) ... ok
test_iterdir_nodir (test.test_pathlib.PathTest) ... ok
test_iterdir_symlink (test.test_pathlib.PathTest) ... ok
test_lstat (test.test_pathlib.PathTest) ... ok
test_lstat_nosymlink (test.test_pathlib.PathTest) ... ok
test_mkdir (test.test_pathlib.PathTest) ... ok
test_mkdir_parents (test.test_pathlib.PathTest) ... ok
test_open_common (test.test_pathlib.PathTest) ... ok
test_owner (test.test_pathlib.PathTest) ... ok
test_parts_interning (test.test_pathlib.PathTest) ... ok
test_pickling_common (test.test_pathlib.PathTest) ... ok
test_rename (test.test_pathlib.PathTest) ... ok
test_replace (test.test_pathlib.PathTest) ... ok
test_resolve_common (test.test_pathlib.PathTest) ... ok
test_resolve_dot (test.test_pathlib.PathTest) ... ok
test_rglob_common (test.test_pathlib.PathTest) ... ok
test_rmdir (test.test_pathlib.PathTest) ... ok
test_stat (test.test_pathlib.PathTest) ... ok
test_symlink_to (test.test_pathlib.PathTest) ... ok
test_touch_common (test.test_pathlib.PathTest) ... ok
test_touch_nochange (test.test_pathlib.PathTest) ... ok
test_unlink (test.test_pathlib.PathTest) ... ok
test_unsupported_flavour (test.test_pathlib.PathTest) ... ok
test_with (test.test_pathlib.PathTest) ... ok
test_parse_parts (test.test_pathlib.PosixFlavourTest) ... ok
test_parse_parts_common (test.test_pathlib.PosixFlavourTest) ... ok
test_splitroot (test.test_pathlib.PosixFlavourTest) ... ok
test_anchor_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_as_bytes_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_as_posix_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_as_uri (test.test_pathlib.PosixPathAsPureTest) ... ok
test_as_uri_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_as_uri_non_ascii (test.test_pathlib.PosixPathAsPureTest) ... ok
test_constructor_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_div (test.test_pathlib.PosixPathAsPureTest) ... ok
test_div_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_drive_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_eq (test.test_pathlib.PosixPathAsPureTest) ... ok
test_eq_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_equivalences (test.test_pathlib.PosixPathAsPureTest) ... ok
test_is_absolute (test.test_pathlib.PosixPathAsPureTest) ... ok
test_is_reserved (test.test_pathlib.PosixPathAsPureTest) ... ok
test_join (test.test_pathlib.PosixPathAsPureTest) ... ok
test_join_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_match (test.test_pathlib.PosixPathAsPureTest) ... ok
test_match_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_name_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_ordering_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_parent_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_parents_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_parts_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_pickling_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_relative_to_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_repr_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_root (test.test_pathlib.PosixPathAsPureTest) ... ok
test_root_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_stem_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_str_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_suffix_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_suffixes_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_with_name_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_with_suffix_common (test.test_pathlib.PosixPathAsPureTest) ... ok
test_chmod (test.test_pathlib.PosixPathTest) ... ok
test_complex_symlinks_absolute (test.test_pathlib.PosixPathTest) ... ok
test_complex_symlinks_relative (test.test_pathlib.PosixPathTest) ... ok
test_complex_symlinks_relative_dot_dot (test.test_pathlib.PosixPathTest) ... ok
test_cwd (test.test_pathlib.PosixPathTest) ... ok
test_empty_path (test.test_pathlib.PosixPathTest) ... ok
test_exists (test.test_pathlib.PosixPathTest) ... ok
test_glob (test.test_pathlib.PosixPathTest) ... ERROR
test_glob_common (test.test_pathlib.PosixPathTest) ... ERROR
test_glob_dotdot (test.test_pathlib.PosixPathTest) ... ERROR
test_group (test.test_pathlib.PosixPathTest) ... ERROR
test_is_block_device_false (test.test_pathlib.PosixPathTest) ... ERROR
test_is_char_device_false (test.test_pathlib.PosixPathTest) ... ERROR
test_is_char_device_true (test.test_pathlib.PosixPathTest) ... ERROR
test_is_dir (test.test_pathlib.PosixPathTest) ... ERROR
test_is_fifo_false (test.test_pathlib.PosixPathTest) ... ERROR
test_is_fifo_true (test.test_pathlib.PosixPathTest) ... ERROR
test_is_file (test.test_pathlib.PosixPathTest) ... ERROR
test_is_socket_false (test.test_pathlib.PosixPathTest) ... ERROR
test_is_socket_true (test.test_pathlib.PosixPathTest) ... ERROR
test_is_symlink (test.test_pathlib.PosixPathTest) ... ERROR
test_iterdir (test.test_pathlib.PosixPathTest) ... ERROR
test_iterdir_nodir (test.test_pathlib.PosixPathTest) ... ERROR
test_iterdir_symlink (test.test_pathlib.PosixPathTest) ... ERROR
test_lstat (test.test_pathlib.PosixPathTest) ... ERROR
test_lstat_nosymlink (test.test_pathlib.PosixPathTest) ... ERROR
test_mkdir (test.test_pathlib.PosixPathTest) ... ERROR
test_mkdir_parents (test.test_pathlib.PosixPathTest) ... ERROR
test_open_common (test.test_pathlib.PosixPathTest) ... ERROR
test_open_mode (test.test_pathlib.PosixPathTest) ... ERROR
test_owner (test.test_pathlib.PosixPathTest) ... ERROR
test_parts_interning (test.test_pathlib.PosixPathTest) ... ERROR
test_pickling_common (test.test_pathlib.PosixPathTest) ... ERROR
test_rename (test.test_pathlib.PosixPathTest) ... ERROR
test_replace (test.test_pathlib.PosixPathTest) ... ERROR
test_resolve_common (test.test_pathlib.PosixPathTest) ... ERROR
test_resolve_dot (test.test_pathlib.PosixPathTest) ... ERROR
test_resolve_loop (test.test_pathlib.PosixPathTest) ... ERROR
test_rglob (test.test_pathlib.PosixPathTest) ... ERROR
test_rglob_common (test.test_pathlib.PosixPathTest) ... ERROR
test_rmdir (test.test_pathlib.PosixPathTest) ... ERROR
test_stat (test.test_pathlib.PosixPathTest) ... ERROR
test_symlink_to (test.test_pathlib.PosixPathTest) ... ERROR
test_touch_common (test.test_pathlib.PosixPathTest) ... ERROR
test_touch_mode (test.test_pathlib.PosixPathTest) ... ERROR
test_touch_nochange (test.test_pathlib.PosixPathTest) ... ERROR
test_unlink (test.test_pathlib.PosixPathTest) ... ERROR
test_with (test.test_pathlib.PosixPathTest) ... ERROR
test_anchor_common (test.test_pathlib.PurePathTest) ... ok
test_as_bytes_common (test.test_pathlib.PurePathTest) ... ok
test_as_posix_common (test.test_pathlib.PurePathTest) ... ok
test_as_uri_common (test.test_pathlib.PurePathTest) ... ok
test_concrete_class (test.test_pathlib.PurePathTest) ... ok
test_constructor_common (test.test_pathlib.PurePathTest) ... ok
test_different_flavours_unequal (test.test_pathlib.PurePathTest) ... ok
test_different_flavours_unordered (test.test_pathlib.PurePathTest) ... ok
test_div_common (test.test_pathlib.PurePathTest) ... ok
test_drive_common (test.test_pathlib.PurePathTest) ... ok
test_eq_common (test.test_pathlib.PurePathTest) ... ok
test_equivalences (test.test_pathlib.PurePathTest) ... ok
test_join_common (test.test_pathlib.PurePathTest) ... ok
test_match_common (test.test_pathlib.PurePathTest) ... ok
test_name_common (test.test_pathlib.PurePathTest) ... ok
test_ordering_common (test.test_pathlib.PurePathTest) ... ok
test_parent_common (test.test_pathlib.PurePathTest) ... ok
test_parents_common (test.test_pathlib.PurePathTest) ... ok
test_parts_common (test.test_pathlib.PurePathTest) ... ok
test_pickling_common (test.test_pathlib.PurePathTest) ... ok
test_relative_to_common (test.test_pathlib.PurePathTest) ... ok
test_repr_common (test.test_pathlib.PurePathTest) ... ok
test_root_common (test.test_pathlib.PurePathTest) ... ok
test_stem_common (test.test_pathlib.PurePathTest) ... ok
test_str_common (test.test_pathlib.PurePathTest) ... ok
test_suffix_common (test.test_pathlib.PurePathTest) ... ok
test_suffixes_common (test.test_pathlib.PurePathTest) ... ok
test_with_name_common (test.test_pathlib.PurePathTest) ... ok
test_with_suffix_common (test.test_pathlib.PurePathTest) ... ok
test_anchor_common (test.test_pathlib.PurePosixPathTest) ... ok
test_as_bytes_common (test.test_pathlib.PurePosixPathTest) ... ok
test_as_posix_common (test.test_pathlib.PurePosixPathTest) ... ok
test_as_uri (test.test_pathlib.PurePosixPathTest) ... ok
test_as_uri_common (test.test_pathlib.PurePosixPathTest) ... ok
test_as_uri_non_ascii (test.test_pathlib.PurePosixPathTest) ... ok
test_constructor_common (test.test_pathlib.PurePosixPathTest) ... ok
test_div (test.test_pathlib.PurePosixPathTest) ... ok
test_div_common (test.test_pathlib.PurePosixPathTest) ... ok
test_drive_common (test.test_pathlib.PurePosixPathTest) ... ok
test_eq (test.test_pathlib.PurePosixPathTest) ... ok
test_eq_common (test.test_pathlib.PurePosixPathTest) ... ok
test_equivalences (test.test_pathlib.PurePosixPathTest) ... ok
test_is_absolute (test.test_pathlib.PurePosixPathTest) ... ok
test_is_reserved (test.test_pathlib.PurePosixPathTest) ... ok
test_join (test.test_pathlib.PurePosixPathTest) ... ok
test_join_common (test.test_pathlib.PurePosixPathTest) ... ok
test_match (test.test_pathlib.PurePosixPathTest) ... ok
test_match_common (test.test_pathlib.PurePosixPathTest) ... ok
test_name_common (test.test_pathlib.PurePosixPathTest) ... ok
test_ordering_common (test.test_pathlib.PurePosixPathTest) ... ok
test_parent_common (test.test_pathlib.PurePosixPathTest) ... ok
test_parents_common (test.test_pathlib.PurePosixPathTest) ... ok
test_parts_common (test.test_pathlib.PurePosixPathTest) ... ok
test_pickling_common (test.test_pathlib.PurePosixPathTest) ... ok
test_relative_to_common (test.test_pathlib.PurePosixPathTest) ... ok
test_repr_common (test.test_pathlib.PurePosixPathTest) ... ok
test_root (test.test_pathlib.PurePosixPathTest) ... ok
test_root_common (test.test_pathlib.PurePosixPathTest) ... ok
test_stem_common (test.test_pathlib.PurePosixPathTest) ... ok
test_str_common (test.test_pathlib.PurePosixPathTest) ... ok
test_suffix_common (test.test_pathlib.PurePosixPathTest) ... ok
test_suffixes_common (test.test_pathlib.PurePosixPathTest) ... ok
test_with_name_common (test.test_pathlib.PurePosixPathTest) ... ok
test_with_suffix_common (test.test_pathlib.PurePosixPathTest) ... ok
test_anchor (test.test_pathlib.PureWindowsPathTest) ... ok
test_anchor_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_as_bytes_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_as_posix_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_as_uri (test.test_pathlib.PureWindowsPathTest) ... ok
test_as_uri_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_constructor_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_div (test.test_pathlib.PureWindowsPathTest) ... ok
test_div_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_drive (test.test_pathlib.PureWindowsPathTest) ... ok
test_drive_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_eq (test.test_pathlib.PureWindowsPathTest) ... ok
test_eq_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_equivalences (test.test_pathlib.PureWindowsPathTest) ... ok
test_is_absolute (test.test_pathlib.PureWindowsPathTest) ... ok
test_is_reserved (test.test_pathlib.PureWindowsPathTest) ... ok
test_join (test.test_pathlib.PureWindowsPathTest) ... ok
test_join_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_match_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_name (test.test_pathlib.PureWindowsPathTest) ... ok
test_name_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_ordering_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_parent (test.test_pathlib.PureWindowsPathTest) ... ok
test_parent_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_parents (test.test_pathlib.PureWindowsPathTest) ... ok
test_parents_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_parts (test.test_pathlib.PureWindowsPathTest) ... ok
test_parts_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_pickling_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_relative_to (test.test_pathlib.PureWindowsPathTest) ... ok
test_relative_to_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_repr_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_root (test.test_pathlib.PureWindowsPathTest) ... ok
test_root_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_stem (test.test_pathlib.PureWindowsPathTest) ... ok
test_stem_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_str (test.test_pathlib.PureWindowsPathTest) ... ok
test_str_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_suffix (test.test_pathlib.PureWindowsPathTest) ... ok
test_suffix_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_suffixes (test.test_pathlib.PureWindowsPathTest) ... ok
test_suffixes_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_with_name (test.test_pathlib.PureWindowsPathTest) ... ok
test_with_name_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_with_suffix (test.test_pathlib.PureWindowsPathTest) ... ok
test_with_suffix_common (test.test_pathlib.PureWindowsPathTest) ... ok
test_anchor (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_anchor_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_as_bytes_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_as_posix_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_as_uri (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_as_uri_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_constructor_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_div (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_div_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_drive (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_drive_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_eq (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_eq_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_equivalences (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_is_absolute (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_is_reserved (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_join (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_join_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_match_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_name (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_name_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_ordering_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parent (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parent_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parents (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parents_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parts (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_parts_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_pickling_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_relative_to (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_relative_to_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_repr_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_root (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_root_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_stem (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_stem_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_str (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_str_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_suffix (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_suffix_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_suffixes (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_suffixes_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_with_name (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_with_name_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_with_suffix (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_with_suffix_common (test.test_pathlib.WindowsPathAsPureTest) ... skipped 'test requires a Windows-compatible system'
test_chmod (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_complex_symlinks_absolute (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_complex_symlinks_relative (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_complex_symlinks_relative_dot_dot (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_cwd (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_empty_path (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_exists (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_glob (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_glob_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_glob_dotdot (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_group (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_block_device_false (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_char_device_false (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_char_device_true (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_dir (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_fifo_false (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_fifo_true (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_file (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_socket_false (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_socket_true (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_is_symlink (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_iterdir (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_iterdir_nodir (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_iterdir_symlink (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_lstat (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_lstat_nosymlink (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_mkdir (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_mkdir_parents (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_open_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_owner (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_parts_interning (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_pickling_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_rename (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_replace (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_resolve_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_resolve_dot (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_rglob (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_rglob_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_rmdir (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_stat (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_symlink_to (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_touch_common (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_touch_nochange (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_unlink (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'
test_with (test.test_pathlib.WindowsPathTest) ... skipped 'test requires a Windows-compatible system'

======================================================================
ERROR: test_glob (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 463, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 421, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 419, in _rmtree_safe_fd
    os.unlink(name, dir_fd=topfd)
OSError: [Errno 16] Device or resource busy: '.nfs0000000001e5f7650000a673'

======================================================================
ERROR: test_glob_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_glob_dotdot (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_group (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_block_device_false (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_char_device_false (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_char_device_true (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_dir (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_fifo_false (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_fifo_true (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_file (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_socket_false (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_socket_true (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_is_symlink (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_iterdir (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_iterdir_nodir (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_iterdir_symlink (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_lstat (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_lstat_nosymlink (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_mkdir (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_mkdir_parents (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_open_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_open_mode (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_owner (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_parts_interning (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_pickling_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_rename (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_replace (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_resolve_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_resolve_dot (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_resolve_loop (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_rglob (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_rglob_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_rmdir (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_stat (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_symlink_to (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_touch_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_touch_mode (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_touch_nochange (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_unlink (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

======================================================================
ERROR: test_with (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/test_pathlib.py", line 1172, in setUp
    os.mkdir(BASE)
FileExistsError: [Errno 17] File exists: '/net/files/home/jey/cpython/build/test_python_8784/@test_8784_tmp'

----------------------------------------------------------------------
Ran 335 tests in 26.297s

FAILED (errors=41, skipped=91)
'test_pathlib' left behind directory '@test_8784_tmp'
1 test failed:
    test_pathlib
test test_pathlib crashed -- Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1278, in runtest_inner
    test_runner()
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1277, in <lambda>
    test_runner = lambda: support.run_unittest(tests)
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 1719, in run_unittest
    _run_suite(suite)
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 1694, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1281, in runtest_inner
    test_time = time.time() - start_time
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1245, in __exit__
    restore(original)
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1203, in restore_support_TESTFN
    shutil.rmtree(support.TESTFN)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 463, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 421, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 419, in _rmtree_safe_fd
    os.unlink(name, dir_fd=topfd)
OSError: [Errno 16] Device or resource busy: '.nfs0000000001e5f7650000a673'

'test_pathlib' left behind directory '@test_8784_tmp' and it couldn't be removed: [Errno 16] Device or resource busy: '.nfs0000000001e5f7650000a673'
Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 824, in temp_dir
    yield path
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 873, in temp_cwd
    yield cwd_dir
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 843, in main
    sys.exit(len(bad) > 0 or interrupted)
SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/net/files/home/jey/cpython/Lib/runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "/net/files/home/jey/cpython/Lib/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/net/files/home/jey/cpython/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/net/files/home/jey/cpython/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/net/files/home/jey/cpython/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 873, in temp_cwd
    yield cwd_dir
  File "/net/files/home/jey/cpython/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/net/files/home/jey/cpython/Lib/test/support/__init__.py", line 827, in temp_dir
    shutil.rmtree(path)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 463, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 401, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 421, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/net/files/home/jey/cpython/Lib/shutil.py", line 419, in _rmtree_safe_fd
    os.unlink(name, dir_fd=topfd)
OSError: [Errno 16] Device or resource busy: '.nfs0000000001e5f7650000a673'

----------
components: Tests
messages: 212982
nosy: Jey.Narasimhan
priority: normal
severity: normal
status: open
title: python -m test test_pathlib fails
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 10 02:01:52 2014
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 10 Mar 2014 01:01:52 +0000
Subject: [New-bugs-announce] [issue20877] test_grammar: assertEquals is
	deprecated
Message-ID: <1394413312.55.0.274378818571.issue20877@psf.upfronthosting.co.za>


New submission from Westley Mart?nez:

Use of assertEquals in test_grammar is deprecated.  I've included a patch  to change it to assertEqual.

----------
files: test_grammar.deprecation.diff
keywords: patch
messages: 213001
nosy: westley.martinez
priority: normal
severity: normal
status: open
title: test_grammar: assertEquals is deprecated
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34323/test_grammar.deprecation.diff

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

From report at bugs.python.org  Mon Mar 10 10:08:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Mar 2014 09:08:52 +0000
Subject: [New-bugs-announce] [issue20878] Windows: uninstall Python 3.4rc3
	after downgrade pip	leaves files in c:\python34
Message-ID: <1394442532.04.0.103973025918.issue20878@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I installed Python 3.4rc3 on Windows 7, I downgraded pip (from 1.5.3) to 1.5.3 and then I uninstalled Python 3.4rc3. Some files of pip and setuptools remaing in C:\Python34, is it expected?

C:\Python34\Scripts:

easy_install-3.4.exe
easy_install.exe
pip.exe
pip3.4.exe
pip3.exe

C:\Python34\Lib\site-packages:

easy_install.py
pip\
pip-1.5.3.dist-info\
pkg_resources.py
setuptools\
setuptools-2.1.dist-info\
_markerlib\
__pycache__\

----------
messages: 213017
nosy: haypo, larry, loewis
priority: normal
severity: normal
status: open
title: Windows: uninstall Python 3.4rc3 after downgrade pip leaves files in c:\python34

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

From report at bugs.python.org  Mon Mar 10 10:35:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Mar 2014 09:35:27 +0000
Subject: [New-bugs-announce] [issue20879] base64 module of Python 3.4 uses
	920 kB of memory
Message-ID: <1394444127.84.0.57737725761.issue20879@psf.upfronthosting.co.za>


New submission from STINNER Victor:

According to tracemalloc, "import base64" allocates 920.6 kB of memory. The 3 top locations are:

Lib/base64.py:414: size=420 KiB, count=7226, average=59 B
    _b85chars2 = [(a + b) for a in _b85chars for b in _b85chars]
Lib/base64.py:306: size=420 KiB, count=7226, average=59 B
    _a85chars2 = [(a + b) for a in _a85chars for b in _a85chars]
Lib/base64.py:142: size=59.8 KiB, count=1025, average=60 B
    _b32tab2 = [a + b for a in _b32tab for b in _b32tab]

Compare it to Python 3.3: base64 of Python 3.3 only allocates 10.3 kB. (I installed tracemalloc manually on Python 3.3 to get this number.)

I suggest to initialized these precomputed tables to None, and compute them at the first call to b32encode() / b85encode() / a85encode().

The new Base65 and Ascii85 codecs were added by the issue #17618.

_b32tab2 comes from changeset (1b5ef05d6ced) of issue #17812: "quadratic complexity of base64.b32encode(). Optimize base64.b32encode() and base64.b32decode() (speed up to 3x)." So 3.3 branch is also affected (for the base32 table).

----------
files: base64_mem.py
messages: 213018
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: base64 module of Python 3.4 uses 920 kB of memory
type: performance
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34325/base64_mem.py

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

From report at bugs.python.org  Mon Mar 10 10:43:05 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 10 Mar 2014 09:43:05 +0000
Subject: [New-bugs-announce] [issue20880] Windows installation problem with
	3.3.5
Message-ID: <1394444585.36.0.114345740007.issue20880@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

The upgrade from 3.3.4 to 3.3.5 has removed py[w].exe from c:\windows.  Tim Golden has given a possible explanation here https://mail.python.org/pipermail/python-list/2014-March/668674.html.

----------
components: Installation, Windows
messages: 213019
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: Windows installation problem with 3.3.5
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 10 15:32:03 2014
From: report at bugs.python.org (Adolph Atkins)
Date: Mon, 10 Mar 2014 14:32:03 +0000
Subject: [New-bugs-announce] [issue20881] Can't install pip-1.5.4,
	ez_setup.py
Message-ID: <1394461923.99.0.421734917699.issue20881@psf.upfronthosting.co.za>


New submission from Adolph Atkins:

In Windows 7 64 bits,I can't install pip-1.5.4, nor ez_setup.py.

----------
messages: 213034
nosy: Adolph.Atkins
priority: normal
severity: normal
status: open
title: Can't install pip-1.5.4,  ez_setup.py
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 10 16:24:58 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Mar 2014 15:24:58 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue20882=5D_Link_to_OpenHatch_?=
 =?utf-8?q?=E2=80=9Cgetting_started=E2=80=9D_page_from_devguide?=
Message-ID: <1394465098.6.0.0841488663317.issue20882@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

The OpenHatch project created this page for would-be GSoC/OPW participants: https://openhatch.org/wiki/Contributing_to_Python (it?s also useful for anyone wanting to contribute).

It contains platform-specific advice to install an IRC client and navigate using the command line, links to a Mercurial tutorial, recommends to join core-mentorship, and then defers to the devguide.

Nick Coghlan and IIRC R. David Murray suggested we link to that page from the devguide.  I think it makes sense, as we don?t want to include everything in it.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 213038
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Link to OpenHatch ?getting started? page from devguide
type: enhancement
versions: 3rd party

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

From report at bugs.python.org  Mon Mar 10 16:33:40 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Mon, 10 Mar 2014 15:33:40 +0000
Subject: [New-bugs-announce] [issue20883] Windows 'for current user'
	installation - 32/64-bit	registrations overwrite each other
Message-ID: <1394465620.39.0.363262899281.issue20883@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

When running the Python Windows installer 'for all users', the 32-bit installation and the 64-bit installation each gets a separate registration in the Windows registry. E.g. under:

  HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4

and:

  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.4

However, when running the installer 'for the current user only', the 32-bit and the 64-bit installation both use the same Windows registry key:

  HKEY_CURRENT_USER\Software\Python\PythonCore\3.4

Note that a 64-bit installation does not automatically uninstall a previous 32-bit installation in either case, or vice versa.

As I understand it, whichever installation you use, you should be able to run a specific Python interpreter using the py.exe runner, as in:

  py.exe -3.4
  py.exe -3.4-32

As it stands now - both of those run the same interpreter when they have been installed 'for the current user only', although when running
'py.exe -3.4-32' the runner will make an extra check and reject running the Python executable if the 64-bit version was installed last.

So:
1. If you install the 64-bit version first and then the 32-bit version, both 'py.exe -3.4' & 'py.exe -3.4-32' run the 32-bit executable.
2. If you install the 32-bit version first and then the 64-bit version, 'py.exe -3.4' runs the 64-bit version, and 'py.exe -3.4-32' exits with an error.

----------
components: Installation, Windows
messages: 213045
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: Windows 'for current user' installation - 32/64-bit registrations overwrite each other
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 10 17:13:50 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Mon, 10 Mar 2014 16:13:50 +0000
Subject: [New-bugs-announce] [issue20884] importlib/__init__.py can not be
	loaded without __file__	- breaks cxFreeze
Message-ID: <1394468030.15.0.192227739072.issue20884@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

Python 3.4 introduced a change to Lib/importlib/__init__.py that added the following code to it:

> else:
>     # importlib._bootstrap is the built-in import, ensure we don't create
>     # a second copy of the module.
>     _bootstrap.__name__ = 'importlib._bootstrap'
>     _bootstrap.__package__ = 'importlib'
>     _bootstrap.__file__ = __file__.replace('__init__.py', '_bootstrap.py')
>     sys.modules['importlib._bootstrap'] = _bootstrap

When attempting to use cxFreeze on a project, using Python 3.4. we ran into a problem with '__file__' identifier not being defined.

I believe this is a bug since the code expects the module loaded from importlib/__init__.py to always have a __file__ identifier set.


Python 3.4.0rc3 documentation explicitly states:

> __file__ is optional. If set, this attribute?s value must be a
> string. The import system may opt to leave __file__ unset if it
> has no semantic meaning (e.g. a module loaded from a database).

  and:

> Ultimately, the loader is what makes use of __file__ and/or
> __cached__.


A possible fix would be to skip setting the _bootstrap.__file__ attribute if the current module does not have a __file__ attribute set.


I hope this can be resolved before the 3.4 final release or it will not be possible to use cxFreeze with Python 3.4 without additional workarounds in cxFreeze.

Best regards,
  Jurko Gospodneti?

----------
components: Interpreter Core, Library (Lib)
messages: 213047
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 10 19:35:55 2014
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 10 Mar 2014 18:35:55 +0000
Subject: [New-bugs-announce] [issue20885] Little Endian PowerPC64 Linux
Message-ID: <1394476555.87.0.433973059487.issue20885@psf.upfronthosting.co.za>


New submission from David Edelsohn:

PowerLinux is shifting to Little Endian with a new ABI (ELFv2). Upstream libffi includes support for the new ABI. What is the recommended method to merge support into CPython? Will CPython update the base libffi or _ctypes/libffi.diff should be updated?

----------
components: ctypes
messages: 213063
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: Little Endian PowerPC64 Linux
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 10 21:30:35 2014
From: report at bugs.python.org (Sworddragon)
Date: Mon, 10 Mar 2014 20:30:35 +0000
Subject: [New-bugs-announce] [issue20886] Disabling logging to
	~/.python_history is not simple	enough
Message-ID: <1394483435.54.0.13789888009.issue20886@psf.upfronthosting.co.za>


New submission from Sworddragon:

I have noticed that since Python 3.4 the interactive mode does log all commands to ~/.python_history. This caused me to switch into "normal user mode" and look for a solution. With Google I have found the related entry in the documentation:

On systems that support readline, this module will also import and configure the rlcompleter module, if Python is started in interactive mode and without the -S option. The default behavior is enable tab-completion and to use ~/.python_history as the history save file. To disable it, delete (or override) the sys.__interactivehook__ attribute in your sitecustomize or usercustomize module or your PYTHONSTARTUP file.


On my system PYTHONSTARTUP is empty and if I would still pretending that I would be a normal user I would now get in panic. I think either the documentation needs an enhancement or disabling logging should be more simplified. For example the shell controls this with the HISTFILESIZE environment variable. Maybe Python can use for this case an environment variable too that the user can store in his ~/.bashrc.

----------
components: Library (Lib)
messages: 213079
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Disabling logging to ~/.python_history is not simple enough
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 10 22:11:04 2014
From: report at bugs.python.org (mattip)
Date: Mon, 10 Mar 2014 21:11:04 +0000
Subject: [New-bugs-announce] [issue20887] stdlib compatibility with pypy,
	test_zipfile.py
Message-ID: <1394485864.85.0.338262339301.issue20887@psf.upfronthosting.co.za>


New submission from mattip:

Files must be explicitly closed on pypy, and switch to use test_support.rmtree which tries harder on Windows.

only test_zipfile.py is patched.

----------
components: Tests
files: zipfile_patch
messages: 213086
nosy: mattip
priority: normal
severity: normal
status: open
title: stdlib compatibility with pypy, test_zipfile.py
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34343/zipfile_patch

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

From report at bugs.python.org  Tue Mar 11 03:33:56 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Mar 2014 02:33:56 +0000
Subject: [New-bugs-announce] [issue20888] tracemalloc: add getline() method
	to Traceback and Frame
Message-ID: <1394505236.1.0.090046168003.issue20888@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Is it too late in Python 3.4 release process to add a new method to classes of the tracemalloc module?

Here is a patch which adds unit tests and uses the new method in the documentation.

Example before:

    Top 10 lines
    #1: collections/__init__.py:368: 291.9 KiB
    #2: Lib/doctest.py:1291: 200.2 KiB
    #3: unittest/case.py:571: 160.3 KiB
    #4: Lib/abc.py:133: 99.8 KiB
    #5: urllib/parse.py:476: 71.8 KiB
    #6: <string>:5: 62.7 KiB
    #7: Lib/base64.py:140: 59.8 KiB
    #8: Lib/_weakrefset.py:37: 51.8 KiB
    #9: collections/__init__.py:362: 50.6 KiB
    #10: test/test_site.py:56: 48.0 KiB
    7496 other: 4161.9 KiB
    Total allocated size: 5258.8 KiB

Example after:

    Top 10 lines
    #1: Lib/base64.py:414: 419.8 KiB
        _b85chars2 = [(a + b) for a in _b85chars for b in _b85chars]
    #2: Lib/base64.py:306: 419.8 KiB
        _a85chars2 = [(a + b) for a in _a85chars for b in _a85chars]
    #3: collections/__init__.py:368: 293.6 KiB
        exec(class_definition, namespace)
    #4: Lib/abc.py:133: 115.2 KiB
        cls = super().__new__(mcls, name, bases, namespace)
    #5: unittest/case.py:574: 103.1 KiB
        testMethod()
    #6: Lib/linecache.py:127: 95.4 KiB
        lines = fp.readlines()
    #7: urllib/parse.py:476: 71.8 KiB
        for a in _hexdig for b in _hexdig}
    #8: <string>:5: 62.0 KiB
    #9: Lib/_weakrefset.py:37: 60.0 KiB
        self.data = set()
    #10: Lib/base64.py:142: 59.8 KiB
        _b32tab2 = [a + b for a in _b32tab for b in _b32tab]
    6220 other: 3602.8 KiB
    Total allocated size: 5303.1 KiB

The getline() is convinient.

Sorry for being late, but the need of the new method came when I started to work again on tracemalloc to prepare my conference for Pycon US.

----------
files: tracemalloc_getline.patch
keywords: patch
messages: 213113
nosy: haypo, larry
priority: normal
severity: normal
status: open
title: tracemalloc: add getline() method to Traceback and Frame
versions: Python 3.4
Added file: http://bugs.python.org/file34349/tracemalloc_getline.patch

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

From report at bugs.python.org  Tue Mar 11 06:19:55 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Tue, 11 Mar 2014 05:19:55 +0000
Subject: [New-bugs-announce] [issue20889] asyncio.docs : asyncio.Condition
	acquire/release/locked	method undocumented
Message-ID: <1394515195.95.0.980364058865.issue20889@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

While the asyncio.Condition.acquire(), release() an locked() methods work as expected (on the underlying Lock), they are not mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 213117
nosy: ajaborsk, docs at python
priority: normal
severity: normal
status: open
title: asyncio.docs : asyncio.Condition acquire/release/locked method undocumented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 11 13:20:25 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Mar 2014 12:20:25 +0000
Subject: [New-bugs-announce] [issue20890] Miscellaneous PEP 101 additions
Message-ID: <1394540425.3.0.905657835354.issue20890@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Spawned from a core-mentorship thread about possibly outdated branch names in dev guide examples.

These are a few places that use real branch names in examples, and need to be kept current to make things easier for new contributors:

http://docs.python.org/devguide/committing.html#multiple-clones-approach
http://docs.python.org/devguide/setup.html#getting-the-source-code
http://docs.python.org/devguide/devcycle.html#summary

Another couple of items:

- one early one (before actually making the release) to check that the latest released version of pip has been bundled into CPython (that's supposed to happen when pip is released, but it's worth double checking)

- there's a missing entry for the RM confirming they have the go ahead from the Mac Expect before proceeding with a release

----------
messages: 213143
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: Miscellaneous PEP 101 additions

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

From report at bugs.python.org  Tue Mar 11 19:40:13 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Mar 2014 18:40:13 +0000
Subject: [New-bugs-announce] [issue20891] PyGILState_Ensure on non-Python
	thread causes fatal error
Message-ID: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za>


New submission from Steve Dower:

In Python 3.4rc3, calling PyGILState_Ensure() from a thread that was not created by Python and without any calls to PyEval_InitThreads() will cause a fatal exit:

Fatal Python error: take_gil: NULL tstate

I believe this was added in http://hg.python.org/cpython/rev/dc4e805ec68a. The attached file has a minimal repro (for Windows, sorry, but someone familiar with low-level *nix threading APIs should be able to translate it easily).

Basically, the sequence looks like this:

1. main() calls Py_Initialize()
2. main() starts new C-level thread
3. main() calls Py_BEGIN_ALLOW_THREADS and waits for the new thread
4. New thread calls PyGILState_Ensure()
5. PyGILState_Ensure() sees that there is no thread state and calls PyEval_InitThreads() (this is what changed in the linked changeset)
6. PyEval_InitThreads() creates the GIL
7. PyEval_InitThreads() calls take_gil(PyThreadState_GET()) (this is what aborts - there is still no thread state)
8. (expected) PyGILState_Ensure() calls PyThreadState_New() and PyEval_RestoreThread().

The attached repro has two workarounds (commented out). The first is to call PyThreadState_New()/PyEval_RestoreThread() from the new thread, and the second is to call PyEval_InitThreads() from the main thread.

The latter is inappropriate for my use, since I am writing a debugger that can inject itself into a running CPython process - there is no way to require that PyEval_InitThreads() has been called and I can't reliably inject it onto the main thread. The first workaround is okay, but I'd rather not have to special-case 3.4 by rewriting PyGILState_Ensure() so that I can safely call PyGILState_Ensure().

----------
components: Extension Modules
files: test.c
messages: 213160
nosy: haypo, pitrou, steve.dower
priority: normal
severity: normal
status: open
title: PyGILState_Ensure on non-Python thread causes fatal error
versions: Python 3.4
Added file: http://bugs.python.org/file34358/test.c

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

From report at bugs.python.org  Tue Mar 11 19:57:23 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Tue, 11 Mar 2014 18:57:23 +0000
Subject: [New-bugs-announce] [issue20892] Typo in howto/pyporting.rst
Message-ID: <1394564243.9.0.819925259163.issue20892@psf.upfronthosting.co.za>


New submission from Auke Willem Oosterhoff:

Somewere around the paragraph 'Projects to Consider'[1]:
"...level library for suppoting Python 2 &...".

Obviously this should be: "...level library for supporting Python 2 &...".

[1]:http://docs.python.org/3.4/howto/pyporting.html#projects-to-consider

----------
assignee: docs at python
components: Documentation
messages: 213162
nosy: OrangeTux, docs at python
priority: normal
severity: normal
status: open
title: Typo in howto/pyporting.rst
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 12 01:29:02 2014
From: report at bugs.python.org (Greg Harris)
Date: Wed, 12 Mar 2014 00:29:02 +0000
Subject: [New-bugs-announce] [issue20893] ctypes crash during PyFinalize
	when librt used
Message-ID: <1394584142.34.0.276929311413.issue20893@psf.upfronthosting.co.za>


New submission from Greg Harris:

When interacting with librt via a ctypes.Structure object I can reliably cause the python interpreter to crash during Py_Finalize *after* all of my code has executed.  It appears to only happen on structures that have been passed to the mq_getattributes call in librt.  Below is the output of GDB showing the crash with python2.7-dbg:

(gdb) run show_ctypes_bug.py 
Starting program: /usr/bin/python2.7-dbg show_ctypes_bug.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Starting example
Creating queue
Loading attributes
Cleaning up
Completed example
Debug memory block at address p=0xb7ab5c28: API 'o'
    80 bytes originally requested
    The 3 pad bytes at p-3 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0xb7ab5c78 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x00 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0x00 *** OUCH
        at tail+3: 0x00 *** OUCH
    The block was made by call #0 to debug malloc/realloc.
    Data at p: 00 00 00 00 b8 dd ad b7 ... 00 00 00 00 00 00 00 00
Fatal Python error: bad trailing pad byte

Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) where
#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb7be11df in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb7be4825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0x0817566a in Py_FatalError (msg=0x820a3a3 "bad trailing pad byte") at ../Python/pythonrun.c:1677
#4  0x080c2fab in _PyObject_DebugCheckAddressApi (api=111 'o', p=0xb7ab5c28) at ../Objects/obmalloc.c:1591
#5  0x080c2c8d in _PyObject_DebugFreeApi (api=111 'o', p=0xb7ab5c28) at ../Objects/obmalloc.c:1478
#6  0x080c2b62 in _PyObject_DebugFree (p=0xb7ab5c28) at ../Objects/obmalloc.c:1422
#7  0x0818d3d3 in PyObject_GC_Del (op=0xb7ab5c34) at ../Modules/gcmodule.c:1507
#8  0xb788e725 in PyCData_dealloc (self=<MessageQueueAttributes at remote 0xb7ab5c34>) at /build/buildd/python2.7-2.7.3/Modules/_ctypes/_ctypes.c:2544
#9  0x080e0251 in subtype_dealloc (self=<MessageQueueAttributes at remote 0xb7ab5c34>) at ../Objects/typeobject.c:1014
#10 0x080c12eb in _Py_Dealloc (op=<MessageQueueAttributes at remote 0xb7ab5c34>) at ../Objects/object.c:2243
#11 0x080b3e51 in insertdict (mp=0xb7bafdf4, key='attributes', hash=673635577, value=None) at ../Objects/dictobject.c:530
#12 0x080b47b4 in PyDict_SetItem (op=<unknown at remote 0x6>, key='attributes', value=None) at ../Objects/dictobject.c:775
#13 0x080bc924 in _PyModule_Clear (m=<module at remote 0xb7b72934>) at ../Objects/moduleobject.c:138
#14 0x08161cc9 in PyImport_Cleanup () at ../Python/import.c:445
#15 0x081726cd in Py_Finalize () at ../Python/pythonrun.c:454
#16 0x0818b4b1 in Py_Main (argc=2, argv=0xbfffef34) at ../Modules/main.c:664
#17 0x0805be8f in main (argc=2, argv=0xbfffef34) at ../Modules/python.c:23

The script being run above (show_ctypes_bug.py) is attached.

----------
components: ctypes
files: show_ctypes_bug.py
messages: 213187
nosy: angrylogic
priority: normal
severity: normal
status: open
title: ctypes crash during PyFinalize when librt used
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file34365/show_ctypes_bug.py

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

From report at bugs.python.org  Wed Mar 12 11:02:25 2014
From: report at bugs.python.org (Elja van Tol)
Date: Wed, 12 Mar 2014 10:02:25 +0000
Subject: [New-bugs-announce] [issue20894] COMSPEC with multiple paths breaks
	subprocess.call
Message-ID: <1394618545.08.0.776752293622.issue20894@psf.upfronthosting.co.za>


New submission from Elja van Tol:

I tried a simple console command:
 import subprocess
 subprocess.call(["dir"], shell=True)

Which failed with an WindowsError 2, (could not find file)

After much googling i found out that this is caused by os.environ['COMSPEC']
(http://stackoverflow.com/questions/20330385/cannot-find-the-file-specified-when-using-subprocess-calldir-shell-true-in#comment30370433_20335954)

At first my COMSPEC was:
C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Users\welja\AppData\Roaming\Composer\vendor\phpunit\phpunit;C:\Python27;

I added ;%SystemRoot%\System32\cmd.exe but that failed.

I then changed COMSPEC to only contain %SystemRoot%\System32\cmd.exe and that worked.

( Please fix this for others like me, users stuck on windows with no knowlegde of Python who just try to get Fabric to work to deploy some PHP sites :) )

----------
components: Windows
messages: 213234
nosy: elja
priority: normal
severity: normal
status: open
title: COMSPEC with multiple paths breaks subprocess.call
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 12 11:29:57 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Mar 2014 10:29:57 +0000
Subject: [New-bugs-announce] [issue20895] Add bytes.empty_buffer and
	deprecate bytes(17) for the	same purpose
Message-ID: <1394620197.12.0.249138601017.issue20895@psf.upfronthosting.co.za>


New submission from Ethan Furman:

`bytes` is a list of integers.  Passing a single integer to `bytes()`, as in:

   --> bytes(7)
   b'\x00\x00\x00\x00\x00\x00\x00'

results in a bytes object containing that many zeroes.

I propose that this behavior be deprecated for eventual removal, and a class method be created to take its place.

----------
components: Interpreter Core
messages: 213242
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 12 12:20:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Mar 2014 11:20:40 +0000
Subject: [New-bugs-announce] [issue20896]
	test_ssl.test_get_server_certificate() is failing: CA	cert of
	svn.python.org changed?
Message-ID: <1394623240.06.0.245086264312.issue20896@psf.upfronthosting.co.za>


New submission from STINNER Victor:

======================================================================
ERROR: test_get_server_certificate (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_ssl.py", line 1373, in test_get_server_certificate
    _test_get_server_certificate('svn.python.org', 443, SVN_PYTHON_ORG_ROOT_CERT)
  File "/home/haypo/prog/python/default/Lib/test/test_ssl.py", line 1354, in _test_get_server_certificate
    pem = ssl.get_server_certificate((host, port))
  File "/home/haypo/prog/python/default/Lib/ssl.py", line 902, in get_server_certificate
    with context.wrap_socket(sock) as sslsock:
  File "/home/haypo/prog/python/default/Lib/ssl.py", line 344, in wrap_socket
    _context=self)
  File "/home/haypo/prog/python/default/Lib/ssl.py", line 540, in __init__
    self.do_handshake()
  File "/home/haypo/prog/python/default/Lib/ssl.py", line 767, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:598)

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

Extract of the current CA cert of svn.python.org:
---
$ openssl x509 -in Lib/test/https_svn_python_org_root.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: md5WithRSAEncryption
        Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support at cacert.org
        Validity
            Not Before: Mar 30 12:29:49 2003 GMT
            Not After : Mar 29 12:29:49 2033 GMT
        Subject: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support at cacert.org
...
---

Lib/test/https_svn_python_org_root.pem is identical to http://www.cacert.org/certs/root.crt: root certificate of cacert.org authority.

----------
messages: 213248
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_ssl.test_get_server_certificate() is failing: CA cert of svn.python.org changed?

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

From report at bugs.python.org  Wed Mar 12 13:49:16 2014
From: report at bugs.python.org (the mulhern)
Date: Wed, 12 Mar 2014 12:49:16 +0000
Subject: [New-bugs-announce] [issue20897] @abstractmethod does not enforce
	method signatures
Message-ID: <1394628556.73.0.32604258797.issue20897@psf.upfronthosting.co.za>


New submission from the mulhern:

Hi!

Here is a simple class hierarchy:

>>> import abc
>>> class META(object):
...     __metaclass__ = abc.ABCMeta
...     @abc.abstractmethod
...     def _junk(self):
...             pass
... 
>>> class Sub(META):
...     def _junk(self, other):
...             pass
... 
>>> class Subber(META):
...     def _junk(self):
...             pass
... 
>>> class SuperSubber(META):
...     pass
... 

In 2.7.5 I can instantiate an object of Sub or Subber, although Sub does not really override META's abstract method.
I think it would be better if I could not instantiate Sub, because the signature of the abstract method in META
is different from the signature of the overriding method in Sub.
I can not instantiate SuperSubber, I get a TypeError. That seems correct.

In 3.3.2 I can instantiate all three, Sub, Subber, and SuperSubber.
I would prefer to only be able to instantiate Subber, since it is the only class that truly overrides the abstract method
_junk in META.

- mulhern

----------
components: Library (Lib)
messages: 213256
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: @abstractmethod does not enforce method signatures
type: behavior
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/issue20897>
_______________________________________

From report at bugs.python.org  Wed Mar 12 16:14:04 2014
From: report at bugs.python.org (Filip Malczak)
Date: Wed, 12 Mar 2014 15:14:04 +0000
Subject: [New-bugs-announce] [issue20898] Missin 507 response description
Message-ID: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za>


New submission from Filip Malczak:

I find it strange, that in http.client module we have variable:
INSUFFICIENT_STORAGE = 507
yet in responses (dict mapping int codes to descriptions) 507 is missing.

It's probably just mistake caused by short dev memory, fix is easy: add line:
507: 'Insufficient storage',
between lines 208 and 209 (just after mapping for 505).

Sorry, if this isn't well formatted issue, or if I specified wrong metadata.

I'm working on Python 3.3.2+ (automatically installed in LUbuntu 13.10), and I don't know whether it was fixed in later versions.

----------
components: IO
messages: 213266
nosy: Filip.Malczak
priority: normal
severity: normal
status: open
title: Missin 507 response description
type: behavior

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

From report at bugs.python.org  Wed Mar 12 21:30:25 2014
From: report at bugs.python.org (Andrey Antsut)
Date: Wed, 12 Mar 2014 20:30:25 +0000
Subject: [New-bugs-announce] [issue20899] Nested namespace imports do not
	work inside zip archives
Message-ID: <1394656225.26.0.176386437395.issue20899@psf.upfronthosting.co.za>


New submission from Andrey Antsut:

Importing modules from subdirectories as "implicit namespace packages" (PEP 420) inside a ZIP archive only works one level deep. Imports from within nested namespaces fail with "ImportError: No module named 'XXX'".

I am attaching an archive with example directory/file structure. To reproduce the problem, run the following from where you unzipped it:

python
>>> import sys
>>> sys.path += ['project1', 'project2.zip', 'project3', 'project4.zip']
>>> import parent.child.hello1
Hello 1
>>> import parent.child.hello2
ImportError: No module named 'parent.child.hello2'
>>> import parent.child.hello3
Hello 3
>>> import parent.child.hello4
ImportError: No module named 'parent.child.hello4'
>>> import boo
boo!
>>> import parent.boo
boo!

Tested on WinXP SP3 with Python 3.3.5 and 3.4.0rc3.

----------
files: reproduce.zip
messages: 213290
nosy: Andrey.Antsut
priority: normal
severity: normal
status: open
title: Nested namespace imports do not work inside zip archives
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34380/reproduce.zip

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

From report at bugs.python.org  Wed Mar 12 21:59:23 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Mar 2014 20:59:23 +0000
Subject: [New-bugs-announce] [issue20900] distutils register command should
	print text, not bytes repr
Message-ID: <1394657963.26.0.506041572829.issue20900@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

?python3 setup.py register --show-response? will display something like "----------b'xxx'----------".  The HTTP response body should be decoded to text for display, instead of the repr of a bytes object.

Setting the ?easy? keyword: thanks to unittest.mock, writing a test for this should not be hard, and with a test we can have the confidence to change the code.

----------
components: Distutils
keywords: easy
messages: 213295
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: distutils register command should print text, not bytes repr
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 12 22:51:44 2014
From: report at bugs.python.org (Andreas Stieger)
Date: Wed, 12 Mar 2014 21:51:44 +0000
Subject: [New-bugs-announce] [issue20901] test_sqlite fails with SQLite 3.8.4
Message-ID: <1394661104.86.0.58139727656.issue20901@psf.upfronthosting.co.za>


New submission from Andreas Stieger:

SQLite 3.8.4 fails test_sqlite on 2.7 and 3.4.

[ 296s] test test_sqlite failed -- Traceback (most recent call last):
[ 296s] File "/home/abuild/rpmbuild/BUILD/Python-2.7.6/Lib/sqlite3/test/hooks.py", line 165, in CheckOpcodeCount
[ 296s] self.assertTrue(first_count > second_count)
[ 296s] AssertionError: False is not true

This seems to be a change in behaviour callback of SQLite: (one "." per callback issued)
sqlite3_progress_handler(db, 1, progress_callback, NULL);
sqlite3_exec(db, "create table foo(a,b)", callback, 0, &zErrMsg);
sqlite3_progress_handler(db, 2, progress_callback, NULL);
sqlite3_exec(db, "create table bar(a,b)", callback, 0, &zErrMsg);

3.7.17> ./test
..................................................................
...........................
3.8.3.1> ./test
........
.......
3.8.4> ./test
.....
.....
3.8.4.1> ./test
.....
.....

This may be a side effect of optimization Documentation does day the callbacks are approximate. Can the test be adjusted to run more than CREATE TABLE so that a difference in the number of callbacks is tested for?

Also see openSUSE bug: https://bugzilla.novell.com/show_bug.cgi?id=867887

----------
components: Tests
messages: 213302
nosy: Andreas.Stieger
priority: normal
severity: normal
status: open
title: test_sqlite fails with SQLite 3.8.4
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Mar 12 22:55:00 2014
From: report at bugs.python.org (Giacomo Alzetta)
Date: Wed, 12 Mar 2014 21:55:00 +0000
Subject: [New-bugs-announce] [issue20902] Which operand is preferred by set
	operations? Missing	information in the documentation
Message-ID: <1394661300.29.0.784191218762.issue20902@psf.upfronthosting.co.za>


New submission from Giacomo Alzetta:

Currently the documentation for set (at: http://docs.python.org/2/library/stdtypes.html#set) does not mention which operand is preferred when performing the usual binary operations.

For example the following sample code doesn't have a defined result according to the documentation:


class MyObj:
  def __init__(self, key, value):
     self.key = key
     self.value = value
  def __key(self):
    return self.key
  def __hash__(self):
    return hash(self.__key())
  def __eq__(self, other):
    return type(self) is type(other) and self.__key() == other.__key()

a = {MyObj(1, 'a')}

b = {MyObj(1, 'b')}

print((a & b).pop().value)  # 'a' or 'b'?


As far as I can tell currently there is no rule about this. Intersection prefers the second operand, while union prefers the first. These are the only operations where this is important since they include common elements.

I believe that this kind of information ought to be included explicitly near such operations. At the very least, if the behaviour should really be somehow undefined, it should be stated there so that people don't rely on such behaviour.

The same should be stated for |= and &=, since the first will not modify common elements while the latter will.


PS: I can't find any resource about the formatting of issues (e.g. if and which syntax is used for code blocks. Sorry for that.

----------
assignee: docs at python
components: Documentation
messages: 213305
nosy: Giacomo.Alzetta, docs at python
priority: normal
severity: normal
status: open
title: Which operand is preferred by set operations? Missing information in the documentation
type: enhancement

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

From report at bugs.python.org  Wed Mar 12 23:52:34 2014
From: report at bugs.python.org (Chris Clark)
Date: Wed, 12 Mar 2014 22:52:34 +0000
Subject: [New-bugs-announce] [issue20903] smtplib.SMTP raises socket.timeout
Message-ID: <1394664754.18.0.260499838693.issue20903@psf.upfronthosting.co.za>


New submission from Chris Clark:

The documentation for smtplib.SMTP says "If the connect() call returns anything other than a success code, an SMTPConnectError is raised." It doesn't explicitly specify what happens when connect() raises instead of returns, but I think either the documentation should mention "socket.timeout" or it should raise SMTPConnectError.


Python 3.3.4 (default, Feb 11 2014, 15:56:08) 
[GCC 4.8.2 20140206 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from smtplib import SMTP
>>> SMTP('a.com', timeout=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/smtplib.py", line 241, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/lib/python3.3/smtplib.py", line 320, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/usr/lib/python3.3/smtplib.py", line 291, in _get_socket
    self.source_address)
  File "/usr/lib/python3.3/socket.py", line 435, in create_connection
    raise err
  File "/usr/lib/python3.3/socket.py", line 426, in create_connection
    sock.connect(sa)
socket.timeout: timed out

----------
components: Library (Lib)
messages: 213321
nosy: Chris.Clark
priority: normal
severity: normal
status: open
title: smtplib.SMTP raises socket.timeout
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 13 08:54:56 2014
From: report at bugs.python.org (Andreas Schwab)
Date: Thu, 13 Mar 2014 07:54:56 +0000
Subject: [New-bugs-announce] [issue20904] HAVE_PY_SET_53BIT_PRECISION for
	m68k
Message-ID: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

m68k has the same problem as x86 with excess floating point precision.  The attached patch implements the necessary support for HAVE_PY_SET_53BIT_PRECISION.

----------
components: Interpreter Core
files: m68k-float-prec.patch
keywords: patch
messages: 213359
nosy: schwab
priority: normal
severity: normal
status: open
title: HAVE_PY_SET_53BIT_PRECISION for m68k
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file34387/m68k-float-prec.patch

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

From report at bugs.python.org  Thu Mar 13 09:18:17 2014
From: report at bugs.python.org (Prashant Sharma)
Date: Thu, 13 Mar 2014 08:18:17 +0000
Subject: [New-bugs-announce] [issue20905] Adapt heapq push/pop/replace to
	allow passing a	comparator.
Message-ID: <1394698697.56.0.738511180994.issue20905@psf.upfronthosting.co.za>


New submission from Prashant Sharma:

It would be more convenient to extend heapq to support user defined comparators. 

Default can be cmp_lt in which case they behave as they do now. 

Caveat:
What happens if uses switches comparator between calls to push or pop. The expected behavior can be unpredictable and should be obvious to the user of the API. It might also be good to state this obvious, if people here agree. 

P.S. I am really new to python world, forgive me for any kind of stupidity. Criticism and comments is what I am looking for here !

----------
components: Library (Lib)
files: heapq_com.patch
keywords: patch
messages: 213361
nosy: Prashant.Sharma
priority: normal
severity: normal
status: open
title: Adapt heapq push/pop/replace to allow passing a comparator.
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file34388/heapq_com.patch

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

From report at bugs.python.org  Thu Mar 13 10:16:27 2014
From: report at bugs.python.org (Graham Wideman)
Date: Thu, 13 Mar 2014 09:16:27 +0000
Subject: [New-bugs-announce] [issue20906] Unicode HOWTO
Message-ID: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>


New submission from Graham Wideman:

The Unicode HOWTO article is an attempt to help users wrap their minds around Unicode. There are some opportunities for improvement. Issues presented in order of the narrative:

http://docs.python.org/3.3/howto/unicode.html

History of Character Codes
---------------------------

References to the 1980's are a bit off.

"In the mid-1980s an Apple II BASIC program..." 

Assuming the comment is about the state of play in the mid-80's, then: The Apple II appeared in 1977. By 1985 we already had Macs, and PCs running DOS, which were capable of various character sets (not to mention lowercase letters!)

"In the 1980s, almost all personal computers were 8-bit"

Both the PC (1983) and Mac (1984) had 16-bit processors.

Definitions:
------------
"Characters are abstractions": Not helpful unless one already knows what "abstraction" means in this specific context.

"the symbol for ohms (?) is usually drawn much like the capital letter omega (?) in the Greek alphabet [...] but these are two different characters that have different meanings."

Omega is a poor example for this concept. Omega is used as the identifier for a unit in the same way as "m" is used for meter, or "A" is used for ampere. Each is a specific use of a character, which, like any specific use, has a particular meaning. However, having a particular meaning doesn't necessarily require a separate character, and in the case of omega, the Unicode standard now says that the separate "ohm" character is deprecated. 

"The ohm sign is canonically equivalent to the capital omega, and normalization would remove any distinction."

http://www.unicode.org/versions/Unicode4.0.0/ch07.pdf#search=%22character%20U%2B2126%20maps%20OR%20map%20OR%20mapping%22

A better example might be the roman numerals, code points U+2160 and subsequent.

Definitions
------------

"A code point is an integer value, usually denoted in base 16."  

When trying to convey clearly the distinction between character, code point, and byte representation, the topic of "how it's denoted" is a potential distraction for the reader, so I suggest this point be a bit more explicitly  parenthetical, and less confusable with "16 bit".  Like:

"A code point value is an integer in the range 0 to over 0x10FFFF (about 1.1 million, with some 110 thousand assigned so far). In a narrative such as the current article, a code point value is usually written in hexadecimal. The Unicode standard displays code points with the notation U+265E to mean the character with value 0x265e (9822 decimal; "Black Chess Knight" character)."

(Also revise subsequent para to use same example character. I suggest not using "Ethiotic Syllable WI", because it's unfamiliar to most readers, and it muddies the topic by suggesting that Unicode in general captures _syllables_ rather than _characters_.)

Encodings:
-----------
"This sequence needs to be represented as a set of bytes"
--> ""This code point sequence needs to be represented as a sequence of bytes"

"4. Many Internet standards are defined in terms of textual data"

This is a vague claim. Probably what was intended was: "Many Internet standards define protocols in which the data must contain no zero bytes, or zero bytes have special meaning."  Is this actually true? Are there "many" such standards?

"Generally people don?t use this encoding,"
Probably "people" per se don't use any encoding, computers do.  --> "Because of these problems, other more efficient and convenient encodings have been devised and are commonly used.

For continuity, directly after that para should come the later paras starting with "UTF-8 is one of the most common".

"2. A Unicode string is turned into a string of bytes..."
--> "2. A Unicode string is turned into a sequence of bytes..."  (Ie: don't overload "string" in and article about strings and encodings.).

Create a new subhead "Converting from Unicode to non-Unicode encodings", and move under it the paras:

"Encodings don't have to..."
"Latin-1, also known as..."
"Encodings don't have to..."

But also revise:

"Encodings don?t have to handle every possible Unicode character, and most encodings don?t."

--> "Non-Unicode code systems usually don't handle all of the characters to be found in Unicode."

----------
assignee: docs at python
components: Documentation
messages: 213367
nosy: docs at python, gwideman
priority: normal
severity: normal
status: open
title: Unicode HOWTO
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/issue20906>
_______________________________________

From report at bugs.python.org  Thu Mar 13 10:46:05 2014
From: report at bugs.python.org (Peter Santoro)
Date: Thu, 13 Mar 2014 09:46:05 +0000
Subject: [New-bugs-announce] [issue20907] behavioral differences between
	shutil.unpack_archive and	ZipFile.extractall
Message-ID: <1394703965.34.0.603199781912.issue20907@psf.upfronthosting.co.za>


New submission from Peter Santoro:

Since Python 3.3.1, ZipFile.extractall was enhanced to better handle absolute paths and illegal characters.  The associated logic within shutil._unpack_zipfile essentially skips zip members with these issues.

If a zip file contains all absolute paths, ZipFile.extractall works as expected (i.e. the zip file is unpacked), but shutil._unpack_zipfile (normally called indirectly via shutil.unpack_archive) appears to do nothing (i.e. it silently fails to unpack the zip file).

The attached patch attempts to unify the behavior of extracting zip files between shutil.unpack_archive with ZipFile.extractall.

----------
components: Library (Lib)
files: shutil.diff
keywords: patch
messages: 213374
nosy: peter at psantoro.net
priority: normal
severity: normal
status: open
title: behavioral differences between shutil.unpack_archive and ZipFile.extractall
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34393/shutil.diff

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

From report at bugs.python.org  Thu Mar 13 12:27:46 2014
From: report at bugs.python.org (Luis G.F)
Date: Thu, 13 Mar 2014 11:27:46 +0000
Subject: [New-bugs-announce] [issue20908] Memory leak in Reg2Py()
Message-ID: <1394710066.6.0.383918848793.issue20908@psf.upfronthosting.co.za>


New submission from Luis G.F:

A memory leak can happend in Reg2Py() loosing the reference to str pointer. 

See file PC/winreg.c +947

----------
components: Extension Modules, Windows
messages: 213384
nosy: luisgf
priority: normal
severity: normal
status: open
title: Memory leak in Reg2Py()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 13 13:20:04 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Mar 2014 12:20:04 +0000
Subject: [New-bugs-announce] [issue20909] 3.4 cherry pick: d22ef969cb82 new
	distribution &	installation guides
Message-ID: <1394713204.59.0.970372183648.issue20909@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Cherry pick request for the Installation & Distribution docs updates for PEP 453.

New changeset d22ef969cb82 by Nick Coghlan in branch 'default':
Close #19407: New installation & distribution guides
http://hg.python.org/cpython/rev/d22ef969cb82

----------
assignee: larry
components: Documentation
messages: 213390
nosy: larry, ncoghlan
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry pick: d22ef969cb82 new distribution & installation guides
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 13 14:18:57 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Mar 2014 13:18:57 +0000
Subject: [New-bugs-announce] [issue20910] Make sleep configurable in tests
Message-ID: <1394716737.96.0.403349621392.issue20910@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

I'm trying to make Python test suite reliable, but it's hard because the speed of our farm of buildbots varies a lot. The whole test suite takes less than 10 minutes on some buildbots (or event less than 5 minutes), while it took 10 hours on other buildbots.

Some tests use time.sleep() as a basic synchronization primitive, because other synchronization primitive cannot be used. For example, lock_tests.py tests locks and so cannot use lock in its tests. The problem is that slow buildbots require long sleep. It makes the test suite slow, whereas fast buildbots could use short lseep.

Some tests make sure that an operation takes less than N seconds. It's very hard to choose a N value for all buildbots. To make tests pass on all buildbots, N can be configured for the slowest buildbots.

I propose to make "time" configurable in the test suite:

- add support.TEST_SLEEP constant: it can be between 50 ms and 1 sec, or longer for very slow buildbots
- add support.TEST_SHORT_SLEEP constant: shorter than TEST_SLEEP, it is usually used to yield the control to another thread or another process and it can be very short (1 ms)
- add a new check_time_delta() functions to check time deltas
- add a new --test-sleep command line option to regrtest.py (python -m test)

check_time_delta() uses the resolution of the clock to tolerate a small difference. This is important on Windows where the resolution is usually 15.6 ms whereas tests use timings close to 100 ms.

Seen values in tests:

- TEST_SLEEP: sleep between 100 ms and 3 sec
- TEST_SHORT_SLEEP: 1 ms or 10 ms
- check_time_delta(): tolerate between 500 and 800 ms on slow buildbots

I chose TEST_SHORT_SLEEP for time < 100 ms, and TEST_SLEEP for the other sleep.

Some issues related to slow buildbots:

- #11185
- #20101
- #20336

The goal of my changes is to run the test suite as fast as possible, so to reduce the sleep. My plan:

- keep current timings for buildbots, but use very short timings by default
- configure slow buildbots to use longer sleep
- use short sleep for the default buildbot configuration

Buildbot config of my patch:

- TEST_SLEEP: 500 ms
- TEST_SHORT_SLEEP: 10 ms
- check_time_delta().slow_buildbot: 1 sec

Default config of my patch:

- TEST_SLEEP: 50 ms
- TEST_SHORT_SLEEP: 1 ms
- check_time_delta().slow_buildbot: 0 ms

The patch doesn't change timings in tests executed in subprocesses, because test.regrtest only modifies test.support variables in the current process. It can be improved later.

----------
files: test_sleep.patch
keywords: patch
messages: 213395
nosy: haypo
priority: normal
severity: normal
status: open
title: Make sleep configurable in tests
versions: Python 3.4
Added file: http://bugs.python.org/file34398/test_sleep.patch

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

From report at bugs.python.org  Thu Mar 13 16:27:34 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Mar 2014 15:27:34 +0000
Subject: [New-bugs-announce] [issue20911] urllib 'headers' is not a well
	defined data type
Message-ID: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>


New submission from R. David Murray:

Some places in the code it is an email.message.Message object.  Some places it is a simple dictionary.  In one place (FTP), it is a string with embedded newlines.

I'm not sure what should be done about this situation, but it looks like a bug magnet, and it makes it pretty much impossible to document the data type.

----------
messages: 213406
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: urllib 'headers' is not a well defined data type
type: behavior

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

From report at bugs.python.org  Thu Mar 13 17:44:22 2014
From: report at bugs.python.org (Vitaly Murashev)
Date: Thu, 13 Mar 2014 16:44:22 +0000
Subject: [New-bugs-announce] [issue20912] [zipfile.py]: Make zip directory
	attributes more	friendly for MS-Windows
Message-ID: <1394729062.0.0.517393567539.issue20912@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

When I use 'zip' command-line tool on my Ubuntu 10.04 to pack a directory in zip-archive, it internally assigns '0x41ed0010' attributes for it.

0x41ed0010 = 0x41ed << 0xfff + 0x0010

Where:
  0x41ed - unix attributes (40755)
  0x0010 - means # MS-DOS directory flag

At the same time zipfile.py doesn't provide MS-DOS directory flag.
It seems be a good idea to do it.
Patch suggested over 3.3.3 code-base.

----------
components: Library (Lib)
files: zipfile.py.diff
keywords: patch
messages: 213416
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [zipfile.py]: Make zip directory attributes more friendly for MS-Windows
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34399/zipfile.py.diff

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

From report at bugs.python.org  Thu Mar 13 18:56:27 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Mar 2014 17:56:27 +0000
Subject: [New-bugs-announce] [issue20913] Standard Library documentation
	needs SSL security best	practices doc.
Message-ID: <1394733387.87.0.332479882256.issue20913@psf.upfronthosting.co.za>


New submission from R. David Murray:

It's great that Christian did all the work he did on the SSL module to enhance its security capabilities, and great that Antoine did the work he did before that.  Now we need an explanation of how best to use it all :)


It is not clear from the existing documentation how to best use the various standard library modules that support SSL in a "best practices" way.  Perhaps this could go in the SSL docs and be linked from all the library components that use it.  Alternatively we could perhaps have a general security overview chapter in the library reference, but we at least an SSL one.  The existing documentation in the SSL module, while it contains a lot of information about the available, doesn't make it clear what a programmer should actually *do*.  As one example, it is not clear when or even if an application programmer would call check_hostname.

----------
assignee: christian.heimes
messages: 213425
nosy: christian.heimes, haypo, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Standard Library documentation needs SSL security best practices doc.

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

From report at bugs.python.org  Thu Mar 13 19:43:16 2014
From: report at bugs.python.org (Vladimir)
Date: Thu, 13 Mar 2014 18:43:16 +0000
Subject: [New-bugs-announce] [issue20914] pyopenssl-0.14-1 error
Message-ID: <1394736196.53.0.542116191166.issue20914@psf.upfronthosting.co.za>


New submission from Vladimir:

After update python2.7-pyopenssl-0.13.1-1 to python2.7-pyopenssl-0.14-1 i have this error on opening deluge. Packpage downgrade solv problem. 
OS: Archlinux

/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
[ERROR   ] 22:19:53 ui:168 No module named cryptography.hazmat.bindings.openssl.binding
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/deluge/ui/ui.py", line 149, in __init__
    from deluge.ui.gtkui.gtkui import GtkUI
  File "/usr/lib/python2.7/site-packages/deluge/ui/gtkui/__init__.py", line 1, in <module>
    from gtkui import start
  File "/usr/lib/python2.7/site-packages/deluge/ui/gtkui/gtkui.py", line 75, in <module>
    from deluge.ui.client import client
  File "/usr/lib/python2.7/site-packages/deluge/ui/client.py", line 37, in <module>
    from twisted.internet import reactor, ssl, defer
  File "/usr/lib/python2.7/site-packages/twisted/internet/ssl.py", line 25, in <module>
    from OpenSSL import SSL
  File "/usr/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/usr/lib/python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
    from OpenSSL._util import (
  File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 3, in <module>
    from cryptography.hazmat.bindings.openssl.binding import Binding
ImportError: No module named cryptography.hazmat.bindings.openssl.binding

----------
components: Library (Lib)
messages: 213438
nosy: Vladimir
priority: normal
severity: normal
status: open
title: pyopenssl-0.14-1 error
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 13 20:31:17 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Mar 2014 19:31:17 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMjA5MTVdIEFkZCDigJxwaXA=?=
 =?utf-8?q?=E2=80=9D_section_to_experts_list_in_devguide?=
Message-ID: <1394739077.76.0.126503478365.issue20915@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

With pip installed by Python and new distutils fixes on the table, I think it will be needed to make pip developers nosy on bugs.python.org issues.  (For many issues we?ll have to close the ticket here and ask to report on github/pypa/pip, but other tickets will be rightfully here.)

What about adding a ?pip? line in experts.rst in the devguide?  It would let us type ?pip? in the nosy field and have our pip contacts notified.

----------
components: Devguide
messages: 213446
nosy: dstufft, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add ?pip? section to experts list in devguide

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

From report at bugs.python.org  Thu Mar 13 20:48:21 2014
From: report at bugs.python.org (Adam Goodman)
Date: Thu, 13 Mar 2014 19:48:21 +0000
Subject: [New-bugs-announce] [issue20916] ssl.enum_certificates() will not
	return all certificates	trusted by Windows
Message-ID: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za>


New submission from Adam Goodman:

Starting with Vista, Microsoft began shipping only a very minimal set of root CA certificates with Windows. Microsoft does trust many other authorities, but for these, Windows relies on the "Update Root Certificates" feature: http://technet.microsoft.com/en-us/library/cc749331(WS.10).aspx

"... if the application is presented with a certificate issued by a certification authority in a PKI that is not directly trusted, the Update Root Certificates feature (if it is not turned off) will contact the Windows Update Web site to see if Microsoft has added the certificate of the root CA to its list of trusted root certificates. If the CA has been added to the Microsoft list of trusted authorities, its certificate will automatically be added to the set of trusted root certificates on the user's computer."

Critically, this update mechanism is only invoked if you're using CryptoAPI functions to validate a specific chain; if you just ask Windows to enumerate the certificates it knows about, it won't pull anything down from Windows Update.

(Some concrete numbers: on a clean installation of Windows 8.1, running certmgr.msc shows 18 certificates listed in the "Trusted Root Certification Authorities"; by contrast, OS X comes with over 200 trusted roots).

To confirm this is an issue, I did the following:

1. Start with a clean Windows 8.1 VM image (I used the one from from http://www.modern.ie/en-us/virtualization-tools#downloads). It is critical that the image be completely clean - i.e. you have never visited https://python.org in any web browser, etc.

2. Install Python 3.4.0 RC 3 (32-bit)

3. Run the attached script (which just does a request to https://python.org/ with cert validation enabled). It prints out 14 CA certificate subjects, then fails with "ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598)". At the time I'm reporting this issue, python.org uses a certificate that chains back to the "DigiCert High Assurance EV Root CA", which is not included in clean installations of Windows.

4. Browse to https://python.org in Internet Explorer

5. Run the attached script again. Now it prints out 17 CA certificate subjects, and the HTTPS request completes successfully.

Right now, the only idea I have for resolving this would require significant architectural changes - instead of pulling the certificates from Windows into an OpenSSL context, hook the OpenSSL verify callbacks to retrieve the leaf and intermediate certificates provided by the server, then use CryptoAPI functions (probably CertGetCertificateChain?) to have Windows perform the actual chain validation.

----------
components: Extension Modules
messages: 213452
nosy: Adam.Goodman, christian.heimes
priority: normal
severity: normal
status: open
title: ssl.enum_certificates() will not return all certificates trusted by Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 13 21:04:57 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Mar 2014 20:04:57 +0000
Subject: [New-bugs-announce] [issue20917] Idle: Enhance font change
	notification system
Message-ID: <1394741097.69.0.88319958865.issue20917@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

If one changes the font in the Idle Preferences dialog, all open windows are somehow notified and they immediately respond. Classes defined in extensions do not get notified. So CodeContext sets up a polling loop. Roger Serwy's line number extension (posted to #17535) copied the polling hack.  It would be better to enhance the the notification mechanism to either generate an event that could be caught or setup a callback registry.

----------
messages: 213453
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Idle: Enhance font change notification system
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 13 21:43:03 2014
From: report at bugs.python.org (the mulhern)
Date: Thu, 13 Mar 2014 20:43:03 +0000
Subject: [New-bugs-announce] [issue20918] LogRecord.__init__ should handle
	exception if %	operation fails
Message-ID: <1394743383.57.0.0490723383406.issue20918@psf.upfronthosting.co.za>


New submission from the mulhern:

Here's my illustrating trace:

Python 3.3.2 (default, Aug 23 2013, 19:00:04) 
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Junk():
...     def __repr__(self):
...             raise AttributeError("junk")
... 
>>> import logging
>>> logging.warning("%r", Junk())
Traceback (most recent call last):
  File "/usr/lib64/python3.3/logging/__init__.py", line 937, in emit
    msg = self.format(record)
  File "/usr/lib64/python3.3/logging/__init__.py", line 808, in format
    return fmt.format(record)
  File "/usr/lib64/python3.3/logging/__init__.py", line 546, in format
    record.message = record.getMessage()
  File "/usr/lib64/python3.3/logging/__init__.py", line 311, in getMessage
    msg = msg % self.args
  File "<stdin>", line 3, in __repr__
AttributeError: junk
Logged from file <stdin>, line 1

The alternative that would be desirable is that the LogRecord initializer
would catch the exception and log that something bad happened while
trying to log. I expect that it would be better if it were optional
behavior.

Note that the use of the % operator happens very early in the logging
process, so implementing your own handler or overriding the makeRecord
method won't fix this problem.

There are plenty of situations where you would like to log a lot
of information, but would be embarrassed to crash while logging.

I realize that I could implement this by surrounding every log call
with some function that caught the exception and then logged that
an exception had occurred while trying to log, but I think it
might work better within the logging module.

----------
components: Library (Lib)
messages: 213465
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: LogRecord.__init__ should handle exception if % operation fails
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 14 03:56:04 2014
From: report at bugs.python.org (Yamini Joshi)
Date: Fri, 14 Mar 2014 02:56:04 +0000
Subject: [New-bugs-announce] [issue20919] Image.show() does not open the
	image on windows xp
Message-ID: <1394765765.0.0.530298385303.issue20919@psf.upfronthosting.co.za>


Changes by Yamini Joshi <yamini.1691 at gmail.com>:


----------
components: IDLE
nosy: Yamini.Joshi
priority: normal
severity: normal
status: open
title: Image.show() does not open the image on windows xp
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 14 04:39:31 2014
From: report at bugs.python.org (Eli Innis)
Date: Fri, 14 Mar 2014 03:39:31 +0000
Subject: [New-bugs-announce] [issue20920] Turtle module transparency.
Message-ID: <1394768371.55.0.507466449855.issue20920@psf.upfronthosting.co.za>


New submission from Eli Innis:

Python's Turtle module doesn't support transparency.
----------------------------------------------------

I emailed the developer that was listed in the Turtle module code,
thinking that was the right way to get help updating it.

I then messaged Python's Facebook page looking for anybody
to help me with this issue.

I then gave a shout out to Jessica McKellar of the
Boston Python User Group, in hopes that she'd know what to do,
as she's more of a Python guru than I.

She recommended I submit a bug report.  Fancy that :)

I'm writing a book to teach the community art,
and I want to use Python as the core for the computer graphics lessons.

While I can create basic graphics, I feel totally constrained by the lack of of RGBA support.

What I'd like is for the Turtle module to default to RGB if three values are given in the tuple for color, but if an optional 4th value exists, then it'll use that value for alpha transparency.

I would think it would be OK if it follows a simlar convention:
0 - 255  (vs)  0 - 1.0
transparency range depending on how
the previous three values for color were inputted.

I looked into the Turtle code.
While it looks like it would be possible to impliment there,
I believe the bottleneck is the tkinter that it relies on.

I don't believe that tkinter handles transparency in Linux.

I wouldn't think this would be an unsurmountable hurdle,
as there's a similar Python + Tutle combo out there called Pynguin
that actually handles transparency.

I couldn't get as much out of that though,
because I'd have to battle with the interface.

I also considered other modules, such as matplotlib
or Pygame, but I think that's adding a layer of complexity
that I'd rather the end-user not have to deal with.

If anyone can take on this challenge and help out,
together, we can take Python graphics to the next level :D

----------
components: Extension Modules, Tkinter
files: 1518814_771323949547840_717525448_n.jpg
messages: 213515
nosy: Eli Innis
priority: normal
severity: normal
status: open
title: Turtle module transparency.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34411/1518814_771323949547840_717525448_n.jpg

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

From report at bugs.python.org  Fri Mar 14 05:53:51 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Fri, 14 Mar 2014 04:53:51 +0000
Subject: [New-bugs-announce] [issue20921] DeprecationWarning: The Windows
	bytes API has been	deprecated,
	use Unicode filenames instead   st = os.stat(path)
Message-ID: <1394772831.17.0.0952033774201.issue20921@psf.upfronthosting.co.za>


New submission from Pramod Jadhav:

C:\Python33\lib\genericpath.py:29: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
  st = os.stat(path)

----------
messages: 213517
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead   st = os.stat(path)
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 14 08:23:36 2014
From: report at bugs.python.org (VIJAY KANSAL)
Date: Fri, 14 Mar 2014 07:23:36 +0000
Subject: [New-bugs-announce] [issue20922] Global variables
Message-ID: <1394781816.56.0.360131329411.issue20922@psf.upfronthosting.co.za>


New submission from VIJAY KANSAL:

Inside functions:
1. Python allows access to global variables.
2. Python allows creation of local variable with the same name as that of of some of the global variable.

Keeping the above two statements in mind, I believe that Python must allow following sequential statements in a function:
1. Accessing global variable
2. Creating local variable with the same name as that of some of the global variable name.

But, it seems that the above is not allowed.
The below code has the following output:

Printing:  12
Throwing Error: 
Traceback (most recent call last):
  File "./bug.py", line 14, in <module>
    func2()
  File "./bug.py", line 9, in func2
    print 'Throwing Error: ', var
UnboundLocalError: local variable 'var' referenced before assignment




CODE:

var = 12

def func1():
    print 'Printing: ', var 

def func2():
    print 'Throwing Error: ', var 
    var = 10
    print 'Unreachable Code: ', var 

func1()
func2()

----------
messages: 213520
nosy: vijay_kansal
priority: normal
severity: normal
status: open
title: Global variables
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 14 15:21:45 2014
From: report at bugs.python.org (=?utf-8?b?TWlsb8WhIEtvbWFyxI1ldmnEhw==?=)
Date: Fri, 14 Mar 2014 14:21:45 +0000
Subject: [New-bugs-announce] [issue20923] ConfigParser should be greedy when
	parsing section name
Message-ID: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>


New submission from Milo? Komar?evi?:

It would be good if ConfigParser supported angled brackets in section names by being greedy when parsing.

For example, section:

[Test[2]_foo]

gets parsed as:

Test[2

----------
messages: 213554
nosy: miloskomarcevic
priority: normal
severity: normal
status: open
title: ConfigParser should be greedy when parsing section name
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 14 15:29:14 2014
From: report at bugs.python.org (bob bob)
Date: Fri, 14 Mar 2014 14:29:14 +0000
Subject: [New-bugs-announce] [issue20924] openssl init 100% CPU utilization
Message-ID: <1394807354.77.0.238568366714.issue20924@psf.upfronthosting.co.za>


New submission from bob bob:

We have written a server on Python 2.7.6  that uses openssl 0.9.8y running on Windows box.

Time to time our server freezes utilizing 100% CPU on ssl_init (C routine). The following is the process stack:

0021ee80 10036d19 0176d259 00000000 00000013 msvcr90+0x3b35d

0021ee9c 10022a22 0021ef1c 0176d218 1001bf62 _ssl!init_ssl+0x33b59

0021ef74 10073920 0176a158 0177ba18 00952a78 _ssl!init_ssl+0x1f862

0021ef84 10001714 0176a158 0147b350 00000000 _ssl!init_ssl+0x70760

0021ef88 0176a158 0147b350 00000000 00952a78 _ssl+0x1714

0021ef8c 0147b350 00000000 00952a78 ffffffff 0x176a158

0021ef90 00000000 00952a78 ffffffff 100d3038 0x147b350

This problem occurs when client connects to our server using slow modem channel. In this case client sends duplicated SYN TCP packet. When second SYN packet arrives to the server after SYN_ACK server's packet we have a trouble. Like this trace from server side:

140 38.807410000   172.16.35.6  192.168.52.1  TCP  74  44697 > 20444 [SYN] Seq=0 Win=14600 Len=0 MSS=1314 SACK_PERM=1 TSval=495224007 TSecr=0 WS=16

141 38.807428000   192.168.52.1 172.16.35.6   TCP  78  20444 > 44697 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 TSval=0 TSecr=0 SACK_PERM=1

148 39.288557000   172.16.35.6  192.168.52.1  TCP  74  44697 > 20444 [SYN] Seq=0 Win=14600 Len=0 MSS=1314 SACK_PERM=1 TSval=495224257 TSecr=0 WS=16

----------
components: Library (Lib), Windows
messages: 213555
nosy: bob.bob
priority: normal
severity: normal
status: open
title: openssl init 100% CPU  utilization
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 14 15:54:18 2014
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 14 Mar 2014 14:54:18 +0000
Subject: [New-bugs-announce] [issue20925] Update TLS version connection table
Message-ID: <1394808858.87.0.746121175293.issue20925@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The table at http://docs.python.org/3.4/library/ssl.html#ssl.wrap_socket doesn't contain information for TLS 1.1 and 1.2. I've attached a script that tests connection between all supported SSL protocol versions. (Note: my OpenSSL doesn't support SSLv2).

server     client     can connect
=========  =========  ===========
SSLv23     SSLv23     True
SSLv23     SSLv3      True
SSLv23     TLSv1      True
SSLv23     TLSv1_1    True
SSLv23     TLSv1_2    True
SSLv3      SSLv23     True
SSLv3      SSLv3      True
SSLv3      TLSv1      False
SSLv3      TLSv1_1    False
SSLv3      TLSv1_2    False
TLSv1      SSLv23     True
TLSv1      SSLv3      False
TLSv1      TLSv1      True
TLSv1      TLSv1_1    False
TLSv1      TLSv1_2    False
TLSv1_1    SSLv23     True
TLSv1_1    SSLv3      False
TLSv1_1    TLSv1      False
TLSv1_1    TLSv1_1    True
TLSv1_1    TLSv1_2    False
TLSv1_2    SSLv23     False
TLSv1_2    SSLv3      False
TLSv1_2    TLSv1      False
TLSv1_2    TLSv1_1    False
TLSv1_2    TLSv1_2    True

----------
assignee: docs at python
components: Documentation
files: ssltest.py
messages: 213559
nosy: christian.heimes, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Update TLS version connection table
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34417/ssltest.py

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

From report at bugs.python.org  Fri Mar 14 17:22:47 2014
From: report at bugs.python.org (Kathleen Weaver)
Date: Fri, 14 Mar 2014 16:22:47 +0000
Subject: [New-bugs-announce] [issue20926] Enhance Quick Start portion of
	instructions for Windows
Message-ID: <1394814167.93.0.592272181711.issue20926@psf.upfronthosting.co.za>


New submission from Kathleen Weaver:

Current text reads:

On Windows, open the solution file PCbuild\pcbuild.sln in Visual Studio, select Debug, and Build ? Build Solution. Run Tools\buildbot\external.bat or Tools\buildbot\external-amd64.bat to download and compile 3rd party libraries.

While it works correctly, this does generate errors in the build process which can be confusing.  This is documented in the read me, and the Getting Started.  I believe it should be mentioned here in the quick start

----------
components: Devguide
messages: 213567
nosy: ezio.melotti, kathweaver
priority: normal
severity: normal
status: open
title: Enhance Quick Start portion of instructions for Windows

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

From report at bugs.python.org  Fri Mar 14 17:59:45 2014
From: report at bugs.python.org (Jovik)
Date: Fri, 14 Mar 2014 16:59:45 +0000
Subject: [New-bugs-announce] [issue20927] Different behaviour on Posix and
	Windows when using	subprocess.Popen(..., cwd=path)
Message-ID: <1394816385.18.0.912805951896.issue20927@psf.upfronthosting.co.za>


New submission from Jovik:

This works on Linux as expected:
import subprocess
proc = subprocess.Popen(["./app"], stdout=subprocess.PIPE, cwd="workspace")

but on Windows I get:
FileNotFoundError: [WinError 2] The system cannot find the file specified

To successfully execute it on Windows I need to set shell=True first:
proc = subprocess.Popen(["app.exe"], stdout=subprocess.PIPE, cwd="workspace", shell=True)

which is odd since by default it should use cwd when searching for binary:
"If cwd is not None, the function changes the working directory to cwd before executing the child. In particular, the function looks for executable (or for the first item in args) relative to cwd if the executable path is a relative path."
from http://docs.python.org/3.3/library/subprocess.html

----------
assignee: docs at python
components: Documentation
messages: 213570
nosy: Jovik, docs at python
priority: normal
severity: normal
status: open
title: Different behaviour on Posix and Windows when using subprocess.Popen(..., cwd=path)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 14 21:40:06 2014
From: report at bugs.python.org (James Bailey)
Date: Fri, 14 Mar 2014 20:40:06 +0000
Subject: [New-bugs-announce] [issue20928] xml.etree.ElementInclude does not
	include nested	xincludes
Message-ID: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za>


New submission from James Bailey:

After xml.etree.ElementInclude.include inserts an Xinclude'd href it does not walk the just-inserted subtree to see if it contains any Xincludes itself.

I think the behaviour should be modified to walk the included subtree and perform any Xincludes contained.

----------
components: Library (Lib), XML
messages: 213589
nosy: James.Bailey
priority: normal
severity: normal
status: open
title: xml.etree.ElementInclude does not include nested xincludes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 15 01:21:50 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 00:21:50 +0000
Subject: [New-bugs-announce] [issue20929] Undefined behavior flagged by
	Clang 3.4
Message-ID: <1394842910.18.0.252723731368.issue20929@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Downloaded Python-3.4.0rc3. Compiled with Clang 3.4, added -fsanitzie=undefined to CFLAGS. Ran 'make' and 'make check'.

Lots of issues, many are duplicates (see below). One or more of these issues might be the reason for `-fwrapv`.

This fellow from objimpl.h seems to be the source of many of the issues:

    #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)

*****

Modules/gcmodule.c:1718:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:120:5: runtime error: left shift of negative value -3
Objects/typeobject.c:905:9: runtime error: left shift of negative value -3
Objects/dictobject.c:818:5: runtime error: left shift of negative value -3
Objects/methodobject.c:45:5: runtime error: left shift of negative value -3
Objects/listobject.c:178:5: runtime error: left shift of negative value -3
Modules/gcmodule.c:1703:9: runtime error: left shift of negative value -2
Modules/gcmodule.c:1693:5: runtime error: left shift of negative value -3
Objects/descrobject.c:9:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:484:13: runtime error: left shift of negative value -3
Objects/tupleobject.c:195:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:503:13: runtime error: left shift of negative value -4
Objects/exceptions.c:2205:5: runtime error: left shift of negative value -2
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/frameobject.c:736:5: runtime error: left shift of negative value -3
Objects/funcobject.c:64:5: runtime error: left shift of negative value -3
Objects/methodobject.c:149:5: runtime error: left shift of negative value -2
Objects/funcobject.c:552:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1364:5: runtime error: left shift of negative value -2
Objects/cellobject.c:16:5: runtime error: left shift of negative value -3
Objects/listobject.c:2744:5: runtime error: left shift of negative value -3
Objects/listobject.c:2751:5: runtime error: left shift of negative value -2
Objects/dictobject.c:3232:5: runtime error: left shift of negative value -3
Objects/dictobject.c:2826:5: runtime error: left shift of negative value -3
Objects/exceptions.c:89:5: runtime error: left shift of negative value -2
Objects/classobject.c:68:5: runtime error: left shift of negative value -3
Objects/classobject.c:193:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:1079:5: runtime error: left shift of negative value -3
Objects/genobject.c:526:5: runtime error: left shift of negative value -3
Objects/tupleobject.c:948:5: runtime error: left shift of negative value -2
Objects/genobject.c:48:5: runtime error: left shift of negative value -2
Objects/genobject.c:53:5: runtime error: left shift of negative value -3
Objects/genobject.c:58:5: runtime error: left shift of negative value -2
Objects/cellobject.c:49:5: runtime error: left shift of negative value -2
Objects/typeobject.c:1170:9: runtime error: left shift of negative value -3
Objects/exceptions.c:662:5: runtime error: left shift of negative value -2
Objects/exceptions.c:1010:5: runtime error: left shift of negative value -2
Objects/exceptions.c:513:5: runtime error: left shift of negative value -2
./Modules/_io/fileio.c:479:5: runtime error: left shift of negative value -2
Objects/setobject.c:944:5: runtime error: left shift of negative value -3
Objects/unicodeobject.c:15267:5: runtime error: left shift of negative value -3
Objects/unicodeobject.c:15128:5: runtime error: left shift of negative value -2
Objects/typeobject.c:6720:5: runtime error: left shift of negative value -2
Objects/bytesobject.c:3006:5: runtime error: left shift of negative value -3
Objects/bytesobject.c:2869:5: runtime error: left shift of negative value -2
Objects/bytearrayobject.c:3094:5: runtime error: left shift of negative value -3
Objects/bytearrayobject.c:2959:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1001:9: runtime error: left shift of negative value -3
Objects/descrobject.c:873:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:861:13: runtime error: left shift of negative value -3
Objects/typeobject.c:2865:5: runtime error: left shift of negative value -2
Objects/dictobject.c:2643:9: runtime error: left shift of negative value -2
Objects/descrobject.c:943:5: runtime error: left shift of negative value -3
Objects/iterobject.c:26:5: runtime error: left shift of negative value -3
Objects/iterobject.c:33:5: runtime error: left shift of negative value -2
Objects/memoryobject.c:74:5: runtime error: left shift of negative value -3
Objects/memoryobject.c:639:5: runtime error: left shift of negative value -3
Objects/memoryobject.c:1060:5: runtime error: left shift of negative value -2
Objects/memoryobject.c:108:5: runtime error: left shift of negative value -2
./Modules/_io/bufferedio.c:402:5: runtime error: left shift of negative value -2
./Modules/_io/textio.c:1156:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1262:9: runtime error: left shift of negative value -3
Objects/listobject.c:2046:22: runtime error: index 623 out of bounds for type 'PyObject *[256]'
Objects/dictobject.c:756:5: runtime error: left shift of negative value -2
Objects/funcobject.c:907:5: runtime error: left shift of negative value -2
Objects/funcobject.c:726:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:1718:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:120:5: runtime error: left shift of negative value -3
Objects/typeobject.c:905:9: runtime error: left shift of negative value -3
Objects/dictobject.c:818:5: runtime error: left shift of negative value -3
Objects/methodobject.c:45:5: runtime error: left shift of negative value -3
Objects/listobject.c:178:5: runtime error: left shift of negative value -3
Modules/gcmodule.c:1703:9: runtime error: left shift of negative value -2
Modules/gcmodule.c:1693:5: runtime error: left shift of negative value -3
Objects/descrobject.c:9:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:484:13: runtime error: left shift of negative value -3
Objects/tupleobject.c:195:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:503:13: runtime error: left shift of negative value -4
Objects/exceptions.c:2205:5: runtime error: left shift of negative value -2
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/frameobject.c:736:5: runtime error: left shift of negative value -3
Objects/funcobject.c:64:5: runtime error: left shift of negative value -3
Objects/methodobject.c:149:5: runtime error: left shift of negative value -2
Objects/funcobject.c:552:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1364:5: runtime error: left shift of negative value -2
Objects/cellobject.c:16:5: runtime error: left shift of negative value -3
Objects/listobject.c:2744:5: runtime error: left shift of negative value -3
Objects/listobject.c:2751:5: runtime error: left shift of negative value -2
Objects/dictobject.c:3232:5: runtime error: left shift of negative value -3
Objects/dictobject.c:2826:5: runtime error: left shift of negative value -3
Objects/exceptions.c:89:5: runtime error: left shift of negative value -2
Objects/classobject.c:68:5: runtime error: left shift of negative value -3
Objects/classobject.c:193:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:1079:5: runtime error: left shift of negative value -3
Objects/genobject.c:526:5: runtime error: left shift of negative value -3
Objects/tupleobject.c:948:5: runtime error: left shift of negative value -2
Objects/genobject.c:48:5: runtime error: left shift of negative value -2
Objects/genobject.c:53:5: runtime error: left shift of negative value -3
Objects/genobject.c:58:5: runtime error: left shift of negative value -2
Objects/cellobject.c:49:5: runtime error: left shift of negative value -2
Objects/typeobject.c:1170:9: runtime error: left shift of negative value -3
Objects/exceptions.c:662:5: runtime error: left shift of negative value -2
Objects/exceptions.c:1010:5: runtime error: left shift of negative value -2
Objects/exceptions.c:513:5: runtime error: left shift of negative value -2
./Modules/_io/fileio.c:479:5: runtime error: left shift of negative value -2
Objects/unicodeobject.c:15267:5: runtime error: left shift of negative value -3
Objects/unicodeobject.c:15128:5: runtime error: left shift of negative value -2
Objects/typeobject.c:6720:5: runtime error: left shift of negative value -2
Objects/setobject.c:944:5: runtime error: left shift of negative value -3
Objects/bytesobject.c:3006:5: runtime error: left shift of negative value -3
Objects/bytesobject.c:2869:5: runtime error: left shift of negative value -2
Objects/bytearrayobject.c:3094:5: runtime error: left shift of negative value -3
Objects/bytearrayobject.c:2959:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1001:9: runtime error: left shift of negative value -3
Objects/descrobject.c:873:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:861:13: runtime error: left shift of negative value -3
Objects/typeobject.c:2865:5: runtime error: left shift of negative value -2
Objects/iterobject.c:26:5: runtime error: left shift of negative value -3
Objects/iterobject.c:33:5: runtime error: left shift of negative value -2
Objects/dictobject.c:2643:9: runtime error: left shift of negative value -2
Objects/descrobject.c:1262:9: runtime error: left shift of negative value -3
Objects/memoryobject.c:74:5: runtime error: left shift of negative value -3
Objects/memoryobject.c:639:5: runtime error: left shift of negative value -3
running build
Objects/memoryobject.c:1060:5: runtime error: left shift of negative value -2
Objects/memoryobject.c:108:5: runtime error: left shift of negative value -2
running build_ext
./Modules/_io/bufferedio.c:402:5: runtime error: left shift of negative value -2
./Modules/_io/textio.c:1156:5: runtime error: left shift of negative value -2
INFO: Can't locate Tcl/Tk libs and/or headers
Objects/tupleobject.c:878:9: runtime error: left shift of negative value -2
Objects/tupleobject.c:896:5: runtime error: left shift of negative value -3

----------
components: Build
files: python-3-4-make.txt
messages: 213604
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Undefined behavior flagged by Clang 3.4
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34425/python-3-4-make.txt

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

From report at bugs.python.org  Sat Mar 15 02:45:10 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 01:45:10 +0000
Subject: [New-bugs-announce] [issue20930] Debian 7.3: This platform's
	pyconfig.h needs to define	PY_FORMAT_LONG_LONG
Message-ID: <1394847910.61.0.831200672097.issue20930@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Checked out the latest Python from mercurial. Running on Debian 7.3 (x64), fully patched:

$ ./configure --disable-ipv6
...
$ make
...
python3.4 ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
/usr/local/bin/clang -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g3 -fsanitize=undefined -g3 -fsanitize=undefined   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Modules/python.c:3:
In file included from Include/Python.h:50:
Include/pyport.h:261:13: error: "This platform's pyconfig.h needs to define
      PY_FORMAT_LONG_LONG"
#           error "This platform's pyconfig.h needs to define PY_FORMAT_...
            ^
1 error generated.
make: *** [Modules/python.o] Error 1

**********
$ uname -a
Linux debian-q500 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

$ cpp -dM < /dev/null | sort
#define __amd64 1
#define __amd64__ 1
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_ACQUIRE 2
#define __ATOMIC_CONSUME 1
#define __ATOMIC_RELAXED 0
#define __ATOMIC_RELEASE 3
#define __ATOMIC_SEQ_CST 5
#define __BIGGEST_ALIGNMENT__ 16
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __CHAR16_TYPE__ short unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __CHAR_BIT__ 8
#define __DBL_DECIMAL_DIG__ 17
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __DBL_DIG__ 15
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
#define __DBL_HAS_DENORM__ 1
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define __DBL_MAX_EXP__ 1024
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __DBL_MIN_EXP__ (-1021)
#define __DEC128_EPSILON__ 1E-33DL
#define __DEC128_MANT_DIG__ 34
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __DEC128_MAX_EXP__ 6145
#define __DEC128_MIN__ 1E-6143DL
#define __DEC128_MIN_EXP__ (-6142)
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __DEC32_EPSILON__ 1E-6DF
#define __DEC32_MANT_DIG__ 7
#define __DEC32_MAX__ 9.999999E96DF
#define __DEC32_MAX_EXP__ 97
#define __DEC32_MIN__ 1E-95DF
#define __DEC32_MIN_EXP__ (-94)
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC64_MANT_DIG__ 16
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __DEC64_MAX_EXP__ 385
#define __DEC64_MIN__ 1E-383DD
#define __DEC64_MIN_EXP__ (-382)
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __DEC_EVAL_METHOD__ 2
#define __DECIMAL_BID_FORMAT__ 1
#define __DECIMAL_DIG__ 21
#define __ELF__ 1
#define __FINITE_MATH_ONLY__ 0
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT_DECIMAL_DIG__ 9
#define __FLT_DENORM_MIN__ 1.40129846432481707092e-45F
#define __FLT_DIG__ 6
#define __FLT_EPSILON__ 1.19209289550781250000e-7F
#define __FLT_EVAL_METHOD__ 0
#define __FLT_HAS_DENORM__ 1
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MANT_DIG__ 24
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282346638528859812e+38F
#define __FLT_MAX_EXP__ 128
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __FLT_MIN_EXP__ (-125)
#define __FLT_RADIX__ 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GNUC__ 4
#define __GNUC_GNU_INLINE__ 1
#define __GNUC_MINOR__ 7
#define __GNUC_PATCHLEVEL__ 2
#define __gnu_linux__ 1
#define __GXX_ABI_VERSION 1002
#define __INT16_C(c) c
#define __INT16_MAX__ 32767
#define __INT16_TYPE__ short int
#define __INT32_C(c) c
#define __INT32_MAX__ 2147483647
#define __INT32_TYPE__ int
#define __INT64_C(c) c ## L
#define __INT64_MAX__ 9223372036854775807L
#define __INT64_TYPE__ long int
#define __INT8_C(c) c
#define __INT8_MAX__ 127
#define __INT8_TYPE__ signed char
#define __INT_FAST16_MAX__ 9223372036854775807L
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_MAX__ 9223372036854775807L
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_MAX__ 9223372036854775807L
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_MAX__ 127
#define __INT_FAST8_TYPE__ signed char
#define __INT_LEAST16_MAX__ 32767
#define __INT_LEAST16_TYPE__ short int
#define __INT_LEAST32_MAX__ 2147483647
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST64_MAX__ 9223372036854775807L
#define __INT_LEAST64_TYPE__ long int
#define __INT_LEAST8_MAX__ 127
#define __INT_LEAST8_TYPE__ signed char
#define __INT_MAX__ 2147483647
#define __INTMAX_C(c) c ## L
#define __INTMAX_MAX__ 9223372036854775807L
#define __INTMAX_TYPE__ long int
#define __INTPTR_MAX__ 9223372036854775807L
#define __INTPTR_TYPE__ long int
#define __k8 1
#define __k8__ 1
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __LDBL_DIG__ 18
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 64
#define __LDBL_MAX_10_EXP__ 4932
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MAX_EXP__ 16384
#define __LDBL_MIN_10_EXP__ (-4931)
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __LDBL_MIN_EXP__ (-16381)
#define __linux 1
#define __linux__ 1
#define linux 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __LONG_MAX__ 9223372036854775807L
#define __LP64__ 1
#define _LP64 1
#define __MMX__ 1
#define __NO_INLINE__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __PTRDIFF_MAX__ 9223372036854775807L
#define __PTRDIFF_TYPE__ long int
#define __REGISTER_PREFIX__ 
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __SIG_ATOMIC_MAX__ 2147483647
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __SIG_ATOMIC_TYPE__ int
#define __SIZE_MAX__ 18446744073709551615UL
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_FLOAT__ 4
#define __SIZEOF_INT128__ 16
#define __SIZEOF_INT__ 4
#define __SIZEOF_LONG__ 8
#define __SIZEOF_LONG_DOUBLE__ 16
#define __SIZEOF_LONG_LONG__ 8
#define __SIZEOF_POINTER__ 8
#define __SIZEOF_PTRDIFF_T__ 8
#define __SIZEOF_SHORT__ 2
#define __SIZEOF_SIZE_T__ 8
#define __SIZEOF_WCHAR_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __SIZE_TYPE__ long unsigned int
#define __SSE__ 1
#define __SSE2__ 1
#define __SSE2_MATH__ 1
#define __SSE_MATH__ 1
#define __STDC__ 1
#define __STDC_HOSTED__ 1
#define __UINT16_C(c) c
#define __UINT16_MAX__ 65535
#define __UINT16_TYPE__ short unsigned int
#define __UINT32_C(c) c ## U
#define __UINT32_MAX__ 4294967295U
#define __UINT32_TYPE__ unsigned int
#define __UINT64_C(c) c ## UL
#define __UINT64_MAX__ 18446744073709551615UL
#define __UINT64_TYPE__ long unsigned int
#define __UINT8_C(c) c
#define __UINT8_MAX__ 255
#define __UINT8_TYPE__ unsigned char
#define __UINT_FAST16_MAX__ 18446744073709551615UL
#define __UINT_FAST16_TYPE__ long unsigned int
#define __UINT_FAST32_MAX__ 18446744073709551615UL
#define __UINT_FAST32_TYPE__ long unsigned int
#define __UINT_FAST64_MAX__ 18446744073709551615UL
#define __UINT_FAST64_TYPE__ long unsigned int
#define __UINT_FAST8_MAX__ 255
#define __UINT_FAST8_TYPE__ unsigned char
#define __UINT_LEAST16_MAX__ 65535
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __UINT_LEAST32_MAX__ 4294967295U
#define __UINT_LEAST32_TYPE__ unsigned int
#define __UINT_LEAST64_MAX__ 18446744073709551615UL
#define __UINT_LEAST64_TYPE__ long unsigned int
#define __UINT_LEAST8_MAX__ 255
#define __UINT_LEAST8_TYPE__ unsigned char
#define __UINTMAX_C(c) c ## UL
#define __UINTMAX_MAX__ 18446744073709551615UL
#define __UINTMAX_TYPE__ long unsigned int
#define __UINTPTR_MAX__ 18446744073709551615UL
#define __UINTPTR_TYPE__ long unsigned int
#define __unix 1
#define __unix__ 1
#define unix 1
#define __USER_LABEL_PREFIX__ 
#define __VERSION__ "4.7.2"
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __WCHAR_TYPE__ int
#define __WINT_MAX__ 4294967295U
#define __WINT_MIN__ 0U
#define __WINT_TYPE__ unsigned int
#define __x86_64 1
#define __x86_64__ 1

----------
components: Build
files: config.log
messages: 213612
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Debian 7.3: This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file34427/config.log

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

From report at bugs.python.org  Sat Mar 15 03:04:35 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Mar 2014 02:04:35 +0000
Subject: [New-bugs-announce] [issue20931] Confusing section title "New
	Expected Features for	Python Implementations" in 3.4 What's New doc
Message-ID: <1394849075.1.0.404974411409.issue20931@psf.upfronthosting.co.za>


New submission from Ned Deily:

The 3.4 What's New document has a section entitled "New expected features for Python implementations", a title not found in previous releases.  I believe that the intention is to document features expected to be implemented by all Python implementations, including non CPython ones, when they claim to support 3.4.  However, I think the wording is likely to be misunderstood by most readers as meaning "features expected to be in the 3.4 release (including CPython)", leaving a question in their minds as to whether all of the described features are actually in the 3.4 release.  On the other hand, AFAIK, the standard documentation set has never attempted to document all of the deviations from CPython for each particular non-CPython implementation; if the wording is understood as intended, it could be construed as implying something that isn't true.  So, under either reading, the wording can be misleading.  I think it should just be removed or reworded as "New Features".

http://docs.python.org/3.4/whatsnew/3.4.html#summary-release-highlights
http://docs.python.org/3.4/whatsnew/3.4.html#new-expected-features-for-python-implementations

----------
assignee: docs at python
components: Documentation
messages: 213617
nosy: docs at python, larry, ncoghlan, ned.deily
priority: normal
severity: normal
status: open
title: Confusing section title "New Expected Features for Python Implementations" in 3.4 What's New doc
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 15 03:37:32 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 02:37:32 +0000
Subject: [New-bugs-announce] [issue20932] Undefined behavior flagged by
	Clang 3.4 (Python 3.5 from	hg)
Message-ID: <1394851052.88.0.193633571289.issue20932@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Checked out Python-3.5 from mercurial. Compiled with Clang 3.4, added -fsanitzie=undefined to CFLAGS. Ran 'make' and 'make check'. A few issues during `make`:

Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/listobject.c:2046:22: runtime error: index 623 out of bounds for type 'PyObject *[256]'
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'

Similar issues with `make test`, with the addition of some mis-aligned pointers. A digest is below, and the tagCDataObject alignment issue dominates the issues. The tests ended early due to a segfault.

$ make test
...
[ 19/389/1] test_struct
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
/home/jwalton/Desktop/cpython-checkout/Objects/floatobject.c:2028: runtime error: value 3.40282e+38 is outside the range of representable values of type 'float'
/home/jwalton/Desktop/cpython-checkout/Modules/_struct.c:792:15: runtime error: left shift of 72057594037927935 by 8 places cannot be represented in type 'long long'
...
[ 43/389/2] test_cmd_line
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
/home/jwalton/Desktop/cpython-checkout/Modules/_ctypes/_ctypes.c:2890:10: runtime error: member access within misaligned address 0x2b54033f1cc8 for type 'CDataObject' (aka 'struct tagCDataObject'), which requires 16 byte alignment
0x2b54033f1cc8: note: pointer points here
 ff ff ff ff  01 00 00 00 00 00 00 00  68 06 43 03 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^ 
test test_cmd_line failed -- multiple errors occurred; run in verbose mode for details
...
[ 45/389/2] test_datetime
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
/home/jwalton/Desktop/cpython-checkout/Python/pytime.c:218: runtime error: value -1e+200 is outside the range of representable values of type 'long'
/home/jwalton/Desktop/cpython-checkout/Python/pytime.c:218: runtime error: value 1e+200 is outside the range of representable values of type 'long'
...
test test_traceback failed -- Traceback (most recent call last):
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/test_traceback.py", line 155, in test_encoded_file
    do_test("", "foo", "ascii", 3)
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/test_traceback.py", line 132, in do_test
    stdout = stdout.decode(output_encoding).splitlines()
LookupError: unknown encoding: Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
...
[130/389/5] test_capi
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Fatal Python error: Segmentation fault

Current thread 0x00002b6eaf8c7b20 (most recent call first):
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/test_capi.py", line 466 in test__testcapi
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/case.py", line 574 in run
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/case.py", line 622 in __call__
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 125 in run
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 87 in __call__
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 125 in run
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 87 in __call__
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 125 in run
  File "/home/jwalton/Desktop/cpython-checkout/Lib/unittest/suite.py", line 87 in __call__
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/support/__init__.py", line 1584 in run
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 1277 in <lambda>
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 978 in runtest
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 532 in main
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 1587 in <module>
  File "/home/jwalton/Desktop/cpython-checkout/Lib/runpy.py", line 86 in _run_code
  File "/home/jwalton/Desktop/cpython-checkout/Lib/runpy.py", line 171 in _run_module_as_main
Traceback (most recent call last):
  File "/home/jwalton/Desktop/cpython-checkout/Lib/runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/jwalton/Desktop/cpython-checkout/Lib/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/home/jwalton/Desktop/cpython-checkout/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_capi: Exit code -11
make: *** [test] Error 1

----------
components: Build
files: python-3.5-make.txt
messages: 213625
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Undefined behavior flagged by Clang 3.4 (Python 3.5 from hg)
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file34428/python-3.5-make.txt

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

From report at bugs.python.org  Sat Mar 15 05:08:02 2014
From: report at bugs.python.org (Wenzhu Man)
Date: Sat, 15 Mar 2014 04:08:02 +0000
Subject: [New-bugs-announce] [issue20933] bad test case in
	test_osx_proxy_bypass	(test.test_urllib2.HandlerTests)
Message-ID: <1394856482.54.0.380202058287.issue20933@psf.upfronthosting.co.za>


New submission from Wenzhu Man:

in test_urllib2.py file:

 test_osx_proxy_bypass (test.test_urllib2.HandlerTests)
# Check hosts that should not trigger the proxy bypass
 for host in ('abc.foo.bar', 'bar.com', '127.0.0.2', '10.11.0.1', 'test'):
        self.assertFalse(_proxy_bypass_macosx_sysconf(host, bypass),
                              'expected bypass of %s to be False' % host)

for host 'test' under some wifi conditions(University of Waterloo wifi)the socket.gethostbyname('test') returns localhost which is in the exceptions.

the assertion will fail.

this testcase should be modified or we add some condition before the assertion

----------
components: Tests
messages: 213633
nosy: Wenzhu.Man
priority: normal
severity: normal
status: open
title: bad test case in test_osx_proxy_bypass (test.test_urllib2.HandlerTests)
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 15 09:38:55 2014
From: report at bugs.python.org (Andreas Schwab)
Date: Sat, 15 Mar 2014 08:38:55 +0000
Subject: [New-bugs-announce] [issue20934] test_multiprocessing is broken by
	design
Message-ID: <1394872735.24.0.583669310043.issue20934@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

This comment say it all:

CHECK_TIMINGS = False     # making true makes tests take a lot longer
                          # and can sometimes cause some non-serious
                          # failures because some calls block a bit
                          # longer than expected

If the failures happen due to different timeouts then the test is broken by design.

----------
components: Tests
messages: 213646
nosy: schwab
priority: normal
severity: normal
status: open
title: test_multiprocessing is broken by design
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 15 17:14:35 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 16:14:35 +0000
Subject: [New-bugs-announce] [issue20935] Cherry pick CFLAGS,
	add to flags for $(BUILDPYTHON) Makefile rule
Message-ID: <1394900075.84.0.261460174909.issue20935@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

>From Python head in mercurial.

When building Python under Clang's sanitizers, we provide a couple of flags to instrument binaries with the sanitizers. For example:

export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS="-g3 -fsanitize=undefined -fsanitize=address"
export CXXFLAGS="-g3 -fsanitize=undefined -fsanitize=address -fno-sanitize=vptr"
./configure
make

However, `make` will fail due to some missing sanitizer libraries. The libraries are added at the link stage by Clang, but the invocation must include the -fsanitize=... flags.

The recipe for $(BUILDPYTHON) in the Makefile does not include necessary CFLAGS:

# Build the interpreter
$(BUILDPYTHON):	Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
	$(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

The result is a failed link when building with the sanitizers.

It would be great if the sanizter flags (-fsanitize=undefined -fsanitize=address -fno-sanitize=vptr) were cherry picked from the FLAGS by the build system and added to the recipe as required:

$(BUILDPYTHON):	Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
	$(LINKCC) -fsanitize=undefined -fsanitize=address -fno-sanitize=vptr $(PY_LDFLAGS) $(LINKFORSHARED) ...

Please consider picking up the sanitizer flags and adding them to the build rule.

----------
components: Build
hgrepos: 220
messages: 213661
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Cherry pick CFLAGS, add to flags for $(BUILDPYTHON) Makefile rule
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 15 17:45:02 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 16:45:02 +0000
Subject: [New-bugs-announce] [issue20936] test_strftime: enormous allocation,
	fails under Clang sanitizer
Message-ID: <1394901902.95.0.363100076763.issue20936@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

>From Python head in mercurial:

    $ hg id
    7ce22d0899e4+ tip

[118/389/1] test_strftime
==11587==WARNING: AddressSanitizer failed to allocate 0x7fffffffffffffff bytes
==11587==AddressSanitizer's allocator is terminating the process instead of returning 0
==11587==If you don't like this behavior set allocator_may_return_null=1
==11587==AddressSanitizer CHECK failed: /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:149 "((0)) != (0)" (0x0, 0x0)
    #0 0x4d79df in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_rtl.cc:66
    #1 0x4dd241 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:69
    #2 0x4dbf80 in __sanitizer::AllocatorReturnNull() /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:149
    #3 0x4d1a76 in malloc /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75
    #4 0x7c8140 in _buffered_init /home/jwalton/Desktop/cpython-checkout/./Modules/_io/bufferedio.c:772
    #5 0x7c6888 in bufferedreader_init /home/jwalton/Desktop/cpython-checkout/./Modules/_io/bufferedio.c:1424
    #6 0x5b06e8 in wrap_init /home/jwalton/Desktop/cpython-checkout/Objects/typeobject.c:5293
    #7 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #8 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #9 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #10 0x670b7a in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4324
    #11 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #12 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #13 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #14 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #15 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #16 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #17 0x670b7a in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4324
    #18 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #19 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #20 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #21 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #22 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #23 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #24 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #25 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #26 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #27 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #28 0x830dcc in method_call /home/jwalton/Desktop/cpython-checkout/Objects/classobject.c:347
    #29 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #30 0x5ae10f in slot_tp_call /home/jwalton/Desktop/cpython-checkout/Objects/typeobject.c:5809
    #31 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #32 0x6653a0 in do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4456
    #33 0x6653a0 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4254
    #34 0x6653a0 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #35 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #36 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #37 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #38 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #39 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #40 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #41 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #42 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #43 0x830dcc in method_call /home/jwalton/Desktop/cpython-checkout/Objects/classobject.c:347
    #44 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #45 0x5ae10f in slot_tp_call /home/jwalton/Desktop/cpython-checkout/Objects/typeobject.c:5809
    #46 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #47 0x6653a0 in do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4456
    #48 0x6653a0 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4254
    #49 0x6653a0 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #50 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #51 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #52 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #53 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #54 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #55 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #56 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #57 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #58 0x830dcc in method_call /home/jwalton/Desktop/cpython-checkout/Objects/classobject.c:347
    #59 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #60 0x5ae10f in slot_tp_call /home/jwalton/Desktop/cpython-checkout/Objects/typeobject.c:5809
    #61 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #62 0x6653a0 in do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4456
    #63 0x6653a0 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4254
    #64 0x6653a0 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #65 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #66 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #67 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #68 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #69 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #70 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #71 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #72 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #73 0x830dcc in method_call /home/jwalton/Desktop/cpython-checkout/Objects/classobject.c:347
    #74 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #75 0x5ae10f in slot_tp_call /home/jwalton/Desktop/cpython-checkout/Objects/typeobject.c:5809
    #76 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #77 0x6653a0 in do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4456
    #78 0x6653a0 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4254
    #79 0x6653a0 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #80 0x670b7a in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4324
    #81 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #82 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #83 0x670b7a in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4324
    #84 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #85 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #86 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #87 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #88 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #89 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #90 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #91 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #92 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #93 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #94 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #95 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #96 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #97 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #98 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #99 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #100 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #101 0x6642d6 in ext_do_call /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4551
    #102 0x6642d6 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2869
    #103 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #104 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #105 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #106 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #107 0x670b7a in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4324
    #108 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #109 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #110 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #111 0x6545ca in PyEval_EvalCode /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:773
    #112 0x64d74c in builtin_exec /home/jwalton/Desktop/cpython-checkout/Python/bltinmodule.c:876
    #113 0x664ceb in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4227
    #114 0x664ceb in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #115 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #116 0x670cb5 in fast_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4334
    #117 0x65fbc8 in call_function /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:4252
    #118 0x65fbc8 in PyEval_EvalFrameEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:2829
    #119 0x655a7b in PyEval_EvalCodeEx /home/jwalton/Desktop/cpython-checkout/Python/ceval.c:3578
    #120 0x84c177 in function_call /home/jwalton/Desktop/cpython-checkout/Objects/funcobject.c:632
    #121 0x4fd729 in PyObject_Call /home/jwalton/Desktop/cpython-checkout/Objects/abstract.c:2067
    #122 0x4ee527 in RunModule /home/jwalton/Desktop/cpython-checkout/Modules/main.c:209
    #123 0x4ed771 in Py_Main /home/jwalton/Desktop/cpython-checkout/Modules/main.c:693
    #124 0x4e7d54 in main /home/jwalton/Desktop/cpython-checkout/./Modules/python.c:69
    #125 0x2b55a2636eac in __libc_start_main /home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244
    #126 0x4e7b0c in _start (/home/jwalton/Desktop/cpython-checkout/python+0x4e7b0c)

----------
components: Tests
messages: 213666
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: test_strftime: enormous allocation, fails under Clang sanitizer
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 15 18:07:06 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 17:07:06 +0000
Subject: [New-bugs-announce] [issue20937] test_socket: buffer overflow in
	sock_recvmsg_guts
Message-ID: <1394903226.57.0.732764988148.issue20937@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

>From Python head in mercurial:

    $ hg id
    7ce22d0899e4+ tip

Exporting "set allocator_may_return_null=1" for Clang might tickle this issue. Without the export, this test did not fail.

=================================================================
==21071==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030000b99f4 at pc 0x4aafea bp 0x7fffd2318c70 sp 0x7fffd2318c20
WRITE of size 24 at 0x6030000b99f4 thread T0
    #0 0x4aafe9 in write_msghdr /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:1395
    #1 0x4aafe9 in __interceptor_recvmsg /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:1405
    #2 0x2ad35b764146 in sock_recvmsg_guts cpython/./Modules/socketmodule.c:2968
    #3 0x2ad35b75f83c in sock_recvmsg cpython/./Modules/socketmodule.c:3098
    #4 0x6642ba in ext_do_call cpython/./Python/ceval.c:4548
    #5 0x6642ba in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #6 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #7 0x670cb5 in fast_function cpython/./Python/ceval.c:4334
    #8 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #9 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #10 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #11 0x670cb5 in fast_function cpython/./Python/ceval.c:4334
    #12 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #13 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #14 0x670b7a in fast_function cpython/./Python/ceval.c:4324
    #15 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #16 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #17 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #18 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #19 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #20 0x6642d6 in ext_do_call cpython/./Python/ceval.c:4551
    #21 0x6642d6 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #22 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #23 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #24 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #25 0x830dcc in method_call cpython/./Objects/classobject.c:347
    #26 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #27 0x5ae10f in slot_tp_call cpython/./Objects/typeobject.c:5809
    #28 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #29 0x6653a0 in do_call cpython/./Python/ceval.c:4456
    #30 0x6653a0 in call_function cpython/./Python/ceval.c:4254
    #31 0x6653a0 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #32 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #33 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #34 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #35 0x6642d6 in ext_do_call cpython/./Python/ceval.c:4551
    #36 0x6642d6 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #37 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #38 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #39 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #40 0x830dcc in method_call cpython/./Objects/classobject.c:347
    #41 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #42 0x5ae10f in slot_tp_call cpython/./Objects/typeobject.c:5809
    #43 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #44 0x6653a0 in do_call cpython/./Python/ceval.c:4456
    #45 0x6653a0 in call_function cpython/./Python/ceval.c:4254
    #46 0x6653a0 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #47 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #48 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #49 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #50 0x6642d6 in ext_do_call cpython/./Python/ceval.c:4551
    #51 0x6642d6 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #52 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #53 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #54 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #55 0x830dcc in method_call cpython/./Objects/classobject.c:347
    #56 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #57 0x5ae10f in slot_tp_call cpython/./Objects/typeobject.c:5809
    #58 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #59 0x6653a0 in do_call cpython/./Python/ceval.c:4456
    #60 0x6653a0 in call_function cpython/./Python/ceval.c:4254
    #61 0x6653a0 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #62 0x670b7a in fast_function cpython/./Python/ceval.c:4324
    #63 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #64 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #65 0x670b7a in fast_function cpython/./Python/ceval.c:4324
    #66 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #67 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #68 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #69 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #70 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #71 0x6642d6 in ext_do_call cpython/./Python/ceval.c:4551
    #72 0x6642d6 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #73 0x670b7a in fast_function cpython/./Python/ceval.c:4324
    #74 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #75 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #76 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #77 0x670cb5 in fast_function cpython/./Python/ceval.c:4334
    #78 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #79 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #80 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #81 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #82 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #83 0x6642d6 in ext_do_call cpython/./Python/ceval.c:4551
    #84 0x6642d6 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #85 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #86 0x670cb5 in fast_function cpython/./Python/ceval.c:4334
    #87 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #88 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #89 0x670b7a in fast_function cpython/./Python/ceval.c:4324
    #90 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #91 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #92 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #93 0x6545ca in PyEval_EvalCode cpython/./Python/ceval.c:773
    #94 0x64d74c in builtin_exec cpython/./Python/bltinmodule.c:876
    #95 0x664ceb in call_function cpython/./Python/ceval.c:4227
    #96 0x664ceb in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #97 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #98 0x670cb5 in fast_function cpython/./Python/ceval.c:4334
    #99 0x65fbc8 in call_function cpython/./Python/ceval.c:4252
    #100 0x65fbc8 in PyEval_EvalFrameEx cpython/./Python/ceval.c:2829
    #101 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578
    #102 0x84c177 in function_call cpython/./Objects/funcobject.c:632
    #103 0x4fd729 in PyObject_Call cpython/./Objects/abstract.c:2067
    #104 0x4ee527 in RunModule cpython/./Modules/main.c:209
    #105 0x4ed771 in Py_Main cpython/./Modules/main.c:693
    #106 0x4e7d54 in main cpython/././Modules/python.c:69
    #107 0x2ad3549e5eac in __libc_start_main /home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244
    #108 0x4e7b0c in _start (cpython/./python+0x4e7b0c)

0x6030000b99f4 is located 0 bytes to the right of 20-byte region [0x6030000b99e0,0x6030000b99f4)
allocated by thread T0 here:
    #0 0x4d1a39 in malloc /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x2ad35b763c55 in sock_recvmsg_guts cpython/./Modules/socketmodule.c:2949
    #2 0x2ad35b75f83c in sock_recvmsg cpython/./Modules/socketmodule.c:3098
    #3 0x6642ba in ext_do_call cpython/./Python/ceval.c:4548
    #4 0x6642ba in PyEval_EvalFrameEx cpython/./Python/ceval.c:2869
    #5 0x655a7b in PyEval_EvalCodeEx cpython/./Python/ceval.c:3578

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:1395 write_msghdr
Shadow bytes around the buggy address:
  0x0c068000f2e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068000f2f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068000f300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068000f310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068000f320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c068000f330: fa fa fa fa fa fa fa fa fa fa fa fa 00 00[04]fa
  0x0c068000f340: fa fa 00 00 00 00 fa fa fd fd fd fd fa fa fd fd
  0x0c068000f350: fd fd fa fa fd fd fd fd fa fa 00 00 00 00 fa fa
  0x0c068000f360: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
  0x0c068000f370: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
  0x0c068000f380: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe

==21071==ABORTING[ 58/389] test_socket

----------
components: Tests
hgrepos: 221
messages: 213667
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: test_socket: buffer overflow in sock_recvmsg_guts
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 15 19:31:27 2014
From: report at bugs.python.org (Ben W.)
Date: Sat, 15 Mar 2014 18:31:27 +0000
Subject: [New-bugs-announce] [issue20938] Broken link to editors page in
	General FAQ
Message-ID: <1394908287.36.0.782138888196.issue20938@psf.upfronthosting.co.za>


New submission from Ben W.:

The link to http://www.python.org/editors/ at the bottom of the answer to "Is Python a good language for beginning programmers?" in the General Python FAQ is broken.

----------
assignee: docs at python
components: Documentation
messages: 213671
nosy: docs at python, lopsided98
priority: normal
severity: normal
status: open
title: Broken link to editors page in General FAQ
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 15 20:41:17 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Mar 2014 19:41:17 +0000
Subject: [New-bugs-announce] [issue20939] test_geturl of test_urllibnet
	fails with	'https://www.python.org/' != 'http://www.python.org/'
Message-ID: <1394912477.16.0.0678033428019.issue20939@psf.upfronthosting.co.za>


New submission from Ned Deily:

It looks like another change to the new python.org website is breaking another test:

======================================================================
FAIL: test_geturl (test.test_urllibnet.urlopenNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_urllibnet.py", line 86, in test_geturl
    self.assertEqual(gotten_url, URL)
AssertionError: 'https://www.python.org/' != 'http://www.python.org/'
- https://www.python.org/
?     -
+ http://www.python.org/

----------
components: Tests
messages: 213677
nosy: ned.deily
priority: high
severity: normal
stage: needs patch
status: open
title: test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/'
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 15 21:46:44 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 20:46:44 +0000
Subject: [New-bugs-announce] [issue20940] Test 239: buffer overflow in
	sock_recvmsg_guts
Message-ID: <1394916404.49.0.725449047453.issue20940@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Test 240 also suffers from a buffer overflow on sock_recvmsg_guts.

Test 240 is the test that follows 239, and 239 is "[239/389/2] test_unittest". (I don't believe the message for 239 has flushed).

=================================================================
==29767==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030000c0ce4 at pc 0x4aafea bp 0x7fff4c426010 sp 0x7fff4c425fc0
WRITE of size 24 at 0x6030000c0ce4 thread T0
    #0 0x4aafe9 in write_msghdr /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:1395
    #1 0x4aafe9 in __interceptor_recvmsg /home/jwalton/Desktop/clang-3.4/llvm-3.4/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:1405
    #2 0x2b955a764166 in sock_recvmsg_guts ./Modules/socketmodule.c:2968
    #3 0x2b955a75f856 in sock_recvmsg ./Modules/socketmodule.c:3098
    #4 0x6642ea in ext_do_call ./Python/ceval.c:4548
    #5 0x6642ea in PyEval_EvalFrameEx ./Python/ceval.c:2869
    #6 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #7 0x670ce5 in fast_function ./Python/ceval.c:4334
    #8 0x65fbf8 in call_function ./Python/ceval.c:4252
    #9 0x65fbf8 in PyEval_EvalFrameEx ./Python/ceval.c:2829
    #10 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #11 0x670ce5 in fast_function ./Python/ceval.c:4334
    #12 0x65fbf8 in call_function ./Python/ceval.c:4252
    #13 0x65fbf8 in PyEval_EvalFrameEx ./Python/ceval.c:2829
    #14 0x670baa in fast_function ./Python/ceval.c:4324
    #15 0x65fbf8 in call_function ./Python/ceval.c:4252
    #16 0x65fbf8 in PyEval_EvalFrameEx ./Python/ceval.c:2829
    #17 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #18 0x84c1a7 in function_call ./Objects/funcobject.c:632
    #19 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #20 0x664306 in ext_do_call ./Python/ceval.c:4551
    #21 0x664306 in PyEval_EvalFrameEx ./Python/ceval.c:2869
    #22 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #23 0x84c1a7 in function_call ./Objects/funcobject.c:632
    #24 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #25 0x830dfc in method_call ./Objects/classobject.c:347
    #26 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #27 0x5ae13f in slot_tp_call ./Objects/typeobject.c:5809
    #28 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #29 0x6653d0 in do_call ./Python/ceval.c:4456
    #30 0x6653d0 in call_function ./Python/ceval.c:4254
    #31 0x6653d0 in PyEval_EvalFrameEx ./Python/ceval.c:2829
    #32 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #33 0x84c1a7 in function_call ./Objects/funcobject.c:632
    #34 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #35 0x664306 in ext_do_call ./Python/ceval.c:4551
    #36 0x664306 in PyEval_EvalFrameEx ./Python/ceval.c:2869
    #37 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #38 0x84c1a7 in function_call ./Objects/funcobject.c:632
    #39 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #40 0x830dfc in method_call ./Objects/classobject.c:347
    #41 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #42 0x5ae13f in slot_tp_call ./Objects/typeobject.c:5809
    #43 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #44 0x6653d0 in do_call ./Python/ceval.c:4456
    #45 0x6653d0 in call_function ./Python/ceval.c:4254
    #46 0x6653d0 in PyEval_EvalFrameEx ./Python/ceval.c:2829
    #47 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #48 0x84c1a7 in function_call ./Objects/funcobject.c:632
    #49 0x4fd729 in PyObject_Call ./Objects/abstract.c:2067
    #50 0x664306 in ext_do_call ./Python/ceval.c:4551
    #51 0x664306 in PyEval_EvalFrameEx ./Python/ceval.c:2869
    #52 0x655aab in PyEval_EvalCodeEx ./Python/ceval.c:3578
    #53 0x84c1a7 in function_call ./Objects/funcobject.c:632

[Missing remainder of trace]

----------
components: Tests
hgrepos: 222
messages: 213683
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Test 239: buffer overflow in sock_recvmsg_guts
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 15 22:48:45 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sat, 15 Mar 2014 21:48:45 +0000
Subject: [New-bugs-announce] [issue20941] pytime.c:184 and pytime.c:218:
	runtime error,
	outside the range of representable values of type 'long'
Message-ID: <1394920125.71.0.89652214774.issue20941@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

pytime.c:184: runtime error: value -1e+200 is outside the range of representable values of type 'long'

   and

pytime.c:218: runtime error: value -1e+200 is outside the range of representable values of type 'long'

It appears the cast on 'intpart' is generating the finding. 'intpart' is a double.

    *sec = (time_t)intpart;
    err = intpart - (double)*sec;
    if (err <= -1.0 || err >= 1.0) {
        error_time_t_overflow();
        return -1;
    }

Shouldn't a range test based on TIME_T_MAX with an epsilon occur first?

----------
components: Tests
hgrepos: 223
messages: 213686
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 06:42:27 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Mar 2014 05:42:27 +0000
Subject: [New-bugs-announce] [issue20942] _frozen_importlib should not have
	a __file__ attribute
Message-ID: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As part of the PEP 451 changes, frozen imports were updated to avoid setting the __file__ attribute, as that attribute makes no sense for frozen modules.

However, _frozen_importlib isn't loaded through the normal mechanisms (they don't exist yet!), so it is still getting a __file__ attribute set. (This was discovered while investigating issue 20884)

This is a fairly harmless state of affairs, so I suggest we leave it alone in the 3.4 maintenance releases, and just tidy it up in 3.5. However, I'm also open to fixing it in 3.4.1.

----------
components: Interpreter Core
messages: 213719
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: _frozen_importlib should not have a __file__ attribute
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 13:19:11 2014
From: report at bugs.python.org (=?utf-8?q?Michael_M=C3=BCller?=)
Date: Sun, 16 Mar 2014 12:19:11 +0000
Subject: [New-bugs-announce] [issue20943] configparser - add 'getDict'
	function
Message-ID: <1394972351.44.0.319802284218.issue20943@psf.upfronthosting.co.za>


New submission from Michael M?ller:

It would be nice to have a 'getDict' function in the configparser lib.

Adding that function would be simply

def getDict(self, *args):
        return dict([entry for entry in self.items(*args)])

inside the RawConfigParser class next to the other get* functions.

----------
components: Library (Lib)
messages: 213721
nosy: Michael.M?ller, lukasz.langa
priority: normal
severity: normal
status: open
title: configparser - add 'getDict' function
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar 16 15:48:35 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sun, 16 Mar 2014 14:48:35 +0000
Subject: [New-bugs-announce] [issue20944] Engineering Process Improvements
Message-ID: <1394981315.04.0.921658084399.issue20944@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Python's code is crisp and sharp. From a software design perspective, I don't see a lot of room for improvement. However, looking at some of the issues flagged by Clang sanitizers and existing bug reports, I think the project has a couple of small opportunities for improvement in the engineering process. The small improvements have the potential for large payoffs, and could help take a mature code base to the next level.

The improvements are not sexy, and they are often overlooked. The improvements are: (1) add instrumentation to the code; and (2) add scanning and analysis to the engineering process. To improve the code and engineering process to proactively hunt obscure and hard to find bugs, I would suggest three actionable items:

  * ASSERTions
  * Clang Santizers
  * Coverity Scans

Placing measures to proactively hunt bugs will improve the code quality, and likely allow the project to drop `-fwrapv` and friends from compiler options (http://bugs.python.org/issue1621).

ASSERTions
==========
The code uses Posix's little assert on occasion. Posix assert is useless during development because it raise SIGABRT. Additionally, the code has minimal assertions, so assertions are not being utilized effectively.

I think there is an opportunity to use a big ASSERT. The big ASSERT raises a SIGTRAP, and during development it will ensure the debugger snaps on an unexpected condition. The big ASSERT raises awareness where needed and allows the developers to continue handling on a negative code path.

ASSERTs should be liberally sprinkled. That is, ASSERT parameters, return values and program state. Python is setup correctly with NDEBUG on Release builds, so the ASSERTs will be removed in production.

With a full compliment of ASSERTs in place, the code will essential debug itself under most circumstances. In fact, I often pitch it as "self-debugging code" to management.

 Self debugging code has three benefits. First, self debugging code is effectively a force multiplier, and it allows fewer developers to maintain a larger code base. Second, it allows non-senior members to effectively contribute to the project. Google Summer of Code interns and junior developers could be effective team members since the ASSERTs will often guide them in tracing problems. Third, ASSERTs free up time for other endeavors, like adding features to Python or watching football.

Clang Sanitizers
===============
I think the code base would benefit from regular Clang sanitizer scans. From initial scanning and testing, I believe Clang and its sanitizers has shown its value.

The sanitizers perform dynamic analysis. The issues flagged are almost always real issues, and require almost no filtering due to false positives. The analysis should include the undefined behavior sanitizer (-fsanitize=undefined) and the address sanitizer (-fsanitize=address). There are more sanitizers available, and they are listed at http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation.

>From past experience, I've used Asan (address sanitizer) and UBsan (undefined behavior sanitizer) to find tricky bugs in other projects and libraries. For example, Wei Dai's Crypto++ would fail one self test when compiled with Intel's ICC (but pass them all under Clang, Comeau, GCC and MSVC).

The failed Crypto++ self test was due to ICC aggressively removing undefined behavior, and the Intel compiler/optimizer targeted [not readily apprent] undefined behavior in the underlying library code. After fixing the library code identifed by Clang UBsan, Crypto++ tested fine under all compilers.

The real beauty here is: (1) Python already has a mature process, so the addition of the Clang analysis will take minimal effort; and (2) Python has a rich set of self-test, so the Clang sanitizers can *really* be effective.

For areas that don't have complete self test coverage, its another task that can be delegated to non-senior members and contributors. That frees up time for senior members to do other things, like adding features to Python or watching football.

Coverity Scans
==============
I think the project could benefit from Coverity scanning and analysis. The analysis is quite good most of the time, and I believe it will complement Python's exiting engineering process. In addition, it will complement Clang analysis is Clang is adopted.

Coverity is one of the high-end analysis engines available. Though Coverity is a pay-to-play service, Coverity offers a free scanning service for free projects. The URL for the free service is http://scan.coverity.com. It cost nothing to sign up for, and it costs nothing to run a scan. Minimal effort is required to prepare a binary for upload.

Coverity performs static analysis, and it will flag false positives on occasion. However, its a trade-off in the effort to proactively hunt bugs.

----------
components: Build
messages: 213728
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Engineering Process Improvements
type: enhancement

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

From report at bugs.python.org  Sun Mar 16 16:08:05 2014
From: report at bugs.python.org (coder.maliubiao)
Date: Sun, 16 Mar 2014 15:08:05 +0000
Subject: [New-bugs-announce] [issue20945] why save the item to be replaced
	as olditem in	PyTuple_SetItem? It's not useful at all.
Message-ID: <1394982485.15.0.988221424677.issue20945@psf.upfronthosting.co.za>


New submission from coder.maliubiao:

code:
int
PyTuple_SetItem(register PyObject *op, register Py_ssize_t i, PyObject *newitem)
{
    register PyObject *olditem;
    register PyObject **p;
    if (!PyTuple_Check(op) || op->ob_refcnt != 1) {
        Py_XDECREF(newitem);
        PyErr_BadInternalCall();
        return -1;
    }
    if (i < 0 || i >= Py_SIZE(op)) {
        Py_XDECREF(newitem);
        PyErr_SetString(PyExc_IndexError,
                        "tuple assignment index out of range");
        return -1;
    }
    p = ((PyTupleObject *)op) -> ob_item + i;
    olditem = *p;
    *p = newitem;
    Py_XDECREF(olditem);
    return 0;
}

olditem is not useful.

----------
components: Devguide
messages: 213730
nosy: ezio.melotti, maliubiao at gmail.com
priority: normal
severity: normal
status: open
title: why save the item to be replaced as olditem in PyTuple_SetItem?  It's not useful at all.
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 16 17:21:37 2014
From: report at bugs.python.org (Andreas Schwab)
Date: Sun, 16 Mar 2014 16:21:37 +0000
Subject: [New-bugs-announce] [issue20946] ctypes test fixes
Message-ID: <1394986897.24.0.595510368024.issue20946@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

The attached patch fixes some wrong alignment assumptions in the ctype tests.  It has been tested on {ppc,ppc64,ppc64le,i586,x86_64,armv6hl,aarch64,m68k}-suse-linux.

----------
components: Tests
files: ctypes-align.patch
keywords: patch
messages: 213735
nosy: schwab
priority: normal
severity: normal
status: open
title: ctypes test fixes
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34440/ctypes-align.patch

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

From report at bugs.python.org  Sun Mar 16 18:39:57 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sun, 16 Mar 2014 17:39:57 +0000
Subject: [New-bugs-announce] [issue20947] -Wstrict-overflow findings
Message-ID: <1394991597.86.0.942219538296.issue20947@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

$ hg id
3736bf94535c+ tip

Forgive me if you were aware of these. 

/usr/bin/gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I./Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/usr/local/include -Icpython/./Include -Icpython/. -c cpython/./Modules/_posixsubprocess.c -o build/temp.linux-x86_64-3.4cpython/./Modules/_posixsubprocess.o
cpython/./Modules/_posixsubprocess.c: In function ?child_exec?:
cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]
cpython/./Modules/_posixsubprocess.c: In function ?subprocess_fork_exec?:
cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]
cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]
cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]
...

/usr/bin/gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I./Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/usr/local/include -Icpython/./Include -Icpython/. -c cpython/./Modules/sha512module.c -o build/temp.linux-x86_64-3.4cpython/./Modules/sha512module.o
cpython/./Modules/sha512module.c: In function ?sha512_transform?:
cpython/./Modules/sha512module.c:128:1: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]
cpython/./Modules/sha512module.c:128:1: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow]

----------
components: Build
hgrepos: 224
messages: 213742
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: -Wstrict-overflow findings
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 18:41:35 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sun, 16 Mar 2014 17:41:35 +0000
Subject: [New-bugs-announce] [issue20948] -Wformat=2 -Wformat-security
	findings
Message-ID: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

$ hg id
3736bf94535c+ tip

-Wformat=2 -Wformat-security are useful for detecting possible security related bugs. Compiling with the two options produced a few hits in the source code.

/usr/bin/gcc -pthread -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align  -Wtrampolines  -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align  -Wtrampolines    -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Objects/unicodeobject.o cpython/./Objects/unicodeobject.c
cpython/./Objects/unicodeobject.c: In function ?unicode_fromformat_arg?:
cpython/./Objects/unicodeobject.c:2527:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2531:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2535:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2538:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2542:13: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2549:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2553:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2557:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Objects/unicodeobject.c:2560:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]

I think those are necessary for to `unicode_fromformat_arg`.

/usr/bin/gcc -pthread -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align  -Wtrampolines  -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align  -Wtrampolines    -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/main.o cpython/./Modules/main.c
cpython/./Modules/main.c: In function ?usage?:
cpython/./Modules/main.c:111:5: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Modules/main.c:118:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
cpython/./Modules/main.c:119:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]

I think the occurrences in main.c could benefit from "%s" to ensure the program does not accidentally leak.

----------
components: Build
hgrepos: 225
messages: 213743
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: -Wformat=2 -Wformat-security findings
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 20:37:03 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sun, 16 Mar 2014 19:37:03 +0000
Subject: [New-bugs-announce] [issue20949] Missing platform security
	integrations
Message-ID: <1394998623.61.0.250593398151.issue20949@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

$ hg id
3736bf94535c+ tip

A standard Python build does not take a proactive approach to integrating with platform security measures. Attepting to add the measures results in a failed build.

For example:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
export CFLAGS="-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2"
export CXXFLAGS="-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2"
export LDFLAGS="-pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro"

will configure properly, but will fail to build.

The idea is to build executables with {-fPIE,-pie} and build shared objects with {-fPIC,-shared}. Both executables and shared objects get the remaining platform security integrations like stack protectors and NX stacks/heaps.

In the case an object file is used for both an executable and shared object, it should be compiled with -fPIC (and linking will include -pie or -shared as required). Its OK to use -fPIC in place of -fPIE. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 for details.

*****

Examining the failed compile:

/usr/bin/gcc -pthread -shared -pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro -pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro -pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro -fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.4/home/jwalton/Desktop/cpython-checkout/Modules/_struct.o -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -o build/lib.linux-x86_64-3.4/_struct.cpython-34m.so

So, autotools tried to add both -pie (for executables) and -shared (for shared objects). Fail.

The same problem occurs with _struct.cpython-34m.so, _ctypes_test.cpython-34m.so, array.cpython-34m.so, cmath.cpython-34m.so, math.cpython-34m.so, time.cpython-34m.so, _datetime.cpython-34m.so, _random.cpython-34m.so, _bisect.cpython-34m.so, ...

*****

I know I can omit -pie from CFLAGS and CXXFLAGS:

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
export CFLAGS="-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2"
export CXXFLAGS="-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2"
export LDFLAGS="-Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro"

but then I have to manually add -pie to Makefile lines with $BUILDPYTHON (and others, like _testembed and _freeze_importlib):

$(BUILDPYTHON):	Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
	$(LINKCC) -pie $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
...

*****

Examining an executable produced by the modified Makefil with Tobias Klein's Checksec (http://www.trapkit.de/tools/checksec.html) shows the platform security integrations were successfully applied:

$ checksec.sh --file ./python
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   ./python

*****

Running `make test` with the security integrations worked as expected, and did not result in any adverse behavior (like an abrupt shutdown).

*****

It would be great if Python tested for features like ASLR for executables, and simply added {-fPIE,-pie} as available. The same is true for the other security offerings (_FORTIFY_SOURCE should be added to Release builds only).

----------
components: Build
hgrepos: 226
messages: 213749
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Missing platform security integrations
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 21:17:10 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Sun, 16 Mar 2014 20:17:10 +0000
Subject: [New-bugs-announce] [issue20950] asyncio.docs :
	asyncio.subprocess.Process.wait() method	typo
Message-ID: <1395001030.61.0.991983384964.issue20950@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

The asyncio.subprocess.Process.wait() documentation mention "self" parameter (typo ?) and don't tell it's a coroutine.

----------
assignee: docs at python
components: Documentation
messages: 213753
nosy: ajaborsk, docs at python
priority: normal
severity: normal
status: open
title: asyncio.docs : asyncio.subprocess.Process.wait() method typo
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 16 22:16:31 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 16 Mar 2014 21:16:31 +0000
Subject: [New-bugs-announce] [issue20951] SSLSocket.send() returns 0 for
	non-blocking socket
Message-ID: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

When using non-blocking operation, the SSLSocket.send method returns 0 if no data can be sent at this point.

This is counterintuitive, because in the same situation (write to non-blocking socket that isn't ready for IO):

 * A regular (non-SSL) socket raises BlockingIOError
 * libc's send(2) does not return 0, but -EAGAIN or -EWOULDBLOCK.
 * OpenSSL's ssl_write does not return 0, but returns an SSL_ERROR_WANT_WRITE error
 * The ssl module's documentation describes the SSLWantWrite exception as "A subclass of SSLError raised by a non-blocking SSL socket when trying to read or write data, but more data needs to be sent on the underlying TCP transport before the request can be fulfilled."
 * Consistent with that, trying to *read* from a non-blocking SSLSocket when no data is ready raises SSLWantRead, instead of returning zero.

This behavior also makes it more complicated to write code that works with both SSLSockets and regular sockets.


Since the current behavior undocumented at best (and contradicting the documentation at worst), can we change this in Python 3.5?

----------
components: Library (Lib)
messages: 213759
nosy: christian.heimes, giampaolo.rodola, janssen, nikratio, pitrou
priority: normal
severity: normal
status: open
title: SSLSocket.send() returns 0 for non-blocking socket
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 16 23:43:43 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Sun, 16 Mar 2014 22:43:43 +0000
Subject: [New-bugs-announce] [issue20952] OpenSSL and RDRAND
Message-ID: <1395009823.06.0.12513934029.issue20952@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Some versions of OpenSSL use the RDRAND engine by default. The versions include openssl-1.0.1-beta1 through openssl-1.0.1f.

RDRAND has taken some criticism because its essentially unaudited and it could be spiked like the Dual-EC generator (http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html).

If the RDRAND engine is in effect, then the application and the library (internally) will be using the generator. But some some folks don't want to use an unaudited generator.

I'm not sure what the best action is to take. For reading on ways to disable the RDRAND engine, see http://seclists.org/fulldisclosure/2013/Dec/142.

----------
components: Extension Modules
messages: 213769
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: OpenSSL and RDRAND

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

From report at bugs.python.org  Mon Mar 17 04:28:17 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Mon, 17 Mar 2014 03:28:17 +0000
Subject: [New-bugs-announce] [issue20953] heap-buffer-overflow in
	obmalloc.c:987
Message-ID: <1395026897.45.0.655059573662.issue20953@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

This came from Python 3.3.5 downloaded from thePython download page (). 

The issue occurred while compiling with Clang 3.4 using the address sanitizer (-fsanitize=address)

/usr/local/bin/clang -fsanitize=address   -Xlinker -export-dynamic -o python Modules/python.o libpython3.3m.a -ldl  -lutil /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -ldl   -lm  
./python -E -S -m sysconfig --generate-posix-vars
=================================================================
==24064==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000004020 at pc 0x4ed4b2 bp 0x7fff80fff010 sp 0x7fff80fff008
READ of size 4 at 0x619000004020 thread T0
    #0 0x4ed4b1 in PyObject_Free Python-3.3.5/./Objects/obmalloc.c:987
    #1 0x7a2141 in code_dealloc Python-3.3.5/./Objects/codeobject.c:359
    #2 0x620c00 in PyImport_ImportFrozenModuleObject Python-3.3.5/./Python/import.c:1098
    #3 0x620d5c in PyImport_ImportFrozenModule Python-3.3.5/./Python/import.c:1114
    #4 0x63fd07 in import_init Python-3.3.5/./Python/pythonrun.c:206
    #5 0x63f636 in _Py_InitializeEx_Private Python-3.3.5/./Python/pythonrun.c:369
    #6 0x681d77 in Py_Main Python-3.3.5/./Modules/main.c:648
    #7 0x4e6894 in main Python-3.3.5/././Modules/python.c:62
    #8 0x2abf9a525eac in __libc_start_main /home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244
    #9 0x4e664c in _start (Python-3.3.5/./python+0x4e664c)

AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: heap-buffer-overflow Python-3.3.5/./Objects/obmalloc.c:987 PyObject_Free
Shadow bytes around the buggy address:
  0x0c327fff87b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff87c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff87d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff87e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff87f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c327fff8800: fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff8810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff8820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff8830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff8840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff8850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==24064==ABORTING
make: *** [pybuilddir.txt] Error 1

----------
components: Build
messages: 213788
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: heap-buffer-overflow in obmalloc.c:987
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 17 10:38:58 2014
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 17 Mar 2014 09:38:58 +0000
Subject: [New-bugs-announce] [issue20954] Bug in
	subprocess._args_from_interpreter_flags causes	MemoryError
Message-ID: <1395049138.68.0.283816495419.issue20954@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

Steps to reproduce:

- clone pytest-cov at https://bitbucket.org/schlamar/pytest-cov/commits/ac14225a67d715b6649f8158e05d2389b78620d2
- remove `@pytest.mark.skipif` from `test_multiprocessing_subprocess` in test_pytest_cov.py
- run: `tox --develop -e py27 -- -x`

Result: it fails with MemoryError in `subprocess._args_from_interpreter_flags` because sys.flags.hash_randomization has a value of 2147483647 and it tries to build a string with such a length. Find more details in attached log. Patch is following.

----------
components: Library (Lib), Windows
files: output.log
messages: 213844
nosy: schlamar
priority: normal
severity: normal
status: open
title: Bug in subprocess._args_from_interpreter_flags causes MemoryError
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file34452/output.log

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

From report at bugs.python.org  Mon Mar 17 12:05:58 2014
From: report at bugs.python.org (cheeleong)
Date: Mon, 17 Mar 2014 11:05:58 +0000
Subject: [New-bugs-announce] [issue20955] Unexpected behavior
	in	sqlite3.Connection.set_progress_handler
Message-ID: <1395054358.08.0.240358865675.issue20955@psf.upfronthosting.co.za>


New submission from cheeleong:

I discovered this bug accidentally when i'm trying to test the Python 3.4 package
$ make test

I've encountered the unittest assertion error at CheckOpcodeCount 
with the message, 5 is not greater than 5.

at line 144 here http://hg.python.org/cpython/file/04f714765c13/Lib/sqlite3/test/hooks.py

I read this 
http://docs.python.org/2/library/sqlite3.html#sqlite3.Connection.set_progress_handler
As I understood, n is the step.

I took it out and tried to test it with Python 2.7 and 3.3.5. But the expected results was as the same as 3.4.

I've tried to replace the n with others number and the results returned don't really look like n is the step.

I have no idea if I'm wrong about this. But #python recommended me to submit this as a ticket.

----------
components: Library (Lib)
messages: 213851
nosy: klrkdekira
priority: normal
severity: normal
status: open
title: Unexpected behavior in sqlite3.Connection.set_progress_handler
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 17 12:56:05 2014
From: report at bugs.python.org (Curtis Maloney)
Date: Mon, 17 Mar 2014 11:56:05 +0000
Subject: [New-bugs-announce] [issue20956] tokenize module claims
	generate_tokens returns	namedtuple, but it doesn't
Message-ID: <1395057365.37.0.876415448459.issue20956@psf.upfronthosting.co.za>


New submission from Curtis Maloney:

Although 3.x does yield a named-tuple, 2.x does not, despite the documentation:

    The exact type can be determined by checking the token string field on the named tuple returned from tokenize.tokenize() for the character sequence that identifies a specific operator token.

(I'd much rather this functionality be back-ported from 3, as it's quite simple)

----------
assignee: docs at python
components: Documentation
messages: 213853
nosy: FunkyBob, docs at python
priority: normal
severity: normal
status: open
title: tokenize module claims generate_tokens returns namedtuple, but it doesn't
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 17 13:56:05 2014
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 17 Mar 2014 12:56:05 +0000
Subject: [New-bugs-announce] [issue20957] test_smptnet Fail instead of Skip
	if SSL-port is	unavailable
Message-ID: <1395060965.42.0.624328393078.issue20957@psf.upfronthosting.co.za>


New submission from Lukas Lueg:

If the SSL-port is unavailable due to firewall settings (or the host simply being down), the SSL-tests in test_smtpnet.py fail instead of being skipped.

The tests should be skipped if the smtp.google.com can't be reached and fail only in case of unexpected behaviour.

----------
components: Tests
files: test_smptnet.txt
messages: 213855
nosy: ebfe
priority: normal
severity: normal
status: open
title: test_smptnet Fail instead of Skip if SSL-port is unavailable
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34461/test_smptnet.txt

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

From report at bugs.python.org  Mon Mar 17 14:47:32 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Mon, 17 Mar 2014 13:47:32 +0000
Subject: [New-bugs-announce] [issue20958] Undefined behavior flagged by
	Clang 3.4 (Python 3.4.0)
Message-ID: <1395064052.59.0.380828169672.issue20958@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Python 3.4.0 downloaded from website (https://www.python.org/download/releases/3.4.0/).

Objects/dictobject.c:756:5: runtime error: left shift of negative value -2
Objects/funcobject.c:907:5: runtime error: left shift of negative value -2
Objects/funcobject.c:726:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:1718:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:120:5: runtime error: left shift of negative value -3
Objects/typeobject.c:905:9: runtime error: left shift of negative value -3
Objects/dictobject.c:818:5: runtime error: left shift of negative value -3
Objects/methodobject.c:45:5: runtime error: left shift of negative value -3
Objects/listobject.c:178:5: runtime error: left shift of negative value -3
Modules/gcmodule.c:1703:9: runtime error: left shift of negative value -2
Modules/gcmodule.c:1693:5: runtime error: left shift of negative value -3
Objects/descrobject.c:9:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:484:13: runtime error: left shift of negative value -3
Objects/tupleobject.c:195:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:503:13: runtime error: left shift of negative value -4
Objects/exceptions.c:2205:5: runtime error: left shift of negative value -2
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type 'PyLongObject [262]'
Objects/frameobject.c:736:5: runtime error: left shift of negative value -3
Objects/funcobject.c:64:5: runtime error: left shift of negative value -3
Objects/methodobject.c:149:5: runtime error: left shift of negative value -2
Objects/funcobject.c:552:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1364:5: runtime error: left shift of negative value -2
Objects/cellobject.c:16:5: runtime error: left shift of negative value -3
Objects/listobject.c:2744:5: runtime error: left shift of negative value -3
Objects/listobject.c:2751:5: runtime error: left shift of negative value -2
Objects/dictobject.c:3232:5: runtime error: left shift of negative value -3
Objects/dictobject.c:2826:5: runtime error: left shift of negative value -3
Objects/exceptions.c:89:5: runtime error: left shift of negative value -2
Objects/classobject.c:68:5: runtime error: left shift of negative value -3
Objects/classobject.c:193:5: runtime error: left shift of negative value -2
Objects/tupleobject.c:1079:5: runtime error: left shift of negative value -3
Objects/genobject.c:526:5: runtime error: left shift of negative value -3
Objects/tupleobject.c:948:5: runtime error: left shift of negative value -2
Objects/genobject.c:48:5: runtime error: left shift of negative value -2
Objects/genobject.c:53:5: runtime error: left shift of negative value -3
Objects/genobject.c:58:5: runtime error: left shift of negative value -2
Objects/cellobject.c:49:5: runtime error: left shift of negative value -2
Objects/typeobject.c:1170:9: runtime error: left shift of negative value -3
Objects/exceptions.c:662:5: runtime error: left shift of negative value -2
Objects/exceptions.c:1010:5: runtime error: left shift of negative value -2
Objects/exceptions.c:513:5: runtime error: left shift of negative value -2
./Modules/_io/fileio.c:479:5: runtime error: left shift of negative value -2
Objects/unicodeobject.c:15267:5: runtime error: left shift of negative value -3
Objects/unicodeobject.c:15128:5: runtime error: left shift of negative value -2
Objects/typeobject.c:6720:5: runtime error: left shift of negative value -2
Objects/setobject.c:944:5: runtime error: left shift of negative value -3
Objects/bytesobject.c:3006:5: runtime error: left shift of negative value -3
Objects/bytesobject.c:2869:5: runtime error: left shift of negative value -2
Objects/bytearrayobject.c:3094:5: runtime error: left shift of negative value -3
Objects/bytearrayobject.c:2959:5: runtime error: left shift of negative value -2
Objects/descrobject.c:1001:9: runtime error: left shift of negative value -3
Objects/descrobject.c:873:5: runtime error: left shift of negative value -2
Modules/gcmodule.c:861:13: runtime error: left shift of negative value -3
Objects/typeobject.c:2865:5: runtime error: left shift of negative value -2
Objects/iterobject.c:26:5: runtime error: left shift of negative value -3
Objects/iterobject.c:33:5: runtime error: left shift of negative value -2
Objects/dictobject.c:2643:9: runtime error: left shift of negative value -2
Objects/descrobject.c:1262:9: runtime error: left shift of negative value -3
Objects/memoryobject.c:74:5: runtime error: left shift of negative value -3
Objects/memoryobject.c:639:5: runtime error: left shift of negative value -3
Objects/memoryobject.c:1060:5: runtime error: left shift of negative value -2
Objects/memoryobject.c:108:5: runtime error: left shift of negative value -2
./Modules/_io/bufferedio.c:402:5: runtime error: left shift of negative value -2
./Modules/_io/textio.c:1156:5: runtime error: left shift of negative value -2
INFO: Can't locate Tcl/Tk libs and/or headers
Objects/tupleobject.c:878:9: runtime error: left shift of negative value -2
Objects/tupleobject.c:896:5: runtime error: left shift of negative value -3

----------
components: Tests
messages: 213861
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Undefined behavior flagged by Clang 3.4 (Python 3.4.0)
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 17 15:17:49 2014
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Mon, 17 Mar 2014 14:17:49 +0000
Subject: [New-bugs-announce] [issue20959] print gives wrong error when
	printing *generator
Message-ID: <1395065869.95.0.783966483031.issue20959@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

One of the more interesting ways to use print is printing output of a generator, as print(*generator()).
But if the generator generates a typeError, you get a very unhelpful error message:
>>> #the way it works OK
>>> def f(): yield 'a'+'b'
...
>>> print(*f())
ab
>>> #Now with a type error
>>> def f(): yield 'a'+5
...
>>> print(*f())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: print() argument after * must be a sequence, not generator

The problem is twofold:
- the message is plainly wrong, since it does work with a generator
- the actual error is hidden from view

----------
components: IO
messages: 213869
nosy: jneb
priority: normal
severity: normal
status: open
title: print gives wrong error when printing *generator
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 17 15:18:43 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 17 Mar 2014 14:18:43 +0000
Subject: [New-bugs-announce] [issue20960] Fix usage of the versionchanged
	directive in the	sys.hash_info documentation
Message-ID: <1395065923.5.0.361192440864.issue20960@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: sys-versionchanged.diff
keywords: patch
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Fix usage of the versionchanged directive in the sys.hash_info documentation
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34463/sys-versionchanged.diff

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

From report at bugs.python.org  Mon Mar 17 15:30:55 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 17 Mar 2014 14:30:55 +0000
Subject: [New-bugs-announce] [issue20961] Fix usages of the note directive
	in the documentation
Message-ID: <1395066655.93.0.683819910553.issue20961@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Here's a patch to fix all "ERROR: Error in "note" directive:
invalid option block." errors in the stdlib documentation.

----------
assignee: docs at python
components: Documentation
files: fix-note-directive.diff
keywords: patch
messages: 213871
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Fix usages of the note directive in the documentation
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34464/fix-note-directive.diff

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

From report at bugs.python.org  Mon Mar 17 19:58:46 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 17 Mar 2014 18:58:46 +0000
Subject: [New-bugs-announce] [issue20962] Rather modest chunk size in
	gzip.GzipFile
Message-ID: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I've had the opportunity to use the seek() method of the gzip.GzipFile class for the first time in the past few days. Wondering why it seemed my processing times were so slow, I took a look at the code for seek() and read(). It seems like the chunk size for reading (1024 bytes) is rather small. I created a simple subclass that overrode just seek() and read(), then defined a CHUNK_SIZE to be 16 * 8192 bytes (the whole idea of compressing files is that they get large, right? seems like most of the time we will want to seek pretty far through the file).

Over a small subset of my inputs, I measured about a 2x decrease in run times, from about 54s to 26s. I ran using both gzip.GzipFile and my subclass several times, measuring the last four runs (two using the stdlib implementation, two using my subclass). I measured both the total time of the run, the time to process each input records, and time to execute just the seek() call for each record. The bulk of the per-record time was in the call to seek(), so by reducing that time, I sped up my run-times significantly.

I'm still using 2.7, but other than the usual 2.x->3.x changes, the code looks pretty much the same between 2.7 and (at least) 3.3, and the logic involving the read size doesn't seem to have changed at all.

I'll try to produce a patch if I have a few minutes, but in the meantime, I've attached my modified GzipFile class (produced against 2.7).

----------
components: Library (Lib)
files: gzipseek.py
messages: 213883
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Rather modest chunk size in gzip.GzipFile
type: performance
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34466/gzipseek.py

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

From report at bugs.python.org  Mon Mar 17 21:34:47 2014
From: report at bugs.python.org (chris-buccella)
Date: Mon, 17 Mar 2014 20:34:47 +0000
Subject: [New-bugs-announce] [issue20963] side_effects swapped in Mock
	example
Message-ID: <1395088487.87.0.432114186877.issue20963@psf.upfronthosting.co.za>


New submission from chris-buccella:

http://docs.python.org/3.4/library/unittest.mock-examples.html

Section 26.5.3.9. Mocking a dictionary with MagicMock

In the Note area:

>>> mock.__setitem__ = Mock(side_effect=getitem)
>>> mock.__getitem__ = Mock(side_effect=setitem)


I think these are swapped; should be:

>>> mock.__setitem__ = Mock(side_effect=setitem)
>>> mock.__getitem__ = Mock(side_effect=getitem)

----------
assignee: docs at python
components: Documentation
messages: 213891
nosy: chris-buccella, docs at python
priority: normal
severity: normal
status: open
title: side_effects swapped in Mock example
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 18 00:23:14 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Mar 2014 23:23:14 +0000
Subject: [New-bugs-announce] [issue20964] Add support.check_time_delta()
Message-ID: <1395098594.14.0.725869658921.issue20964@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Follow-up of issue #20910: add a support.check_time_delta() function an a --check-time-delta command line option for Lib/test/regrtest.py. By default, the function tolerate a difference of 500 ms for the maximum delta.

The idea is to set the --check-time-delta option on slowest buildbots to tolerate larger difference.

For example, test_time_and_call_at() of test_asyncio takes 2000 ms instead of 100 ms on the "AMD64 OpenIndiana 3.x" buildbot:
http://bugs.python.org/issue20336#msg208714

----------
components: Tests
files: check_time_delta.patch
keywords: patch
messages: 213914
nosy: haypo
priority: normal
severity: normal
status: open
title: Add support.check_time_delta()
versions: Python 3.5
Added file: http://bugs.python.org/file34471/check_time_delta.patch

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

From report at bugs.python.org  Tue Mar 18 03:17:50 2014
From: report at bugs.python.org (Jeffrey Walton)
Date: Tue, 18 Mar 2014 02:17:50 +0000
Subject: [New-bugs-announce] [issue20965] Clang devguide update
Message-ID: <1395109070.85.0.633835253813.issue20965@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

Updated. Its a lot easier to identify gaps and update once its seen with formatting.

* Added info on interpreting results
* Added info on flags and CFLAGS, CXXFLAGS, CC, and CXX
* Added info on Mac OS X
* Asan -> ASan, UBsan -> UBSan
* Fixed UBSan example formatting
* Added 'make test 2>&1 | asan_symbolize.py' example to text
* Added section on blacklisting or ignoring findings
* Added blacklist example with audioop.c
* Spelling corrections

----------
components: Devguide
files: clang.diff
hgrepos: 227
keywords: patch
messages: 213935
nosy: Jeffrey.Walton, ezio.melotti
priority: normal
severity: normal
status: open
title: Clang devguide update
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file34477/clang.diff

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

From report at bugs.python.org  Tue Mar 18 10:07:19 2014
From: report at bugs.python.org (andy.ma)
Date: Tue, 18 Mar 2014 09:07:19 +0000
Subject: [New-bugs-announce] [issue20966] Documentation Link for "Python
	Tkinter Resources" is	currently broken
Message-ID: <1395133639.04.0.49728308047.issue20966@psf.upfronthosting.co.za>


New submission from andy.ma:

The "Python Tkinter Resources" link(http://www.python.org/topics/tkinter/) resides in the topic of "tkinter ? Python interface to Tcl/Tk"(http://docs.python.org/2/library/tkinter.html) is currently broken.

It redirects to "https://www.python.org/topics/tkinter/" which presented a 404 error.

----------
assignee: docs at python
components: Documentation
messages: 213950
nosy: andyma, docs at python
priority: normal
severity: normal
status: open
title: Documentation Link for "Python Tkinter Resources" is currently broken
type: resource usage
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/issue20966>
_______________________________________

From report at bugs.python.org  Tue Mar 18 15:03:55 2014
From: report at bugs.python.org (Adrian Teng)
Date: Tue, 18 Mar 2014 14:03:55 +0000
Subject: [New-bugs-announce] [issue20967] hashlib memory leak
Message-ID: <1395151435.82.0.675671732533.issue20967@psf.upfronthosting.co.za>


New submission from Adrian Teng:

A particular usage pattern of hashlib will cause a memory leak.

This leaks:
import hashlib
import sys

if __name__ == '__main__':
    data_sha1 = "hello world"
    data_md5 = "hello world"
    for i in xrange(int(1e6)):
        hashlib.sha1(data_sha1)
        hashlib.md5(data_md5)

        if i % 1000 == 0:
            print sys.getrefcount(data_sha1), ",", sys.getrefcount(data_md5)

-------
this doesn't leak:

import hashlib
import sys


if __name__ == '__main__':
    data_sha1 = "hello world"
    data_md5 = "hello world"
    for i in xrange(int(1e6)):
        sha1 = hashlib.sha1()
        sha1.update(data_sha1)
		md5 = hashlib.md5()
		md5.update(data_md5)
        
        if i % 1000 == 0:
            print sys.getrefcount(data_sha1), ", ", sys.getrefcount(data_md5)


See attached for leak memory profiling in linux

----------
components: Library (Lib)
files: memoryleak_min.py
messages: 213961
nosy: ateng
priority: normal
severity: normal
status: open
title: hashlib memory leak
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file34489/memoryleak_min.py

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

From report at bugs.python.org  Tue Mar 18 15:13:34 2014
From: report at bugs.python.org (Johannes Baiter)
Date: Tue, 18 Mar 2014 14:13:34 +0000
Subject: [New-bugs-announce] [issue20968] mock.MagicMock does not mock
	__truediv__
Message-ID: <1395152014.45.0.112877741.issue20968@psf.upfronthosting.co.za>


New submission from Johannes Baiter:

It seems that when creating a MagicMock the magic '__truediv__' method is not replaced with a mock:

>>> import mock
>>> foo = mock.MagicMock()
>>> foo / 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'MagicMock' and 'int'

The same thing works perfectly fine when using the third party module in Python 2.7, since the 2.x '__div__' seems to be mocked:

>>> import mock
>>> foo = mock.MagicMock()
>>> foo/2
<MagicMock name='mock.__div__()' id='139760595027088'>

To clarify the context, I am trying to mock a 'pathlib.Path' object in my unittest, which overloads the division operator, i.e. implements '__truediv__'.

----------
components: Library (Lib)
messages: 213964
nosy: Johannes.Baiter
priority: normal
severity: normal
status: open
title: mock.MagicMock does not mock __truediv__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 18 15:34:09 2014
From: report at bugs.python.org (Christian Clauss)
Date: Tue, 18 Mar 2014 14:34:09 +0000
Subject: [New-bugs-announce] [issue20969] Author of EPUB version of Python
	docs is set to Unknown	instead of PSF
Message-ID: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za>


New submission from Christian Clauss:

http://docs.python.org/3/download.html has an EPUB version of the Python docs but the Author of the document is set to Unknown so this text appears on the cover page and is repeated on the top of every other page throughout the document (in the iBooks app at least). Perhaps something like The Python Software Foundation would be better than Unknown.

To fix this issue, both Makefile and make.bat in https://github.com/python/pythondotorg/blob/master/docs would need to be modified to add the Sphinx -A option to the EPUB make. Perhaps the Release (-R) and/or Version (-V) should also be set to the relevant Python version number.

----------
assignee: docs at python
components: Documentation
messages: 213972
nosy: Christian.Clauss, docs at python
priority: normal
severity: normal
status: open
title: Author of EPUB version of Python docs is set to Unknown instead of PSF
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 18 17:42:49 2014
From: report at bugs.python.org (Aaron Meurer)
Date: Tue, 18 Mar 2014 16:42:49 +0000
Subject: [New-bugs-announce] [issue20970] contradictory documentation for
	prog option of argparse
Message-ID: <1395160969.17.0.758674872934.issue20970@psf.upfronthosting.co.za>


New submission from Aaron Meurer:

I hope it's OK to report documentation issues on this tracker.  Reading http://docs.python.org/3.4/library/argparse.html#prog I had to do a double take. The documentation states, "By default, ArgumentParser objects uses sys.argv[0] to determine how to display the name of the program in help messages." The example then goes on to show it *not* using sys.argv[0] (sys.argv[0] in the second example would be 'subdir\myprogram.py'). 

Furthermore, even though the commands are apparently POSIX style, with a $ prompt and using cd, they use a backslash to access a subdirectory.

----------
assignee: docs at python
components: Documentation
messages: 213988
nosy: Aaron.Meurer, docs at python
priority: normal
severity: normal
status: open
title: contradictory documentation for prog option of argparse

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

From report at bugs.python.org  Tue Mar 18 18:19:02 2014
From: report at bugs.python.org (Jasvir Singh)
Date: Tue, 18 Mar 2014 17:19:02 +0000
Subject: [New-bugs-announce] [issue20971] HTML output of difflib
Message-ID: <1395163142.65.0.134532339762.issue20971@psf.upfronthosting.co.za>


New submission from Jasvir Singh:

HTML output of python difflib is in HTML1 which is outdated now. I am working on updating this library and I'll submit a patch as soon as possible.

----------
components: Library (Lib)
messages: 213992
nosy: Jasvir.Singh
priority: normal
severity: normal
status: open
title: HTML output of difflib
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 18 19:37:26 2014
From: report at bugs.python.org (Mikhail)
Date: Tue, 18 Mar 2014 18:37:26 +0000
Subject: [New-bugs-announce] [issue20972] python34.dll not in System32 or
	SysWOW64 folders after	install python-3.4.0.amd64.msi
Message-ID: <1395167846.8.0.709062302496.issue20972@psf.upfronthosting.co.za>


New submission from Mikhail:

The Windows x86-64 MSI Installer (python-3.4.0.amd64.msi, python-3.3.4.amd64.msi...) does not install python3X.dll in windows\system32 or windows\SysWOW64 folder.

I select an option "install for all users"

Windows 7 64 bit 

(The Windows x86 MSI installer works fine.)

----------
components: Installation
messages: 214002
nosy: mifik
priority: normal
severity: normal
status: open
title: python34.dll not in System32 or SysWOW64 folders after install python-3.4.0.amd64.msi
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Mar 18 21:54:29 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Tue, 18 Mar 2014 20:54:29 +0000
Subject: [New-bugs-announce] [issue20973] Implement proper comparison
	operations for in	_TotalOrderingMixin in ipaddres module.
Message-ID: <1395176069.22.0.2337521372.issue20973@psf.upfronthosting.co.za>


New submission from Auke Willem Oosterhoff:

The comparison methods of _TotalOrderingMixin don't have nice implementation. Some of them raises a NotImplementedError. A few aren't covered in the tests. The comment suggests that these methods has been implemented this way because of issue 10042 which has been fixed. 

[1]:http://hg.python.org/cpython/file/f8b40d33e45d/Lib/ipaddress.py#l396
[2]:http://bugs.python.org/issue10042

----------
components: Library (Lib)
messages: 214017
nosy: OrangeTux, ncoghlan
priority: normal
severity: normal
status: open
title: Implement proper comparison operations for in _TotalOrderingMixin in ipaddres module.
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 18 22:08:30 2014
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 18 Mar 2014 21:08:30 +0000
Subject: [New-bugs-announce] [issue20974] email module docs say not
	compatible with current python	version
Message-ID: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za>


New submission from Jim Jewett:

http://docs.python.org/3.4/library/email.html#package-history

The table ends with email version 5.1, distributed with Python 3.2, and compatible with Python 3.0 to 3.2.

Since Python 3.3 and 3.4 also distribute 5.1.0, I'm betting that the actual compatibility is at least 3.0-3.4.  (Currently, it is also used on the 3.5 tip, but I suppose we don't want to guarantee that yet.)

----------
assignee: docs at python
components: Documentation, email
keywords: easy
messages: 214018
nosy: Jim.Jewett, barry, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: email module docs say not compatible with current python version
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 18 22:49:58 2014
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 18 Mar 2014 21:49:58 +0000
Subject: [New-bugs-announce] [issue20975] Python 3.4 build info wrong in
	code snippet
Message-ID: <1395179398.5.0.851425870515.issue20975@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak:

Notice the wrong build info of Python 3.4 interpreter in the first code snippet at http://docs.python.org/3/tutorial/interpreter.html#interactive-mode. I know this snippet is just an example to show what does executing the command python3.4 do, but still. Anyone interested in fixing this little nuance?

----------
assignee: docs at python
components: Documentation
messages: 214029
nosy: Zvezdoslovec, docs at python
priority: normal
severity: normal
status: open
title: Python 3.4 build info wrong in code snippet
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 19 11:47:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Mar 2014 10:47:40 +0000
Subject: [New-bugs-announce] [issue20976] pyflakes: remove unused imports
Message-ID: <1395226060.54.0.340292135181.issue20976@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I ran pyflakes on Python 3.5. Attached patch removes unused imports.

Sometimes, it's tricky to decide if an import is useless or if it is part of the API.

Strange example using import to define a method!
---
class Message:
    ...
    def get_charsets(self, failobj=None):
        ...
    # I.e. def walk(self): ...
    from email.iterators import walk
---

For the email module, I moved "from quopri import decodestring as _qdecode" from Lib/email/utils.py to email submodules where it used.

I made a similar change in multiprocessing for "from subprocess import _args_from_interpreter_flags".

Since "_qdecode" and "_args_from_interpreter_flags" are private functions, I don't consider that they were part of the public API.

Removing imports might reduce the Python memory footprint and speedup the Python startup.

----------
files: unused_imports.patch
keywords: patch
messages: 214073
nosy: barry, haypo, jnoller, r.david.murray, sbt
priority: normal
severity: normal
status: open
title: pyflakes: remove unused imports
versions: Python 3.5
Added file: http://bugs.python.org/file34511/unused_imports.patch

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

From report at bugs.python.org  Wed Mar 19 11:49:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Mar 2014 10:49:13 +0000
Subject: [New-bugs-announce] [issue20977] pyflakes: undefined "ctype" in 2
	except blocks
Message-ID: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ctype is undefined in the two following blocks:

diff -r 72889bf8531d Lib/email/_header_value_parser.py
--- a/Lib/email/_header_value_parser.py Tue Mar 18 13:21:29 2014 +0100
+++ b/Lib/email/_header_value_parser.py Wed Mar 19 11:47:56 2014 +0100
@@ -2897,6 +2897,7 @@ def parse_content_disposition_header(val
     try:
         token, value = get_token(value)
     except errors.HeaderParseError:
+        # FIXME: ctype: undefined name
         ctype.defects.append(errors.InvalidHeaderDefect(
             "Expected content disposition but found {!r}".format(value)))
         _find_mime_parameters(disp_header, value)
@@ -2928,6 +2929,7 @@ def parse_content_transfer_encoding_head
     try:
         token, value = get_token(value)
     except errors.HeaderParseError:
+        # FIXME: ctype: undefined name
         ctype.defects.append(errors.InvalidHeaderDefect(
             "Expected content trnasfer encoding but found {!r}".format(value)))
     else:

----------
messages: 214074
nosy: barry, haypo, r.david.murray
priority: normal
severity: normal
status: open
title: pyflakes: undefined "ctype" in 2 except blocks
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 19 11:52:38 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Mar 2014 10:52:38 +0000
Subject: [New-bugs-announce] [issue20978] pyflakes: undefined names
Message-ID: <1395226358.4.0.442423011029.issue20978@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I ran pyflakes on Python 3.5. Attached patch fixes some undefined names warnings.

I don't know what to with these two warnings, they look to be false positive:

diff -r 72889bf8531d Lib/multiprocessing/spawn.py
--- a/Lib/multiprocessing/spawn.py      Tue Mar 18 13:21:29 2014 +0100
+++ b/Lib/multiprocessing/spawn.py      Wed Mar 19 11:49:24 2014 +0100
@@ -64,6 +64,7 @@ def freeze_support():
     Run code for process object if this in not the main process
     '''
     if is_forking(sys.argv):
+        # FIXME: main() is undefined
         main()
         sys.exit()
 
diff -r 72889bf8531d Lib/multiprocessing/synchronize.py
--- a/Lib/multiprocessing/synchronize.py        Tue Mar 18 13:21:29 2014 +0100
+++ b/Lib/multiprocessing/synchronize.py        Wed Mar 19 11:50:50 2014 +0100
@@ -51,7 +51,6 @@ class SemLock(object):
     _rand = tempfile._RandomNameSequence()
 
     def __init__(self, kind, value, maxvalue, *, ctx):
-        ctx = ctx or get_context()
         ctx = ctx.get_context()
         unlink_now = sys.platform == 'win32' or ctx._name == 'fork'
         for i in range(100):

----------
files: undefined.patch
keywords: patch
messages: 214075
nosy: haypo, jnoller, sbt
priority: normal
severity: normal
status: open
title: pyflakes: undefined names
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34512/undefined.patch

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

From report at bugs.python.org  Wed Mar 19 15:53:46 2014
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 19 Mar 2014 14:53:46 +0000
Subject: [New-bugs-announce] [issue20979] Calling getdents()/readdir64()
	repeatedly while closing	descriptors provides unexpected behaviour.
Message-ID: <1395240826.46.0.532005505249.issue20979@psf.upfronthosting.co.za>


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

1. Please see last comments/patches for issue8052
2. Not closing some descriptos is security breach (PEP-0446 describes that)


=================
Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour. Reading directory while it modified is not safe by default. For example: http://en.it-usenet.org/thread/18514/15719/. 

So, we should re-open directory if we received full array of structures. I don't know if just lseek(dirfd, 0) sufficies.

Please reopen bug, as Linux behaviour of stable reading /proc/<pid>/fd may be broken in future without any error at python side (!) (typically, second call returns empty list if dir was modified)

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

Also, please check exit code of getdents() instead of just ignoring error and NOT closing file descriptors.
=================

P.S. Please set affected python versions...

----------
components: Library (Lib)
messages: 214100
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.
type: security

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

From report at bugs.python.org  Wed Mar 19 15:53:54 2014
From: report at bugs.python.org (Steven Myint)
Date: Wed, 19 Mar 2014 14:53:54 +0000
Subject: [New-bugs-announce] [issue20980] In multiprocessing.pool,
	ExceptionWithTraceback should derive from Exception
Message-ID: <1395240834.44.0.695907745472.issue20980@psf.upfronthosting.co.za>


New submission from Steven Myint:

In multiprocessing.pool, ExceptionWithTraceback is not derived from Exception. Thus when it is raised, we get the exception, "TypeError: exceptions must derive from BaseException". Attached is a patch that fixes this.

See below example traceback that prompted me to notice this:

Traceback (most recent call last):
  File "/Users/myint/Library/Python/3.4/bin/yolk", line 9, in <module>
    load_entry_point('yolk3k==0.7.3', 'console_scripts', 'yolk')()
  File "/Users/myint/Library/Python/3.4/lib/python/site-packages/yolk/cli.py", line 1123, in main
    my_yolk.run()
  File "/Users/myint/Library/Python/3.4/lib/python/site-packages/yolk/cli.py", line 208, in run
    return getattr(self, action)()
  File "/Users/myint/Library/Python/3.4/lib/python/site-packages/yolk/cli.py", line 240, in show_updates
    for (project_name, version, newest) in _updates(pkg_list, self.pypi):
  File "/Users/myint/Library/Python/3.4/lib/python/site-packages/yolk/cli.py", line 1104, in _updates
    names):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 255, in map
    return self._map_async(func, iterable, mapstar, chunksize).get()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 594, in get
    raise self._value
TypeError: exceptions must derive from BaseException

----------
components: Library (Lib)
files: exception_with_traceback.diff
keywords: patch
messages: 214101
nosy: myint
priority: normal
severity: normal
status: open
title: In multiprocessing.pool, ExceptionWithTraceback should derive from Exception
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34518/exception_with_traceback.diff

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

From report at bugs.python.org  Wed Mar 19 17:38:41 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Mar 2014 16:38:41 +0000
Subject: [New-bugs-announce] [issue20981] ssl doesn't build anymore with old
	OpenSSL versions
Message-ID: <1395247121.79.0.24713590698.issue20981@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Modules/_ssl.c, I see:
---
#if OPENSSL_VERSION_NUMBER < 0x10001000L                   
    dps = X509_get_ext_d2i(certificate, NID_crl_distribution_points,
                           NULL, NULL);
#else                            
    /* Calls x509v3_cache_extensions and sets up crldp */ 
    X509_check_ca(certificate);                     
    dps = certificate->crldp;
#endif   
---

But later X509_check_ca() is used without checking for OpenSSL versions: in cert_store_stats() and get_ca_certs().

As as result, the _ssl cannot be compiled on our FreeBSD 6.4 buildbot anymore.

http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/4590/steps/test/logs/stdio

building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c -o build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.o
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `_get_peer_alt_names':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:818: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:823: warning: passing arg 2 of pointer to function from incompatible pointer type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `PySSL_cipher':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1374: warning: passing arg 1 of `SSL_CIPHER_get_name' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1384: warning: passing arg 1 of `SSL_CIPHER_get_version' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1394: warning: passing arg 1 of `SSL_CIPHER_get_bits' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `cert_store_stats':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:3045: warning: implicit declaration of function `X509_check_ca'
gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_ssl.so: Undefined symbol "X509_check_ca"
building '_multiprocessing' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -IModules/_multiprocessing -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.c -o build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.o
gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.o -L/usr/local/lib -o build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_multiprocessing.so: Undefined symbol "_PyMp_sem_unlink"

Python build finished successfully!
The necessary bits to build these optional modules were not found:
spwd                                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_multiprocessing      _ssl

----------
messages: 214110
nosy: christian.heimes, haypo, pitrou
priority: normal
severity: normal
status: open
title: ssl doesn't build anymore with old OpenSSL versions
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 19 17:53:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Mar 2014 16:53:46 +0000
Subject: [New-bugs-announce] [issue20982] http://www.python.org used in unit
	test is directed to	HTTPS url
Message-ID: <1395248026.28.0.627328538995.issue20982@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Many Python unit tests use http://www.python.org/ but the URL is directed to https://www.python.org/. Tests fail if the ssl module is missing.

I modified test_urllib2.test_issue16464() but then I realized that many more tests are impacted: many tests of test_urllibnet.
---
changeset:   89857:ad0c75b7bd7d
tag:         tip
parent:      89855:9120196b3114
parent:      89856:68335b8afb1f
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Wed Mar 19 17:34:12 2014 +0100
description:
(Merge 3.4) Skip test_urllib2.test_issue16464() is the ssl module is missing


changeset:   89856:68335b8afb1f
branch:      3.4
parent:      89852:c44258b4b7a4
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Wed Mar 19 17:31:20 2014 +0100
files:       Lib/test/test_urllib2.py
description:
Skip test_urllib2.test_issue16464() is the ssl module is missing
---

Should we modify all unit tests to skip them if ssl is missing, or should we use another HTTP URL?

----------
messages: 214112
nosy: haypo
priority: normal
severity: normal
status: open
title: http://www.python.org used in unit test is directed to HTTPS url
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 19 17:59:28 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Wed, 19 Mar 2014 16:59:28 +0000
Subject: [New-bugs-announce] [issue20983] Python 3.4 'repair' Windows
	installation does not	install pip & setuptools packages
Message-ID: <1395248368.62.0.321132661018.issue20983@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

On Windows, when you repair your Python 3.4 installation, it
will not reinstall pip & setuptools. Here by 'repair' I mean
a 'Windows Installer' based repair installation.

Reproduced using:
  * Windows 7 SP1 x64.
  * Python 3.4.0 (32-bit).

To reproduce do the following:
  * Install Python.
    * For example to the target installation folder:
      'C:\Program Files (x32)\Python\Python340'.
    * This will automatically install pip & setuptools
      Python packages.
  * Delete or rename your target installation folder.
  * Rerun your Python installation and choose to repair
    the current installation.
    * This will restore the original target installation
      folder and all the basic installation files under
      that folder, but it will not reinstall pip &
      setuptols Python packages.

----------
components: Installation, Windows
messages: 214113
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: Python 3.4 'repair' Windows installation does not install pip & setuptools packages
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 19 18:46:34 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Wed, 19 Mar 2014 17:46:34 +0000
Subject: [New-bugs-announce] [issue20984] 'Add/Remove Programs' dialog
	missing entries for 32-bit	CPython 'current user only'
	installations on 64-bit Windows
Message-ID: <1395251194.85.0.622620129448.issue20984@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

When you install 32-bit CPython 'for the current user
only' on 64-bit Windows, the installation does not show
up in the Windows 'Add/Remove Programs' dialog (a.k.a.
'Programs and Features' dialog on Windows 7). It does
not show up there even for the current user.

I tested this CPython installation behaviour with the
following CPython versions:
  * 2.3.4 - works correctly
  * 2.5.4 - works correctly
  * 2.6.0 - works correctly
  * 2.6.2 - works correctly
  * 2.6.3 - does not work correctly
  * 2.6.4 - does not work correctly
  * 2.6.6 - does not work correctly
  * 2.7.6 - does not work correctly
  * 3.3.3 - does not work correctly
  * 3.3.5 - does not work correctly
  * 3.4.0 - does not work correctly

All this has been tested using one Windows 7 SP1 (x64)
machine and using only CPython 3.4.0 installation on
another.

Several related observations, indicating that this could
be some sort of a Windows Installer misconfiguration
issue possibly solvable in the CPython installer:

* The same does not occur when you install a 64-bit
  CPython version - its entry is correctly displayed in
  the 'Add/Remove Programs' dialog.

* 32-bit CPython installer still correctly detects that a
  specific 32-bit version has already been installed,
  even if that previous installation is not listed in the
  'Add/Remove Programs' dialog.

* When you ask Windows using its WMI interface to list
  all the products installed on it (e.g. by running
  'wmic product list' on the command-line), all the
  installed CPython versions are correctly displayed,
  even the 32-bit versions not displayed in the
  'Add/Remove Programs' dialog.

I compared MSI packaging related CPython source code
(Tools/msi folder) in 2.6.2 & 2.6.3 releases but failed to
see anything suspicious there. It could be that the
observed beaviour change between those two versions is a
result of the final release packager changing his used
Windows Installer version, but I have not rebuilt CPython,
and its MSI installer to test this theory out.

----------
components: Installation, Windows
messages: 214116
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
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/issue20984>
_______________________________________

From report at bugs.python.org  Wed Mar 19 21:21:49 2014
From: report at bugs.python.org (py.user)
Date: Wed, 19 Mar 2014 20:21:49 +0000
Subject: [New-bugs-announce] [issue20985] Add new style formatting to
	logging.config.fileConfig
Message-ID: <1395260509.42.0.740511724413.issue20985@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/howto/logging.html#configuring-logging

"
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=
"


I tried to make:
format={asctime} - {name} - {levelname} - {message}

and it doesn't work.

In the source, I found this is not implemented.
However, new formatting has more capabilities than old.

----------
components: Library (Lib)
messages: 214129
nosy: py.user
priority: normal
severity: normal
status: open
title: Add new style formatting to logging.config.fileConfig
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar 19 21:45:53 2014
From: report at bugs.python.org (Sean McGrail)
Date: Wed, 19 Mar 2014 20:45:53 +0000
Subject: [New-bugs-announce] [issue20986] test_startup_imports fails in
	test_site while executed	inside venv
Message-ID: <1395261953.74.0.442281582846.issue20986@psf.upfronthosting.co.za>


New submission from Sean McGrail:

test_startup_imports fails in test_site when executed from within a virtual environment (venv). Test passes when not executed within a venv.

$ python -m test test_site

[1/1] test_site
test test_site failed -- Traceback (most recent call last):
  File "/software/python/lib/python3.4/test/test_site.py", line 451, in test_startup_imports
    self.assertFalse(modules.intersection(re_mods), stderr)
AssertionError: {'sre_parse', '_sre', 'sre_constants', 're', 'sre_compile'} is not false

----------
components: Tests
messages: 214134
nosy: finitemachine
priority: normal
severity: normal
status: open
title: test_startup_imports fails in test_site while executed inside venv
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 20 05:37:21 2014
From: report at bugs.python.org (John Yeung)
Date: Thu, 20 Mar 2014 04:37:21 +0000
Subject: [New-bugs-announce] [issue20987] Python for AS/400 (OS/400) is
	actually 2.7
Message-ID: <1395290241.07.0.355599966375.issue20987@psf.upfronthosting.co.za>


New submission from John Yeung:

Not sure if this is the right place to report this, but the "other platforms" page <https://www.python.org/download/other/> says the AS/400 port by Per Gummedal is 2.5. While it's true that he did port 2.5 quite a while back, the 2.7 port has been available for 3 years now.

I will say that I'm happy to see any mention of this platform at all!

----------
assignee: docs at python
components: Documentation
messages: 214172
nosy: John.Yeung, docs at python
priority: normal
severity: normal
status: open
title: Python for AS/400 (OS/400) is actually 2.7
type: enhancement

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

From report at bugs.python.org  Thu Mar 20 05:45:39 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Mar 2014 04:45:39 +0000
Subject: [New-bugs-announce] [issue20988] Recommend
	ssl.create_default_context() in "Security	considerations"
Message-ID: <1395290739.65.0.71721715189.issue20988@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The ssl docs currently have a security warning at the top directing users to the Security Considerations section at http://docs.python.org/3/library/ssl#ssl-security

That section currently dives directly into the technical details of choosing suitable SSL settings, and doesn't reference back to the new http://docs.python.org/3/library/ssl#ssl.create_default_context helper function.

I believe this section should *start* with an example of using the create_default_context() to create an SSL wrapped socket with reasonable settings, and only *then* continue on with the technical details.

----------
assignee: docs at python
components: Documentation
messages: 214173
nosy: alex, christian.heimes, docs at python, giampaolo.rodola, janssen, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Recommend ssl.create_default_context() in "Security considerations"
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 20 05:52:18 2014
From: report at bugs.python.org (Rex Kim)
Date: Thu, 20 Mar 2014 04:52:18 +0000
Subject: [New-bugs-announce] [issue20989] XML File I/O Misbehavior with
	open() when the flag is	'r+'
Message-ID: <1395291138.56.0.807224188986.issue20989@psf.upfronthosting.co.za>


New submission from Rex Kim:

I found a misbehavior when reading and writing XML File by open() with 'r+' flag, some strings will be overlapped at the end of the file. 

you can demonstrate it like below:

f = open(file, "r+")
c = f.read()

# todo: write something to do

f.write(c)
f.close()

Actually I'm not sure if it's bug or not however it might be.

----------
components: IO
messages: 214174
nosy: rexperience7
priority: normal
severity: normal
status: open
title: XML File I/O Misbehavior with open() when the flag is 'r+'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 20 09:00:03 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Mar 2014 08:00:03 +0000
Subject: [New-bugs-announce] [issue20990] pyflakes: undefined names,
	get_context() and main(), in multiprocessing
Message-ID: <1395302403.98.0.300002152741.issue20990@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Two warnings from pyflakes:

diff -r 72889bf8531d Lib/multiprocessing/spawn.py
--- a/Lib/multiprocessing/spawn.py      Tue Mar 18 13:21:29 2014 +0100
+++ b/Lib/multiprocessing/spawn.py      Wed Mar 19 11:49:24 2014 +0100
@@ -64,6 +64,7 @@ def freeze_support():
     Run code for process object if this in not the main process
     '''
     if is_forking(sys.argv):
+        # FIXME: main() is undefined
         main()
         sys.exit()
 
diff -r 72889bf8531d Lib/multiprocessing/synchronize.py
--- a/Lib/multiprocessing/synchronize.py        Tue Mar 18 13:21:29 2014 +0100
+++ b/Lib/multiprocessing/synchronize.py        Wed Mar 19 11:50:50 2014 +0100
@@ -51,7 +51,6 @@ class SemLock(object):
     _rand = tempfile._RandomNameSequence()
 
     def __init__(self, kind, value, maxvalue, *, ctx):
-        ctx = ctx or get_context()
         ctx = ctx.get_context()
         unlink_now = sys.platform == 'win32' or ctx._name == 'fork'
         for i in range(100):

----------
messages: 214182
nosy: haypo, jnoller, sbt, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pyflakes: undefined names, get_context() and main(), in multiprocessing
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 20 09:25:19 2014
From: report at bugs.python.org (Vatel)
Date: Thu, 20 Mar 2014 08:25:19 +0000
Subject: [New-bugs-announce] [issue20991] Issues about relative& absolute
	import way for	Portingfrom python2.4 to python2.7
Message-ID: <1395303919.25.0.639710696496.issue20991@psf.upfronthosting.co.za>


New submission from Vatel:

I just wrote a sample like this:
testPy/
         __init__.py
         client.py
         SoamFactory.c
         SoamFactory.so
         soamapi.py
         sample/testP.py
export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy
Here's the source codes:
__init__.py:
import client
client.py
import soamapi
class Client(soamapi.SessionCallback):

  def __init__(self):
    print "----class Client----"
    super(Client, self).__init__()
    soamapi.initialize()

  def create_session(self):
    sec_cb = soamapi.DefaultSecurityCallback()
    self.connection = soamapi.connect(sec_cb)
soamapi.py
import SoamFactory

class ConnectionSecurityCallback(object):  
  def __init__(self):
    print "----class ConnectionSecurityCallback----"

  def __del__(self):
    pass

  def test_P(self):
    print "test_P in class ConnectionSecurityCallback"

class DefaultSecurityCallback(ConnectionSecurityCallback):
  def __init__(self):
    super(DefaultSecurityCallback, self).__init__()
    print "----class DefaultSecurityCallback----"

  def __del__(self):
    super(DefaultSecurityCallback, self).__del__()

  def test(self):
    print "test in class DefaultSecurityCallback"

class SessionCallback(object):
  def __init__(self):
    pass
 
  def __del__(self):
    pass

def connect(security_callback):
  return SoamFactory.SoamFactory_connect(security_callback)

def initialize():
  SoamFactory.SoamFactory_initialize()

print "call soamapi"
SoamFactory.c
#include "Python.h"
#include "PythonLoop.c"

PyObject* SOAM_API_MODULE = NULL;
PyObject* pyModule = NULL;

static PyObject* SoamFactory_initialize(PyObject* self, PyObject* args){
    PyEval_InitThreads();
    init();
    Py_RETURN_NONE;
}

static PyObject* SoamFactory_connect(PyObject* self, PyObject* args){
    PyObject* pySecCallback = NULL;
    int ok = PyArg_ParseTuple(args, "O", &pySecCallback);
    if (!ok){
        printf("parse tuple error!\n");
        Py_RETURN_NONE;
    }
    if (! PyObject_IsInstance(pySecCallback, connectSecCallback)){
        printf("pySecCallback is not an instance of ConnectionSecurityCallback!\n");
        Py_RETURN_NONE;
    }
    printf("Successful!\n");
    Py_RETURN_NONE;
}

static PyMethodDef SoamFactory[] = {
    {"SoamFactory_connect", SoamFactory_connect, METH_VARARGS, "connection function"},
    {"SoamFactory_initialize", SoamFactory_initialize, METH_VARARGS, "SoamFactory_initialize"},
    {NULL, NULL}
};

void initSoamFactory(){
    PyEval_InitThreads();
    Py_Initialize();
    pyModule = Py_InitModule("SoamFactory", SoamFactory);
    SOAM_API_MODULE = PyImport_ImportModule("soamapi");
}
sample/testP.py
import testPy

print "========================================"
submitter = testPy.client.Client()
submitter.create_session()
print "========================================"

When I ran it on python2.4, it worked well, and the result was
call soamapi
after import soamapi------client.py
========================================
----class Client----
----class ConnectionSecurityCallback----
----class DefaultSecurityCallback----
Successful!
========================================   
     
But when I ran it on python2.7, it worked beyond my expectation, the result was
call soamapi
call soamapi
========================================
----class Client----
----class ConnectionSecurityCallback----
----class DefaultSecurityCallback----
pySecCallback is not an instance of ConnectionSecurityCallback!
========================================

I found that soamapi was imported twice, and I investigated this is related to absolute&relative import way.  PyImport_ImportModule in python2.7 uses absolute import way, it will look up sys.path to get soamapi module, and when testP.py file import testPy module, it will find local module soamapi under testPy package, and binds module's name to package, as testPy.soamapi.
There are two ways to correct it for python2.7, 1) Don't use import testPy, use import client directly to avoid using relative; 2) Use from __future__ import absolute_import to enable absolute import feature.

But there are two Pre-conditions:
1) Should not modify testP.py;
2) Should be ran on both python2.4 and 2.7.

I don't know how to fix it. Is there any official way about how to porting this scenario or better idea?

Thanks,
Vatel

----------
components: Library (Lib)
messages: 214185
nosy: Vatel.Z
priority: normal
severity: normal
status: open
title: Issues about relative& absolute import way for Portingfrom python2.4 to python2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 20 10:39:18 2014
From: report at bugs.python.org (Tommy Carstensen)
Date: Thu, 20 Mar 2014 09:39:18 +0000
Subject: [New-bugs-announce] [issue20992] reading individual bytes of
	multiple binary files using	the Python module fileinput
Message-ID: <1395308358.24.0.394354098821.issue20992@psf.upfronthosting.co.za>


New submission from Tommy Carstensen:

This is my first post on bugs.python.org. I hope I abide to the rules. It was suggested to me on stackoverflow.com, that I request an enhancement to the module fileinput here:
http://stackoverflow.com/questions/22510123/reading-individual-bytes-of-multiple-binary-files-using-the-python-module-filein

I can read the first byte of a binary file like this:

    with open(my_binary_file,'rb') as f:
        f.read(1)

But when I run this code:

    import fileinput
    with fileinput.FileInput(my_binary_file,'rb') as f:
        f.read(1)

then I get this error:

    AttributeError: 'FileInput' object has no attribute 'read'

I would like to propose an enhancement to fileinput, which makes it possible to read binary files byte by byte.

I posted this solution to my problem:

    def process_binary_files(list_of_binary_files):

        for file in list_of_binary_files:
            with open(file,'rb') as f:
                yield f.read(1)

        return

    list_of_binary_files = ['f1', 'f2']
    generate_byte = process_binary_files(list_of_binary_files)
    byte = next(generate_byte)

----------
components: Library (Lib)
messages: 214195
nosy: Tommy.Carstensen
priority: normal
severity: normal
status: open
title: reading individual bytes of multiple binary files using the Python module fileinput
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 20 12:00:56 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Thu, 20 Mar 2014 11:00:56 +0000
Subject: [New-bugs-announce] [issue20993] Quicklink to PEPs is wrong.
Message-ID: <1395313256.29.0.75481590183.issue20993@psf.upfronthosting.co.za>


New submission from Auke Willem Oosterhoff:

Quicklink[1] to PEPs points to the old page which doesn't exists anymore.
Patch provided with correct link.

[1]:http://docs.python.org/devguide/#quick-links

----------
components: Devguide
files: index.patch
keywords: patch
messages: 214202
nosy: OrangeTux, ezio.melotti
priority: normal
severity: normal
status: open
title: Quicklink to PEPs is wrong.
versions: Python 3.5
Added file: http://bugs.python.org/file34530/index.patch

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

From report at bugs.python.org  Thu Mar 20 14:53:36 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Mar 2014 13:53:36 +0000
Subject: [New-bugs-announce] [issue20994] Disable TLS Compression
Message-ID: <1395323616.33.0.927638655451.issue20994@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Since Python 3.3 the ssl module has supported the ability to opt in to disabling TLS Compression [1]. However TLS Compression has the problem that it typically leaks data through an attack known as CRIME. CRIME is specific to HTTP but the type of attack it employs is not.

I believe that CPython should just flat out disable TLS Compression and it should do so in all currently active branches (2.7, 3.2+). The patch is fairly minor however there is the question of how that should be handled in 3.3+ where there would be a now useless flag and method on SSLContext. The likelhood for breakage is fairly low and all modern browsers have already permanently disabled it.

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

----------
messages: 214234
nosy: christian.heimes, dstufft, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Disable TLS Compression
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 20 15:11:16 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Mar 2014 14:11:16 +0000
Subject: [New-bugs-announce] [issue20995] Use Better Default Ciphers for the
	SSL Module
Message-ID: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za>


New submission from Donald Stufft:

As of right now the default cipher list for the ssl module is DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2, additionally on Python 3.4 when you use create_default_context() then you also additionally get HIGH:!aNULL:!RC4:!DSS.

I think we should change this to the cipher string:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

This will:

* Prefer cipher suites that offer perfect forward secrecy (DHE/ECDHE)
* prefer ECDHE over DHE for better performance
* prefer any AES-GCM over any AES-CBC for better performance and security
* use 3DES as fallback which is secure but slow
* disable NULL authentication, MD5 MACs and DSS for security reasons

This cipher string is taken from urllib3 where it was compiled through the resources of:

* https://www.ssllabs.com/projects/best-practices/index.html
* https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

The compatibility of this is pretty good. The only time this should cause a connection to *fail* is if a server is using an insecure cipher and in that case you can re-enable it by simply passing the original cipher list through the ssl.wrap_socket ciphers function.

----------
messages: 214239
nosy: benjamin.peterson, christian.heimes, dstufft, ezio.melotti, haypo, lemburg, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Use Better Default Ciphers for the SSL Module
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 20 15:16:45 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Mar 2014 14:16:45 +0000
Subject: [New-bugs-announce] [issue20996] Backport TLS 1.1 and 1.2 support
	for ssl_version
Message-ID: <1395325005.18.0.706730120112.issue20996@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Python 3.4 has constants and code to enable forcing the ssl_version to TLS 1.1 or 1.2. As it stands now Python 2.7, 3.2, and 3.3 can successfully connect and will use a TLS 1.1 or 1.2 connection if it's available (new enough OpenSSL) but cannot _force_ a connection to use TLS 1.1 or 1.2.

It would be good to backport this from 3.4, it would involve adding constants to ssl.py, and minimal code to _ssl.c to handle actually forcing the TLS method.

----------
messages: 214241
nosy: alex, christian.heimes, dstufft, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Backport TLS 1.1 and 1.2 support for ssl_version
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar 20 15:50:03 2014
From: report at bugs.python.org (Baptiste Mispelon)
Date: Thu, 20 Mar 2014 14:50:03 +0000
Subject: [New-bugs-announce] [issue20997] Wrong URL fragment identifier in
	search result
Message-ID: <1395327003.08.0.0901954371896.issue20997@psf.upfronthosting.co.za>


New submission from Baptiste Mispelon:

When doing a search for "PYTHONDONTWRITEBYTECODE" on the 2.7 docs (http://docs.python.org/2/search.html?q=PYTHONDONTWRITEBYTECODE), the first (and only) search result is the following link:

http://docs.python.org/2/using/cmdline.html?highlight=pythondontwritebytecode#PYTHONDONTWRITEBYTECODE

(note the `#PYTHONDONTWRITEBYTECODE` at the end)

Clicking this link takes you to the right page but the browser doesn't scroll to the correct position on the page as expected.

This is because there's no element with an `id` of `PYTHONDONTWRITEBYTECODE`. The correct id is `envvar-PYTHONDONTWRITEBYTECODE`.


Things work as expected when searching on version 3 docs (http://docs.python.org/3/search.html?q=PYTHONDONTWRITEBYTECODE), where the correct fragment identifier is generated in the search results.

----------
assignee: docs at python
components: Documentation
messages: 214245
nosy: bmispelon, docs at python
priority: normal
severity: normal
status: open
title: Wrong URL fragment identifier in search result
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 20 19:40:40 2014
From: report at bugs.python.org (Nathan West)
Date: Thu, 20 Mar 2014 18:40:40 +0000
Subject: [New-bugs-announce] [issue20998] fullmatch isn't matching correctly
	under re.IGNORECASE
Message-ID: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za>


New submission from Nathan West:

I have the following regular expression:

In [2]: regex = re.compile("ME IS \w+", re.I)

For some reason, when using `fullmatch`, it doesn't match substrings longer than 1 for the '\w+':

In [3]: regex.fullmatch("ME IS L")
Out[3]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [4]: regex.fullmatch("me is l")
Out[4]: <_sre.SRE_Match object; span=(0, 7), match='me is l'>

In [5]: regex.fullmatch("ME IS Lucretiel")

In [6]: regex.fullmatch("me is lucretiel")


I have no idea why this is happening. Using `match` works fine:

In [7]: regex.match("ME IS L")
Out[7]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [8]: regex.match("ME IS Lucretiel")
Out[8]: <_sre.SRE_Match object; span=(0, 15), match='ME IS Lucretiel'>

In [9]: regex.match("me is lucretiel")
Out[9]: <_sre.SRE_Match object; span=(0, 15), match='me is lucretiel'>

Additionally, using `fullmatch` WITHOUT using the `re.I` flag causes it to work:

In [10]: regex = re.compile("ME IS \w+")

In [11]: regex.fullmatch("ME IS L")
Out[11]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [12]: regex.fullmatch("ME IS Lucretiel")
Out[12]: <_sre.SRE_Match object; span=(0, 15), match='ME IS Lucretiel'>

My platform is Ubuntu 12.04, using Python 3.4 installed from Felix Krull's deadsnakes PPA (https://launchpad.net/~fkrull/+archive/deadsnakes).

----------
components: Regular Expressions
messages: 214257
nosy: Lucretiel, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: fullmatch isn't matching correctly under re.IGNORECASE
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 20 19:50:08 2014
From: report at bugs.python.org (albertjan)
Date: Thu, 20 Mar 2014 18:50:08 +0000
Subject: [New-bugs-announce] [issue20999] setlocale,
	getlocale succession --> ValueError or (None, None)
Message-ID: <1395341408.25.0.421765471202.issue20999@psf.upfronthosting.co.za>


New submission from albertjan:

------------->> see also issue #18378

# Result applies to Python 2.7.2 and Python 3.3.4
# Mac OS X Mountain Lion 10.9.1 on Virtualbox with a Linux Debian AMD-64 host
fomcls-Mac-Pro:~ fomcl$ uname -a
Darwin fomcls-Mac-Pro.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_6

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C/UTF-8/C/C/C/C'
>>> locale.getlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 515, in getlocale
    return _parse_localename(localename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 428, in _parse_localename
    raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

########################################################################
# below another configuration (no hackintosh)
########################################################################


conda 2.7:

Python 2.7.6 |Continuum Analytics, Inc.| (default, Jan 10 2014, 11:23:15)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)

conda 3.3:

Python 3.3.5 |Continuum Analytics, Inc.| (default, Mar 10 2014, 11:22:25)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)

Regular 2.7:

Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)
>>>


Regular 3.3  (broken installation??)
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
Segmentation fault: 11


########################################################################
### finally, the expected result (on Linux)
########################################################################

antonia at antonia-HP-2133 ~ $ uname -a
Linux antonia-HP-2133 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686 i686 GNU/Linux
Python 2.7.3 (default, Feb 27 2014, 19:39:10) [GCC 4.7.2] on linux2
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF-8')

----------
assignee: ronaldoussoren
components: Macintosh
messages: 214260
nosy: albertjan, ronaldoussoren
priority: normal
severity: normal
status: open
title: setlocale, getlocale succession --> ValueError or (None, None)
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Mar 20 19:56:04 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Mar 2014 18:56:04 +0000
Subject: [New-bugs-announce] [issue21000] json.tool ought to have a help flag
Message-ID: <1395341764.54.0.268971679103.issue21000@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

I current get this behavior:
% python3 -m json.tool -h
Traceback (most recent call last):
  File "/usr/lib64/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.3/json/tool.py", line 40, in <module>
    main()
  File "/usr/lib64/python3.3/json/tool.py", line 21, in main
    infile = open(sys.argv[1], 'r')
FileNotFoundError: [Errno 2] No such file or directory: '-h'

Instead of that, json.tool should show a helpful message expalining what it does in response to the -h or --help flags.

----------
components: Library (Lib)
keywords: easy
messages: 214261
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: json.tool ought to have a help flag
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 21 00:58:58 2014
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 20 Mar 2014 23:58:58 +0000
Subject: [New-bugs-announce] [issue21001] Python 3.4 MSI installer doesn't
	work
Message-ID: <1395359938.82.0.179552103299.issue21001@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I'm trying to install Python 3.4 final on Windows 7 and it doesn't work. I'm using the x64 MSI.

Nothing happens after running the MSI. I used Process Explorer but I can't see any new process created. I tried restarting my computer, didn't help. I tried launching using `msiexec /i`, didn't work. 

I really need to use 3.4 urgently, so if you could create an exe installer, that would be nice.

----------
components: Installation
messages: 214311
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Python 3.4 MSI installer doesn't work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 21 02:31:17 2014
From: report at bugs.python.org (Gareth Gouldstone)
Date: Fri, 21 Mar 2014 01:31:17 +0000
Subject: [New-bugs-announce] [issue21002] _sre.SRE_Scanner object should
	have a fullmatch() method
Message-ID: <1395365477.75.0.293934412072.issue21002@psf.upfronthosting.co.za>


New submission from Gareth Gouldstone:

I believe that the SRE_Scanner object should have a .fullmatch() method for consistency with other re pattern-matching behaviour.

>>> rex = re.compile('([^\\W\\d_]{1,2}[0-9]{1,2}[^\\d\\W_]?)[ \\t]*([0-9][^\\d\\W_]{2})')
>>> rex.scanner('bn20bs')
<_sre.SRE_Scanner object at 0x102006400>
>>> rex.scanner('bn20bs').search()                                           
<_sre.SRE_Match object; span=(0, 6), match='bn20bs'>
>>> rex.scanner('bn20bs').match()                                           
<_sre.SRE_Match object; span=(0, 6), match='bn20bs'>
>>> rex.scanner('bn20bs').fullmatch()                                           Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '_sre.SRE_Scanner' object has no attribute 'fullmatch'

----------
components: Regular Expressions
messages: 214317
nosy: Gareth.Gouldstone, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: _sre.SRE_Scanner object should have a fullmatch() method
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 21 06:37:59 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Fri, 21 Mar 2014 05:37:59 +0000
Subject: [New-bugs-announce] [issue21003] how to do batch processing using
	python
Message-ID: <1395380279.84.0.337842820917.issue21003@psf.upfronthosting.co.za>


New submission from Pramod Jadhav:

i am new in python.i have created twitter data anlysis script.how to run this script dailly using python script.

----------
messages: 214327
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: how to do batch processing using python

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

From report at bugs.python.org  Fri Mar 21 06:39:38 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Fri, 21 Mar 2014 05:39:38 +0000
Subject: [New-bugs-announce] [issue21004] how to store json data into
	postgresql using python	script
Message-ID: <1395380378.18.0.687918516938.issue21004@psf.upfronthosting.co.za>


Changes by Pramod Jadhav <jadhavpamu2020 at gmail.com>:


----------
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: how to store json data into postgresql using python script

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

From report at bugs.python.org  Fri Mar 21 11:42:40 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Fri, 21 Mar 2014 10:42:40 +0000
Subject: [New-bugs-announce] [issue21005] asyncio.docs :
	asyncio.subprocess.DEVNULL doc inadequate
Message-ID: <1395398560.63.0.792567362612.issue21005@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

asyncio.subprocess.DEVNULL documentation is the same as asyncio.subprocess.STDOUT one and (I guess) inadequate (cut & paste error ?).

----------
assignee: docs at python
components: Documentation
messages: 214338
nosy: ajaborsk, docs at python
priority: normal
severity: normal
status: open
title: asyncio.docs : asyncio.subprocess.DEVNULL doc inadequate
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 21 11:54:02 2014
From: report at bugs.python.org (Alexandre JABORSKA)
Date: Fri, 21 Mar 2014 10:54:02 +0000
Subject: [New-bugs-announce] [issue21006] asyncio.docs :
	create_subprocess_exec example does not	work on windows
Message-ID: <1395399242.2.0.683863961681.issue21006@psf.upfronthosting.co.za>


New submission from Alexandre JABORSKA:

The documentation example (getstatusoutput) does not work on windows because it use the default loop (based on select). The whole asyncio.ProactorEventLoop stuff is not really explained anywhere. Maybe a "How to use asyncio on Windows" could be useful.

----------
assignee: docs at python
components: Documentation
messages: 214341
nosy: ajaborsk, docs at python
priority: normal
severity: normal
status: open
title: asyncio.docs : create_subprocess_exec example does not work on windows
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 21 14:56:13 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 21 Mar 2014 13:56:13 +0000
Subject: [New-bugs-announce] [issue21007] List of development releases in
	PEPs like 429 should be	links to download pages
Message-ID: <1395410173.95.0.4047767973.issue21007@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
assignee: docs at python
components: Documentation
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: List of development releases in PEPs like 429 should be links to download pages
type: behavior
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/issue21007>
_______________________________________

From report at bugs.python.org  Fri Mar 21 15:38:49 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Mar 2014 14:38:49 +0000
Subject: [New-bugs-announce] [issue21008] Update devinabox for Python 3.4
Message-ID: <1395412729.18.0.57595460397.issue21008@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. with pip included it makes setting up coverage.py easier.

----------
assignee: brett.cannon
messages: 214371
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Update devinabox for Python 3.4

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

From report at bugs.python.org  Fri Mar 21 16:47:26 2014
From: report at bugs.python.org (Simon Jagoe)
Date: Fri, 21 Mar 2014 15:47:26 +0000
Subject: [New-bugs-announce] [issue21009] Potential deadlock in concurrent
	futures when garbage	collection occurs during Queue.get
Message-ID: <1395416846.85.0.759574712799.issue21009@psf.upfronthosting.co.za>


New submission from Simon Jagoe:

At Enthought we have been tracking a deadlock in some code that turned out to be due to the following scenario:

  0) There is some cyclic garbage that requires collection; an object in the garbage is referred to by a weakref with a callback
  1) You have a lock that is acquired
  2) While the lock is held, the garbage collector runs (on the same thread)
  3) The weakref callback in (0) is called via the garbage collecter and the callback tries to acquire the same lock that was acquired in (1)

Attached is a simple script that exercises the issue in Python 3.3. The script monkey-patches Queue.get to force garbage collection after acquiring the Queue.not_empty lock.

----------
components: Library (Lib)
files: executor-hang.py
messages: 214380
nosy: simon.jagoe
priority: normal
severity: normal
status: open
title: Potential deadlock in concurrent futures when garbage collection occurs during Queue.get
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34551/executor-hang.py

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

From report at bugs.python.org  Fri Mar 21 17:04:17 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 21 Mar 2014 16:04:17 +0000
Subject: [New-bugs-announce] [issue21010] asyncio doc typo
Message-ID: <1395417857.61.0.236262518907.issue21010@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

There is an invalid item "meth:`resume_reading`".

----------
assignee: docs at python
components: Documentation
files: asyncio_doc_fix.patch
keywords: patch
messages: 214381
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: asyncio doc typo
versions: Python 3.5
Added file: http://bugs.python.org/file34552/asyncio_doc_fix.patch

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

From report at bugs.python.org  Fri Mar 21 17:45:16 2014
From: report at bugs.python.org (Hristo Venev)
Date: Fri, 21 Mar 2014 16:45:16 +0000
Subject: [New-bugs-announce] [issue21011] PyArg_ParseTupleAndKeywords
	doesn't take const char	*keywords[]
Message-ID: <1395420316.16.0.247771357348.issue21011@psf.upfronthosting.co.za>


New submission from Hristo Venev:

This really annoys me. I have to store the literals in char[] and then make a char*[] from them. It would be better if a simple array of string literals could be used. It would also require less data space because string literals could be merged by the compiler.

I don't know why PyArg_ParseTupleAndKeywords would ever modify the keywords array so it makes absolutely no sense to me for the array not to be const char*[].

In all cases I have seen PyArg_ParseTupleAndKeywords being used string literals were converted to char* (dropping const) which is far far worse than inefficient code.

----------
components: Extension Modules
messages: 214388
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyArg_ParseTupleAndKeywords doesn't take const char *keywords[]
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 21 17:59:22 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Mar 2014 16:59:22 +0000
Subject: [New-bugs-announce] [issue21012] Figure out how to best leverage
	pip in devinabox
Message-ID: <1395421162.45.0.220152918386.issue21012@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Probably the most complicated bit now for using devinabox is building the various bits of docs in a way that doesn't require mucking with the system python:

* Having Python built
* Creating a venv
* Installing sphinx
* Running the requisite Makefile with the proper envvar overridden to point to the venv

I see a couple of ways of handling this:

* Assume people know how to do the above
* Verbally instruct people on how to do these steps
* Provide a requirements.txt file for sphinx and coverage -- two birds w/ one stone =) -- and instruct on how to install from that
* Provide a setup_venv script and then instruct on the doc building
* Provide a build.py script which takes named commands like 'docs', 'peps', etc. and then does the right thing automatically

There is also the question of whether any of this should make its way up into the devguide, etc.

My gut says that we should rename README to SPRINT_LEADERS and then provide a README for the sprint participants which lays out the commands along with comments on where to learn more about what's going on. We don't have to advertise that the doc is actually a shell script that we can use to verify the steps are all correct. =) This way they have to grasp the concept of how to build, make a venv, use pip, etc. We can also make sure that there are no documentation holes outside of devinabox for any one step.

Another way to utilize pip is to use it to download all the files necessary to build the docs and get coverage so that offline installations can occur. Not sure what's the easiest way to make pip just download projects and their deps in a way that allows for easily pointing pip at something and say "install from here", but I suspect there's a way (using just wheels is a little tricky as markupsafe has an accelerator and coverage has to be compiled).

IOW how do we get contributors using venv and pip effectively w/o training them only on how to do things in a devinabox instance?

----------
messages: 214390
nosy: brett.cannon, ncoghlan, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: Figure out how to best leverage pip in devinabox

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

From report at bugs.python.org  Fri Mar 21 20:07:46 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Mar 2014 19:07:46 +0000
Subject: [New-bugs-announce] [issue21013] server-specific SSL context
	configuration
Message-ID: <1395428866.17.0.533076056941.issue21013@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, create_default_context() doesn't do anything special for server use. It seems the configuration could be improved, though:

- PROTOCOL_TLSv1 is suboptimal for servers: a "TLSv1" server can't accept a TLSv1.2 client, but a "SSLv23" server will; so we should use PROTOCOL_SSLv23 (!)

- we could enable ECDH by calling SSLContext.set_ecdh_curve(<something>)

----------
components: Library (Lib)
messages: 214405
nosy: christian.heimes, dstufft, pitrou
priority: normal
severity: normal
status: open
title: server-specific SSL context configuration
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 22 02:59:16 2014
From: report at bugs.python.org (Samuel Marks)
Date: Sat, 22 Mar 2014 01:59:16 +0000
Subject: [New-bugs-announce] [issue21014] `1` => `True`; for tutorial docs
Message-ID: <1395453556.85.0.399159850271.issue21014@psf.upfronthosting.co.za>


New submission from Samuel Marks:

Particularly for new programmers `True` makes more sense than `1` when doing boolean logic.

If you aren't going to accept this patch; at least add in a sentence explaining that: `> 1 == True`.

Best,

Samuel Marks

----------
assignee: docs at python
components: Documentation
files: Use_`True`_instead_of_`1`_.patch
hgrepos: 229
keywords: patch
messages: 214430
nosy: SamuelMarks, docs at python
priority: normal
severity: normal
status: open
title: `1` => `True`; for tutorial docs
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file34559/Use_`True`_instead_of_`1`_.patch

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

From report at bugs.python.org  Sat Mar 22 03:34:31 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Mar 2014 02:34:31 +0000
Subject: [New-bugs-announce] [issue21015] support SSL_CTX_set_ecdh_auto on
	newer OpenSSLs
Message-ID: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>From the OpenSSL changelog:

  *) Support for automatic EC temporary key parameter selection. If enabled
     the most preferred EC parameters are automatically used instead of
     hardcoded fixed parameters. Now a server just has to call:
     SSL_CTX_set_ecdh_auto(ctx, 1) and the server will automatically
     support ECDH and use the most appropriate parameters.
     [Steve Henson]

We could probably call this function automatically on SSL contexts, when possible.

Besides, Apache's mod_ssl has the following code:

#if defined(SSL_CTX_set_ecdh_auto)
        SSL_CTX_set_ecdh_auto(mctx->ssl_ctx, 1);
#else
        SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx,
                             EC_KEY_new_by_curve_name(NID_X9_62_prime256v1));
#endif

So perhaps we can also reuse the same fallback to "prime256v1" (which would allow prioritizing ECDH in the cipher string).

----------
components: Library (Lib)
messages: 214431
nosy: christian.heimes, dstufft, pitrou
priority: normal
severity: normal
status: open
title: support SSL_CTX_set_ecdh_auto on newer OpenSSLs
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 22 04:46:20 2014
From: report at bugs.python.org (Ben Boeckel)
Date: Sat, 22 Mar 2014 03:46:20 +0000
Subject: [New-bugs-announce] [issue21016] trace: $prefix and $exec_prefix
	improperly replaced on	Fedora
Message-ID: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>


New submission from Ben Boeckel:

In the --ignore-dir handling of trace.py, the following is done:

                s = s.replace("$prefix",
                              os.path.join(sys.base_prefix, "lib",
                                           "python" + sys.version[:3]))
                s = s.replace("$exec_prefix",
                              os.path.join(sys.base_exec_prefix, "lib",
                                           "python" + sys.version[:3]))

This does not do what is expected on 64-bit Fedora and newer Debian since the proper directory is /usr/lib64/python2.7 or /usr/lib/$triple/python2.7. Just the libsuffix can't be changed either since Fedora also has /usr/lib/python2.7 for arch-independent modules. It'd be nice if $prefix were replaced with the following directories from sysconfig.get_paths(): platstdlib, platlib, purelib, and stdlib.

It also erroneously replaces things like '$prefixpath'. It should probably do split the path on the path separators and only replace components that are equal to $prefix or $exec_prefix (so that the '$' can be escaped for directories named as such literally, but that would require a pass to parse the escapes).

----------
components: Library (Lib)
messages: 214435
nosy: mathstuf
priority: normal
severity: normal
status: open
title: trace: $prefix and $exec_prefix improperly replaced on Fedora
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Mar 22 05:17:38 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Mar 2014 04:17:38 +0000
Subject: [New-bugs-announce] [issue21017] Enable Debug Tix build on Windows
Message-ID: <1395461858.13.0.721078691235.issue21017@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch to be applied to svn.python.org/projects/external/tix-8.4.3.x to enable building Tix in Debug configuration.  It also eliminates some superfluous warnings due to unrecognized command line options.

Closely related to #15968.

----------
components: Build, Tkinter, Windows
files: issue15968_tix.svndiff
messages: 214438
nosy: loewis, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Enable Debug Tix build on Windows
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34560/issue15968_tix.svndiff

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

From report at bugs.python.org  Sat Mar 22 06:00:20 2014
From: report at bugs.python.org (Arun Persaud)
Date: Sat, 22 Mar 2014 05:00:20 +0000
Subject: [New-bugs-announce] [issue21018] [patch] added missing
	documentation about escaping	characters for configparser
Message-ID: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za>


New submission from Arun Persaud:

Couldn't find how to escape % and $ in the documentation, so I thought I add a short patch.

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 214442
nosy: Arun.Persaud, docs at python
priority: normal
severity: normal
status: open
title: [patch] added missing documentation about escaping characters for configparser
type: enhancement
Added file: http://bugs.python.org/file34562/mywork.patch

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

From report at bugs.python.org  Sat Mar 22 11:14:14 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:14:14 +0000
Subject: [New-bugs-announce] [issue21019] PyMethodDef ml_name is char*
	instead of const char*
Message-ID: <1395483254.03.0.173099227784.issue21019@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
messages: 214451
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyMethodDef ml_name is char* instead of const char*

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

From report at bugs.python.org  Sat Mar 22 11:15:22 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:15:22 +0000
Subject: [New-bugs-announce] [issue21020] PyMethodDef ml_doc is char*
	instead of const char*
Message-ID: <1395483322.57.0.466317443541.issue21020@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
messages: 214452
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyMethodDef ml_doc is char* instead of const char*

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

From report at bugs.python.org  Sat Mar 22 11:15:59 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:15:59 +0000
Subject: [New-bugs-announce] [issue21021] PyMemberDef name is char* instead
	of const char*
Message-ID: <1395483359.95.0.0463894937939.issue21021@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
messages: 214453
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyMemberDef name is char* instead of const char*

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

From report at bugs.python.org  Sat Mar 22 11:16:31 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:16:31 +0000
Subject: [New-bugs-announce] [issue21022] PyMemberDef doc is char* instead
	of const char*
Message-ID: <1395483391.18.0.709378946504.issue21022@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
messages: 214454
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyMemberDef doc is char* instead of const char*

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

From report at bugs.python.org  Sat Mar 22 11:17:30 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:17:30 +0000
Subject: [New-bugs-announce] [issue21023] PyTypeObject tp_name is char*
	instead of const char*
Message-ID: <1395483450.02.0.347211146616.issue21023@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
components: Extension Modules
messages: 214455
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyTypeObject tp_name is char* instead of const char*
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 22 11:18:05 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sat, 22 Mar 2014 10:18:05 +0000
Subject: [New-bugs-announce] [issue21024] PyTypeObject tp_doc is char*
	instead of const char*
Message-ID: <1395483485.81.0.6602220127.issue21024@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It would be better if string literals could be used there.

----------
components: Extension Modules
messages: 214456
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyTypeObject tp_doc is char* instead of const char*
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 22 12:35:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Mar 2014 11:35:11 +0000
Subject: [New-bugs-announce] [issue21025] if check_hostname is true,
	context can't be used for server purposes
Message-ID: <1395488111.76.0.767188030074.issue21025@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

On a SSLContext with check_hostname = True, calling wrap_socket(..., server_side=True) will complain that no server hostname has been passed. This should only be done for client sockets.

----------
components: Library (Lib)
messages: 214462
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: if check_hostname is true, context can't be used for server purposes
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 22 21:13:06 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Mar 2014 20:13:06 +0000
Subject: [New-bugs-announce] [issue21026] Document sitecustomize.py problems
	with pythonw
Message-ID: <1395519186.07.0.912886400259.issue21026@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In the first section of the doc for site.py, after

"After these path manipulations, an attempt is made to import a module named sitecustomize, which can perform arbitrary site-specific customizations. It is typically created by a system administrator in the site-packages directory. If this import fails with an ImportError exception, it is silently ignored."

I propose to add (something like)

"If python is started without output streams available, as with pythonw on Windows (used by default to start Idle), attempted output from sitecustomize is ignored. Any exception other that ImportError causes a silent and perhaps mysterious failure of the process."

This issue was stimulated by someone asking on python-list about print() outout appearing when starting the console interpreter but not when starting Idle (on Windows).  I then tested the result of an excecption other than ImportError. At the console, nothing visible happens until a new prompt appears.

C:\Programs\Python34>pythonw -m idlelib.idle

C:\Programs\Python34>

If Idle is already running, the attempt to run a file with F5 gives a messages about not being able to connect to the subprocess (which silently failed).

----------
components: Library (Lib)
keywords: patch
messages: 214512
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document sitecustomize.py problems with pythonw
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 22 21:44:16 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 22 Mar 2014 20:44:16 +0000
Subject: [New-bugs-announce] [issue21027] difflib new cli interface
Message-ID: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello!

The attached patch proposes a new command line interface to difflib module.
Currently, `python -m difflib` does nothing useful, it runs the doc suite for the difflib module.
Right now, there are a couple of modules in the standard lib, which provides
helpful cli interfaces. For instance, inspect for analyzing an object, compileall for compilation of Python files
or json.tool for validating and pretty printing JSON. Also, in Tools/scripts/ there is a small utility called diff.py,
which uses difflib to implement a simple diff like utility, but the following issue proposes its deprecation
and I'll enumerate my reasons for this:

- On Windows, py -3 -m difflib is easier to use. Yes, Tools/Scripts can be added to PATH, so that diff.py can be used there, but we can't do always that. I have at work a couple of machines where I can't modify the PATH due to user limitations. Having `py -3 -m difflib` as a handy diff tool is invaluable on such systems.

- Continuing the same argument as above, you can't always install a proper diff tool, due to same limitations. Having a simple one builtin in the stdlib is more than useful! Also, you can't always use a versioning system, in order to use its diff feature.

- Tools/Scripts/diff.py is not tested at all.

- diff.py was added before the `-m` thingy came, now `-m difflib` is the more natural way and I hope to see even more modules providing it with useful cli interfaces, like compileall or inspect.

Thanks in advance!

----------
components: Library (Lib)
files: difflib_cli.patch
keywords: patch
messages: 214516
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: difflib new cli interface
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34571/difflib_cli.patch

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

From report at bugs.python.org  Sat Mar 22 23:47:56 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Mar 2014 22:47:56 +0000
Subject: [New-bugs-announce] [issue21028] ElementTree objects should support
	all the same methods	are Element objects
Message-ID: <1395528476.17.0.859396205804.issue21028@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The inner objects are Elements which has a great deal of flexiblity (for example, they can be iterated over directly).   The outermost object is an ElementTree which lacks those capabilities (it only supports findall).

For example in a catalog of books:

    catalog = xml.etree.ElementTree.parse('books.xml')

    # This succeeds
    for book in catalog.findall('book'):
        print(book.tag)

    # This fails:
    for book in catalog:
        print(book.tag)

    # But for inner elements, we have more options
    book = catalog.find('bk101')
    for subelement in book:
        print(subelement.tag)

Here are the differences between the API for ElementTree and Element

In [9]: set(dir(book)) - set(dir(catalog))
Out[9]: 
{'__delitem__',
 '__getitem__',
 '__len__',
 '__nonzero__',
 '__setitem__',
 '_children',
 'append',
 'attrib',
 'clear',
 'copy',
 'extend',
 'get',
 'getchildren',
 'insert',
 'items',
 'itertext',
 'keys',
 'makeelement',
 'remove',
 'set',
 'tag',
 'tail',
 'text'}

In [10]: set(dir(catalog)) - set(dir(book))
Out[10]: {'_root', '_setroot', 'getroot', 'parse', 'write', 'write_c14n'}

Note, the XML data model requires that the outermost element have some capabilities that inner elements don't have (such as comments and processing instructions).  That said, the outer element shouldn't have fewer capabilities that the inner elements.

----------
components: Library (Lib)
messages: 214521
nosy: rhettinger
priority: normal
severity: normal
status: open
title: ElementTree objects should support all the same methods are Element objects
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 23 00:28:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Mar 2014 23:28:49 +0000
Subject: [New-bugs-announce] [issue21029] IDLE mis-coloring "print"
Message-ID: <1395530929.17.0.0912248943658.issue21029@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Sometimes, IDLE displays "print" in orange, identifying it as a keyword and sometimes "print" is displayed in "purple" identifying it as a built-in function.

>>> print 'hello'          # This print is orange
hello

>>> for i in range(1):
	print ('hello')    # This print is purple

hello

----------
components: IDLE
messages: 214522
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE mis-coloring "print"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 23 01:25:44 2014
From: report at bugs.python.org (Christian Ullrich)
Date: Sun, 23 Mar 2014 00:25:44 +0000
Subject: [New-bugs-announce] [issue21030] pip usable only by administrators
	on Windows
Message-ID: <1395534344.37.0.780621309419.issue21030@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

After installing python-3.4.0.amd64.msi on Windows 8.1 x64, the "pip" command (and the versioned ones as well) only work for administrators. Regular users get this:

Traceback (most recent call last):
  File "C:\Program Files\Python34\lib\runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Program Files\Python34\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Program Files\Python34\Scripts\pip.exe\__main__.py", line 5, in <module>
ImportError: cannot import name 'main'

The immediate reason is that the files in the site-packages/pip directory are created with no access permissions for non-administrators:

C:\Program Files\Python34\Lib\site-packages\pip>icacls __main__.py
__main__.py NT-AUTHORITY\SYSTEM:(F)
            BUILTIN\Administrators:(F)
            abc\Admin:(F)

Why that is, I have no idea. It can be fixed by running:

icacls path\to\site-packages\pip /inheritance:e /t
icacls path\to\site-packages\pip /reset /t

The /reset may be unnecessary.

----------
components: Installation, Windows
messages: 214527
nosy: Christian.Ullrich
priority: normal
severity: normal
status: open
title: pip usable only by administrators on Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 23 05:05:36 2014
From: report at bugs.python.org (Elizabeth Myers)
Date: Sun, 23 Mar 2014 04:05:36 +0000
Subject: [New-bugs-announce] [issue21031] [patch] Add AlpineLinux to the
	platform module's	supported distributions list
Message-ID: <1395547536.87.0.0316178193706.issue21031@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

This patch adds support for the AlpineLinux distrubtion (http://alpinelinux.org) to the platform.linux_distributions function, e.g.:

>>> platform.linux_distribution()
('alpine', '2.8.0_alpha2', '')

Thoughts, feelings, and rotten tomatoes welcome :).

----------
components: Library (Lib)
files: platform.patch
keywords: patch
messages: 214545
nosy: Elizacat
priority: normal
severity: normal
status: open
title: [patch] Add AlpineLinux to the platform module's supported distributions list
versions: Python 3.5
Added file: http://bugs.python.org/file34578/platform.patch

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

From report at bugs.python.org  Sun Mar 23 05:05:47 2014
From: report at bugs.python.org (Martin Panter)
Date: Sun, 23 Mar 2014 04:05:47 +0000
Subject: [New-bugs-announce] [issue21032] Socket leak if
	HTTPConnection.getresponse() fails
Message-ID: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za>


New submission from Martin Panter:

Here is a regression test and patch to close the socket reader when a HTTP server causes getresponse() to fail, for instance if the server times out and drops the connection without sending any response. Without the patch the socket will only be closed by the garbage collector at some arbitrary point.

----------
components: Library (Lib)
files: test.patch
keywords: patch
messages: 214546
nosy: vadmium
priority: normal
severity: normal
status: open
title: Socket leak if HTTPConnection.getresponse() fails
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file34579/test.patch

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

From report at bugs.python.org  Sun Mar 23 09:36:13 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 23 Mar 2014 08:36:13 +0000
Subject: [New-bugs-announce] [issue21033] previous trace function still
	invoked after	sys.settrace()
Message-ID: <1395563773.85.0.562245931726.issue21033@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following output of settrace.py shows that the Tracer trace function is still called in foo() after the New_tracer trace function has been installed with sys.settrace() from within the trace function itself, and even though f_trace has been set on all the frames of the stack with the new trace function as this is done in bdb.Bdb.set_trace():

sys.settrace(Tracer.trace)
Tracer:line at <module>:30
Tracer:call at foo:23
sys.settrace(New_tracer.trace)
Tracer:line at foo:24
New_tracer:call at bar:27
New_tracer:line at bar:27
New_tracer:return at bar:27
Tracer:line at foo:25
Tracer:return at foo:25
New_tracer:return at <module>:30

Python should not allow to call successfully sys.settrace() when tracing, except for sys.settrace(None).
This does not seem easy to fix without adding some state, as the 'tracing' field in PyThreadState is used for both trace/profile codes.

----------
components: Interpreter Core
files: settrace.py
messages: 214553
nosy: xdegaye
priority: normal
severity: normal
status: open
title: previous trace function still invoked after sys.settrace()
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file34581/settrace.py

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

From report at bugs.python.org  Sun Mar 23 09:48:39 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 23 Mar 2014 08:48:39 +0000
Subject: [New-bugs-announce] [issue21034] Python docs reference the
	Distribute package which has	been deprecated in favor of Setuptools
Message-ID: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

In the Python documentation note:

  http://docs.python.org/3.4/library/venv.html#venv-def

the paragraph:

> Common installation tools such as Distribute and pip work
> as expected with venvs - i.e. when a venv is active, they
> install Python packages into the venv without needing to
> be told to do so explicitly. Of course, you need to
> install them into the venv first: this could be done by
> running distribute_setup.py with the venv activated,
> followed by running easy_install pip. Alternatively, you
> could download the source tarballs and run python setup.py
> install after unpacking, with the venv activated.

refers to the Distribute package and its specifics (how it
should be installed) but that package has been deprecated
in favor of the setuptools package. I suggest to change it
to something like:

> Common installation tools such as setuptools and pip work
> as expected with venvs - i.e. when a venv is active, they
> install Python packages into the venv without needing to
> be told to do so explicitly. Of course, you need to
> install them into the venv first: this could be done by
> running setuptools project's ez_setup.py with the venv
> activated, followed by running easy_install pip.
> Alternatively, you could download the source tarballs and
> run python setup.py install after unpacking, with the venv
> activated.

I'm attaching a patch based on the current tip in CPython's
development repository.

Hope this helps.

Best regards,
  Jurko Gospodneti?

----------
assignee: docs at python
components: Documentation
files: fix_Distribute_reference_in_venv_docs.patch
keywords: patch
messages: 214554
nosy: Jurko.Gospodneti?, docs at python
priority: normal
severity: normal
status: open
title: Python docs reference the Distribute package which has been deprecated in favor of Setuptools
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34582/fix_Distribute_reference_in_venv_docs.patch

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

From report at bugs.python.org  Sun Mar 23 12:14:12 2014
From: report at bugs.python.org (Parto Chobeiry)
Date: Sun, 23 Mar 2014 11:14:12 +0000
Subject: [New-bugs-announce] [issue21035] Python's HTTP server
	implementations hangs after 16.343	requests on MacOSX
Message-ID: <1395573252.44.0.596727679776.issue21035@psf.upfronthosting.co.za>


New submission from Parto Chobeiry:

While deriving from Python's HTTP server implementation I think I found a bug (on MacOSX) which can be reproduced like this:

(1) Start the HTTP server:
python -m SimpleHTTPServer (or python -m http.server)

(2) Benchmark the HTTP server:
ab -n 20000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
apr_socket_recv: Operation timed out (60)
Total of 16343 requests completed

This does not happen on Ubuntu.

What is the reason for timing out after 16.343 requests?

----------
messages: 214562
nosy: chobeiry
priority: normal
severity: normal
status: open
title: Python's HTTP server implementations hangs after 16.343 requests on MacOSX
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 23 13:30:39 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 23 Mar 2014 12:30:39 +0000
Subject: [New-bugs-announce] [issue21036] typo in hashtable API:
	_PY_HASHTABLE_ENTRY_DATA ->	_Py_HASHTABLE_ENTRY_DATA
Message-ID: <1395577839.9.0.530387469392.issue21036@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

The title says it all: in Modules/hashtable.c, the macro name is _PY_HASHTABLE_ENTRY_DATA instead of _Py_HASHTABLE_ENTRY_DATA.

Should this be fixed in 3.4?

----------
components: Extension Modules
messages: 214570
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: typo in hashtable API: _PY_HASHTABLE_ENTRY_DATA -> _Py_HASHTABLE_ENTRY_DATA
type: behavior

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

From report at bugs.python.org  Sun Mar 23 14:38:47 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 23 Mar 2014 13:38:47 +0000
Subject: [New-bugs-announce] [issue21037] add an AddressSanitizer build
	option
Message-ID: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Adding a compile option to build with ASAN (https://code.google.com/p/address-sanitizer) could allow us to catch many memory-related errors (stack/buffer overflows, etc).

Of course, the second step would be to setup buildbots to use this flag.

----------
files: asan.diff
keywords: patch
messages: 214578
nosy: christian.heimes, neologix
priority: normal
severity: normal
status: open
title: add an AddressSanitizer build option
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34584/asan.diff

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

From report at bugs.python.org  Sun Mar 23 14:46:17 2014
From: report at bugs.python.org (Andreas Schwab)
Date: Sun, 23 Mar 2014 13:46:17 +0000
Subject: [New-bugs-announce] [issue21038]
	test_epoll.TestEPoll.test_control_and_wait: remove extra	assertion
Message-ID: <1395582377.02.0.495747397438.issue21038@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

The extra assertion doesn't check something new and can result in spurious testsuite failures due to the stricter condition.

----------
components: Tests
files: 0001-test_epoll.TestEPoll.test_control_and_wait-remove-ex.patch
keywords: patch
messages: 214580
nosy: schwab
priority: normal
severity: normal
status: open
title: test_epoll.TestEPoll.test_control_and_wait: remove extra assertion
type: enhancement
Added file: http://bugs.python.org/file34585/0001-test_epoll.TestEPoll.test_control_and_wait-remove-ex.patch

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

From report at bugs.python.org  Sun Mar 23 14:55:56 2014
From: report at bugs.python.org (Hristo Venev)
Date: Sun, 23 Mar 2014 13:55:56 +0000
Subject: [New-bugs-announce] [issue21039] pathlib strips trailing slash
Message-ID: <1395582956.56.0.801867388239.issue21039@psf.upfronthosting.co.za>


New submission from Hristo Venev:

Some programs' behavior is different depending on whether the path has a trailing slash or not. Examples include ls, cp, mv, ln, rm and rsync. URL paths may also behave differently. For example http://xkcd.com/1 redirects to http://xkcd.com/1/

Boost.Filesystem's path class also supports trailing slashes in paths. C++'s filesystem library proposal is also based on Boost.Filesystem.

----------
components: Library (Lib)
files: pathlib.patch
keywords: patch
messages: 214581
nosy: h.venev
priority: normal
severity: normal
status: open
title: pathlib strips trailing slash
versions: Python 3.4
Added file: http://bugs.python.org/file34586/pathlib.patch

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

From report at bugs.python.org  Sun Mar 23 21:17:05 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 23 Mar 2014 20:17:05 +0000
Subject: [New-bugs-announce] [issue21040] socketserver: use selectors module
Message-ID: <1395605825.75.0.216216542224.issue21040@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This patch updates the socketserver module to use selectors.
It's simpler, will use poll() when available, and also fixes a bug where the timeout would not be recomputed upon EINTR.

Note that I removed an EINTR-handling test from test_socketserver because test_selectors already covers this in a more clean and robust way.

----------
components: Library (Lib)
files: socketserver_use_selectors.diff
keywords: patch
messages: 214631
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: socketserver: use selectors module
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34592/socketserver_use_selectors.diff

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

From report at bugs.python.org  Sun Mar 23 23:16:51 2014
From: report at bugs.python.org (akira)
Date: Sun, 23 Mar 2014 22:16:51 +0000
Subject: [New-bugs-announce] [issue21041] pathlib.PurePath.parents rejects
	negative indexes
Message-ID: <1395613011.22.0.29152070109.issue21041@psf.upfronthosting.co.za>


New submission from akira:

`pathlib.PurePath.parents` is a sequence [1] but it rejects negative indexes:

  >>> from pathlib import PurePath
  >>> PurePath('a/b/c').parents[-2]
  Traceback (most recent call last):
  ...
  IndexError: -2

Sequences in Python interpret negative indexes as `len(seq) + i` [2]

I've included the patch that fixes the issue and adds corresponding tests. No documentation changes are needed.

[1]: http://docs.python.org/3/library/pathlib#pathlib.PurePath.parents
[2]: http://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range

----------
components: Library (Lib)
files: pathlib-parents-allow-negative-index.patch
keywords: patch
messages: 214642
nosy: akira
priority: normal
severity: normal
status: open
title: pathlib.PurePath.parents rejects negative indexes
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34595/pathlib-parents-allow-negative-index.patch

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

From report at bugs.python.org  Sun Mar 23 23:47:15 2014
From: report at bugs.python.org (Hernan Grecco)
Date: Sun, 23 Mar 2014 22:47:15 +0000
Subject: [New-bugs-announce] [issue21042] ctypes.util.find_library() should
	return full pathname	instead of filename in linux
Message-ID: <1395614835.79.0.900137034576.issue21042@psf.upfronthosting.co.za>


New submission from Hernan Grecco:

In Windows and OSX, `find_library` returns the full pathname of the library file. But on Linux, it returns just the filename. Is there a reason for this difference? 

For consistency, it would be better to return the full pathname in all cases. It is easy to get the filename from the full pathname, but not the other way around.

----------
components: ctypes
messages: 214647
nosy: Hernan.Grecco
priority: normal
severity: normal
status: open
title: ctypes.util.find_library() should return full pathname instead of filename in linux
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 24 00:50:30 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 23 Mar 2014 23:50:30 +0000
Subject: [New-bugs-announce] [issue21043] Stop reccomending CACert.org in
	the SSL documentation
Message-ID: <1395618630.76.0.364791925712.issue21043@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

CACert is not in the root trust store on *any* platform that I'm aware of, and has not passed any audits. See http://lwn.net/SubscriberLink/590879/ce23ed7bab68e489/ for more background.

In it's place I've added StartSSL, which is included in most (all?) root trust stores, and offers free certs.

----------
assignee: docs at python
components: Documentation
files: cacert.diff
keywords: patch
messages: 214656
nosy: alex, docs at python, dstufft
priority: normal
severity: normal
status: open
title: Stop reccomending CACert.org in the SSL documentation
type: enhancement
Added file: http://bugs.python.org/file34598/cacert.diff

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

From report at bugs.python.org  Mon Mar 24 02:32:57 2014
From: report at bugs.python.org (Antoine Pietri)
Date: Mon, 24 Mar 2014 01:32:57 +0000
Subject: [New-bugs-announce] [issue21044] tempfile.TemporaryFile() shouldn't
	have a name attribute
Message-ID: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za>


New submission from Antoine Pietri:

The fact that tempfile.TemporaryFile() has a "name" integer attribute  causes weird behavior when interacting with libraries that rely on this attribute being a valid string for file objects.
For instance, it led to this exception with the "tarfile" module, which I resolved by using a NamedTemporaryFile():

>>> tarfile.open(fileobj=tempfile.TemporaryFile(), mode='w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/tarfile.py", line 1585, in open
    return cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.4/tarfile.py", line 1595, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.4/tarfile.py", line 1431, in __init__
    self.name = os.path.abspath(name) if name else None
  File "/usr/lib/python3.4/posixpath.py", line 360, in abspath
    if not isabs(path):
  File "/usr/lib/python3.4/posixpath.py", line 64, in isabs
    return s.startswith(sep)
AttributeError: 'int' object has no attribute 'startswith'

Which is caused by these lines in the "tarfile" module:

if name is None and hasattr(fileobj, "name"):
    name = fileobj.name

If TemporaryFile() didn't have a name attribute, tarfile, which doesn't really need the file name, would simply have continued without errors.

I am not aware of any place where this "name" integer attribute is actually useful, and, as a matter of fact, it is not even documented: http://docs.python.org/3.4/library/tempfile.html#tempfile.TemporaryFile

----------
components: Library (Lib)
messages: 214662
nosy: seirl
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile() shouldn't have a name attribute
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 24 02:58:44 2014
From: report at bugs.python.org (Jorge Araya Navarro)
Date: Mon, 24 Mar 2014 01:58:44 +0000
Subject: [New-bugs-announce] [issue21045] fix layout to generate
	documentation for Qt Assistant
Message-ID: <1395626324.01.0.108694815155.issue21045@psf.upfronthosting.co.za>


New submission from Jorge Araya Navarro:

Python use sphinx to generate its documentation, sphinx can generate documentation for Qt Assistant using the qthelp builder (and `qcollectiongenerator build/qthelp/Python.qhcp`). The thing is that using the default layout or static css files, the final results look very bad, and changing its theme doesn't help either.

----------
assignee: docs at python
components: Documentation
files: V6cXI.png
messages: 214664
nosy: docs at python, shackra
priority: normal
severity: normal
status: open
title: fix layout to generate documentation for Qt Assistant
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34601/V6cXI.png

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

From report at bugs.python.org  Mon Mar 24 04:10:19 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 24 Mar 2014 03:10:19 +0000
Subject: [New-bugs-announce] [issue21046] Document formulas used in
	statistics
Message-ID: <1395630619.14.0.819197288528.issue21046@psf.upfronthosting.co.za>


New submission from Zachary Ware:

>From docs@:

On Sun, Mar 23, 2014 at 5:55 PM, Alex <aaa5500 at ya.ru> wrote:
> http://docs.python.org/dev/library/statistics.html
>  
> I know math. I ended the institute. But in Russia. Doc doesn't show me WHAT
> FORMULAS are used for mean, median, median_low , etc. I canot understand
> doc. Please write formulas:
>  
> e.g. mean = sum(x[i] from i=1 to N) / N
>  
>  
> Regards
> Alex

----------
assignee: stevenjd
components: Documentation
messages: 214666
nosy: stevenjd, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Document formulas used in statistics
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 24 06:17:18 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 24 Mar 2014 05:17:18 +0000
Subject: [New-bugs-announce] [issue21047] html.parser.HTMLParser:
	convert_charrefs should become	True by default
Message-ID: <1395638238.78.0.969546304297.issue21047@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Follow-up to issue #13633.

Lib/html/parser.py still has:

if convert_charrefs is _default_sentinel:
    convert_charrefs = False  # default
    warnings.warn("The value of convert_charrefs will become True in "
                  "3.5. You are encouraged to set the value explicitly.",
                  DeprecationWarning, stacklevel=2)

----------
components: Library (Lib)
messages: 214668
nosy: Arfrever, eric.araujo, ezio.melotti, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: html.parser.HTMLParser: convert_charrefs should become True by default
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 24 06:22:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Mar 2014 05:22:38 +0000
Subject: [New-bugs-announce] [issue21048] Index 'as' in import and with
	statements
Message-ID: <1395638558.42.0.404654056681.issue21048@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Did I forget anything? (Patch vs. 3.4)

----------
files: index-as.diff
keywords: patch
messages: 214669
nosy: terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Index 'as' in import and with statements
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34602/index-as.diff

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

From report at bugs.python.org  Mon Mar 24 07:25:35 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 24 Mar 2014 06:25:35 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue21049=5D_Flood_of_=E2=80=9C?=
 =?utf-8?q?ImportWarning=3A_sys=2Emeta=5Fpath_is_empty=E2=80=9D_after_exce?=
 =?utf-8?q?ption_with_socket_subclass?=
Message-ID: <1395642335.41.0.483787590936.issue21049@psf.upfronthosting.co.za>


New submission from Martin Panter:

With the code included below, and warnings enabled, I see a flood of unexpected ImportWarnings as the interpreter exits. The issue is seen with Python 3.4.0, but apparently not with 3.3.5.

The issue originally happened with code using the Py Socks library <https://github.com/Anorov/PySocks>, which I interrupted because the connect() call was hanging. I have reduced it down to the following code:

import _socket

class socket(_socket.socket):
    def __init__(self):
        _socket.socket.__init__(self)
        self.attr = self.__init__
        raise Exception()

socket()

Output from running this code:
[vadmium at localhost tmp]$ python3 -Wall script.py
/usr/lib/python3.4/site.py:333: DeprecationWarning: "site-python" directories will not be supported in 3.5 anymore
  DeprecationWarning)
Traceback (most recent call last):
  File "script.py", line 9, in <module>
    socket()
  File "script.py", line 7, in __init__
    raise Exception()
Exception
sys:1: ResourceWarning: unclosed <socket object, fd=3, family=2, type=1, proto=0>
/tmp/<frozen>:2127: ImportWarning: sys.meta_path is empty
/tmp/<frozen>:2127: ImportWarning: sys.meta_path is empty
. . .
[About two hundred lines]
. . .
/tmp/<frozen>:2127: ImportWarning: sys.meta_path is empty
/tmp/<frozen>:2127: ImportWarning: sys.meta_path is empty
[Exit 1]
[vadmium at localhost tmp]$ 

These seem to be conditions necessary to produce the issue:

* Instantiate a subclass of ?_socket.socket?
* Assign a bound method to an attribute of the socket object
* Save the socket object in a local variable of a function, __init__() in my demonstration
* Raise an exception from the function holding the socket object

----------
messages: 214671
nosy: vadmium
priority: normal
severity: normal
status: open
title: Flood of ?ImportWarning: sys.meta_path is empty? after exception with socket subclass
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 24 08:33:52 2014
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 24 Mar 2014 07:33:52 +0000
Subject: [New-bugs-announce] [issue21050] Failure to import win32api (from
	pywin32)
Message-ID: <1395646432.86.0.518413494432.issue21050@psf.upfronthosting.co.za>


New submission from Thomas Heller:

With python 3.4 and pywin32 version 218 it is only possible
to import win32com or win32api when pywintypes has been imported before.

Here is part of a session with 'python -v':

>>>
>>> import win32api
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 2214, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2203, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1191, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1161, in _load_backward_compatible
  File "<frozen importlib._bootstrap>", line 539, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1692, in load_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
>>> import pdb; pdb.pm()
> <frozen importlib._bootstrap>(321)_call_with_frames_removed()
(Pdb) locals()
{'kwds': {}, 'f': <built-in function load_dynamic>, 'args': ('win32api', 'C:\\Python34\\lib\\site-packages\\win32\\win32api.pyd')}
(Pdb) q
>>> import pywintypes
# C:\Python34\lib\site-packages\win32\lib\__pycache__\pywintypes.cpython-34.pyc matches C:\Python34\lib\site-packages\win32\lib\pywintypes.py
# code object from 'C:\\Python34\\lib\\site-packages\\win32\\lib\\__pycache__\\pywintypes.cpython-34.pyc'
# C:\Python34\lib\__pycache__\imp.cpython-34.pyc matches C:\Python34\lib\imp.py
# code object from 'C:\\Python34\\lib\\__pycache__\\imp.cpython-34.pyc'
import 'imp' # <_frozen_importlib.SourceFileLoader object at 0x02F64AB0>
# extension module loaded from 'C:\\Python34\\lib\\site-packages\\win32\\_win32sysloader.pyd'
# C:\Python34\lib\__pycache__\datetime.cpython-34.pyc matches C:\Python34\lib\datetime.py
# code object from 'C:\\Python34\\lib\\__pycache__\\datetime.cpython-34.pyc'
import 'datetime' # <_frozen_importlib.SourceFileLoader object at 0x02F70230>
import 'pywintypes' # <_frozen_importlib.SourceFileLoader object at 0x02F64950>
>>> import win32api
# extension module loaded from 'C:\\Python34\\lib\\site-packages\\win32\\win32api.pyd'
>>>

----------
components: Interpreter Core
keywords: 3.4regression
messages: 214672
nosy: theller
priority: normal
severity: normal
status: open
title: Failure to import win32api (from pywin32)
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 24 17:17:02 2014
From: report at bugs.python.org (=?utf-8?q?David_Z=C3=A1mek?=)
Date: Mon, 24 Mar 2014 16:17:02 +0000
Subject: [New-bugs-announce] [issue21051] incorrect utf-8 conversion with c
	api
Message-ID: <1395677822.9.0.352855585113.issue21051@psf.upfronthosting.co.za>


New submission from David Z?mek:

I use python 2.7.6 on win32.

If I enter u'\u010d'.encode('utf-8') to console, I get '\xc4\x8d' as response. That's correct.

But it I use C API for the same, I get incorrect '\xc3\xa8' as response. 

I was testing it on this program:

#include <Python.h>
int main() {
Py_Initialize();
PyObject* dict = PyDict_New();
PyRun_String("u'\u010d'.encode('utf-8')", Py_single_input, dict, dict);
Py_DECREF(dict);
}

----------
components: Unicode
messages: 214693
nosy: dzaamek, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: incorrect utf-8 conversion with c api
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 24 18:20:08 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Mar 2014 17:20:08 +0000
Subject: [New-bugs-announce] [issue21052] Consider dropping ImportWarning
	for empty sys.path_hooks	and sys.meta_path
Message-ID: <1395681608.6.0.965988272103.issue21052@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Issue #21049 managed to trigger a huge output of "ImportWarning: sys.meta_path is empty" because it managed to trigger an import during interpreter shutdown. The ImportWarning for sys.path_hooks and sys.meta_path were originally added because before importlib took over import it was totally legal to blank out sys.path_hooks and sys.meta_path and have import continue to work. But hopefully by the time Python 3.5 comes out there will be enough knowledge out there to not blindly empty them, making the warning superfluous as well as an annoyance when things go wrong in other respects.

----------
components: Interpreter Core
messages: 214702
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Consider dropping ImportWarning for empty sys.path_hooks and sys.meta_path
type: behavior

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

From report at bugs.python.org  Mon Mar 24 22:11:07 2014
From: report at bugs.python.org (Pierre K)
Date: Mon, 24 Mar 2014 21:11:07 +0000
Subject: [New-bugs-announce] [issue21053] Idle Crash with the ^ button
Message-ID: <1395695467.77.0.0336778831429.issue21053@psf.upfronthosting.co.za>


New submission from Pierre K:

Idle crashes systematically when holding the ^button, which is regularly used in French. Very very annoying.

----------
components: IDLE
files: Script.sh
messages: 214726
nosy: pancakesnutella
priority: normal
severity: normal
status: open
title: Idle Crash with the ^ button
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file34606/Script.sh

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

From report at bugs.python.org  Tue Mar 25 00:26:18 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Mar 2014 23:26:18 +0000
Subject: [New-bugs-announce] [issue21054] Improve indexing of syntax symbols
Message-ID: <1395703578.43.0.642568496743.issue21054@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Since I will post multiple patches for review on separate issues, this is an index issue that will have multiple dependencies.

----------
messages: 214761
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Improve indexing of syntax symbols
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 25 00:27:25 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Mar 2014 23:27:25 +0000
Subject: [New-bugs-announce] [issue21055] Index (augmented) assignment
	symbols
Message-ID: <1395703645.11.0.646299409216.issue21055@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Dependency of 21054

----------
files: index-assign.diff
keywords: patch
messages: 214763
nosy: terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Index (augmented) assignment symbols
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34607/index-assign.diff

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

From report at bugs.python.org  Tue Mar 25 05:11:43 2014
From: report at bugs.python.org (NRGunby)
Date: Tue, 25 Mar 2014 04:11:43 +0000
Subject: [New-bugs-announce] [issue21056] csv documentation is incorrect
Message-ID: <1395720703.0.0.19592596057.issue21056@psf.upfronthosting.co.za>


New submission from NRGunby:

The documentation for the csv reader objects next() method is incorrect. It states '
csvreader.next()

Return the next row of the reader?s iterable object as a list, parsed according to the current dialect.'

Either the documentation for DictReader objects needs to be be made separate from normal reader objects, or this needs to be amended to say '
csvreader.next()

Return the next row of the reader?s iterable object as a list (if reader) or dict (if DictReader), parsed according to the current dialect.
'
 
I observed this in the 2.7 online docs, found it to be the case in the 3.4 online docs as well, and haven't checked other versions but assume it's the case.

----------
assignee: docs at python
components: Documentation
messages: 214775
nosy: NRGunby, docs at python
priority: normal
severity: normal
status: open
title: csv documentation is incorrect
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Mar 25 05:14:29 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 25 Mar 2014 04:14:29 +0000
Subject: [New-bugs-announce] [issue21057] TextIOWrapper does not support
	reading bytearrays or	memoryviews
Message-ID: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

In Python 3.4, TextIOWrapper can not read from streams that return bytearrays or memoryviews:

from io import TextIOWrapper, BytesIO
class MyByteStream(BytesIO):
    def read1(self, len_):
        return memoryview(super().read(len_))
bs = MyByteStream(b'some data in ascii\n')
ss = TextIOWrapper(bs, encoding='ascii')
print(ss.read(200))

results in:

TypeError: underlying read1() should have returned a bytes object, not 'memoryview'

I don't think there's any good reason for TextIOWrapper not accepting any bytes-like object (especially now that b''.join finally accepts bytes-like objects as well).

----------
components: Library (Lib)
messages: 214776
nosy: nikratio
priority: normal
severity: normal
status: open
title: TextIOWrapper does not support reading bytearrays or memoryviews
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 25 05:47:27 2014
From: report at bugs.python.org (tholzer)
Date: Tue, 25 Mar 2014 04:47:27 +0000
Subject: [New-bugs-announce] [issue21058] tempfile.NamedTemporaryFile leaks
	file descriptor when	fdopen fails
Message-ID: <1395722847.75.0.725562206789.issue21058@psf.upfronthosting.co.za>


New submission from tholzer:

The NamedTemporaryFile inside the standard tempfile library leaks an open file descriptor when fdopen fails.

Test case:

# ulimit -SHn 50
# python test1.py

from tempfile import NamedTemporaryFile

while 1:
    try:
        NamedTemporaryFile(mode='x')
    except ValueError as ex:
        pass

Output:

Traceback (most recent call last):
  File "./a2.py", line 7, in <module>
  File "/usr/lib/python2.7/tempfile.py", line 454, in NamedTemporaryFile
  File "/usr/lib/python2.7/tempfile.py", line 235, in _mkstemp_inner
OSError: [Errno 24] Too many open files: '/tmp/tmpI0MIEW'
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
ImportError: No module named fileutils

Original exception was:
Traceback (most recent call last):
  File "./a2.py", line 7, in <module>
  File "/usr/lib/python2.7/tempfile.py", line 454, in NamedTemporaryFile
  File "/usr/lib/python2.7/tempfile.py", line 235, in _mkstemp_inner
OSError: [Errno 24] Too many open files: '/tmp/tmpI0MIEW'

Patch:

@@ -452,7 +452,11 @@
         flags |= _os.O_TEMPORARY
 
     (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
-    file = _os.fdopen(fd, mode, bufsize)
+    try:
+        file = _os.fdopen(fd, mode, bufsize)
+    except Exception as ex:
+        _os.close(fd)
+        raise
     return _TemporaryFileWrapper(file, name, delete)
 
 if _os.name != 'posix' or _os.sys.platform == 'cygwin':

----------
components: Library (Lib)
messages: 214778
nosy: tholzer
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile leaks file descriptor when fdopen fails
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 25 09:12:54 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 25 Mar 2014 08:12:54 +0000
Subject: [New-bugs-announce] [issue21059] idle_test.test_warning failure
Message-ID: <1395735174.52.0.231038807129.issue21059@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Many buildbots are failing with this error:
"""
======================================================================
ERROR: idlelib.idle_test.test_warning (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\unittest\case.py", line 57, in testPartExecutor
    yield
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\unittest\case.py", line 574, in run
    testMethod()
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\unittest\loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: idlelib.idle_test.test_warning
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\unittest\loader.py", line 312, in _find_tests
    module = self._get_module_from_name(name)
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\unittest\loader.py", line 290, in _get_module_from_name
    __import__(name)
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\idlelib\idle_test\test_warning.py", line 19, in <module>
    from idlelib import run
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\idlelib\run.py", line 58, in <module>
    tcl = tkinter.Tcl()
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\tkinter\__init__.py", line 1901, in Tcl
    return Tk(screenName, baseName, className, useTk)
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\tkinter\__init__.py", line 1805, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories: 
    E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/build/lib/tcl8.6 E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/build/lib/tcl8.6 E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/lib/tcl8.6 E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/build/library E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/library E:/Data/buildslave/cpython/3.x.snakebite-win2k3r2sp2-x86/tcl8.6.1/library E:/Data/buildslave/cpython/tcl8.6.1/library



This probably means that Tcl wasn't installed properly.
"""

See e.g. http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/2274/steps/test/logs/stdio

----------
components: Tests
messages: 214781
nosy: neologix
priority: normal
severity: normal
status: open
title: idle_test.test_warning failure
type: behavior

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

From report at bugs.python.org  Tue Mar 25 09:46:37 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Mar 2014 08:46:37 +0000
Subject: [New-bugs-announce] [issue21060] Better error message for setup.py
	upload command without	sdist
Message-ID: <1395737197.75.0.193444855893.issue21060@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

>From http://jamie.curle.io/blog/my-first-experience-adding-package-pypi/ :

    python setup.py upload
    running upload
    error: no dist file created in earlier command

  I thought I was going mad because I could see the dist file, it was right there in all of [its] tar and gzipped glory.

?earlier command? is misleading, as the dist file must be created by the same command line that calls upload (for now at least; see #12944).  The error message should be clearer, and if the doc doesn?t explain how this works, it should be improved too.

----------
components: Distutils
keywords: easy
messages: 214793
nosy: dstufft, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Better error message for setup.py upload command without sdist
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 25 10:36:06 2014
From: report at bugs.python.org (Timothy Pederick)
Date: Tue, 25 Mar 2014 09:36:06 +0000
Subject: [New-bugs-announce] [issue21061] Is contextlib.redirect_stdout
	reentrant or not?
Message-ID: <1395740166.01.0.738234296915.issue21061@psf.upfronthosting.co.za>


New submission from Timothy Pederick:

The docs are contradictory on whether or not contextlib.redirect_stdout is reentrant, or reusable-but-not-reentrant. This would seem to be an oversight from issue19403, which probably should have changed "reusable but not reentrant" to "reentrant".

Present in both current and upcoming docs:
  http://docs.python.org/3/library/contextlib.html
  http://docs.python.org/3.5/library/contextlib.html

contextlib.redirect_stdout(new_target)
  ...
  This context manager is reusable but not reentrant.

29.6.3.1. Reentrant context managers
  ...
  threading.RLock is an example of a reentrant context manager, as are suppress() and redirect_stdout().
  ...
  Note also that being reentrant is not the same thing as being thread safe. redirect_stdout(), for example...

----------
assignee: docs at python
components: Documentation
messages: 214801
nosy: docs at python, perey
priority: normal
severity: normal
status: open
title: Is contextlib.redirect_stdout reentrant or not?
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 25 16:58:58 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Mar 2014 15:58:58 +0000
Subject: [New-bugs-announce] [issue21062] Evalute all import-related modules
	for best practices
Message-ID: <1395763138.25.0.943943141564.issue21062@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm thinking of:

* pkgutil
* py_compile
* compileall
* modulefinder
* freeze

Should make sure they are (a) doing the right/best thing in the face of importlib/PEP 302/PEP 420/PEP 451, and (b) if they should be integrated into importlib somehow in a non-compatible fashion for future growth and let the old versions slowly wither away.

I'm leaving out runpy as it's not directly import-related, just import-reliant, and zipimport because I don't want to touch its code. =)

----------
messages: 214833
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Evalute all import-related modules for best practices

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

From report at bugs.python.org  Tue Mar 25 17:00:11 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Mar 2014 16:00:11 +0000
Subject: [New-bugs-announce] [issue21063] Touch up one-line descriptions of
	modules for module	index
Message-ID: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. linecache says "This module provides random access to individual lines from text files." That's a big awkward and could just drop "This module" to read more easily.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 214834
nosy: brett.cannon, docs at python
priority: low
severity: normal
stage: needs patch
status: open
title: Touch up one-line descriptions of modules for module index
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 25 17:24:59 2014
From: report at bugs.python.org (Jona Sassenhagen)
Date: Tue, 25 Mar 2014 16:24:59 +0000
Subject: [New-bugs-announce] [issue21064] Simple segfault
Message-ID: <1395764699.01.0.368892003733.issue21064@psf.upfronthosting.co.za>


New submission from Jona Sassenhagen:

Simple OOP segfault CtD using OSX 10.9.2

User at here:~/$ python3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> class Word(object):
...     def __init__(self, name, phon, semantics=None, askglobal=None, ask=None, giveglobal=None, give=None):
		self.name = name
		self.phon = phon
		self.semantics = semantics
		self.askglobal = askglobal
		self.ask = ask
		self.giveglobal = giveglobal
		self.give = give


class V(Word):
	def __init__(self)
		super().__init__(self,name,phon,semantics=None, askglobal=None, ask=None, giveglobal=None, give=None):
		self.askglobal = [nom,acc]

Segmentation fault: 11

----------
assignee: ronaldoussoren
components: Macintosh
messages: 214835
nosy: Jona.Sassenhagen, ronaldoussoren
priority: normal
severity: normal
status: open
title: Simple segfault
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 25 22:42:02 2014
From: report at bugs.python.org (LuisC)
Date: Tue, 25 Mar 2014 21:42:02 +0000
Subject: [New-bugs-announce] [issue21065] Can't solve special women's
	problems? Let us do it.
Message-ID: <V94DWBIH062I08UH7F5M028615XIC7T6@docusign.net>


New submission from LuisC:

HelloLet's do it.http://blog.blueinnotech.com/xpa/
Meds that fits just for you! Because you're a lady.

----------
files: unnamed
messages: 214854
nosy: lcarrionr
priority: normal
severity: normal
status: open
title: Can't solve special women's problems? Let us do it.
Added file: http://bugs.python.org/file34620/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21065>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
<title>Hello</title>
<br>
<body>
<br>
Let's do it.
<a href="http://janwallen.com/yb/">http://blog.blueinnotech.com/xpa/</a>
<br>
</body>
  </body>

</html>


From report at bugs.python.org  Tue Mar 25 23:42:26 2014
From: report at bugs.python.org (Cristian Baboi)
Date: Tue, 25 Mar 2014 22:42:26 +0000
Subject: [New-bugs-announce] [issue21066] The separate download version for
	the documentation	doesn't work
Message-ID: <1395787346.93.0.116419141266.issue21066@psf.upfronthosting.co.za>


New submission from Cristian Baboi:

I downloaded python 2.7.6 documentation file for Windows python276.chm and it doesn't display any documentation page. It shows only the table of content.

----------
assignee: docs at python
components: Documentation, Windows
messages: 214860
nosy: Cristian.Baboi, docs at python
priority: normal
severity: normal
status: open
title: The separate download version for the documentation doesn't work
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 25 23:44:17 2014
From: report at bugs.python.org (Kevin Cox)
Date: Tue, 25 Mar 2014 22:44:17 +0000
Subject: [New-bugs-announce] [issue21067] Support Multiple finally clauses.
Message-ID: <1395787457.4.0.287090998616.issue21067@psf.upfronthosting.co.za>


New submission from Kevin Cox:

I think it would be useful to support multiple finally clauses.  The idea would be that each clause would be run, even if prior clauses throw exceptions.

The idea came when hunting a bug in the Mozilla test suite.  The code looked like as follows.

try:
	resource1 = allocateresource1()
	resource2 = allocateresource2()
	
	dostuffthatmightthrowexception()
finally:
	if resource1:
		resource1.close()
	if resource2:
		resource2.close()

The problem is that if resource1,close() throws an exception resource2 is not closed.

The alternative looks like this.

try:
	resource1 = allocateresource1()
	try:
		resource2 = allocateresource2()
		
		dostuffthatmightthrowexception()
	finally:
		if resource2:
			resource2.close()
finally:
	if resource2:
		resource2.close()

Or it could look like this.

try:
	resource1 = allocateresource1()
	resource2 = allocateresource2()
	
	dostuffthatmightthrowexception()
finally:
	try:
		if resource1:
			resource1.close()
	finally:
		if resource2:
			resource2.close()

Both of which exhibit indentation explosion when there are a number of resources that need to be cleaned up.

If multiple finally clauses were allowed the code would be much more readable and would look as follows.

try:
	resource1 = allocateresource1()
	resource2 = allocateresource2()
	
	dostuffthatmightthrowexception()
finally:
	if resource1:
		resource1.close()
finally:
	if resource2:
		resource2.close()

----------
messages: 214861
nosy: kevincox
priority: normal
severity: normal
status: open
title: Support Multiple finally clauses.

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

From report at bugs.python.org  Wed Mar 26 00:13:47 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Mar 2014 23:13:47 +0000
Subject: [New-bugs-announce] [issue21068] Make ssl.PROTOCOL_* an enum
Message-ID: <1395789227.19.0.206884350375.issue21068@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Small patch to make PROTOCOL_SSLv23 and friends enum members. Not sure this is useful.

----------
components: Library (Lib)
files: sslproto_enum.patch
keywords: patch
messages: 214865
nosy: christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Make ssl.PROTOCOL_* an enum
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34621/sslproto_enum.patch

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

From report at bugs.python.org  Wed Mar 26 09:10:37 2014
From: report at bugs.python.org (Daniel Farrell)
Date: Wed, 26 Mar 2014 08:10:37 +0000
Subject: [New-bugs-announce] [issue21069] urllib unit tests failing without
	ssl module
Message-ID: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>


New submission from Daniel Farrell:

I'm seeing quite a few unit test failures in urllib ("urlopen error unknown url type: https"). From what I've gathered on IRC, this seems to be because I'm missing the ssl module. I'm seeing these errors in 3.4.0, after a simple `./configure; make; make test`. Test results: http://pastebin.com/5LBAjkVW

I'm not seeing them after `hg clone http://hg.python.org/cpython; ./configure --with-pydebug && make -j2; ./python -m test -j3`, via http://docs.python.org/devguide/#quick-start.

Issue 20939 is the closest thing I've found to this, but it seems to be more narrowly scoped (http -> https change at python.org). Nice people on IRC suggest that this is a different enough problem to warrant a new issue.

I'm on an up-to-date Fedora 20 install.

----------
files: test_failures.txt
messages: 214882
nosy: dfarrell07
priority: normal
severity: normal
status: open
title: urllib unit tests failing without ssl module
versions: Python 3.4
Added file: http://bugs.python.org/file34626/test_failures.txt

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

From report at bugs.python.org  Wed Mar 26 18:36:51 2014
From: report at bugs.python.org (jan matejek)
Date: Wed, 26 Mar 2014 17:36:51 +0000
Subject: [New-bugs-announce] [issue21070] test_xmlrpc waits forever instead
	of reporting failure
Message-ID: <1395855411.43.0.953076776934.issue21070@psf.upfronthosting.co.za>


New submission from jan matejek:

Testcases derived from BaseServerTestCase will launch a server process in a separate thread. This server will shut itself down after handling a specified number of requests. If the test case fails before performing enough requests, the server thread will continue to wait indefinitely.

Fix for issue 14001 removed timeout from the wait on server thread, so now if a test fails, it will hang forever.

To reproduce: put self.assertTrue(False) at start of any testcase.

This matters in two cases:
1. If a testcase performs more than one request, an assertion failure on the first one will freeze the rest
2. If you make a mistake when writing a testcase, the test will hang instead of telling you that you did something wrong, and with no indication of what caused the problem (because your testcase won't be part of the backtrace when you break the wait)

----------
components: Tests
messages: 214902
nosy: matejcik
priority: normal
severity: normal
status: open
title: test_xmlrpc waits forever instead of reporting failure
type: behavior
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/issue21070>
_______________________________________

From report at bugs.python.org  Wed Mar 26 18:48:53 2014
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Wed, 26 Mar 2014 17:48:53 +0000
Subject: [New-bugs-announce] [issue21071] struct.Struct.format is bytes,
	but should be str
Message-ID: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

In Python 2, Struct.format used to be a str. In Python 3 it is bytes, which is unexpected.

Why do I expect .format to be a string:
- This format is pretty much the same as a "{}-format" - plain text
- according to documentation it is composed of things like characters from a closed set '<.=@hi...', a subset of ASCII,
- it is always called "format string" in the documentation

Why is this a problem:
- If I use a str format in constructor, I expect to get a str format,
- Comparisons are broken:

>>> struct.Struct('x').format == 'x'
False
>>> struct.Struct('x').format[0] == 'x'
False

- doctests are broken
>>> struct.Struct('x').format
'x' # in Python 2
b'x' # in Python 3

----------
components: Library (Lib)
messages: 214903
nosy: zbysz
priority: normal
severity: normal
status: open
title: struct.Struct.format is bytes, but should be str
type: behavior
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/issue21071>
_______________________________________

From report at bugs.python.org  Wed Mar 26 23:27:03 2014
From: report at bugs.python.org (Leo Butcher)
Date: Wed, 26 Mar 2014 22:27:03 +0000
Subject: [New-bugs-announce] [issue21072] Python docs and downloads not
	available for Egypt
Message-ID: <1395872823.34.0.614292416852.issue21072@psf.upfronthosting.co.za>


New submission from Leo Butcher:

I can't seem to access docs.python.org, mail.python.org, or even legacy.python.org
from my ISP in Egypt "LinkDotNet" the usual dynamic IP range is 41.130.xx.xx
please tell me if you need any further info

----------
assignee: docs at python
components: Documentation
messages: 214917
nosy: Leo.Butcher, docs at python
priority: normal
severity: normal
status: open
title: Python docs and downloads not available for Egypt
type: resource usage
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/issue21072>
_______________________________________

From report at bugs.python.org  Wed Mar 26 23:57:40 2014
From: report at bugs.python.org (Itai Bar-Natan)
Date: Wed, 26 Mar 2014 22:57:40 +0000
Subject: [New-bugs-announce] [issue21073] Py_ReprEnter potentially
	misbehaves during malformed	thread states
Message-ID: <1395874660.7.0.888688266629.issue21073@psf.upfronthosting.co.za>


New submission from Itai Bar-Natan:

While browsing the Python source code, I found this suspicious snippet in Py_ReprEnter:

    dict = PyThreadState_GetDict();
    if (dict == NULL)
        return 0;

It seems to me like the last line should be "return -1;". The way the program currently behaves, if PyThreadState_GetDict() fails and returns NULL, Py_ReprEnter will fail silently and always report that the input isn't in a recursive loop. The correct behavior is to report an error.

It would be difficult to explicitly exhibit this error since it relies on another component of Python failing first. One possible way would be to call PyObject_Repr on a recursive structure before fully initializing Python. I haven't tested this.

Alternately, it's possible that this behavior is intentional because we want PyObject_Repr to work for non-self-referential structures even before Python is fully initialized (perhaps it could be called during initialization), in exchange for a small risk of failure if it is called with a self-referential structure before initialization. In that case I suggest that this should be pointed out explicitly in the comments to this function.

----------
components: Interpreter Core
messages: 214920
nosy: itaibn
priority: normal
severity: normal
status: open
title: Py_ReprEnter potentially misbehaves during malformed thread states
type: behavior
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/issue21073>
_______________________________________

From report at bugs.python.org  Thu Mar 27 03:26:36 2014
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 27 Mar 2014 02:26:36 +0000
Subject: [New-bugs-announce] [issue21074] Too aggressive constant folding
Message-ID: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za>


New submission from INADA Naoki:

When I run following script:

def uncalled():
    x = b'x' * (2**32)
print('Hello')

Python 3.4 consumes huge memory in spite of uncalled() function isn't called.

$ /usr/bin/time  -l /usr/local/bin/python2 constant_folding.py
Hello
        0.02 real         0.01 user         0.00 sys
   4337664  maximum resident set size

$ /usr/bin/time  -l /usr/local/bin/python3 constant_folding.py
Hello
        2.76 real         1.36 user         1.39 sys
4300234752  maximum resident set size

Both of Python 2.7.6 and Python 3.4.0 is built with Homebrew.

----------
components: Interpreter Core
messages: 214928
nosy: naoki
priority: normal
severity: normal
status: open
title: Too aggressive constant folding
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 27 14:42:43 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Thu, 27 Mar 2014 13:42:43 +0000
Subject: [New-bugs-announce] [issue21075] fileinput should use stdin.buffer
	for "rb" mode
Message-ID: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

In Python 3, fileinput.input() returns str lines whether the data is
coming from stdin or from a list of files on the command line. But if
input(mode='rb') is specified, then its behavior becomes inconsistent:
lines from stdin are delivered as already-decoded strings, but data
from files is delivered (correctly) as bytes.

The solution may be that, if a "b" is anywhere in the mode, then input()
should read from the bytes stdin.buffer data source instead of from
stdin.

Otherwise the "rb" mode is rather useless since you can wind
up getting text from it anyway depending on how you are invoked.

----------
components: Library (Lib)
messages: 214952
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: fileinput should use stdin.buffer for "rb" mode
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 27 16:48:50 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 Mar 2014 15:48:50 +0000
Subject: [New-bugs-announce] [issue21076] Turn signal.SIG* constants into
	enums
Message-ID: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

Relevant discussion + BDFL approval:
https://mail.python.org/pipermail/python-ideas/2014-March/027286.html
Patch (not tested on Windows) is in attachment.

----------
components: Library (Lib)
files: signals.patch
keywords: patch
messages: 214959
nosy: giampaolo.rodola, gvanrossum
priority: normal
severity: normal
status: open
title: Turn signal.SIG* constants into enums
versions: Python 3.5
Added file: http://bugs.python.org/file34636/signals.patch

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

From report at bugs.python.org  Thu Mar 27 17:16:30 2014
From: report at bugs.python.org (Garrett Grimsley)
Date: Thu, 27 Mar 2014 16:16:30 +0000
Subject: [New-bugs-announce] [issue21077] Turtle Circle Speed 0
Message-ID: <1395936990.77.0.953738655575.issue21077@psf.upfronthosting.co.za>


New submission from Garrett Grimsley:

A circle is supposed to draw upon a click event, but if speed is set to 0 it appears that the circle fails to draw and all existing lines are erased.

A screenshot of the behavior with radius = 20 can be seen here: http://i.imgur.com/y7z87AN.png This state can be replicated by completing an entire game worth of clicks.



Someone replying to my StackOverflow question noted that if the radius of the circle is increased (radius = 200 for example) it becomes apparent that the circle  is actually drawing, but the existing lines are still erased. 

A screenshot of the behavior with radius = 200 can be seen here: http://i.imgur.com/gYeOlnT.png This state can be replicated by clicking bottom middle, middle middle, then bottom right, in that order.


You will note that only lines on the clickable Tic-Tac-Toe board are erased, and lines outside of it remain intact.


Load my code and click the Tic-Tac-Toe board to reproduce the bug. Please use my exact code, as you WILL fail to reproduce the bug by simply importing turtle and drawing a circle. To change the circle radius in my code locate the radius variable assignment in the draw_circle() function. It is located on line 77 of the code.


Source code in file is also available here: http://bpaste.net/show/189364/
Relevant StackExchange overflow link: http://stackoverflow.com/questions/22432679/turtle-circle-makes-lines-disappear/22445757

----------
components: Library (Lib)
files: aoeu.py
messages: 214963
nosy: Garrett.Grimsley, gregorlingl
priority: normal
severity: normal
status: open
title: Turtle Circle Speed 0
versions: Python 3.3
Added file: http://bugs.python.org/file34638/aoeu.py

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

From report at bugs.python.org  Thu Mar 27 17:49:51 2014
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 27 Mar 2014 16:49:51 +0000
Subject: [New-bugs-announce] [issue21078]
	multiprocessing.managers.BaseManager.__init__'s	"serializer"
	argument is not documented
Message-ID: <1395938991.3.0.211293361393.issue21078@psf.upfronthosting.co.za>


New submission from Yuriy Taraday:

We're going to use BaseManager for simple secure local RPC and for the "secure" part we can't use pickle, so we have to use "serializer" argument to switch to xmlrpclib.

We need to be sure that argument won't go away so we need it to be documented and supported on future versions.

----------
assignee: docs at python
components: Documentation
messages: 214967
nosy: docs at python, yorik.sar
priority: normal
severity: normal
status: open
title: multiprocessing.managers.BaseManager.__init__'s "serializer" argument is not documented
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/issue21078>
_______________________________________

From report at bugs.python.org  Thu Mar 27 18:12:10 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Thu, 27 Mar 2014 17:12:10 +0000
Subject: [New-bugs-announce] [issue21079] EmailMessage.is_attachment ==
	False if filename is	present
Message-ID: <1395940330.14.0.456041860337.issue21079@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

Most attachments (in my inbox, at least) specify a filename, and thus
have a Content-Disposition header that looks like:

Content-Disposition: attachment; filename="attachment.gz"

In fact, this sample header was generated by the new add_attachment()
method in Python itself. Unfortunately, the is_attachment property
currently does this test:

c_d.lower() == 'attachment'

Which means that it returns False for almost all attachments in my
email archive. I believe that the test should instead be:

c_d.split(';', 1)[0].lower() == 'attachment'

----------
components: email
messages: 214969
nosy: barry, brandon-rhodes, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.is_attachment == False if filename is present
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 28 00:10:39 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Mar 2014 23:10:39 +0000
Subject: [New-bugs-announce] [issue21080] asyncio.subprocess: connect pipes
	of two programs
Message-ID: <1395961839.47.0.279247512768.issue21080@psf.upfronthosting.co.za>


New submission from STINNER Victor:

With the current asyncio API, it's not possible to implement the shell command "ls | wc -l" in Python: connect the stdin of a consumer to the stdin of a producer.

----------
messages: 214994
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.subprocess: connect pipes of two programs
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 28 02:38:41 2014
From: report at bugs.python.org (=?utf-8?q?Jean_Christophe_Andr=C3=A9?=)
Date: Fri, 28 Mar 2014 01:38:41 +0000
Subject: [New-bugs-announce] [issue21081] missing vietnamese codec TCVN
	5712:1993 in Python
Message-ID: <1395970721.88.0.828263715521.issue21081@psf.upfronthosting.co.za>


New submission from Jean Christophe Andr?:

In Python version 2.x and at least 3.2 there no Vietnamese encoding support for TCVN 5712:1993.

This encoding is currently largely used in Vietnam and I think it would be usefull to add it to the python core encodings.

I already wrote some codec code, based on the codecs already available, that I successfully used in real life situation.

I would like to give it as a contribution to Python.

----------
components: Unicode
files: vntime_tcvn.py
messages: 215012
nosy: ezio.melotti, haypo, progfou
priority: normal
severity: normal
status: open
title: missing vietnamese codec TCVN 5712:1993 in Python
type: enhancement
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file34644/vntime_tcvn.py

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

From report at bugs.python.org  Fri Mar 28 08:04:06 2014
From: report at bugs.python.org (Ryan Lortie)
Date: Fri, 28 Mar 2014 07:04:06 +0000
Subject: [New-bugs-announce] [issue21082] _get_masked_mode in os.makedirs()
	is a serious security	problem
Message-ID: <1395990246.32.0.278092008539.issue21082@psf.upfronthosting.co.za>


New submission from Ryan Lortie:

http://bugs.python.org/file19849/mkdirs.tr.diff introduced a patch with this code in it:

+def _get_masked_mode(mode):
+    mask = umask(0)
+    umask(mask)
+    return mode & ~mask

This changes the umask of the entire process.  If another thread manages to create a file between those two calls then it will be world read/writable, regardless of the original umask of the process.

This is not theoretical: I discovered this bug by observing it happen.

----------
components: Library (Lib)
messages: 215020
nosy: desrt
priority: normal
severity: normal
status: open
title: _get_masked_mode in os.makedirs() is a serious security problem
type: security
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 28 12:13:22 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Fri, 28 Mar 2014 11:13:22 +0000
Subject: [New-bugs-announce] [issue21083] Add get_content_disposition() to
	email.message.Message
Message-ID: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

"Content-Disposition is an optional header field. In its absence, the MUA may use whatever presentation method it deems suitable." ? RFC 2183

The email.message.Message class should gain a get_content_disposition() method with the three possible return values 'inline', 'attachment', and None so that email clients can easily distinguish between the three states described in the RFC.

See also the discussion at http://bugs.python.org/issue21079

----------
components: email
messages: 215036
nosy: barry, brandon-rhodes, r.david.murray
priority: normal
severity: normal
status: open
title: Add get_content_disposition() to email.message.Message
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 28 13:01:05 2014
From: report at bugs.python.org (wjssz)
Date: Fri, 28 Mar 2014 12:01:05 +0000
Subject: [New-bugs-announce] [issue21084] IDLE can't deal with characters
	above the range	(U+0000-U+FFFF)
Message-ID: <1396008065.84.0.00802001667749.issue21084@psf.upfronthosting.co.za>


New submission from wjssz:

When open a file with characters above the range (U+0000-U+FFFF), IDLE quit without any report. For example, open this file \Lib\test\test_re.py

The below is Traceback info, the last line tells the reason. I just hope IDLE say something before quit, so we can know what happend.

I have checked Python 3.3.5 and 3.4.0, they have the same problem. I didn't find a 3.5 build, so I can't test this problem under 3.5.

=============================================
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1489, in __call__
    return self.func(*args)
  File "C:\Python33\lib\idlelib\IOBinding.py", line 186, in open
    flist.open(filename)
  File "C:\Python33\lib\idlelib\FileList.py", line 36, in open
    edit = self.EditorWindow(self, filename, key)
  File "C:\Python33\lib\idlelib\PyShell.py", line 126, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python33\lib\idlelib\EditorWindow.py", line 288, in __init__
    if io.loadfile(filename):
  File "C:\Python33\lib\idlelib\IOBinding.py", line 236, in loadfile
    self.text.insert("1.0", chars)
  File "C:\Python33\lib\idlelib\Percolator.py", line 25, in insert
    self.top.insert(index, chars, tags)
  File "C:\Python33\lib\idlelib\UndoDelegator.py", line 81, in insert
    self.addcmd(InsertCommand(index, chars, tags))
  File "C:\Python33\lib\idlelib\UndoDelegator.py", line 116, in addcmd
    cmd.do(self.delegate)
  File "C:\Python33\lib\idlelib\UndoDelegator.py", line 219, in do
    text.insert(self.index1, self.chars, self.tags)
  File "C:\Python33\lib\idlelib\ColorDelegator.py", line 85, in insert
    self.delegate.insert(index, chars, tags)
  File "C:\Python33\lib\idlelib\WidgetRedirector.py", line 104, in __call__
    return self.tk_call(self.orig_and_operation + args)
_tkinter.TclError: character U+1d518 is above the range (U+0000-U+FFFF) allowed by Tcl

----------
components: IDLE
messages: 215038
nosy: wjssz
priority: normal
severity: normal
status: open
title: IDLE can't deal with characters above the range (U+0000-U+FFFF)
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 28 16:17:09 2014
From: report at bugs.python.org (dellair jie)
Date: Fri, 28 Mar 2014 15:17:09 +0000
Subject: [New-bugs-announce] [issue21085] compile error Python3.3 on Cygwin
Message-ID: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za>


New submission from dellair jie:

Folks,

Is Cygwin supported by Python? We met the following error when compiling Python 3.3.2 on Cygwin 1.7.17:

gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c:17:0: warning: "PATH_MAX" redefined
/usr/include/limits.h:336:0: note: this is the location of the previous definition
Modules/main.c: In function ?Py_Main?:
Modules/main.c:561:5: warning: implicit declaration of function ?_setmode?
gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/_threadmodule.c -o Modules/_threadmodule.o
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes     -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c: In function ?fill_siginfo?:
./Modules/signalmodule.c:745:5: error: ?siginfo_t? has no member named ?si_band?
Makefile:1501: recipe for target `Modules/signalmodule.o' failed
make: *** [Modules/signalmodule.o] Error 1

Any lights would be appreciated.

Thanks,

----------
components: Build
messages: 215050
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: compile error Python3.3 on Cygwin
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 28 16:48:48 2014
From: report at bugs.python.org (Morten Z)
Date: Fri, 28 Mar 2014 15:48:48 +0000
Subject: [New-bugs-announce] [issue21086] Source with "# -*- coding: ASCII
	-*-" and UNIX EOL (\n)	results in SyntaxError
Message-ID: <1396021728.2.0.00333249984382.issue21086@psf.upfronthosting.co.za>


New submission from Morten Z:

Python 3.4 introduced a problem with use of

# -*- coding: ASCII -*-

so when running on Windows, the EOL must be Windows type, and else an error is generated.


See trials below:


C:\>Python34\python.exe hello_unix.py
  File "hello_unix.py", line 3
    II -*-
        ^
SyntaxError: invalid syntax


C:\>Python34\python.exe hello_win.py
Hello Python version 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:24:06) ...


C:\>Python33\python.exe hello_unix.py
Hello Python version 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) ...


C:\>Python33\python.exe hello_win.py
Hello Python version 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) ...

----------
components: Interpreter Core
files: hello_unix.py
messages: 215054
nosy: Morten.Z
priority: normal
severity: normal
status: open
title: Source with "# -*- coding: ASCII -*-" and UNIX EOL (\n) results in SyntaxError
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file34651/hello_unix.py

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

From report at bugs.python.org  Fri Mar 28 19:30:43 2014
From: report at bugs.python.org (Eric Snow)
Date: Fri, 28 Mar 2014 18:30:43 +0000
Subject: [New-bugs-announce] [issue21087] imp.frozen_init() incorrectly
	removes module during	reload
Message-ID: <1396031443.58.0.0339900849824.issue21087@psf.upfronthosting.co.za>


New submission from Eric Snow:

While reviewing code[1] for issue 20942, I noticed that when someone uses imp.frozen_init[2], the module is removed from sys.modules in some error cases.  However, this should not be done when the module already exists (e.g. reload).

As Brett pointed out in his reply to my comment in the review, frozen modules really shouldn't be reloaded, so this isn't something we necessarily need to worry about.  I.E. it's a rare corner case.  I brought it up because there's a comment in PyImport_ExecCodeModuleObject() implying a reload-related use-case.

We have 3 options:

1. don't worry about it (imp.frozen_init() is deprecated, etc.),
2. stop calling remove_module() in the reload case (i.e. be accommodating),
3. disallow reloading frozen modules (and remove that comment from import.c).

I'll shy away from #3 (consenting adults, etc.).  If someone felt like it they could work on #2, but keep in mind that there may be other reload-unfriendly code in this code path that would need adjusting if we wanted to really accommodate the use case.  I'm not convinced it's worth the trouble.

If anyone else agrees, feel free to close this issue.

[1] http://bugs.python.org/review/20942/#msg4
[2] really, anything that directly or indirectly uses PyImport_ExecCodeModuleObject() (or module_dict_for_exec() from #20942) is impacted.  In addition to imp.frozen_init(), that includes PyImport_ImportFrozenModule and PyImport_ImportFrozenModuleObject

----------
components: Library (Lib)
messages: 215063
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: test needed
status: open
title: imp.frozen_init() incorrectly removes module during reload
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 28 20:51:30 2014
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Fri, 28 Mar 2014 19:51:30 +0000
Subject: [New-bugs-announce] [issue21088] curses addch() argument position
	reverses in Python3.4.0
Message-ID: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za>


New submission from Masayuki Yamamoto:

There is a test code that is "RB" characters display on screen. I expected displaying "R" to right, and displaying "B" to bottom. It was run as expected in Python 2.7.3 and 3.2.3 on Cygwin.
But they were displayed reverse in Python 3.4.0. And when addch() arguments reversed, they were displayed in expected positions.

import curses

def test(stdscr):
    stdscr.addch(0, 5, b'R')
    stdscr.addch(5, 0, b'B')
    stdscr.refresh()
    stdscr.getch()

curses.wrapper(test)

Please make sure of issues, and fix it.
Thanks.

----------
components: Library (Lib)
messages: 215074
nosy: masamoto
priority: normal
severity: normal
status: open
title: curses addch() argument position reverses in Python3.4.0
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 28 21:19:14 2014
From: report at bugs.python.org (Eric Snow)
Date: Fri, 28 Mar 2014 20:19:14 +0000
Subject: [New-bugs-announce] [issue21089] macro SET_SYS_FROM_STRING_BORROW
	doesn't get unset
Message-ID: <1396037954.9.0.881070684031.issue21089@psf.upfronthosting.co.za>


New submission from Eric Snow:

In Python/sysmodule.c (_PySys_Init), the SET_SYS_FROM_STRING_BORROW macro is created right next to SET_SYS_FROM_STRING.  However, while SET_SYS_FROM_STRING is unset at the end of _PySys_Init,  SET_SYS_FROM_STRING_BORROW is not unset.  I expect that it should be.

 #endif

 #undef SET_SYS_FROM_STRING
+#undef SET_SYS_FROM_STRING_BORROW
     if (PyErr_Occurred())

----------
messages: 215075
nosy: brett.cannon, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: macro SET_SYS_FROM_STRING_BORROW doesn't get unset
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 28 23:29:46 2014
From: report at bugs.python.org (ivank)
Date: Fri, 28 Mar 2014 22:29:46 +0000
Subject: [New-bugs-announce] [issue21090] File read silently stops after EIO
	I/O error
Message-ID: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za>


New submission from ivank:

I intentionally corrupted a zpool to induce an I/O error in a file, in this case, /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so

# ls -l /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so
-rw-r--r-- 1 root root 231,496 2014-03-24 06:26 /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so

# cat /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so > /dev/null
cat: /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so: Input/output error

When I read the file, Python 3.3.5 and 3.4.0 check for EIO and raise an exception:

>>> open("/usr/lib/x86_64-linux-gnu/gconv/IBM1390.so", "rb").read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 5] Input/output error

but Python 2.7.6 does not:

# python2
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = open("/usr/lib/x86_64-linux-gnu/gconv/IBM1390.so", "rb").read()
>>> len(x)
131072

----------
components: IO
messages: 215085
nosy: ivank
priority: normal
severity: normal
status: open
title: File read silently stops after EIO I/O error
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 29 02:26:19 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 29 Mar 2014 01:26:19 +0000
Subject: [New-bugs-announce] [issue21091] EmailMessage.is_attachment should
	be a method
Message-ID: <1396056379.22.0.363709068017.issue21091@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

I love properties and think they should be everywhere. But consistency is more important, so I suspect that EmailMessage.is_attachment should be demoted to a normal method. Why? Because if it remains a property then I am likely to first write:

    if msg.is_attachment:
        ...

and then later, when doing another bit of email logic, write:

    if msg.is_multipart:
        ...

Unfortunately this second piece of code will give me no error and will appear to run just fine, because bool(a_method) always returns True without a problem or warning or error. But the result will not be what I expect: the if statement's true block will always run, regardless of whether the message is multipart.

Since EmailMessage is still provisional, and since no one can use is_attachment yet anyway because it is broken for nearly all attachments, mightn't we make these two features consistent before calling it official?

----------
components: email
messages: 215104
nosy: barry, brandon-rhodes, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.is_attachment should be a method
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 29 03:02:12 2014
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 29 Mar 2014 02:02:12 +0000
Subject: [New-bugs-announce] [issue21092] json serializer implicitly
	stringifies non-string keys
Message-ID: <1396058532.4.0.747084200104.issue21092@psf.upfronthosting.co.za>


New submission from Chris Rebert:

Python 3.3.4 (default, Feb 21 2014, 18:00:34) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from json import dumps
>>> dumps({True: True, False: False, None: None, 42: 42})
'{"false": false, "true": true, "42": 42, "null": null}'
>>>


This implicit stringification of non-string dictionary keys does not currently appear to be documented.

----------
assignee: docs at python
components: Documentation
messages: 215105
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: json serializer implicitly stringifies non-string keys
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 29 03:31:12 2014
From: report at bugs.python.org (Nullpex)
Date: Sat, 29 Mar 2014 02:31:12 +0000
Subject: [New-bugs-announce] [issue21093] ctypes test_macholib fails if libz
	is not installed in	/usr/lib
Message-ID: <1396060272.92.0.250728546732.issue21093@psf.upfronthosting.co.za>


New submission from Nullpex:

I'm compiling on a Mac OS X 10.9.2.
Python version 3.4.0.
My libz --prefix is $HOME so the library is in $HOME/lib/
The issue is line 53 of Lib/ctypes/test/test_macholib.py which has /usr/lib/libz.1 hardcoded:

======================================================================
FAIL: test_find (ctypes.test.test_macholib.MachOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/machados/src/Python-3.4.0/Lib/ctypes/test/test_macholib.py", line 53, in test_find
    self.assertTrue(result.startswith('/usr/lib/libz.1'))
AssertionError: False is not true

I've added a print before the assert command and the library is successfully found:

$ ./python.exe ./Lib/ctypes/test/test_macholib.py
/Users/machados/lib/libz.1.2.8.dylib
F
======================================================================
FAIL: test_find (__main__.MachOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/machados/src/Python-3.4.0/Lib/ctypes/test/test_macholib.py", line 54, in test_find
    self.assertTrue(result.startswith('/usr/lib/libz.1'))
AssertionError: False is not true

----------------------------------------------------------------------
Ran 1 test in 0.001s

As you can see the library is found in /Users/machados/lib/libz.1.2.8.dylib which is correct.

----------
components: ctypes
messages: 215107
nosy: nullpex
priority: normal
severity: normal
status: open
title: ctypes test_macholib fails if libz is not installed in /usr/lib
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 29 03:45:12 2014
From: report at bugs.python.org (Nullpex)
Date: Sat, 29 Mar 2014 02:45:12 +0000
Subject: [New-bugs-announce] [issue21094] sqlite3 CheckOpcodeCount fails
	with AssertionError: 5	not greater than 5
Message-ID: <1396061112.81.0.192825646408.issue21094@psf.upfronthosting.co.za>


New submission from Nullpex:

This is the only sqlite3 test that fails:

Re-running test 'test_sqlite' in verbose mode
test_sqlite: testing with version '2.6.0', sqlite_version '3.8.4.2'
CheckAPILevel (sqlite3.test.dbapi.ModuleTests) ... ok
CheckDataError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckDatabaseError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckIntegrityError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckInterfaceError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckInternalError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckNotSupportedError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckOperationalError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckParamStyle (sqlite3.test.dbapi.ModuleTests) ... ok
CheckProgrammingError (sqlite3.test.dbapi.ModuleTests) ... ok
CheckThreadSafety (sqlite3.test.dbapi.ModuleTests) ... ok
CheckWarning (sqlite3.test.dbapi.ModuleTests) ... ok
CheckClose (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckCommit (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckCommitAfterNoChanges (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckCursor (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckExceptions (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckFailedOpen (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckInTransaction (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckInTransactionRO (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckOpenUri (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckRollback (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckRollbackAfterNoChanges (sqlite3.test.dbapi.ConnectionTests) ... ok
CheckArraySize (sqlite3.test.dbapi.CursorTests) ... ok
CheckClose (sqlite3.test.dbapi.CursorTests) ... ok
CheckCursorConnection (sqlite3.test.dbapi.CursorTests) ... ok
CheckCursorWrongClass (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteArgFloat (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteArgInt (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteArgString (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteArgStringWithZeroByte (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteDictMapping (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteDictMappingNoArgs (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteDictMappingTooLittleArgs (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteDictMappingUnnamed (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteDictMapping_Mapping (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteIllegalSql (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManyGenerator (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManyIterator (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManyNotIterable (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManySelect (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManySequence (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteManyWrongSqlArg (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteNoArgs (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteParamList (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteParamSequence (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteTooMuchSql (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteTooMuchSql2 (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteTooMuchSql3 (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteWrongNoOfArgs1 (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteWrongNoOfArgs2 (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteWrongNoOfArgs3 (sqlite3.test.dbapi.CursorTests) ... ok
CheckExecuteWrongSqlArg (sqlite3.test.dbapi.CursorTests) ... ok
CheckFetchIter (sqlite3.test.dbapi.CursorTests) ... ok
CheckFetchall (sqlite3.test.dbapi.CursorTests) ... ok
CheckFetchmany (sqlite3.test.dbapi.CursorTests) ... ok
CheckFetchmanyKwArg (sqlite3.test.dbapi.CursorTests)
Checks if fetchmany works with keyword arguments ... ok
CheckFetchone (sqlite3.test.dbapi.CursorTests) ... ok
CheckFetchoneNoStatement (sqlite3.test.dbapi.CursorTests) ... ok
CheckRowcountExecute (sqlite3.test.dbapi.CursorTests) ... ok
CheckRowcountExecutemany (sqlite3.test.dbapi.CursorTests) ... ok
CheckRowcountSelect (sqlite3.test.dbapi.CursorTests) ... ok
CheckSetinputsizes (sqlite3.test.dbapi.CursorTests) ... ok
CheckSetoutputsize (sqlite3.test.dbapi.CursorTests) ... ok
CheckSetoutputsizeNoColumn (sqlite3.test.dbapi.CursorTests) ... ok
CheckTotalChanges (sqlite3.test.dbapi.CursorTests) ... ok
CheckWrongCursorCallable (sqlite3.test.dbapi.CursorTests) ... ok
CheckConClose (sqlite3.test.dbapi.ThreadTests) ... ok
CheckConCommit (sqlite3.test.dbapi.ThreadTests) ... ok
CheckConCursor (sqlite3.test.dbapi.ThreadTests) ... ok
CheckConRollback (sqlite3.test.dbapi.ThreadTests) ... ok
CheckCurClose (sqlite3.test.dbapi.ThreadTests) ... ok
CheckCurExecute (sqlite3.test.dbapi.ThreadTests) ... ok
CheckCurImplicitBegin (sqlite3.test.dbapi.ThreadTests) ... ok
CheckCurIterNext (sqlite3.test.dbapi.ThreadTests) ... ok
CheckBinary (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckDate (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckDateFromTicks (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckTime (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckTimeFromTicks (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckTimestamp (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckTimestampFromTicks (sqlite3.test.dbapi.ConstructorTests) ... ok
CheckConnectionExecute (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckConnectionExecutemany (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckConnectionExecutescript (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckScriptErrorNormal (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckScriptStringSql (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckScriptSyntaxError (sqlite3.test.dbapi.ExtensionTests) ... ok
CheckClosedCall (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedConCommit (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedConCursor (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedConRollback (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedCreateAggregate (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedCreateFunction (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedCurExecute (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedSetAuthorizer (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosedSetProgressCallback (sqlite3.test.dbapi.ClosedConTests) ... ok
CheckClosed (sqlite3.test.dbapi.ClosedCurTests) ... ok
CheckBlob (sqlite3.test.types.SqliteTypeTests) ... ok
CheckFloat (sqlite3.test.types.SqliteTypeTests) ... ok
CheckLargeInt (sqlite3.test.types.SqliteTypeTests) ... ok
CheckSmallInt (sqlite3.test.types.SqliteTypeTests) ... ok
CheckString (sqlite3.test.types.SqliteTypeTests) ... ok
CheckUnicodeExecute (sqlite3.test.types.SqliteTypeTests) ... ok
CheckBlob (sqlite3.test.types.DeclTypesTests) ... ok
CheckBool (sqlite3.test.types.DeclTypesTests) ... ok
CheckFloat (sqlite3.test.types.DeclTypesTests) ... ok
CheckFoo (sqlite3.test.types.DeclTypesTests) ... ok
CheckLargeInt (sqlite3.test.types.DeclTypesTests) ... ok
CheckNumber1 (sqlite3.test.types.DeclTypesTests) ... ok
CheckNumber2 (sqlite3.test.types.DeclTypesTests)
Checks whether converter names are cut off at '(' characters ... ok
CheckSmallInt (sqlite3.test.types.DeclTypesTests) ... ok
CheckString (sqlite3.test.types.DeclTypesTests) ... ok
CheckUnicode (sqlite3.test.types.DeclTypesTests) ... ok
CheckUnsupportedDict (sqlite3.test.types.DeclTypesTests) ... ok
CheckUnsupportedSeq (sqlite3.test.types.DeclTypesTests) ... ok
CheckCaseInConverterName (sqlite3.test.types.ColNamesTests) ... ok
CheckColName (sqlite3.test.types.ColNamesTests) ... ok
CheckCursorDescriptionNoRow (sqlite3.test.types.ColNamesTests) ... ok
CheckDeclTypeNotUsed (sqlite3.test.types.ColNamesTests) ... ok
CheckNone (sqlite3.test.types.ColNamesTests) ... ok
CheckCasterIsUsed (sqlite3.test.types.ObjectAdaptationTests) ... ok
CheckBinaryInputForConverter (sqlite3.test.types.BinaryConverterTests) ... ok
CheckDateTimeSubSeconds (sqlite3.test.types.DateTimeTests) ... ok
CheckDateTimeSubSecondsFloatingPoint (sqlite3.test.types.DateTimeTests) ... ok
CheckSqlTimestamp (sqlite3.test.types.DateTimeTests) ... ok
CheckSqliteDate (sqlite3.test.types.DateTimeTests) ... ok
CheckSqliteTimestamp (sqlite3.test.types.DateTimeTests) ... ok
CheckFuncErrorOnCreate (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncException (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncRefCount (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnBlob (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnFloat (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnInt (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnLongLong (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnNull (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnText (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckFuncReturnUnicode (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamBlob (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamFloat (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamInt (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamLongLong (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamNone (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckParamString (sqlite3.test.userfunctions.FunctionTests) ... ok
CheckAggrCheckAggrSum (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrCheckParamBlob (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrCheckParamFloat (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrCheckParamInt (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrCheckParamNone (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrCheckParamStr (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrErrorOnCreate (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrExceptionInFinalize (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrExceptionInInit (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrExceptionInStep (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrNoFinalize (sqlite3.test.userfunctions.AggregateTests) ... ok
CheckAggrNoStep (sqlite3.test.userfunctions.AggregateTests) ... ok
test_column_access (sqlite3.test.userfunctions.AuthorizerTests) ... ok
test_table_access (sqlite3.test.userfunctions.AuthorizerTests) ... ok
test_column_access (sqlite3.test.userfunctions.AuthorizerRaiseExceptionTests) ... ok
test_table_access (sqlite3.test.userfunctions.AuthorizerRaiseExceptionTests) ... ok
test_column_access (sqlite3.test.userfunctions.AuthorizerIllegalTypeTests) ... ok
test_table_access (sqlite3.test.userfunctions.AuthorizerIllegalTypeTests) ... ok
test_column_access (sqlite3.test.userfunctions.AuthorizerLargeIntegerTests) ... ok
test_table_access (sqlite3.test.userfunctions.AuthorizerLargeIntegerTests) ... ok
CheckIsInstance (sqlite3.test.factory.ConnectionFactoryTests) ... ok
CheckIsInstance (sqlite3.test.factory.CursorFactoryTests) ... ok
CheckIsProducedByFactory (sqlite3.test.factory.RowFactoryTestsBackwardsCompat) ... ok
CheckCustomFactory (sqlite3.test.factory.RowFactoryTests) ... ok
CheckSqliteRowAsDict (sqlite3.test.factory.RowFactoryTests)
Checks if the row object can be correctly converted to a dictionary ... ok
CheckSqliteRowAsTuple (sqlite3.test.factory.RowFactoryTests)
Checks if the row object can be converted to a tuple ... ok
CheckSqliteRowHashCmp (sqlite3.test.factory.RowFactoryTests)
Checks if the row object compares and hashes correctly ... ok
CheckSqliteRowIndex (sqlite3.test.factory.RowFactoryTests) ... ok
CheckSqliteRowIter (sqlite3.test.factory.RowFactoryTests)
Checks if the row object is iterable ... ok
CheckCustom (sqlite3.test.factory.TextFactoryTests) ... ok
CheckOptimizedUnicode (sqlite3.test.factory.TextFactoryTests) ... ok
CheckString (sqlite3.test.factory.TextFactoryTests) ... ok
CheckUnicode (sqlite3.test.factory.TextFactoryTests) ... ok
CheckBytearray (sqlite3.test.factory.TextFactoryTestsWithEmbeddedZeroBytes) ... ok
CheckBytes (sqlite3.test.factory.TextFactoryTestsWithEmbeddedZeroBytes) ... ok
CheckCustom (sqlite3.test.factory.TextFactoryTestsWithEmbeddedZeroBytes) ... ok
CheckString (sqlite3.test.factory.TextFactoryTestsWithEmbeddedZeroBytes) ... ok
CheckDMLdoesAutoCommitBefore (sqlite3.test.transactions.TransactionTests) ... ok
CheckDeleteStartsTransaction (sqlite3.test.transactions.TransactionTests) ... ok
CheckInsertStartsTransaction (sqlite3.test.transactions.TransactionTests) ... ok
CheckLocking (sqlite3.test.transactions.TransactionTests) ... ok
CheckRaiseTimeout (sqlite3.test.transactions.TransactionTests) ... ok
CheckReplaceStartsTransaction (sqlite3.test.transactions.TransactionTests) ... ok
CheckRollbackCursorConsistency (sqlite3.test.transactions.TransactionTests) ... ok
CheckToggleAutoCommit (sqlite3.test.transactions.TransactionTests) ... ok
CheckUpdateStartsTransaction (sqlite3.test.transactions.TransactionTests) ... ok
CheckDropTable (sqlite3.test.transactions.SpecialCommandTests) ... ok
CheckPragma (sqlite3.test.transactions.SpecialCommandTests) ... ok
CheckVacuum (sqlite3.test.transactions.SpecialCommandTests) ... ok
CheckCollationIsUsed (sqlite3.test.hooks.CollationTests) ... ok
CheckCollationRegisterTwice (sqlite3.test.hooks.CollationTests) ... ok
CheckCollationReturnsLargeInteger (sqlite3.test.hooks.CollationTests) ... ok
CheckCreateCollationNotAscii (sqlite3.test.hooks.CollationTests) ... ok
CheckCreateCollationNotCallable (sqlite3.test.hooks.CollationTests) ... ok
CheckDeregisterCollation (sqlite3.test.hooks.CollationTests) ... ok
CheckCancelOperation (sqlite3.test.hooks.ProgressTests) ... ok
CheckClearHandler (sqlite3.test.hooks.ProgressTests) ... ok
CheckOpcodeCount (sqlite3.test.hooks.ProgressTests) ... FAIL
CheckProgressHandlerUsed (sqlite3.test.hooks.ProgressTests) ... ok
CheckClearTraceCallback (sqlite3.test.hooks.TraceCallbackTests) ... ok
CheckTraceCallbackUsed (sqlite3.test.hooks.TraceCallbackTests) ... ok
CheckUnicodeContent (sqlite3.test.hooks.TraceCallbackTests) ... ok
CheckAutoCommit (sqlite3.test.regression.RegressionTests) ... ok
CheckCollation (sqlite3.test.regression.RegressionTests) ... ok
CheckColumnNameWithSpaces (sqlite3.test.regression.RegressionTests) ... ok
CheckConnectionCall (sqlite3.test.regression.RegressionTests) ... ok
CheckConnectionConstructorCallCheck (sqlite3.test.regression.RegressionTests) ... ok
CheckConvertTimestampMicrosecondPadding (sqlite3.test.regression.RegressionTests) ... ok
CheckCursorConstructorCallCheck (sqlite3.test.regression.RegressionTests) ... ok
CheckCursorRegistration (sqlite3.test.regression.RegressionTests) ... ok
CheckEmptyStatement (sqlite3.test.regression.RegressionTests) ... ok
CheckErrorMsgDecodeError (sqlite3.test.regression.RegressionTests) ... ok
CheckInvalidIsolationLevelType (sqlite3.test.regression.RegressionTests) ... ok
CheckOnConflictRollback (sqlite3.test.regression.RegressionTests) ... ok
CheckPragmaAutocommit (sqlite3.test.regression.RegressionTests) ... ok
CheckPragmaSchemaVersion (sqlite3.test.regression.RegressionTests) ... ok
CheckPragmaUserVersion (sqlite3.test.regression.RegressionTests) ... ok
CheckRecursiveCursorUse (sqlite3.test.regression.RegressionTests) ... ok
CheckRegisterAdapter (sqlite3.test.regression.RegressionTests) ... ok
CheckSetDict (sqlite3.test.regression.RegressionTests) ... ok
CheckSetIsolationLevel (sqlite3.test.regression.RegressionTests) ... ok
CheckStatementFinalizationOnCloseDb (sqlite3.test.regression.RegressionTests) ... ok
CheckStatementReset (sqlite3.test.regression.RegressionTests) ... ok
CheckStrSubclass (sqlite3.test.regression.RegressionTests) ... ok
CheckTypeMapUsage (sqlite3.test.regression.RegressionTests) ... ok
CheckWorkaroundForBuggySqliteTransferBindings (sqlite3.test.regression.RegressionTests) ... ok
CheckTableDump (sqlite3.test.dump.DumpTests) ... ok
CheckUnorderableRow (sqlite3.test.dump.DumpTests) ... ok

======================================================================
FAIL: CheckOpcodeCount (sqlite3.test.hooks.ProgressTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/machados/src/Python-3.4.0/Lib/sqlite3/test/hooks.py", line 165, in CheckOpcodeCount
    self.assertGreater(first_count, second_count)
AssertionError: 5 not greater than 5

----------------------------------------------------------------------
Ran 233 tests in 0.479s

FAILED (failures=1)
test test_sqlite failed
make: *** [test] Error 1

----------
components: Tests
messages: 215109
nosy: nullpex
priority: normal
severity: normal
status: open
title: sqlite3 CheckOpcodeCount fails with AssertionError: 5 not greater than 5
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 29 04:33:26 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 29 Mar 2014 03:33:26 +0000
Subject: [New-bugs-announce] [issue21095] EmailMessage should support Header
	objects
Message-ID: <1396064006.24.0.869969435717.issue21095@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

Currently, the new wonderful EmailMessage class ignores the encoding specified in any Header objects that are provided to it.

import email.message, email.header
m = email.message.Message()
m['Subject'] = email.header.Header('B??varr'.encode('latin-1'), 'latin-1')
print(m.as_string())

Subject: =?iso-8859-1?q?B=F6=F0varr?=

m = email.message.EmailMessage()
m['Subject'] = email.header.Header('B??varr'.encode('latin-1'), 'latin-1')
print(m.as_string())

Traceback (most recent call last):
  ...
TypeError: 'Header' object does not support indexing

If the EmailMessage came to recognize and support Header objects, then Python programmers under specific constraints regarding what encodings their customers' email clients will recognize and support would be able to hand-craft the selection of the correct encoding instead of being forced to either ASCII or UTF-8 with binary as the two predominant choices that EmailMessage makes on its own.

----------
components: email
messages: 215112
nosy: barry, brandon-rhodes, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage should support Header objects
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 29 19:37:37 2014
From: report at bugs.python.org (Nathanel Titane)
Date: Sat, 29 Mar 2014 18:37:37 +0000
Subject: [New-bugs-announce] [issue21096] Python icon hardcoded
Message-ID: <1396118257.64.0.180360168436.issue21096@psf.upfronthosting.co.za>


New submission from Nathanel Titane:

The python icon path in each of the respective launchers for the 2.x and 3.x series seem to be hardcoded to an absolute path rather than designating the relative /usr/share/icons/... directory on the 'Icon=' line within the desktop launcher file located within  usr/share/applications/

Arguments:

Trivial bug yet very important to prevent inexperienced user root access and modification of system files

Needed to prevent system-wide icon theme 'breakage' from non standard 'Icon=' path that should normally refer to /usr/share/icons/ when using third party themes (ex: Faenza, Numix, etc.)

---

Before:

Icon=/usr/share/pixmaps/python2.7.xpm

Icon=/usr/share/pixmaps/python3.3.xpm

Icon=/usr/share/pixmaps/python3.4.xpm

After:

Icon=python

----------
components: Installation
messages: 215137
nosy: nathanel.titane
priority: normal
severity: normal
status: open
title: Python icon hardcoded
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/issue21096>
_______________________________________

From report at bugs.python.org  Sat Mar 29 22:21:24 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 29 Mar 2014 21:21:24 +0000
Subject: [New-bugs-announce] [issue21097] Move test_namespace_pkgs into
	test_importlib.
Message-ID: <1396128084.92.0.614609718769.issue21097@psf.upfronthosting.co.za>


New submission from Eric Snow:

While working on #19711 it dawned on me that test_namespace_pkgs might be more appropriate as a submodule of test_importlib.  The feature doesn't have it's own module nor is it otherwise independent of importlib.

I don't want to introduce churn here for the sake of conceptual purity.  Rather, the module would be more discoverable if associated with importlib in this way.  For #19711 I wrote a test case that was overly complicated and did not work (goes hand-in-hand, no?) that I would not have spent time on if I'd remembered about test_namespace_pkgs or seen it somewhere under test_import*.

As a bonus, this change moves 1 file and 1 directory out of Lib/test (a directory that takes "flat is better than nested" to the extreme).

Any objections?

----------
messages: 215145
nosy: barry, brett.cannon, eric.smith, eric.snow, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Move test_namespace_pkgs into test_importlib.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 29 22:32:38 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 29 Mar 2014 21:32:38 +0000
Subject: [New-bugs-announce] [issue21098] Address remaining PEP 451-related
	to-do comments.
Message-ID: <1396128758.33.0.18680321708.issue21098@psf.upfronthosting.co.za>


New submission from Eric Snow:

(from msg207510 in issue 18864)

There are a few lingering to-do comments:

Lib/test/test_importlib/extension/test_case_sensitivity.py:# XXX find_spec tests
Lib/test/test_importlib/extension/test_finder.py:# XXX find_spec tests
Lib/test/test_importlib/source/test_file_loader.py:                mod = loader.load_module('_temp') # XXX
Lib/test/test_importlib/source/test_file_loader.py:            # XXX Change to use exec_module().
Lib/test/test_importlib/test_windows.py:    # XXX Need a test that finds the spec via the registry.

----------
assignee: eric.snow
components: Tests
messages: 215146
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Address remaining PEP 451-related to-do comments.
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 29 22:34:35 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 29 Mar 2014 21:34:35 +0000
Subject: [New-bugs-announce] [issue21099] Switch applicable importlib tests
	to use PEP 451 API
Message-ID: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>


New submission from Eric Snow:

(from msg202657 in issue 18864)

A bunch of importlib (and other?) tests make direct calls to find_module(), find_loader(), or load_module().  These are still working, as expected.  However, we should probably either replace them or supplement them with equivalent tests that make use of specs directly.

----------
assignee: eric.snow
components: Tests
messages: 215147
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Switch applicable importlib tests to use PEP 451 API
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 30 07:49:39 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Mar 2014 05:49:39 +0000
Subject: [New-bugs-announce] [issue21100] Micro-optimization for tuple
	comparison
Message-ID: <1396158579.93.0.877720077458.issue21100@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The tuple comparison code contains an outdated comment to the effect that testing unequal lengths for an early-out may not be worth it because it is an uncommon case in real code.

While the unequal length case remains rare, the common case code (added when rich comparisons were introduced) pays a price by not being able to assume the lengths are equal.  Adding an single early length equality test saves a repeated inner loop test for "i < wlen" and a single post-loop test for "i >= wlen".

----------
components: Interpreter Core
files: tuple_micro_optimization.diff
keywords: patch
messages: 215166
nosy: rhettinger
priority: low
severity: normal
stage: patch review
status: open
title: Micro-optimization for tuple comparison
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34665/tuple_micro_optimization.diff

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

From report at bugs.python.org  Sun Mar 30 10:47:09 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Mar 2014 08:47:09 +0000
Subject: [New-bugs-announce] [issue21101] Extend the PyDict C API to handle
	cases where the hash	value in known
Message-ID: <1396169229.58.0.519434506461.issue21101@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: Interpreter Core
files: known_hash.diff
keywords: patch
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Extend the PyDict C API to handle cases where the hash value in known
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34666/known_hash.diff

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

From report at bugs.python.org  Sun Mar 30 11:25:42 2014
From: report at bugs.python.org (koobs)
Date: Sun, 30 Mar 2014 09:25:42 +0000
Subject: [New-bugs-announce] [issue21102] 3.4.0 PDF (a4,
	letter) and EPUB documentation missing
Message-ID: <1396171542.11.0.799932081672.issue21102@psf.upfronthosting.co.za>


New submission from koobs:

python-3.4.0-docs-pdf-letter.{zip,tar.bz2}
python-3.4.0-docs-pdf-letter.{zip,tar.bz2}

are missing from:

https://www.python.org/ftp/python/doc/3.4.0/

/current/ also still points to 3.3.x documentation:

https://www.python.org/ftp/python/doc/current/

----------
assignee: docs at python
components: Documentation
messages: 215176
nosy: docs at python, koobs
priority: normal
severity: normal
status: open
title: 3.4.0 PDF (a4,letter) and EPUB documentation missing
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 30 19:57:53 2014
From: report at bugs.python.org (Christopher Foo)
Date: Sun, 30 Mar 2014 17:57:53 +0000
Subject: [New-bugs-announce] [issue21103] Encoding str to IDNA with ellipsis
	decomposes to empty	labels
Message-ID: <1396202273.23.0.997989439656.issue21103@psf.upfronthosting.co.za>


New submission from Christopher Foo:

When encoding a string with the IDNA codec I expected that it will always raise an exception with empty labels. When I do this

    >>> 'example.c?'.encode('idna').decode('ascii')

it returns

    'example.c...'

instead of raising UnicodeError. The original string ends with U+2026 HORIZONTAL ELLIPSIS if you can't see it clearly. These strings are coming from web pages in a web crawler.

I tested this on Python 3.4, 3.3.2, 2.7.5, 2.6.9.

----------
components: Library (Lib)
messages: 215189
nosy: chfoo
priority: normal
severity: normal
status: open
title: Encoding str to IDNA with ellipsis decomposes to empty labels
type: behavior

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

From report at bugs.python.org  Sun Mar 30 20:02:23 2014
From: report at bugs.python.org (Alex Grinko)
Date: Sun, 30 Mar 2014 18:02:23 +0000
Subject: [New-bugs-announce] [issue21104] Read from file aborted
Message-ID: <1396202543.66.0.928305526795.issue21104@psf.upfronthosting.co.za>


New submission from Alex Grinko:

When reading from text file on Windows Python ends loop on character 0x1A
sample.py:
number = 0
with open("sample.txt",'r') as f:
    for line in f:
        number += 1
	print line
print "File has 8 lines, but Python could read only ",number

----------
components: Windows
files: sample.txt
messages: 215190
nosy: Alex.Grinko
priority: normal
severity: normal
status: open
title: Read from file aborted
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file34670/sample.txt

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

From report at bugs.python.org  Sun Mar 30 20:15:13 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 30 Mar 2014 18:15:13 +0000
Subject: [New-bugs-announce] [issue21105] functools.partialmethod example
	doesn't actually work
Message-ID: <1396203313.39.0.663002564911.issue21105@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Specifically the example at: https://docs.python.org/3/library/functools.html?highlight=functools#functools.partialmethod

``_alive`` isn't actually assigned before the example tries to read it. Running this code at a for-real REPL results in:

>>> class Cell(object):
...     @property
...     def alive(self):
...         return self._alive
...     def set_state(self, state):
...         self._alive = bool(state)
...     import functools
...     set_alive = functools.partialmethod(set_state, True)
...     set_dead = functools.partialmethod(set_state, False)
...
>>> c = Cell()
>>> c.alive
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in alive
AttributeError: 'Cell' object has no attribute '_alive'

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 215191
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: functools.partialmethod example doesn't actually work
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 30 23:14:17 2014
From: report at bugs.python.org (Vivek Jain)
Date: Sun, 30 Mar 2014 21:14:17 +0000
Subject: [New-bugs-announce] [issue21106] Updated Mac folder icon
Message-ID: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za>


New submission from Vivek Jain:

Python 3 still uses an old-style Mac folder icon in its installer (https://github.com/python-git/python/blob/master/Mac/Icons/Python%20Folder.icns?raw=true) that looks out of place on recent Macs. I created a quick replacement that is higher res and fits in better.

----------
assignee: ronaldoussoren
components: Macintosh
files: Python Folder.icns
messages: 215200
nosy: ronaldoussoren, viveksjain
priority: normal
severity: normal
status: open
title: Updated Mac folder icon
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34671/Python Folder.icns

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

From report at bugs.python.org  Mon Mar 31 06:04:19 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 31 Mar 2014 04:04:19 +0000
Subject: [New-bugs-announce] [issue21107] Add pgen.vcxproj to allow
	regenerating grammar files on	Windows
Message-ID: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch to allow building (and using) pgen on Windows.

All changes outside of PCbuild are solely to avoid compiler warnings, namely 4 instances of C4005 for PGEN being redefined and 2 instances of C4018, "'<' : signed/unsigned mismatch".

pgen.vcxproj is in large part copied directly from _freeze_importlib.vcxproj (and modified appropriately).

pgen is not set to build on any solution configuration, but it happily builds from a clean checkout so pythoncore.vcxproj could be made to depend on it.

----------
components: Build, Windows
files: windows_pgen.diff
keywords: patch
messages: 215218
nosy: loewis, tim.golden, tim.peters, zach.ware
priority: low
severity: normal
status: open
title: Add pgen.vcxproj to allow regenerating grammar files on Windows
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34674/windows_pgen.diff

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

From report at bugs.python.org  Mon Mar 31 06:42:24 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Mon, 31 Mar 2014 04:42:24 +0000
Subject: [New-bugs-announce] [issue21108] Add doc examples for importlib
Message-ID: <1396240944.13.0.279884654032.issue21108@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

The imp module was the defacto module to access the import internals,upto 3.3
It has been deprecated(pending) in 3.4 in favor of importlib.
There are plenty of examples on how to use imp around the web, but very little (even in doc.python.org), on how to use importlib. 

The proposed patch adds couple of examples. These examples are aimed towards people, who were earlier using imp's load_module().

Inspiration for the patch from this SO answer, where user had to go through source code.
http://stackoverflow.com/questions/19009932/import-abitrary-python-source-file-python-3-3

----------
assignee: docs at python
components: Documentation
files: importlib-example.patch
keywords: patch
messages: 215220
nosy: docs at python, sahutd
priority: normal
severity: normal
status: open
title: Add doc examples for importlib
versions: Python 3.4
Added file: http://bugs.python.org/file34675/importlib-example.patch

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

From report at bugs.python.org  Mon Mar 31 10:14:19 2014
From: report at bugs.python.org (Daniel Garcia)
Date: Mon, 31 Mar 2014 08:14:19 +0000
Subject: [New-bugs-announce] [issue21109] tarfile: Traversal attack
	vulnerability
Message-ID: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>


New submission from Daniel Garcia:

The application does not validate the filenames inside the tar archive, allowing to extract files in arbitrary path. An attacker can craft a tar file to override files.

I've view this vulnerability in libtar:
http://lwn.net/Vulnerabilities/587141/
I've checked that python tarfile doesn't validate the filenames so python tarfile is vulnerable to this attack.

----------
components: Library (Lib)
files: prevent-tar-traversal-attack.diff
keywords: patch
messages: 215222
nosy: Daniel.Garcia
priority: normal
severity: normal
status: open
title: tarfile: Traversal attack vulnerability
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file34676/prevent-tar-traversal-attack.diff

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

From report at bugs.python.org  Mon Mar 31 12:35:23 2014
From: report at bugs.python.org (MrValdez)
Date: Mon, 31 Mar 2014 10:35:23 +0000
Subject: [New-bugs-announce] [issue21110] Slowdown and high memory usage
	when adding a new module	in embedded Python 3.4 on 64bit Windows
Message-ID: <1396262123.2.0.239412802273.issue21110@psf.upfronthosting.co.za>


New submission from MrValdez:

The example in the "Extending Embedded Python" (https://docs.python.org/3/extending/embedding.html#extending-embedded-python) takes up a lot of memory and slow downs the computer. I am using Windows 7 64bit, Python 3.4 64bit and gcc (rubenvb-4.8.0) 4.8.0.

Solution:

Apparently, you need to add this to your C program:

#define HAVE_SSIZE_T

I found the solution at (https://forums.embarcadero.com/message.jspa?messageID=581594). The page said that when adding the above, "this ensures that the type Py_ssize_t becomes __int64 instead of int."


Expected: 

The programmer should not see a simple program (that came from the main documentation, no less) causing slowdowns and high memory usage. The 64bit version of the Python installer was downloaded so the programmer should, at least, not need to know that they need this flag. 

Can the Python.h in the 64 bit builds automatically set the flag? Or, if this isn't feasible, add a note to the documentation that this flag exist.

----------
components: Windows
messages: 215227
nosy: MrValdez
priority: normal
severity: normal
status: open
title: Slowdown and high memory usage when adding a new module in embedded Python 3.4 on 64bit Windows
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 31 15:26:36 2014
From: report at bugs.python.org (Hristo Venev)
Date: Mon, 31 Mar 2014 13:26:36 +0000
Subject: [New-bugs-announce] [issue21111] PyLong_AsUnsignedLongAndOverflow
	does not exist
Message-ID: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za>


New submission from Hristo Venev:

It could set *overflow to -1 on negative value and to 1 on overflow.
And PyLong_AsUnsignedLongLongAndOverflow.

----------
components: Extension Modules
messages: 215236
nosy: h.venev
priority: normal
severity: normal
status: open
title: PyLong_AsUnsignedLongAndOverflow does not exist
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 31 16:20:26 2014
From: report at bugs.python.org (William Schwartz)
Date: Mon, 31 Mar 2014 14:20:26 +0000
Subject: [New-bugs-announce] [issue21112] 3.4 regression:
	unittest.expectedFailure no longer works	on TestCase subclasses
Message-ID: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>


New submission from William Schwartz:

In Python 2.7 and 3.3, decorating a unittest.TestCase subclass with unittest.expectedFailure caused test discover to skip the decorated test case. Python 3.4 apparently ignores the decorator when applied to classes.

The attached file when run with Python 2.7.6 on Mac OS X produces the following output

$ python -m unittest discover
F.
======================================================================
FAIL: test_fails (test.TestControl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/schwartz_w/Documents/testtest/test.py", line 9, in test_fails
    self.assertFalse(True)
AssertionError: True is not false

----------------------------------------------------------------------
Ran 2 tests in 0.000s

FAILED (failures=1)

When run with Python 3.4.0 produces the following output.

~/Documents/testtest $ python3 -m unittest discover
F.F.
======================================================================
FAIL: test_fails (test.TestControl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/schwartz_w/Documents/testtest/test.py", line 9, in test_fails
    self.assertFalse(True)
AssertionError: True is not false

======================================================================
FAIL: test_fails (test.TestTreatment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/schwartz_w/Documents/testtest/test.py", line 9, in test_fails
    self.assertFalse(True)
AssertionError: True is not false

----------------------------------------------------------------------
Ran 4 tests in 0.001s

FAILED (failures=2)


The expectedFailure decorator when applied to a class should either skip the class or run all of its tests and check that they failed for consistency with how expectedFailure applies to test methods.

----------
components: Library (Lib)
files: test_expectedFailure.py
messages: 215240
nosy: William.Schwartz
priority: normal
severity: normal
status: open
title: 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34680/test_expectedFailure.py

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

From report at bugs.python.org  Mon Mar 31 16:30:34 2014
From: report at bugs.python.org (Lotus Qin)
Date: Mon, 31 Mar 2014 14:30:34 +0000
Subject: [New-bugs-announce] [issue21113] Error usage of class.__bases__()
Message-ID: <1396276234.22.0.492654933854.issue21113@psf.upfronthosting.co.za>


New submission from Lotus Qin:

function in urllib.request.build_opener()

    def isclass(obj):
        return isinstance(obj, type) or hasattr(obj, "__bases__")

should it be `obj` or `obj.__class__`?

cause in the man of 3.4, there is only `class.__bases__`, but the code there may function like `instance.__bases__`.

=======

# my code behave like this: 

cookie = http.cookiejar.CookieJar()
cookie_handler = urllib.request.HTTPCookieProcessor(cookie)
opener = urllib.request.build_opener(cookie_handler)

# the variable `skip` in `build_opener` will be empty cause `isclass(obj)` always return false. 

cookie_handler.__bases__
AttributeError: 'HTTPCookieProcessor' object has no attribute '__bases__'

cookie_handler.__class__.__bases__
(<class 'urllib.request.BaseHandler'>,)

----------
components: Library (Lib)
messages: 215241
nosy: ZealotuS
priority: normal
severity: normal
status: open
title: Error usage of class.__bases__()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 31 19:02:31 2014
From: report at bugs.python.org (Alan Braithwaite)
Date: Mon, 31 Mar 2014 17:02:31 +0000
Subject: [New-bugs-announce] [issue21114] wsgiref.simple_server doesn't
	handle multi-line headers	correctly
Message-ID: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za>


New submission from Alan Braithwaite:

At wsgiref.simple_server:99, it uses the wrong field to get the headers from the request.  In rfc822.Message.readheaders it describes that the headers attribute is an uninterrupted list of the lines in the header.  The dict attribute of Message should contain the proper key/value map of the headers.

I've attached a patch of what I think the behavior should be.  This has incidentally been fixed in python 3+.

----------
components: Library (Lib)
files: simple_server.py.patch
keywords: patch
messages: 215251
nosy: Alan.Braithwaite
priority: normal
severity: normal
status: open
title: wsgiref.simple_server doesn't handle multi-line headers correctly
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34684/simple_server.py.patch

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

From report at bugs.python.org  Mon Mar 31 19:31:12 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Mar 2014 17:31:12 +0000
Subject: [New-bugs-announce] [issue21115] python.org server change causing
	failures in	test_urllib2net test_xxxwithfrag?
Message-ID: <1396287072.33.0.426039489195.issue21115@psf.upfronthosting.co.za>


New submission from R. David Murray:

It looks like something changed on the python.org server-side that is causing test_urllib2net tests test_urlwithfrag (and, on 3.4, test_redirect_url_withfrag) to fail because the fragment doesn't appear in the response url.  Which is very puzzling.  At least, I can't see any recent changes to urllib or the tests in the hg log.  The errors came to my attention as a result of a 3.4 buildbot run on a couple of completely unrelated patches, but I've confirmed that it also fails on 3.3 now.

----------
keywords: buildbot
messages: 215253
nosy: r.david.murray
priority: high
severity: normal
status: open
title: python.org server change causing failures in test_urllib2net test_xxxwithfrag?

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

From report at bugs.python.org  Mon Mar 31 21:37:47 2014
From: report at bugs.python.org (=?utf-8?b?TcOpZMOpcmljIEJvcXVpZW4=?=)
Date: Mon, 31 Mar 2014 19:37:47 +0000
Subject: [New-bugs-announce] [issue21116] Failure to create multiprocessing
	shared arrays larger	than 50% of memory size under linux
Message-ID: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za>


New submission from M?d?ric Boquien:

It is currently impossible to create multiprocessing shared arrays larger than 50% of memory size under linux (and I assume other unices). A simple test case would be the following:

from multiprocessing.sharedctypes import RawArray
import ctypes

foo = RawArray(ctypes.c_double, 10*1024**3//8)  # Allocate 10GB array

If the array is larger than 50% of the total memory size, the process get SIGKILL'ed by the OS. Deactivate the swap for better effects.

Naturally this requires that the tmpfs max size is large enough, which is the case here, 15GB max with 16GB of RAM.

I have tracked down the problem to multiprocessing/heap.py. The guilty line is: f.write(b'\0'*size). Indeed, for very large sizes it is going to create a large intermediate array (10 GB in my test case) and as much memory is going to be allocated to the new shared array, leading to a memory consumption over the limit.

To solve the problem, I have split the zeroing of the shared array into blocks of 1MB. I can now allocate arrays as large as the tmpfs maximum size. Also it runs a bit faster. On a test case of a 6GB RawArray, 3.4.0 takes a total time of 3.930s whereas it goes down to 3.061s with the attached patch.

----------
components: Library (Lib)
files: shared_array.diff
keywords: patch
messages: 215258
nosy: mboquien
priority: normal
severity: normal
status: open
title: Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
versions: Python 3.4
Added file: http://bugs.python.org/file34685/shared_array.diff

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

From report at bugs.python.org  Mon Mar 31 22:30:36 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 31 Mar 2014 20:30:36 +0000
Subject: [New-bugs-announce] [issue21117] inspect: PartialSignature and
	PartialParameter classes
Message-ID: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

There is a small detail in the current Signature class implementation, in regards to how partial signatures are treated. Consider the following example:

   def foo(a, b): pass
   foo_partial = functools.partial(foo, 'spam')

Now, the signature of 'foo_partial' is '(a="spam", b)', which (strictly speaking) is not a valid python function signature. For cases like that, we have a private "Parameter._partial_kwarg" attribute. When this attribute is set to True, it means, that this parameter's default came from partial (or alike) function. Parameter instances with '_partial_kwarg=True' are treated a bit differently during signature validation and binding.

A small and nasty detail: Parameter.__eq__ ignores value of '_partial_kwarg'. Because, for the following code:

   def bar(a, b=10): pass
   def baz(a, b): pass
   baz2 = functools.partial(baz, b=10)

signature of 'bar' is equal to 'baz2'.

In light of making signatures hashable, the obvious question was raised: should __hash__ account for '_partial_kwarg' value or not.  I think it should.  But in this case, it should be really obvious, if parameter was modified by partial or not.

Hence, I propose to add two more classes:

- PartialSignature(Signature)
- PartialParameter(Parameter)

Results of signature(functools.partial(..)) and Signature.bind_partial(..) will be instances of PartialSignature. It will be OK if some PartialSignature is equal to Signature, but they will have different __hash__es.

What do you think?

----------
assignee: yselivanov
components: Library (Lib)
messages: 215265
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect: PartialSignature and PartialParameter classes
type: enhancement
versions: Python 3.5

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