From report at bugs.python.org  Sat Feb  1 01:08:42 2014
From: report at bugs.python.org (A Hettinger)
Date: Sat, 01 Feb 2014 00:08:42 +0000
Subject: [New-bugs-announce] [issue20469] ssl.getpeercert() should include
	extensions
Message-ID: <1391213322.18.0.0407523257896.issue20469@psf.upfronthosting.co.za>


New submission from A Hettinger:

I have crafted an ssl cert which contains a custom extension, when I check the cert using OpenSSL on the commandline, I clearly see the extension, but when I have the server try to pprint.pprint(s.getpeercert()), I do not see these fields.

Overall, I think it would be helpful to include extensions in ssl.getpeercert()'s returned list, but if there is a workaround for this (probably rare) issue, I would appreciate it.

(I have only tested 3.4, not head)

----------
components: Extension Modules
messages: 209850
nosy: oninoshiko
priority: normal
severity: normal
status: open
title: ssl.getpeercert() should include extensions
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  1 03:30:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2014 02:30:10 +0000
Subject: [New-bugs-announce] [issue20470] "Fatal Python error: Bus error" on
	the SPARC Solaris 10	buildbot
Message-ID: <1391221810.73.0.133738651444.issue20470@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On the buildbot "SPARC Solaris 10 (cc, 64b) [SB] 3.x", Python crash randomly with bus error. It looks like a regression introduced since the build 1422.

Since it's a crash, it probably comes from a change in C module and so I expected this changeset:
http://hg.python.org/cpython/rev/2fbb3c77f1577acc60f57401e07d7feceea66841
"Issue #17919: Fixed integer overflow in the eventmask parameter."

=> see issue #17919

http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20%28cc%2C%2064b%29%20%5BSB%5D%203.x/builds/1422/

    Change #34778
    Category 	None
    Changed by 	R David Murray <rdmurray at bitdance.com>
    Changed at 	Sat 14 Dec 2013 16:26:20
    Branch 	default
    Revision 	561822250761b47d643656a0be9c71f9d770252b
    Comments

    #19970: fix additional typo in 3.4 asyncio docs.

    Changed files
        Doc/library/asyncio-protocol.rst
    Change #34781
    Category 	None
    Changed by 	Serhiy Storchaka <storchaka at gmail.com>
    Changed at 	Sat 14 Dec 2013 17:19:15
    Branch 	default
    Revision 	2fbb3c77f1577acc60f57401e07d7feceea66841
    Comments

    Issue #17919: Fixed integer overflow in the eventmask parameter.

    Changed files
        Lib/test/test_devpoll.py
        Lib/test/test_poll.py
        Misc/NEWS
        Modules/selectmodule.c
    Change #34784
    Category 	None
    Changed by 	Serhiy Storchaka <storchaka at gmail.com>
    Changed at 	Sat 14 Dec 2013 18:43:21
    Branch 	default
    Revision 	804406d79b45d02b1ea0ae2da45cfd5769141830
    Comments

    Issue #19623: Fixed writing to unseekable files in the aifc module.

    Changed files
        Lib/aifc.py
        Lib/test/audiotests.py
        Lib/test/test_aifc.py
        Lib/test/test_sunau.py
        Lib/test/test_wave.py
        Misc/NEWS
    Change #34786
    Category 	None
    Changed by 	Serhiy Storchaka <storchaka at gmail.com>
    Changed at 	Sat 14 Dec 2013 19:08:18
    Branch 	default
    Revision 	953d8ec1aeb3bff787204343a1c1837a17dbf68c
    Comments

    Null merge

    Changed files
        Lib/test/test_getargs2.py
        Lib/test/test_index.py
        Lib/test/test_int.py
        Misc/NEWS
        Objects/abstract.c
        Objects/longobject.c

----------
messages: 209861
nosy: haypo
priority: normal
severity: normal
status: open
title: "Fatal Python error: Bus error" on the SPARC Solaris 10 buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  1 04:14:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2014 03:14:10 +0000
Subject: [New-bugs-announce] [issue20471] test_signature_on_class() of
	test_inspect fails on	"AMD64 FreeBSD 9.0 3.x" buildbot
Message-ID: <1391224450.54.0.294439950021.issue20471@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6302/steps/test/logs/stdio

======================================================================
ERROR: test_signature_on_class (test.test_inspect.TestSignatureObject)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_inspect.py", line 2198, in test_signature_on_class
    self.assertEqual(str(inspect.signature(C)), '()')
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/inspect.py", line 1734, in signature
    return signature(object)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/inspect.py", line 1695, in signature
    return Signature.from_builtin(obj)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/inspect.py", line 2196, in from_builtin
    raise ValueError("no signature found for builtin {!r}".format(func))
ValueError: no signature found for builtin <class 'object'>

----------
messages: 209869
nosy: haypo, larry
priority: normal
severity: normal
status: open
title: test_signature_on_class() of test_inspect fails on "AMD64 FreeBSD 9.0 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  1 04:20:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2014 03:20:19 +0000
Subject: [New-bugs-announce] [issue20472] test_write_pty() of test_asyncio
	fails on "x86 Tiger	3.x" buildbot
Message-ID: <1391224819.03.0.550911452449.issue20472@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7801/steps/test/logs/stdio

======================================================================
FAIL: test_write_pty (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 1105, in test_write_pty
    self.assertEqual(b'1', data)
AssertionError: b'1' != b''

----------
messages: 209870
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: test_write_pty() of test_asyncio fails on "x86 Tiger 3.x" buildbot

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

From report at bugs.python.org  Sat Feb  1 04:42:17 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Feb 2014 03:42:17 +0000
Subject: [New-bugs-announce] [issue20473] inspect.Signature no longer
	handles builtin classes	correctly
Message-ID: <1391226137.37.0.568949403046.issue20473@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Yury: In revision 9433b380ad33 you changed inspect.Signature so that it cannot handle builtin classes.  Please fix it.

   >>> import _pickle
   >>> import inspect
   >>> str(inspect.signature(_pickle.Pickler))
   '()'
   >>> _pickle.Pickler.__text_signature__
   '(file, protocol=None, fix_imports=True)'

Those two strings should be the same.

I don't know any guaranteed way to tell a builtin class from a
user class.  So if you pass in a class, the best approach is to
do what it used to do: try from_builtin, and if it fails fail over
to the isinstance(obj, type) code.  You changed it to

    if _signature_is_builtin(obj):
        return Signature.from_builtin(obj)

This unambiguously returns the result from from_builtin.  Either
find a way that you can determine a class is a builtin 100%
reliably, or change this to *try* from_builtin but only return its
result if it's successful.

Your changes might have also caused #20471; that wasn't failing before.  I'm still investigating.

----------
assignee: yselivanov
messages: 209871
nosy: larry, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature no longer handles builtin classes correctly
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  1 11:11:49 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Feb 2014 10:11:49 +0000
Subject: [New-bugs-announce] [issue20474] test_socket failures on OS X due
	to fixed "expected	failures"
Message-ID: <1391249509.61.0.504777849278.issue20474@psf.upfronthosting.co.za>


New submission from Ned Deily:

Three "send timeout" test cases in test_socket were changed by a4e4facad164 for Issue12958 to be "expected failures" on OS X because of observed failures on the OS X buildbots running OS X 10.6 (Snow Leopard) and earlier.

testInterruptedSendTimeout (test.test_socket.InterruptedSendTimeoutTest) ... unexpected success
testInterruptedSendmsgTimeout (test.test_socket.InterruptedSendTimeoutTest) ... unexpected success
testInterruptedSendtoTimeout (test.test_socket.InterruptedSendTimeoutTest) ... unexpected success

It seems that the platform bugs causing the failures were fixed in OS X 10.7 so that the "expected failures" no longer fail.  However, the change in behavior had not been noticed because, until the recent change to unittest in Issue20165, unittest did not fail when there were unexpected successes.  Now it does fail, causing test_socket to fail on OS X 10.7+ for 3.4.  On 3.3 the "unexpected success" failures are silently skipped.  The attached patch changes the test cases to be skipped for OS X versions prior to 10.7 rather than to always expect failure on OS X.

----------
components: Tests
messages: 209882
nosy: larry, ncoghlan, ned.deily
priority: high
severity: normal
stage: patch review
status: open
title: test_socket failures on OS X due to fixed "expected failures"
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  1 22:10:18 2014
From: report at bugs.python.org (Paul Sokolovsky)
Date: Sat, 01 Feb 2014 21:10:18 +0000
Subject: [New-bugs-announce] [issue20475] pystone.py in 3.4 still uses
	time.clock(), even though it's marked as deprecated since 3.3
Message-ID: <1391289018.79.0.847652804265.issue20475@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

http://docs.python.org/3.3/library/time.html#time.clock says that it's deprecated, but pystone.py in Python-3.4.0b3 tarball still uses it. 

Please kindly consider switching it to plain time.time() and not to some other novelties.

My usecase is: I'm working on alternative Python implementation, I of course want to benchmark it, and of course want to claim that I ran unmodified pystone.py. Now to achieve that, I need to implement deprecated function.

----------
messages: 209916
nosy: pfalcon
priority: normal
severity: normal
status: open
title: pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3
type: enhancement

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

From report at bugs.python.org  Sat Feb  1 23:08:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Feb 2014 22:08:05 +0000
Subject: [New-bugs-announce] [issue20476] If new email policies are used,
	default message factory should be EmailMessage
Message-ID: <1391292485.67.0.381493162498.issue20476@psf.upfronthosting.co.za>


New submission from R. David Murray:

This was part of the design of the new stuff added in 3.4, so it is a bug that it doesn't work...somehow I missed implementing this detail.  The full implementation should make this a policy setting, so that a custom policy could specify its own factory.  However, since 3.4 is in beta it would be a bad time to add that to the policy.

The patch proposed here implements the required behavior by hardcoding any non-compat32 policy to use EmailMessage instead of Message in feedparser.

----------
components: email
files: use_emailmessage.patch
keywords: patch
messages: 209921
nosy: barry, r.david.murray
priority: high
severity: normal
stage: commit review
status: open
title: If new email policies are used, default message factory should be EmailMessage
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33848/use_emailmessage.patch

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

From report at bugs.python.org  Sat Feb  1 23:45:58 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Feb 2014 22:45:58 +0000
Subject: [New-bugs-announce] [issue20477] Add examples of using the new
	contentmanager api to the	email docs
Message-ID: <1391294758.28.0.146811184979.issue20477@psf.upfronthosting.co.za>


New submission from R. David Murray:

Here are the examples I promised to write in issue 18891.

----------
assignee: docs at python
components: Documentation, email
files: contentmanager-examples.patch
keywords: patch
messages: 209922
nosy: barry, docs at python, r.david.murray
priority: normal
severity: normal
stage: commit review
status: open
title: Add examples of using the new contentmanager api to the email docs
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33850/contentmanager-examples.patch

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

From report at bugs.python.org  Sun Feb  2 02:16:29 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Feb 2014 01:16:29 +0000
Subject: [New-bugs-announce] [issue20478] Avoid inadvertently special casing
	Counter in statistics	module
Message-ID: <1391303789.61.0.448801013488.issue20478@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As per the python-ideas thread at https://mail.python.org/pipermail/python-ideas/2014-February/025226.html the statistics.mode() function currently passes its argument directly to the collections.Counter() constructor. This results in Counter() objects being special-cased rather than treated as ordinary iterables.

For the main API, it seems more appropriate to force treatment as an iterable by calling iter() on the argument before passing it to the Counter() constructor.

I'll file a separate RFE about making it easier and more efficient to use the statistics module with weight/frequency mappings.

----------
components: Library (Lib)
messages: 209930
nosy: gregory.p.smith, larry, ncoghlan, oscarbenjamin, stevenjd, wolma
priority: release blocker
severity: normal
stage: test needed
status: open
title: Avoid inadvertently special casing Counter in statistics module
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  2 02:21:11 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Feb 2014 01:21:11 +0000
Subject: [New-bugs-announce] [issue20479] Efficiently support
	weight/frequency mappings in the	statistics module
Message-ID: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 20478 suggests ensuring that even weight/frequency mappings like collections.Counter are consistently handled as iterables in the current statistics module API.

However, it likely makes sense to provide public APIs that support efficiently working with such weight/frequency mappings directly, rather than requiring that they be expanded to a full iterable all the time.

One possibility would be to provide parallel APIs with the _map suffix, similar to the format() vs format_map() distinction in the string formatting APIs.

----------
components: Library (Lib)
messages: 209931
nosy: gregory.p.smith, ncoghlan, oscarbenjamin, stevenjd, wolma
priority: normal
severity: normal
stage: needs patch
status: open
title: Efficiently support weight/frequency mappings in the statistics module
type: enhancement

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

From report at bugs.python.org  Sun Feb  2 02:22:28 2014
From: report at bugs.python.org (Leon Weber)
Date: Sun, 02 Feb 2014 01:22:28 +0000
Subject: [New-bugs-announce] [issue20480] Add ipaddress property to get
	reverse DNS name
Message-ID: <1391304148.19.0.350065852039.issue20480@psf.upfronthosting.co.za>


New submission from Leon Weber:

I was missing a method to compute the reverse DNS name for an IP address, and I felt this is something that would belong in the ipaddress module; so here?s a patch for the ipaddress module adding a reverse_name property to IPv?Address.

This is an example:

>>> ipaddress.ip_address("127.0.0.1").reverse_name
'1.0.0.127.in-addr.arpa.'
>>> ipaddress.ip_address("2001:db8::1").reverse_name
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.'

Would this be an acceptable feature for inclusion in the ipaddress module?

----------
components: Library (Lib)
files: ipaddress_reverse_names.patch
keywords: patch
messages: 209933
nosy: leonn, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: Add ipaddress property to get reverse DNS name
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33851/ipaddress_reverse_names.patch

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

From report at bugs.python.org  Sun Feb  2 02:31:51 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Feb 2014 01:31:51 +0000
Subject: [New-bugs-announce] [issue20481] Clarify type coercion rules in
	statistics module
Message-ID: <1391304711.74.0.578704343666.issue20481@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I haven't completely following the type coercion discussion on python-ideas. but the statistics module at least needs a docs clarification (to explain that the current behaviour when mixing input types is not fully defined, especially when Decimal is involved), and potentially a behavioural change to disallow certain type combinations where the behaviour may change in the future (see
https://mail.python.org/pipermail/python-ideas/2014-February/025214.html for example)

Either option seems reasonable to me (with a slight preference for the latter), but it's at least clear that we need to avoid locking ourselves into the exact coercion behaviour of the current implementation indefinitely.

----------
components: Library (Lib)
messages: 209934
nosy: gregory.p.smith, larry, ncoghlan, oscarbenjamin, stevenjd, wolma
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Clarify type coercion rules in statistics module
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  2 03:41:28 2014
From: report at bugs.python.org (yegle)
Date: Sun, 02 Feb 2014 02:41:28 +0000
Subject: [New-bugs-announce] [issue20482] smtplib.SMTP.sendmail: improve
	exception message
Message-ID: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za>


New submission from yegle:

Currently the `msg` argument of `smtplib.SMTP.sendmail` accept a `str` in Py3k if every characters in this `str` is in ASCII range, or a `bytes`.

This is confusing for new comer because:

1. When you send your mail using only ASCII characters, everything is fine (no matter you use bytes or str).
2. When sometimes you included non-ASCII characters in your email, the traceback is hard to understand.

Here's an example of such traceback:

Traceback (most recent call last):
  File "./manage.py", line 113, in <module>
    manager.run()
  File "/data/web/cgi-bin/venv/lib/python3.3/site-packages/flask_script/__init__.py", line 405, in run
    result = self.handle(sys.argv[0], sys.argv[1:])
  File "/data/web/cgi-bin/venv/lib/python3.3/site-packages/flask_script/__init__.py", line 384, in handle
    return handle(app, *positional_args, **kwargs)
  File "/data/web/cgi-bin/venv/lib/python3.3/site-packages/flask_script/commands.py", line 145, in handle
    return self.run(*args, **kwargs)
  File "./manage.py", line 108, in run
    conn.send(msg)
  File "/data/web/cgi-bin/venv/lib/python3.3/site-packages/flask_mail.py", line 168, in send
    message.as_string())
  File "/data/web/cgi-bin/python-3.3.3/lib/python3.3/smtplib.py", line 747, in sendmail
    msg = _fix_eols(msg).encode('ascii')
UnicodeEncodeError: 'ascii' codec can't encode character '\u9f99' in position 646: ordinal not in range(128)

Here's my proposal:

--- smtplib.py.orig     2014-02-01 21:26:47.000000000 -0500
+++ smtplib.py  2014-02-01 21:37:51.000000000 -0500
@@ -744,7 +744,12 @@
         esmtp_opts = []
         print(msg)
         if isinstance(msg, str):
-            msg = _fix_eols(msg).encode('ascii')
+            try:
+                msg = _fix_eols(msg).encode('ascii')
+            except UnicodeEncodeError:
+                raise SMTPException(
+                    "msg may be a string containing characters in the "
+                    "ASCII range, or a byte string.")
         if self.does_esmtp:
             # Hmmm? what's this? -ddm
             # self.esmtp_features['7bit']=""

----------
components: email
messages: 209943
nosy: barry, r.david.murray, yegle
priority: normal
severity: normal
status: open
title: smtplib.SMTP.sendmail: improve exception message
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb  2 05:59:35 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Feb 2014 04:59:35 +0000
Subject: [New-bugs-announce] [issue20483] Missing network resource checks in
	test_urllib2 &	test_smtplib
Message-ID: <1391317175.95.0.400221944155.issue20483@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

These two tests appear to rely on DNS lookups or other network access that isn't guarded by the network resource (my internet dropped out and these two tests failed, but they work correctly now the internet connection is back up).

----------
components: Tests
messages: 209947
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Missing network resource checks in test_urllib2 & test_smtplib
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  2 06:57:56 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 Feb 2014 05:57:56 +0000
Subject: [New-bugs-announce] [issue20484] test_pydoc can alter execution
	environment causing	subsequent test failures
Message-ID: <1391320676.2.0.0607136124043.issue20484@psf.upfronthosting.co.za>


New submission from Ned Deily:

With the "pydoc.synopsis() for 'binary' modules" changes (d6c3fb8d5f84) to pydoc and test_pydoc for Issue20123, running test_pydoc can leave the regrtest environment altered and cause subsequent tests to fail in strange ways.  I ran into this issue running regression tests for 3.4.0 and was able to isolate the failure to this change set.

A somewhat simplified (if not necessarily minimal) set of steps to reproduce follow.  I've not had time to further investigate the cause.  I've also only seen the problem when running the tests with an installed Python or from a build directory when there is also a Python installed in the configured prefix but not from the build directory with no Python installed at the configured prefix.  I've reproduced the failure on both Debian Linux and on OS X.  The following output is from the former.

$ rm -rf /tmp/root/*
$ hg purge --all
$ hg update 6d72617cae64  # the parent change set of d6c3fb8d5f84
$ hg log -r .
changeset:   88306:6d72617cae64
user:        R David Murray <rdmurray at bitdance.com>
date:        Sat Jan 04 21:17:52 2014 -0500
summary:     whatsnew: removal of TYPE_INT64 from marshal.
$ ./configure --prefix=/tmp/root
$ make && make install
$ ( cd /tmp && /tmp/root/bin/python3.4 -m test -w test_pydoc test_distutils )
[1/2] test_pydoc
[2/2] test_distutils
All 2 tests OK.
$ hg update d6c3fb8d5f84
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg log -r .
changeset:   88307:d6c3fb8d5f84
user:        Eric Snow <ericsnowcurrently at gmail.com>
date:        Sat Jan 04 20:38:11 2014 -0700
summary:     Issue 20123: Fix pydoc.synopsis() for "binary" modules.
$ make && make install
$ ( cd /tmp && /tmp/root/bin/python3.4 -m test -w test_pydoc test_distutils )
[1/2] test_pydoc
Warning -- warnings.filters was modified by test_pydoc
Warning -- logging._handlerList was modified by test_pydoc
[2/2] test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_distutils
1 test altered the execution environment:
    test_pydoc
Re-running failed tests in verbose mode
Re-running test 'test_distutils' in verbose mode
test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase) ... FAIL
test_check_all (distutils.tests.test_check.CheckTestCase) ... ok
[...]

======================================================================
ERROR: test_metadata_check_option (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_sdist.py", line 247, in test_metadata_check_option
    cmd.run()
  File "/tmp/root/lib/python3.4/distutils/command/sdist.py", line 158, in run
    self.get_file_list()
  File "/tmp/root/lib/python3.4/distutils/command/sdist.py", line 204, in get_file_list
    self.add_defaults()
  File "/tmp/root/lib/python3.4/distutils/command/sdist.py", line 262, in add_defaults
    self.filelist.extend(build_py.get_source_files())
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 301, in get_source_files
    return [module[-1] for module in self.find_all_modules()]
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 295, in find_all_modules
    package_dir = self.get_package_dir(package)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/build_py.py", line 187, in get_package_dir
    return os.path.join(self.distribution.src_root, res)
  File "/tmp/root/lib/python3.4/posixpath.py", line 83, in join
    path += b
TypeError: unsupported operand type(s) for +=: 'dict' and 'str'

======================================================================
ERROR: test_debug_mode (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_install.py", line 236, in test_debug_mode
    self.test_record()
  File "/tmp/root/lib/python3.4/distutils/tests/test_install.py", line 186, in test_record
    cmd.run()
  File "/tmp/root/lib/python3.4/distutils/command/install.py", line 566, in run
    self.run_command(cmd_name)
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/install_scripts.py", line 18, in run
    self.run_command("egg_info")
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 163, in run
    self.find_sources()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 186, in find_sources
    mm.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 246, in run
    self.add_defaults()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 282, in add_defaults
    sdist.add_defaults(self)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/sdist.py", line 148, in add_defaults
    if os.path.exists(fn):
  File "/tmp/root/lib/python3.4/genericpath.py", line 19, in exists
    os.stat(path)
TypeError: stat: can't specify None for path argument

======================================================================
ERROR: test_record (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_install.py", line 186, in test_record
    cmd.run()
  File "/tmp/root/lib/python3.4/distutils/command/install.py", line 566, in run
    self.run_command(cmd_name)
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/install_scripts.py", line 18, in run
    self.run_command("egg_info")
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 163, in run
    self.find_sources()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 186, in find_sources
    mm.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 246, in run
    self.add_defaults()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 282, in add_defaults
    sdist.add_defaults(self)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/sdist.py", line 148, in add_defaults
    if os.path.exists(fn):
  File "/tmp/root/lib/python3.4/genericpath.py", line 19, in exists
    os.stat(path)
TypeError: stat: can't specify None for path argument

======================================================================
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_install.py", line 217, in test_record_extensions
    cmd.run()
  File "/tmp/root/lib/python3.4/distutils/command/install.py", line 566, in run
    self.run_command(cmd_name)
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/install_egg_info.py", line 29, in run
    self.run_command('egg_info')
  File "/tmp/root/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/tmp/root/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 163, in run
    self.find_sources()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 186, in find_sources
    mm.run()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 246, in run
    self.add_defaults()
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 282, in add_defaults
    sdist.add_defaults(self)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/sdist.py", line 148, in add_defaults
    if os.path.exists(fn):
  File "/tmp/root/lib/python3.4/genericpath.py", line 19, in exists
    os.stat(path)
TypeError: stat: can't specify None for path argument

======================================================================
ERROR: test_get_inputs (distutils.tests.test_install_lib.InstallLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_install_lib.py", line 91, in test_get_inputs
    inputs = cmd.get_inputs()
  File "/tmp/root/lib/python3.4/distutils/command/install_lib.py", line 211, in get_inputs
    inputs.extend(build_py.get_outputs())
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 308, in get_outputs
    modules = self.find_all_modules()
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 295, in find_all_modules
    package_dir = self.get_package_dir(package)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/build_py.py", line 187, in get_package_dir
    return os.path.join(self.distribution.src_root, res)
  File "/tmp/root/lib/python3.4/posixpath.py", line 83, in join
    path += b
TypeError: unsupported operand type(s) for +=: 'dict' and 'str'

======================================================================
ERROR: test_get_outputs (distutils.tests.test_install_lib.InstallLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_install_lib.py", line 71, in test_get_outputs
    outputs = cmd.get_outputs()
  File "/tmp/root/lib/python3.4/distutils/command/install_lib.py", line 188, in get_outputs
    self.install_dir)
  File "/tmp/root/lib/python3.4/distutils/command/install_lib.py", line 148, in _mutate_outputs
    build_files = build_cmd.get_outputs()
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 308, in get_outputs
    modules = self.find_all_modules()
  File "/tmp/root/lib/python3.4/distutils/command/build_py.py", line 295, in find_all_modules
    package_dir = self.get_package_dir(package)
  File "/tmp/root/lib/python3.4/site-packages/setuptools/command/build_py.py", line 187, in get_package_dir
    return os.path.join(self.distribution.src_root, res)
  File "/tmp/root/lib/python3.4/posixpath.py", line 83, in join
    path += b
TypeError: unsupported operand type(s) for +=: 'dict' and 'str'

======================================================================
FAIL: test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_bdist_dumb.py", line 91, in test_simple_built
    self.assertEqual(contents, sorted(wanted))
AssertionError: Lists differ: ['PKG-INFO', 'SOURCES.txt', 'dependency_lin[52 chars]txt'] != ['foo-0.1-py3.4.egg-info', 'foo.cpython-34.pyc', 'foo.py']

First differing element 0:
PKG-INFO
foo-0.1-py3.4.egg-info

First list contains 3 additional elements.
First extra element 3:
foo.cpython-34.pyc

+ ['foo-0.1-py3.4.egg-info', 'foo.cpython-34.pyc', 'foo.py']
- ['PKG-INFO',
-  'SOURCES.txt',
-  'dependency_links.txt',
-  'foo.cpython-34.pyc',
-  'foo.py',
-  'top_level.txt']

======================================================================
FAIL: test_formats (distutils.tests.test_bdist.BuildTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_bdist.py", line 26, in test_formats
    self.assertEqual(found, formats)
AssertionError: Lists differ: ['bztar', 'egg', 'gztar', 'msi', 'rpm', 'tar', 'wininst', 'zip', 'ztar'] != ['bztar', 'gztar', 'msi', 'rpm', 'tar', 'wininst', 'zip', 'ztar']

First differing element 1:
egg
gztar

First list contains 1 additional elements.
First extra element 8:
ztar

- ['bztar', 'egg', 'gztar', 'msi', 'rpm', 'tar', 'wininst', 'zip', 'ztar']
?           -------

+ ['bztar', 'gztar', 'msi', 'rpm', 'tar', 'wininst', 'zip', 'ztar']

======================================================================
FAIL: test_dir_in_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_build_py.py", line 153, in test_dir_in_package_data
    dist.run_commands()
distutils.errors.DistutilsFileError: can't copy 'pkg/doc/otherdir': doesn't exist or not a regular file

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_build_py.py", line 155, in test_dir_in_package_data
    self.fail("failed package_data when data dir includes a dir")
AssertionError: failed package_data when data dir includes a dir

======================================================================
FAIL: test_empty_package_dir (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_build_py.py", line 87, in test_empty_package_dir
    dist.run_commands()
distutils.errors.DistutilsFileError: can't copy 'oc/testfile': doesn't exist or not a regular file

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/root/lib/python3.4/distutils/tests/test_build_py.py", line 89, in test_empty_package_dir
    self.fail("failed package_data test when package_dir is ''")
AssertionError: failed package_data test when package_dir is ''

----------------------------------------------------------------------
Ran 201 tests in 0.915s

FAILED (failures=4, errors=6, skipped=19)
test test_distutils failed
$ rm -rf /tmp/root/*
$ hg purge --all
$ hg update default  # current tip
339 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ hg log -r .
changeset:   88889:d7ac90c0463a
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Sat Feb 01 22:49:59 2014 +0100
summary:     Issue #20400: Merge Tulip into Python: add the new asyncio.subprocess module
$ ./configure --prefix=/tmp/root
$ make && make install
$ ( cd /tmp && /tmp/root/bin/python3.4 -m test -w test_pydoc test_distutils )
[1/2] test_pydoc
Warning -- warnings.filters was modified by test_pydoc
Warning -- logging._handlerList was modified by test_pydoc
[2/2] test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_distutils
1 test altered the execution environment:
    test_pydoc
Re-running failed tests in verbose mode
Re-running test 'test_distutils' in verbose mode
test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase) ... FAIL
[...]
----------------------------------------------------------------------
Ran 201 tests in 0.959s

FAILED (failures=4, errors=6, skipped=19)
test test_distutils failed
$ # problem still exists

----------
assignee: eric.snow
components: Library (Lib), Tests
messages: 209950
nosy: eric.snow, ned.deily
priority: high
severity: normal
stage: needs patch
status: open
title: test_pydoc can alter execution environment causing subsequent test failures
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  2 15:20:28 2014
From: report at bugs.python.org (Suzumizaki)
Date: Sun, 02 Feb 2014 14:20:28 +0000
Subject: [New-bugs-announce] [issue20485] Enable 'import <Non-ASCII>.pyd'
Message-ID: <1391350828.19.0.622173065149.issue20485@psf.upfronthosting.co.za>


New submission from Suzumizaki:

Currently, the name of .pyd modules is limited within 7 bit US-ASCII.

I want to do "import X" to import X.pyd, where X contains Unicode characters.
I tried to make the patch and my work seems to be done successfully.
I will post the patch with this issue, and next what should I do?

About the solution:
To make the export entry 'PyInit_xxx' kept inside 7 bit, I use the simple encoding 'szm62' for unicode, called in the patch.

1) 'szm62' is used once per module(.pyd), only for 'PyInit_xxx'.
2) 'szm62' is used only when non-ASCII characters are in the name of the module.
3) 'szm62' generates short string as UTF-8, except 0-9A-Za-z are encoded to 2 bytes.
4) 'szm62' is very simple, much easier than UTF-8.
5) I tested it only with MS VC++, but I believe highly compatible with other environments.
6) 'szm62' also can decode 7 bits to unicode, but only the encoding is used for this issue.

Notes:
The simplicity is important for the project like Cython -- it generates .pyd files.
The codepoints over 16bits are also simply supported. They will be encoded to 4 alnum(0-9A-Za-z) characters.
0-9A-Za-z are (always) encoded to 2 alnums. They will be simply prefixed with '0'(U+000030).
When the generating 'Non-ASCII.pyd' with MSVC toolkit, the report 'LINK : warning LNK4232' will be raised on linking. But no problem. The warning says "When someone try to link with LoadLibraryEx'A' function, it may or may not fail, depends on the user locale." Our Python.exe uses always LoadLibraryEx'W', it never fail with locale issue.

Or if you have any question, please tell me that.

Regards,
Suzumizaki-Kimitaka

----------
components: Interpreter Core
files: 20140202_patch_for_python_default_branch_88885.patch
keywords: patch
messages: 209988
nosy: Suzumizaki
priority: normal
severity: normal
status: open
title: Enable 'import <Non-ASCII>.pyd'
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33866/20140202_patch_for_python_default_branch_88885.patch

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

From report at bugs.python.org  Sun Feb  2 16:37:29 2014
From: report at bugs.python.org (=?utf-8?b?0JjQs9C+0YDRjCDQqNCw0YPQu9Cw?=)
Date: Sun, 02 Feb 2014 15:37:29 +0000
Subject: [New-bugs-announce] [issue20486] msilib: can't close opened database
Message-ID: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>


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

In Python 2.7.6 can't find any way to close MSI database after finish working with it.
As a result database is locked and can't be opened by any other application until Python process is finished.

    import msilib
    db = msilib.OpenDatabase('test.msi', msilib.MSIDBOPEN_TRANSACT)
    view = db.OpenView("SELECT File, Component_, FileName FROM File")
    view.Execute(None)
    r1 = view.Fetch()
    r1.SetString(3,"test.txt")
    view.Modify(msilib.MSIMODIFY_UPDATE, r1)
    view.Close()
    db.Commit()
    del db
    db2 = msilib.OpenDatabase('test.msi', msilib.MSIDBOPEN_TRANSACT)

    MSIError: 1: 2203 2: test.msi 3: -2147287008

----------
components: Library (Lib), Windows
messages: 209992
nosy: gentoo90
priority: normal
severity: normal
status: open
title: msilib: can't close opened database
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  2 16:38:27 2014
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 02 Feb 2014 15:38:27 +0000
Subject: [New-bugs-announce] [issue20487] Odd words in unittest.mock
	document.
Message-ID: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/unittest.mock.html#magic-mock

> The two equality method, __eq__ and __ne__, are special. They do the default equality comparison on identity, using a side effect, unless you change their return value to return something else:

What "using a side effect" means?

----------
assignee: docs at python
components: Documentation
messages: 209993
nosy: docs at python, michael.foord, naoki
priority: normal
severity: normal
status: open
title: Odd words in unittest.mock document.
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Feb  2 16:41:58 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Feb 2014 15:41:58 +0000
Subject: [New-bugs-announce] [issue20488] importlib title and introduction
	are out of date
Message-ID: <1391355718.64.0.231740167188.issue20488@psf.upfronthosting.co.za>


New submission from R. David Murray:

Now that importlib *is* the import system in CPython, the title ("An Implementation of import") and the intro ("a reference implementation that is easier to comprehend than..." seem to me like they are out of date and should be reworded.

----------
assignee: docs at python
components: Documentation
messages: 209994
nosy: brett.cannon, docs at python, eric.snow, r.david.murray
priority: normal
severity: normal
status: open
title: importlib title and introduction are out of date
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  2 18:12:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Feb 2014 17:12:02 +0000
Subject: [New-bugs-announce] [issue20489] help() fails for zlib Compress and
	Decompress objects
Message-ID: <1391361122.5.0.357428984902.issue20489@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import zlib
>>> d = zlib.decompressobj()
>>> d
<zlib.Decompress object at 0xb70a9288>
>>> c = zlib.compressobj()
>>> c
<zlib.Compress object at 0xb6f85ac8>
>>> zlib.DEF_BUF_SIZE
16384
>>> zlib.Z_FINISH
4
>>> help(c)
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2243, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name 'Z_FINISH' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2246, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name 'Z_FINISH' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/_sitebuiltins.py", line 99, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1799, in __call__
    self.help(request)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1849, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1585, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 357, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1276, in docclass
    lambda t: t[1] == 'method')
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1225, in spill
    name, mod, object))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 358, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1328, in docroutine
    signature = inspect.signature(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1695, in signature
    return Signature.from_builtin(obj)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2298, in from_builtin
    p(name, default)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2284, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/home/serhiy/py/cpython/Lib/ast.py", line 245, in visit
    return visitor(node)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2276, in visit_Name
    return wrap_value(node.id)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2248, in wrap_value
    raise RuntimeError()
RuntimeError
>>> help(d)
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2243, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name 'DEF_BUF_SIZE' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2246, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name 'DEF_BUF_SIZE' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/_sitebuiltins.py", line 99, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1799, in __call__
    self.help(request)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1849, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1585, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 357, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1276, in docclass
    lambda t: t[1] == 'method')
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1225, in spill
    name, mod, object))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 358, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1328, in docroutine
    signature = inspect.signature(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1695, in signature
    return Signature.from_builtin(obj)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2298, in from_builtin
    p(name, default)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2284, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/home/serhiy/py/cpython/Lib/ast.py", line 245, in visit
    return visitor(node)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2276, in visit_Name
    return wrap_value(node.id)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2248, in wrap_value
    raise RuntimeError()
RuntimeError

----------
components: Library (Lib)
messages: 210001
nosy: larry, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: help() fails for zlib Compress and Decompress objects
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  2 20:04:48 2014
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 02 Feb 2014 19:04:48 +0000
Subject: [New-bugs-announce] [issue20490] Show clear error message on
	circular import
Message-ID: <1391367888.31.0.501253544651.issue20490@psf.upfronthosting.co.za>


New submission from Ram Rachum:

If there's a circular import in my program, I don't want to see an error message, "Cannot import name 'foo'" and then say in my mind, "ah, I'm an experienced Python developer, I know that when Python says that it often means that there's a circular import problem." I want the error message to **say there's a circular import problem**, so (a) I won't have to remember this piece of trivia and (b) less experienced developers won't have to bang their heads on their desks trying to figure out why the import isn't working. 

Bonus points if the error message actually shows which module is trying to import a module that imports itself, so we'll know where to fix.

----------
components: Interpreter Core
messages: 210006
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Show clear error message on circular import
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Feb  2 21:46:37 2014
From: report at bugs.python.org (Kaarle Ritvanen)
Date: Sun, 02 Feb 2014 20:46:37 +0000
Subject: [New-bugs-announce] [issue20491] textwrap: Non-breaking space not
	honored
Message-ID: <1391373997.78.0.616228125857.issue20491@psf.upfronthosting.co.za>


New submission from Kaarle Ritvanen:

The textwrap module does not distinguish non-breaking space (\xa0) from other whitespace when determining word boundaries.

In the beginning of the module, the _whitespace variable is defined to address this issue but is not used in the regular expressions determining the splitting rules.

----------
components: Library (Lib)
files: textwrap-honor-non-breaking-spaces.patch
keywords: patch
messages: 210013
nosy: kunkku
priority: normal
severity: normal
status: open
title: textwrap: Non-breaking space not honored
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33872/textwrap-honor-non-breaking-spaces.patch

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

From report at bugs.python.org  Sun Feb  2 21:47:19 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 02 Feb 2014 20:47:19 +0000
Subject: [New-bugs-announce] [issue20492] test_tcl is failing on windows 2.7
Message-ID: <1391374039.08.0.285544417854.issue20492@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%202.7/builds/833/steps/test/logs/stdio

----------
assignee: serhiy.storchaka
messages: 210014
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_tcl is failing on windows 2.7
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  3 01:37:51 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2014 00:37:51 +0000
Subject: [New-bugs-announce] [issue20493] asyncio: OverflowError('timeout is
	too large')
Message-ID: <1391387871.01.0.754074352669.issue20493@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In asyncio, if the next event is in 2^40 seconds, epoll.poll() raises an OverflowError because epoll_wait() maximum value for the timeout is INT_MAX seconds.

Test timeout_overflow.py to reproduce the issue.

----------
files: timeout_overflow.py
messages: 210061
nosy: haypo
priority: normal
severity: normal
status: open
title: asyncio: OverflowError('timeout is too large')
versions: Python 3.4
Added file: http://bugs.python.org/file33879/timeout_overflow.py

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

From report at bugs.python.org  Mon Feb  3 01:52:49 2014
From: report at bugs.python.org (Benjamin Yolken)
Date: Mon, 03 Feb 2014 00:52:49 +0000
Subject: [New-bugs-announce] [issue20494] Backport of
	http://bugs.python.org/issue11849 to Python	2.7 (Make it more
	likely for the system allocator to release	free()d memory
	arenas on glibc-based systems).
Message-ID: <1391388769.61.0.620925038774.issue20494@psf.upfronthosting.co.za>


New submission from Benjamin Yolken:

We have found that http://bugs.python.org/issue11849 affects a number of our Python 2.7 systems in production. I took the changes in http://hg.python.org/cpython/rev/f8a697bc3ca8 and backported them to the head of the python 2.7 cpython hg branch. I have verified that these changes fix the problem and that all tests pass.

Please see the attached patch.

----------
files: memory_fix.patch
keywords: patch
messages: 210063
nosy: bhyolken
priority: normal
severity: normal
status: open
title: Backport of http://bugs.python.org/issue11849 to Python 2.7 (Make it more likely for the system allocator to release free()d memory arenas on glibc-based systems).
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file33881/memory_fix.patch

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

From report at bugs.python.org  Mon Feb  3 02:29:28 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2014 01:29:28 +0000
Subject: [New-bugs-announce] [issue20495] test_read_pty_output() hangs on
	FreeBSD 7.2 buildbot
Message-ID: <1391390968.29.0.23257855186.issue20495@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/4969/steps/test/logs/stdio
---
[298/389/1] test_asyncio
Timeout (1:00:00)!
Current thread 0x28401040 (most recent call first):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/base_events.py", line 208 in time
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/base_events.py", line 641 in _run_once
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/base_events.py", line 154 in run_forever
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/base_events.py", line 173 in run_until_complete
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/test_utils.py", line 44 in run_briefly
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/asyncio/test_utils.py", line 59 in run_until
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_asyncio/test_events.py", line 979 in test_read_pty_output
...
---

FYI The test is now skipped on Mac OS X older than 10.6, the test on the kqueue selector is skipped on Mac OS X older than 10.9: issue #20472.

----------
messages: 210072
nosy: gvanrossum, haypo, skrah
priority: normal
severity: normal
status: open
title: test_read_pty_output() hangs on FreeBSD 7.2 buildbot
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb  3 06:09:47 2014
From: report at bugs.python.org (Alan Isaac)
Date: Mon, 03 Feb 2014 05:09:47 +0000
Subject: [New-bugs-announce] [issue20496] function definition tutorial
	encourages bad practice
Message-ID: <1391404187.28.0.545168168954.issue20496@psf.upfronthosting.co.za>


New submission from Alan Isaac:

Section 4.6 of the tutorial introduces function definition:
http://docs.python.org/3/tutorial/controlflow.html#defining-functions

The first example defines a function that *prints* a Fibonacci series.

A basic mistake made by students new to programming is to use a function to print values rather than to return them.  In this sense, the example encourages bad practice and misses an opportunity to instruct.  Since they have already met lists in Section 3, I suggest that returning a list of the values and then printing the list would enhance the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 210077
nosy: aisaac, docs at python
priority: normal
severity: normal
status: open
title: function definition tutorial encourages bad practice
type: enhancement

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

From report at bugs.python.org  Mon Feb  3 07:19:42 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 03 Feb 2014 06:19:42 +0000
Subject: [New-bugs-announce] [issue20497] Unclear word in socket document.
Message-ID: <1391408382.37.0.746852071929.issue20497@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/socket.html#socket.getaddrinfo

> Changed in version 3.2: parameters can now be passed as single keyword arguments.

What *single* means?
I can use multiple keyword arguments:

In [3]: socket.getaddrinfo('www.python.org', 80, proto=socket.SOL_TCP, family=socket.AF_INET)
Out[3]:
[(<AddressFamily.AF_INET: 2>,
  <SocketType.SOCK_STREAM: 1>,
  6,
  '',
  ('82.94.164.162', 80))]

----------
assignee: docs at python
components: Documentation
messages: 210078
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Unclear word in socket document.
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  3 07:57:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2014 06:57:35 +0000
Subject: [New-bugs-announce] [issue20498] Update StringIO newline tests
Message-ID: <1391410655.69.0.384794659533.issue20498@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patches adds several new checks and test cases to StringIO newline tests. It also fixes test_newline_lf which didn't use the newline argument.

----------
components: IO, Tests
messages: 210080
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Update StringIO newline tests
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  3 13:46:19 2014
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 03 Feb 2014 12:46:19 +0000
Subject: [New-bugs-announce] [issue20499] Rounding errors with
	statistics.variance
Message-ID: <1391431579.33.0.244887922603.issue20499@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

The mean/variance functions in the statistics module don't quite round correctly.

The reasons for this are that although exact rational arithmetic is used internally in the _sum function it is not used throughout the module. In particular the _sum function should be changed to return an exact result and exact arithmetic should be used right up to the point before returning to the user at which point a rounding/coercion should be used to give the user their answer in the appropriate type correctly rounded once.

Using exact arithmetic everywhere makes it possible to replace all of the variance* functions with single-pass algorithms based on the computational formula for variance which should be more efficient as well.

For example the following implements pvariance so that it returns a perfectly rounded result for float input and output in a single pass:

def pvariance(data):
    sx = 0
    sx2 = 0
    for n, x in enumerate(map(Fraction, data), 1):
        sx += x
        sx2 += x ** 2
    Ex = sx / n
    Ex2 = sx2 / n
    var = Ex2 - Ex ** 2
    return float(var)

Comparing the above with the statistics module:

>>> pvariance([0, 0, 1])
0.2222222222222222
>>> statistics.pvariance([0, 0, 1])
0.22222222222222224

The true answer is:

>>> from fractions import Fraction as F
>>> float(statistics.pvariance([F(0), F(0), F(1)]))
0.2222222222222222

The logic in the _sum function for computing exact integer ratios and coercing back to the output type could be moved into utility functions so that it does not need to be duplicated.

Some examples of rounding issues:

>>> from statistics import variance, mean
>>> from decimal import Decimal as D, getcontext
>>> from fractions import Fraction as F

Variance with ints or floats returns a float but the float is not quite the nearest possible float:

>>> variance([0, 0, 2])
1.3333333333333335
>>> float(variance([F(0), F(0), F(2)]))  # true result rounded once
1.3333333333333333

Another example with Decimal:

>>> getcontext().prec = 5
>>> getcontext()
Context(prec=5, rounding=ROUND_HALF_EVEN, Emin=-999999999, Emax=999999999, capitals=1, clamp=0, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation])

>>> variance([D(0), D(0), D(2)] * 2)  # Rounded down instead of up
Decimal('1.0666')
>>> r = (variance([F(0), F(0), F(2)] * 2))
>>> D(r.numerator) / r.denominator  # Correctly rounded
Decimal('1.0667')

The mean function may also not be correctly rounded:

>>> getcontext().prec = 2
>>> r = mean((F('1.2'), F('1.3'), F('1.55')))
>>> r
Fraction(27, 20)
>>> D(r.numerator) / r.denominator # Correctly rounded
Decimal('1.4')
>>> mean([D('1.2'), D('1.3'), D('1.55')])
Decimal('1.3')

----------
components: Library (Lib)
messages: 210121
nosy: oscarbenjamin, stevenjd
priority: normal
severity: normal
status: open
title: Rounding errors with statistics.variance
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb  3 14:07:09 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 03 Feb 2014 13:07:09 +0000
Subject: [New-bugs-announce] [issue20500] assertion failed when passing an
	exception object to	sys.exit
Message-ID: <1391432829.26.0.791023513998.issue20500@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following code crashes python with:

python: Objects/object.c:512: PyObject_Str: Assertion `!PyErr_Occurred()' failed.

on the tip of the default branch, but not on python 3.3.3.


import sys

error = None
try:
    raise ValueError('some text')
except ValueError as err:
    error = err

if error:
    sys.exit(error)

----------
components: Interpreter Core
messages: 210123
nosy: xdegaye
priority: normal
severity: normal
status: open
title: assertion failed when passing an exception object to sys.exit
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb  3 15:27:33 2014
From: report at bugs.python.org (Gunnar Aastrand Grimnes)
Date: Mon, 03 Feb 2014 14:27:33 +0000
Subject: [New-bugs-announce] [issue20501] fileinput module will read whole
	file into memory when	using fileinput.hook_encoded
Message-ID: <1391437653.41.0.935040025319.issue20501@psf.upfronthosting.co.za>


New submission from Gunnar Aastrand Grimnes:

When reading large files with fileinput, it will work as expected and only process a line at a time when used normally, but if you add an hook_encoded openhook it will read the whole file into memory before returning the first line. 

Verify by running this program on a large text file: 

import fileinput

for l in fileinput.input(openhook=fileinput.hook_encoded('iso-8859-1')):
    raw_input()

and check how much memory it uses. Remove the openhook and memory usage goes down to nothing.

----------
components: IO
messages: 210130
nosy: gromgull
priority: normal
severity: normal
status: open
title: fileinput module will read whole file into memory when using fileinput.hook_encoded
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  3 15:28:52 2014
From: report at bugs.python.org (Mauricio de Alencar)
Date: Mon, 03 Feb 2014 14:28:52 +0000
Subject: [New-bugs-announce] [issue20502]
	Context.create_decimal_from_float() inconsistent	precision
	for zeros after decimal mark
Message-ID: <1391437732.8.0.604418392969.issue20502@psf.upfronthosting.co.za>


New submission from Mauricio de Alencar:

The following code demonstrates an inconsistency of this method in dealing with zeros after the decimal mark.


from decimal import Context

context = Context(prec=2)

for x in [100., 10., 1., 0.1]:
    print(context.create_decimal_from_float(x), context.create_decimal_from_float(4.56*x))


Produces the output:
1.0E+2 4.6E+2
10 46
1 4.6
0.10 0.46

Line 3 is inconsistent. It should be "1.0 4.6".

----------
messages: 210131
nosy: mdealencar
priority: normal
severity: normal
status: open
title: Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  3 16:36:42 2014
From: report at bugs.python.org (Gerrit Holl)
Date: Mon, 03 Feb 2014 15:36:42 +0000
Subject: [New-bugs-announce] [issue20503] super behavioru and abstract base
	classes (either	implementation or documentation/error message
	is wrong)
Message-ID: <1391441802.61.0.557224247712.issue20503@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

When using an abstract base class, super(type, obj) throws a TypeError stating "obj must be an instance (...) of type", even though isinstance(obj, type) returns True.  I'm not sure what is supposed to happen here, but either the error message and the documentation for super would need to be reformulated, or there is an issue with the implementation, or I am misunderstanding something.

Python 3.3.3 (default, Dec 12 2013, 11:13:02) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numbers
>>> super(numbers.Number, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: super(type, obj): obj must be an instance or subtype of type
>>> isinstance(0, numbers.Number)
True

----------
components: Interpreter Core
messages: 210141
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: super behavioru and abstract base classes (either implementation or documentation/error message is wrong)
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  3 22:33:19 2014
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 03 Feb 2014 21:33:19 +0000
Subject: [New-bugs-announce] [issue20504] cgi.FieldStorage, multipart,
	missing Content-Length
Message-ID: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>


New submission from Sebastian Rittau:

Consider the attached test case. This test will run fine with Python 2.7, but will fail with Python 3.3. If cgi.FieldStorage() tries to parse a multipart request without a Content-Length header in the main section, segments will have a length of 0.

During the parse process, two instances of FieldStorage are involved. The outer one reads the whole request and creates and delegates reading of the fragment to inner instances.

The main problem is that FieldStorage.read_lines_to_outerboundary() of the inner FieldStorage will read nothing, since self.limit is lower than zero.

    def read_lines_to_outerboundary(self):
        ...
        while 1:
            if _read >= self.limit:
                break
        ...

This happens, since limit is passed when creating the inner instance in FieldStorage.read_multi():

    def read_multi(self, environ, keep_blank_values, strict_parsing):
        ...
            part = klass(self.fp, headers, ib, environ, keep_blank_values,
                         strict_parsing,self.limit-self.bytes_read,
                         self.encoding, self.errors)
        ...

Now, if the total request did not have a Content-Length header, self.limit will be -1.

The naive fix works for the test case, at least, but I don't know if there are other repercussions:

--- /usr/lib/python3.3/cgi.py	2014-02-03 22:31:16.649431125 +0100
+++ cgi.py	2014-02-03 22:32:14.849704379 +0100
@@ -788,7 +788,7 @@
         last_line_lfend = True
         _read = 0
         while 1:
-            if _read >= self.limit:
+            if self.limit >= 0 and _read >= self.limit:
                 break
             line = self.fp.readline(1<<16) # bytes
             self.bytes_read += len(line)

----------
components: Library (Lib)
files: cgi-bug.py
messages: 210166
nosy: srittau
priority: normal
severity: normal
status: open
title: cgi.FieldStorage, multipart, missing Content-Length
versions: Python 3.3
Added file: http://bugs.python.org/file33891/cgi-bug.py

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

From report at bugs.python.org  Tue Feb  4 00:34:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2014 23:34:16 +0000
Subject: [New-bugs-announce] [issue20505] Remove resolution from selectors
	and granularity from	asyncio
Message-ID: <1391470456.74.0.460953910028.issue20505@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To solve a performance issue in asyncio, I added a new resolution attribute to selectors.BaseSelector and a new _granularity attribute to asyncio.BaseEventLoop. If I understood correctly, Charles-Fran?ois (author and so maintainer of the new selectors module) doesn't like the new resolution attribute because it is a lie (if I understood correctly Charles-Fran?ois complain).

He's right: the kernel can use a clock with a worse resolution. For example, on Linux kernel older than 2.6.28, all selectors (select, poll, epoll) had a resolution of 1/HZ where HZ is usually 100, 250 or 1000. So the best resolution was 1 ms (10^-3), whereas the timeval structure used in select() has a resolution of 1 us (10^-6).

On Windows, there is a different issue: the clock used by time.monotonic() has a resolution of 15.6 ms, whereas the type to describe the timeouf of the proactor selector (GetQueuedCompletionStatus function) has a resolution of 1 ms. So the resolution of the clock, time.get_clock_info('monotonic').resolution, should also be used.

Attached patch removes the two new attributes to make the code simpler.

I created this issue to reopen the discussion, but I would prefer to keep the attributes. I wrote the patch to be able to compare the different options. It's just to ensure that everyone agree on the solution.

The patch is a comprise, it solves partially the asyncio performance issue. With the patch, BaseEventLoop._run_once() may not executed a task even if there was a scheduled task, just because of timing rounding issues. So I modified the existing patch to tolerate "useless calls" to _run_once().

It was hard for me to analyze and choose the best solution for these issues because on my Fedora 20 (Linux kernel 3.12), the timings look "perfect". I'm unable to reproduce the sporadic timing issues (selector sleeping 8 ms or 9 ms whereas we asked to sleep 10 ms), whereas the test failed on many different buildbots. I suppose that depending on the hardware and the Linux kernel version, the exact resolution selectors is very different.

I didn't test the patch on Windows yet.

See issues #20311 and #20452 for the background and raw numbers.

Note: the test_timeout_rounding() test of test_asyncio now pass on all buildbots: various platforms, selectors and hardwares.

Note 2: If we decide to keep the BaseSelector.resolution attribute, I hesitate to replace it with a method because we might improve the read resolution later, which may require to execute code. For example, on Linux older than 2.6.28, the resolution can be computed by retrieving the HZ constant. It requires to check the OS and kernel version.

----------
files: remove_granularity.patch
keywords: patch
messages: 210170
nosy: gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: Remove resolution from selectors and granularity from asyncio
versions: Python 3.4
Added file: http://bugs.python.org/file33892/remove_granularity.patch

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

From report at bugs.python.org  Tue Feb  4 02:23:14 2014
From: report at bugs.python.org (Arup Chakravarty)
Date: Tue, 04 Feb 2014 01:23:14 +0000
Subject: [New-bugs-announce] [issue20506] Command to display all available
	Import Library
Message-ID: <1391476994.58.0.915135187283.issue20506@psf.upfronthosting.co.za>


New submission from Arup Chakravarty:

Have a built-in mechanism to display all available import libraries within the interpreter. Like what is available through the built-in dir function.

----------
components: Library (Lib)
messages: 210171
nosy: arupchakrav
priority: normal
severity: normal
status: open
title: Command to display all available Import Library
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  4 12:09:02 2014
From: report at bugs.python.org (Gareth Rees)
Date: Tue, 04 Feb 2014 11:09:02 +0000
Subject: [New-bugs-announce] [issue20507] TypeError from str.join has no
	message
Message-ID: <1391512142.14.0.683696819623.issue20507@psf.upfronthosting.co.za>


New submission from Gareth Rees:

If you pass an object of the wrong type to str.join, Python raises a
TypeError with no error message:

    Python 3.4.0b3 (default, Jan 27 2014, 02:26:41) 
    [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> ''.join(1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError

It is unnecessarily hard to understand from this error what the
problem actually was. Which object had the wrong type? What type
should it have been? Normally a TypeError is associated with a message
explaining which type was wrong, and what it should have been. For
example:

    >>> b''.join(1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: can only join an iterable

It would be nice if the TypeError from ''.join(1) included a message
like this.

The reason for the lack of message is that PyUnicode_Join starts out
by calling PySequence_Fast(seq, "") which suppresses the error message
from PyObject_GetIter. This commit by Tim Peters is responsible:
<http://hg.python.org/cpython/rev/8579859f198c>. The commit message
doesn't mention the suppression of the message so I can assume that it
was an oversight.

I suggest replacing the line:

    fseq = PySequence_Fast(seq, "");

in PyUnicode_Join in unicodeobject.c with:

    fseq = PySequence_Fast(seq, "can only join an iterable");

for consistency with bytes_join in stringlib/join.h. Patch attached.

----------
components: Interpreter Core
files: join.patch
keywords: patch
messages: 210200
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: TypeError from str.join has no message
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33900/join.patch

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

From report at bugs.python.org  Tue Feb  4 14:09:31 2014
From: report at bugs.python.org (Gareth Rees)
Date: Tue, 04 Feb 2014 13:09:31 +0000
Subject: [New-bugs-announce] [issue20508] IndexError from
	ipaddress._BaseNetwork.__getitem__ has	no message
Message-ID: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za>


New submission from Gareth Rees:

If you try to look up an out-of-range address from an object returned
by ipaddress.ip_network, then ipaddress._BaseNetwork.__getitem__
raises an IndexError with no message:

    Python 3.4.0b3 (default, Jan 27 2014, 02:26:41) 
    [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ipaddress
    >>> ipaddress.ip_network('2001:db8::8/125')[100]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/ipaddress.py", line 601, in __getitem__
        raise IndexError
    IndexError

Normally an IndexError is associated with a message explaining the
cause of the error. For example:

    >>> [].pop()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    IndexError: pop from empty list

It would be nice if the IndexError from
ipaddress._BaseNetwork.__getitem__ included a message like this.

With the attached patch, the error message looks like this in the
positive case:

    >>> ipaddress.ip_network('2001:db8::8/125')[100]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/gdr/hg.python.org/cpython/Lib/ipaddress.py", line 602, in __getitem__
        % (self, self.num_addresses))
    IndexError: 100 out of range 0..7 for 2001:db8::8/125

and like this in the negative case:

    >>> ipaddress.ip_network('2001:db8::8/125')[-100]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/gdr/hg.python.org/cpython/Lib/ipaddress.py", line 608, in __getitem__
        % (n - 1, self.num_addresses, self))
    IndexError: -100 out of range -8..-1 for 2001:db8::8/125

(If you have a better suggestion for how the error message should
read, I could submit a revised patch. I suppose it could just say
"address index out of range" for consistency with list.__getitem__ and
str.__getitem__. But I think the extra information is likely to be
helpful for the programmer who is trying to track down the cause of an
error.)

----------
components: Library (Lib)
files: ipaddress.patch
keywords: patch
messages: 210224
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: IndexError from ipaddress._BaseNetwork.__getitem__ has no message
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33903/ipaddress.patch

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

From report at bugs.python.org  Tue Feb  4 16:53:33 2014
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 04 Feb 2014 15:53:33 +0000
Subject: [New-bugs-announce] [issue20509] logging.config.fileConfig() docs
	could link to the	config file format
Message-ID: <1391529213.62.0.538303765352.issue20509@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

When one is reading the description of logging.config.fileConfig()
at http://docs.python.org/3.3/library/logging.config.html#logging.config.fileConfig not immediately apparent what the "configparser-format file" should contain (i.e. the naming convention for sections, and what keys mean what.)

This is all nicely described at http://docs.python.org/3.3/library/logging.config.html#configuration-file-format but personal experience shows that users like me hit Page Down a few times and give up before they reach that part (and also they do not think to read the outline in the sidebar).

It would be nice if there was a direct link, like in the attached patch.

----------
assignee: docs at python
components: Documentation
files: improve-fileconfig-docs.patch
keywords: patch
messages: 210245
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: logging.config.fileConfig() docs could link to the config file format
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33907/improve-fileconfig-docs.patch

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

From report at bugs.python.org  Tue Feb  4 17:09:06 2014
From: report at bugs.python.org (Gareth Rees)
Date: Tue, 04 Feb 2014 16:09:06 +0000
Subject: [New-bugs-announce] [issue20510] Test cases in test_sys don't match
	the comments
Message-ID: <1391530146.21.0.549410928914.issue20510@psf.upfronthosting.co.za>


New submission from Gareth Rees:

Lib/test/test_sys.py contains test cases with incorrect comments -- or
comments with incorrect test cases, if you prefer:

    # call without argument
    try:
        sys.exit(0)
    except SystemExit as exc:
        self.assertEqual(exc.code, 0)
    ...

    # call with tuple argument with one entry
    # entry will be unpacked
    try:
        sys.exit(42)
    except SystemExit as exc:
        self.assertEqual(exc.code, 42)
    ...

    # call with integer argument
    try:
        sys.exit((42,))
    except SystemExit as exc:
        self.assertEqual(exc.code, 42)
    ...

(In the quote above I've edited out some inessential detail; see the
file if you really want to know.)

You can see that in the first test case sys.exit is called with an
argument (although the comment claims otherwise); in the second it is
called with an integer (not a tuple), and in the third it is called
with a tuple (not an integer).

These comments have been unchanged since the original commit by Walter
D?rwald <http://hg.python.org/cpython/rev/6a1394660270>. I've attached
a patch that corrects the first test case and swaps the comments for
the second and third test cases:

    # call without argument
    rc = subprocess.call([sys.executable, "-c",
                          "import sys; sys.exit()"])
    self.assertEqual(rc, 0)

    # call with integer argument
    try:
        sys.exit(42)
    except SystemExit as exc:
        self.assertEqual(exc.code, 42)
    ...

    # call with tuple argument with one entry
    # entry will be unpacked
    try:
        sys.exit((42,))
    except SystemExit as exc:
        self.assertEqual(exc.code, 42)
    ...

Note that in the first test case (without an argument) sys.exit() with
no argument actually raises SystemExit(None), so it's not sufficient
to catch the SystemExit and check exc.code; I need to check that it
actually gets translated to 0 on exit.

----------
components: Tests
files: exittest.patch
keywords: patch
messages: 210246
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: Test cases in test_sys don't match the comments
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33908/exittest.patch

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

From report at bugs.python.org  Tue Feb  4 18:40:31 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 04 Feb 2014 17:40:31 +0000
Subject: [New-bugs-announce] [issue20511] asyncio: StreamReader should use
	bytearray for its	internal buffer
Message-ID: <1391535631.01.0.473053250343.issue20511@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This issue on google code: https://code.google.com/p/tulip/issues/detail?id=124

----------
files: sr_ba_01.patch
keywords: needs review, patch
messages: 210253
nosy: gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: StreamReader should use bytearray for its internal buffer
Added file: http://bugs.python.org/file33912/sr_ba_01.patch

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

From report at bugs.python.org  Tue Feb  4 19:48:23 2014
From: report at bugs.python.org (Alexis Daboville)
Date: Tue, 04 Feb 2014 18:48:23 +0000
Subject: [New-bugs-announce] [issue20512] Python3.3 segfaults when using
	big5hkscs encoding
Message-ID: <1391539703.53.0.816371062299.issue20512@psf.upfronthosting.co.za>


New submission from Alexis Daboville:

When using the 'big5hkscs' encoding it's possible to make Python3.3 segfault, here is how to repro:

 ? 13:41 adaboville @ adoboville-mbp in ~ $ py3
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.
>>> 'nb'.encode('big5hkscs')
b'nb'
>>> 'nb'.encode('big5hkscs')
Segmentation fault: 11

Note that it doesn't crash on the first first line, but on the second (even though both lines are the same). FWIW pypy3.3 doesn't crash:

 ? 13:43 adaboville @ adoboville-mbp in .../pypy3-2.1-beta1-osx64 $ bin/pypy
Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
[PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``why did you guys have to make the
builtin fortune more interesting than actual work? i just catched myself
restarting pypy 20 times''
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>>

----------
messages: 210258
nosy: alexis.d
priority: normal
severity: normal
status: open
title: Python3.3 segfaults when using big5hkscs encoding
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  4 20:03:28 2014
From: report at bugs.python.org (Victor Scherba)
Date: Tue, 04 Feb 2014 19:03:28 +0000
Subject: [New-bugs-announce] [issue20513] Script interruption on logoff from
	0 session under	Win2003 and earlier
Message-ID: <1391540608.89.0.389395011233.issue20513@psf.upfronthosting.co.za>


New submission from Victor Scherba:

To get the bug:
1. Windows Server 2003 (same bug should be under earlier versions: XP, 2000, ...).
2. Any Windows service should spawn process with Python script.
3. Py script should stay into time.sleep.
4. Any Windows user should login in console session 0.
5. Bug: when this user logoff, script interrupts.

To repeat the bug simply you could use srvany which spawn: python.exe -c "import time; time.sleep(10000)".

There is problem in cpython/Modules/timemodule.c in PyCtrlHandler.
Before logoff Windows broadcasts to all services and its children CTRL_LOGOFF_EVENT signal. But PyCtrlHandler doesn't filter it out by dwCtrlType and always sets hInterruptEvent. This forces script interruption.

CTRL_SHUTDOWN_EVENT also should be filtered out. CTRL_SHUTDOWN_EVENT broacasted to all services before Windows shutdown. But after it has been handled, other process can block or pause shutdowning.

Default Windows console control handler does not call ExitProcess when processing the CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT signals. See more at http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx

On Win Vista and higher bug not presents. Impossible to login to session 0 because of session 0 isolation.

Patch attached. There is same fix in cpython/Modules/_multiprocessing/multiprocessing.c

----------
components: Extension Modules, Windows
messages: 210259
nosy: vScherba
priority: normal
severity: normal
status: open
title: Script interruption on logoff from 0 session under Win2003 and earlier
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  4 23:27:12 2014
From: report at bugs.python.org (Robert Copperwhite)
Date: Tue, 04 Feb 2014 22:27:12 +0000
Subject: [New-bugs-announce] [issue20514] Errno 10013 - ipython notebook
Message-ID: <1391552832.57.0.277394042566.issue20514@psf.upfronthosting.co.za>


New submission from Robert Copperwhite:

Hello,

I've recently installed ipython (Anaconda) and haven't managed to get up and running.  When I execute "ipython notebook" from the command prompt I get the attached error message, basically: "Errno 10013: An attempt was made to access a socket in a way forbidden by its access permissions".

I have disabled all firewalls, and even uninstalled McAfee but no resolution.  Would be grateful for some recommendations on what to try next.

Thanks

----------
components: Installation
messages: 210272
nosy: robertc
priority: normal
severity: normal
status: open
title: Errno 10013 - ipython notebook
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  5 00:09:12 2014
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Feb 2014 23:09:12 +0000
Subject: [New-bugs-announce] [issue20515] Null pointer dereference in
	tkinter module
Message-ID: <1391555352.52.0.553421944384.issue20515@psf.upfronthosting.co.za>


New submission from Christian Heimes:

varname_converter() doesn't check the return value of PyUnicode_AsUTF8AndSize() for NULL. The bug was introduced by http://hg.python.org/cpython/rev/321b714653e3 / issue #20368

3. returned_null: Function "PyUnicode_AsUTF8AndSize(PyObject *, Py_ssize_t *)" returns null (checked 28 out of 30 times).[show details]
4. var_assigned: Assigning: "s" = null return value from "PyUnicode_AsUTF8AndSize(PyObject *, Py_ssize_t *)".
1399        s = PyUnicode_AsUTF8AndSize(in, &size);
5. Condition "size > 2147483647", taking false branch
1400        if (size > INT_MAX) {
1401            PyErr_SetString(PyExc_OverflowError, "string is too long");
1402            return 0;
1403        }
CID 1167595 (#1 of 1): Dereference null return value (NULL_RETURNS)6. dereference: Dereferencing a pointer that might be null "s" when calling "strlen(char const *)"
1404        if (strlen(s) != size) {

----------
components: Tkinter
files: cid1167595.patch
keywords: patch
messages: 210276
nosy: christian.heimes, larry, serhiy.storchaka
priority: release blocker
severity: normal
stage: patch review
status: open
title: Null pointer dereference in tkinter module
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file33918/cid1167595.patch

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

From report at bugs.python.org  Wed Feb  5 03:56:55 2014
From: report at bugs.python.org (Glenn Langford)
Date: Wed, 05 Feb 2014 02:56:55 +0000
Subject: [New-bugs-announce] [issue20516] Concurrent.futures base
	concurrency improvement (with	patch)
Message-ID: <1391569015.82.0.789033083368.issue20516@psf.upfronthosting.co.za>


New submission from Glenn Langford:

The current approach taken in as_completed() and wait() is to immediately lock the entire set of given Futures simultaneously. This limits concurrency, particularly when the number of futures is large, and also requires the complete set of Futures to be known up front.

A different approach is to lock Futures one at a time, as they are given. In the case of as_completed(), completed futures can be yielded immediately. For completed futures, a waiter also does not have to be installed (whereas the current implementation installs waiters for all given Futures, regardless of state).

A demonstration patch is attached which 
- locks Futures one at a time for as_completed() and all variations of wait()
- reduces the overhead in tracking the state of each Future
- makes it easier to add other user APIs if desired later
- consolidates the machinery into a new internal class, reducing the amount of code

----------
components: Library (Lib)
files: futures-base.patch
keywords: patch
messages: 210286
nosy: bquinlan, glangford, haypo, pitrou
priority: normal
severity: normal
status: open
title: Concurrent.futures base concurrency improvement (with patch)
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33920/futures-base.patch

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

From report at bugs.python.org  Wed Feb  5 04:43:10 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 05 Feb 2014 03:43:10 +0000
Subject: [New-bugs-announce] [issue20517] Support errors with two filenames
	for errno exceptions
Message-ID: <1391571790.8.0.840627368503.issue20517@psf.upfronthosting.co.za>


New submission from Larry Hastings:

There are a bunch of functions provided by Python, e.g. PyErr_SetFromErrnoWithFilenameObject(), that allow specifying a filename associated with the error.  But there are some errors that really need two filenames, like copy(), symlink(), and rename().  The error could be on only one file, but some errors could apply to either or both, and errno's error doesn't always provide enough context to tell which it would be.

I propose that we add new APIs that allow specifying a second filename.  We take all the *WithFilename* APIs and add the *WithFilenames* equivalent (e.g. PyErr_SetFromErrnoWithFilenameObjects()).  Internally, oserror_parse_args() would now parse an extra "filename2" entry in the tuple, just after the "filename" entry (but before the possible "winerror" entry).

Currently when formatting an error with a filename, the format string looks like
    [Errno {errno}] {errstring}: {filename}
I propose that for two filenames it look like
    [Errno {errno}] {errstring}: \"{filename}\" -> \"{filename2}\"

----------
messages: 210290
nosy: georg.brandl, larry, richard, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Support errors with two filenames for errno exceptions
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  5 09:30:36 2014
From: report at bugs.python.org (Martin Teichmann)
Date: Wed, 05 Feb 2014 08:30:36 +0000
Subject: [New-bugs-announce] [issue20518] Weird behavior with multiple
	inheritance when C classes	involved
Message-ID: <1391589036.91.0.744972661823.issue20518@psf.upfronthosting.co.za>


New submission from Martin Teichmann:

Python behaves odd with regards to multiple inheritance and classes
written in C. I stumbled over this problem while working with PyQt4,
but soon realized that part of the problem is not actually in that
library, but is deep down in the CPython core. For better
understanding of this post, I still use PyQt4 as an example. For those
who don't know PyQt4, it's an excellent Python binding for some C++
library, for this post you only need to know that QTimer is a class
that inherits from QObject.

The PyQt4 documentation repeatedly insists that it is not possible to
inherit more than one of its classes. This is not astonishing, since
this is actually a limitation of CPython. What should still be
possible is to inherit from two classes if one is the parent of the
other. Let me give an example:

========================================
from PyQt4.QtCore import QObject, QTimer
# QObject is the parent of QTimer

class A(QObject):
    pass

class B(A, QTimer):
    pass

class C(QTimer, A):
    pass

print(B.__base__, B.__mro__)
print(C.__base__, C.__mro__)
========================================

Both classes B and C technically inherit from both QObject and QTimer,
but given that QTimer inherits from QObject, there is no actual
multiple inheritance here, from the perspective of a class written in
C.

But now the problems start. The metaclass of PyQt4 uses the __base__
class attribute to find out which of its classes the new class
actually decends from (this is called the "best_base" in typeobject.c).
This is the correct behavior, this is exactly
what __base__ is for. Lets see what it contains. For the class B, the
second-to-last line prints:

<class '__main__.A'> (<class '__main__.B'>, <class '__main__.A'>, <class 'PyQt4.QtCore.QTimer'>, <class 'PyQt4.QtCore.QObject'>, <class 'sip.wrapper'>, <class 'sip.simplewrapper'>, <class 'object'>)

So, __base__ is set to class A. This is incorrect, as PyQt4 now thinks
it should create a QObject. The reason is the weird algorithm that
typeobject.c uses: it tries to find the most special class that does
not change the size of the its instances (called the solid_base). This
sounds reasonable at first, because only classes written in C can
change the size of their instances. Unfortunately, this does not hold
the other way around: in PyQt4, the instances only contain a pointer
to the actual data structures, so all instances of all PyQt4 classes
have the same size, and __base__ will simply default to __bases__[0].

Now I tried to outsmart this algorithm, why not put the PyQt4 class as
the first parent class? This is what the class C is for in my example.
And indeed, the last line of my example prints:

<class 'PyQt4.QtCore.QTimer'> (<class '__main__.C'>, <class 'PyQt4.QtCore.QTimer'>, <class '__main__.A'>, <class 'PyQt4.QtCore.QObject'>, <class 'sip.wrapper'>, <class 'sip.simplewrapper'>, <class 'object'>)

So hooray, __base__ is set to QTimer, the metaclass will inherit from
the correct class! But well, there is a strong drawback: now the MRO,
which I print in the same example, has a mixture of Python and PyQt4
classes in it. Unfortunately, the methods of the PyQt4 classes do not
call super, so they are uncooperative when it comes to multiple
inheritance. This is expected, as they are written in C++, a language
that has a weird concept of cooperative multiple inheritance, if it
has one at all.

So, to conclude: it is sometimes not possible to use python
cooperative multiple inheritance if C base classes are involved. This
is a bummer.

Can we change this behavior? Yes, certainly. The clean way would be to
re-write typeobject.c to actually find the best_base in a sane way.
This would be easiest if we could just find out somehow whether a
class is written in Python or in C, e.g. by adding a tp_flag to
PyTypeObject. best_base would then point to the most specialized
parent written in C.

A simpler solution would be to default to __bases__[-1] for __base__,
then we can tell users to simply put their uncooperative base classes
last in the list of bases.

----------
components: Interpreter Core
messages: 210291
nosy: Martin.Teichmann
priority: normal
severity: normal
status: open
title: Weird behavior with multiple inheritance when C classes involved
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Wed Feb  5 12:52:23 2014
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Wed, 05 Feb 2014 11:52:23 +0000
Subject: [New-bugs-announce] [issue20519] uuid.uuid4().hex generates garbage
	when ctypes available
Message-ID: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za>


New submission from Gustavo J. A. M. Carneiro:

If you try the attached program, you will find that for every iteration the uuid.uuid4() call generates objects that contain reference cycles and need the help of the garbage collector.  This is not nice.  If I make the ctypes module not able to import, then no garbage is generated.

This problem appears in 2.7, 3.3, and 3.4, at least.

----------
components: Library (Lib)
files: gc.py
messages: 210306
nosy: gustavo
priority: normal
severity: normal
status: open
title: uuid.uuid4().hex generates garbage when ctypes available
type: resource usage
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33925/gc.py

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

From report at bugs.python.org  Wed Feb  5 14:09:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2014 13:09:34 +0000
Subject: [New-bugs-announce] [issue20520] Readline test in test_codecs is
	broken
Message-ID: <1391605774.47.0.366195437882.issue20520@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The ReadTest.test_readline test in Lib/test/test_codecs.py has two loops on "\n \r\n \r \u2028".split(). But as far as "\n \r\n \r \u2028".split() is empty list (because newline characters are whitespace characters), the bodies of these loops are never executed.

After fixing this bug, a number of other tests were exposed. I tried to fix them. The purpose of these tests is not entirely clear, so I'm not sure that it is properly grasped the idea of the author.

Test was added in issue1076985 and modified in issue1175396.

----------
components: Tests
files: test_codecs_readline.patch
keywords: patch
messages: 210309
nosy: doerwalter, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Readline test in test_codecs is broken
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33928/test_codecs_readline.patch

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

From report at bugs.python.org  Wed Feb  5 14:56:12 2014
From: report at bugs.python.org (Sven Berkvens-Matthijsse)
Date: Wed, 05 Feb 2014 13:56:12 +0000
Subject: [New-bugs-announce] [issue20521] [PATCH] Cleanup for "dis" module
	documentation
Message-ID: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za>


New submission from Sven Berkvens-Matthijsse:

The documentation for the "dis" module has a wrong opcode name in it (POP_STACK instead of POP_TOP). Furthermore, the patch fixes inconsistent use of markers for code and opcodes.

----------
assignee: docs at python
components: Documentation
files: dis-doc.patch
keywords: patch
messages: 210314
nosy: docs at python, svenberkvens
priority: normal
severity: normal
status: open
title: [PATCH] Cleanup for "dis" module documentation
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33929/dis-doc.patch

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

From report at bugs.python.org  Wed Feb  5 15:59:12 2014
From: report at bugs.python.org (Simone Serrajotto)
Date: Wed, 05 Feb 2014 14:59:12 +0000
Subject: [New-bugs-announce] [issue20522] pandas version 0.13.0 does not
	give warning when summing	float with object
Message-ID: <CA+NpumA8h5cWV=cNXSvFvkar+rytW1Ac4Hyjwa4uGEZjFTageA@mail.gmail.com>


New submission from Simone Serrajotto:

Good afternoon,
I have just installed pandas 0.13.0 and was observing some strange results
produced by old codes.
One major issue is that I found that when summing two columns of a
dataframe, one of which is a float64 and the other an object, the result
includes just the float64 columns.
This would be not an issue per se, but no warning message is displayed.
I think a warning in this case is of paramount importance.

Regards,
Simone

-- 

Simone Serrajotto

Quaestio Capital Management SGR SpA Unipersonale

Corso Como 15 (8? piano)

20154 Milano

C.F. e P.I. 06803880969

Iscritta all'Albo delle SGR al n. 299

Mobile:  +39 393 919 0217

Tel:           +39 02 3676 5241

E-Mail:        s.serrajotto at quaestiocapital.com<c.prinoth at quaestiocapital.com>

-- 

Le informazioni contenute nella comunicazione che precede sono riservate e 
destinate esclusivamente alla persona o all'ente sopraindicati. La 
diffusione, distribuzione e/o copiatura del presente email o di qualsiasi 
documento allegato da parte di qualsiasi soggetto diverso dal destinatario 
e' proibita. La sicurezza e la correttezza dei messaggi di posta 
elettronica non possono essere garantite. Se avete ricevuto questo 
messaggio per errore, Vi preghiamo di contattarci immediatamente. Grazie

The content of this email is confidential and it is intended for the sole 
use of the addressees. The transmission, distribution and/or copy of this 
email or any document attached hereto by any person other than the 
addressees is prohibited. The transmission of this email cannot be 
guaranteed to be secure or error-free. If you have received this 
communication unintentionally, please inform us immediately. Thank you.

----------
messages: 210323
nosy: serrajo
priority: normal
severity: normal
status: open
title: pandas version 0.13.0 does not give warning when summing float with object

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

From report at bugs.python.org  Wed Feb  5 22:57:33 2014
From: report at bugs.python.org (mbyt)
Date: Wed, 05 Feb 2014 21:57:33 +0000
Subject: [New-bugs-announce] [issue20523] global .pdbrc on windows 7 not
	reachable out of the box
Message-ID: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za>


New submission from mbyt:

The global .pdbrc file is determined by the %HOME% environment variable. However, this is not available out of the box on e.g. windows 7 systems. Here only %HOMEDRIVE% and %HOMEPATH% are defined.

Thus the usual approach to have a global .pdbrc file on windows is to define a %HOME% environment variable by hand. This could be avoided if the global .pdbrc would be determined by os.path.expanduser("~/.pdbrc"), which works on current windows and does the magic behind.

There are two possible approaches to improve this situation:
* explicitly mention in the docs that on windows a %HOME% varialbe need to be created manually
* patch pdb.py to use os.path.expanduser instead (see attached diff)

For reference, see also old discussion https://mail.python.org/pipermail/python-list/2005-October/349550.html.

----------
files: pdb.diff
keywords: patch
messages: 210349
nosy: mbyt
priority: normal
severity: normal
status: open
title: global .pdbrc on windows 7 not reachable out of the box
type: enhancement
Added file: http://bugs.python.org/file33935/pdb.diff

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

From report at bugs.python.org  Thu Feb  6 00:23:15 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Feb 2014 23:23:15 +0000
Subject: [New-bugs-announce] [issue20524] format error messages should
	provide context information
Message-ID: <1391642595.93.0.722493013717.issue20524@psf.upfronthosting.co.za>


New submission from R. David Murray:

Consider the following:

   '{run_time:%H:%M:%S}, ,COM,DA{id},"{title:.43}",{id},{length:%M:%S}'.format(**mydict)

The error message I got was:

   Invalid format specifier

The problem turned out to be that the value of the 'length' key was an integer instead of a datetime.time(), but it sure wasn't easy to figure out which bit of the format string or which variable was the problem.

It would be nice for the format error message to include the pattern that it is parsing when it hits the error.  The type of the value being substituted would also be nice.  Perhaps something like:

   The format specifier in {length:%HH:%MM} is not valid for type int()

----------
components: Library (Lib)
messages: 210351
nosy: eric.smith, r.david.murray
priority: normal
severity: normal
status: open
title: format error messages should provide context information

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

From report at bugs.python.org  Thu Feb  6 08:58:12 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 06 Feb 2014 07:58:12 +0000
Subject: [New-bugs-announce] [issue20525] Got compiler warning when
	compiling readline module
Message-ID: <1391673492.51.0.068271536657.issue20525@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

On Fedora 20, I got this compiler warning:

/home/sky/Code/python/cpython3.4/Modules/readline.c: In function ?flex_complete?:
/home/sky/Code/python/cpython3.4/Modules/readline.c:962:5: warning: passing argument 1 of ?completion_matches? discards ?const? qualifier from pointer target type [enabled by default]
     result = completion_matches(text, *on_completion);
     ^
/home/sky/Code/python/cpython3.4/Modules/readline.c:40:15: note: expected ?char *? but argument is of type ?const char *?
 extern char **completion_matches(char *, rl_compentry_func_t *);
               ^

Here is the patch using Christian Heimes' strategy in silencing compiler warning in dbm module.
http://hg.python.org/cpython/rev/3068ff3d9d1e

----------
components: Extension Modules
files: fix_compile_warning_readline.patch
keywords: patch
messages: 210364
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got compiler warning when compiling readline module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33938/fix_compile_warning_readline.patch

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

From report at bugs.python.org  Thu Feb  6 10:14:02 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2014 09:14:02 +0000
Subject: [New-bugs-announce] [issue20526] python: Modules/gcmodule.c:379:
	visit_decref: Assertion	`((gc)->gc.gc_refs >> (1)) != 0' failed.
Message-ID: <1391678042.33.0.420181737425.issue20526@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While trying to reproduce a race condition in asyncio, I got an assertion error from the Python garbage collector at exit. It's not easy to reproduce the issue: run attached script on Python 3.4 compiled in debug mode (to get assertions) and press CTRL+c twice. It looks like the bug occurs more often after at least 400 runs.

The Future class of the asyncio may store an exception in its private Future._exception attribute. An exception stores a traceback. I don't know if it's related.

Output:
---
...
run #347
^CTraceback (most recent call last):
  File "x.py", line 73, in <module>
    main()
  File "x.py", line 70, in main
    el.join()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1061, in join
    self._wait_for_tstate_lock()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1077, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
run #348
KeyboardInterrupt
...
run #364
run #365
run #366
run #367
-cancelled-
run #368
^CException ignored in: <module 'threading' from '/home/haypo/prog/python/default/Lib/threading.py'>
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1295, in _shutdown
    t.join()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1061, in join
    self._wait_for_tstate_lock()
  File "/home/haypo/prog/python/default/Lib/threading.py", line 1077, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
-cancelled-
python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.
Abandon (core dumped)

$ ls *core
python-6564.core

$ gdb ./python -c python-6564.core

Core was generated by `./python x.py'.
Program terminated with signal SIGABRT, Aborted.
(gdb) where
#0  0x0000003f3a835c59 in raise () from /lib64/libc.so.6
#1  0x0000003f3a837368 in abort () from /lib64/libc.so.6
#2  0x0000003f3a82ebb6 in __assert_fail_base () from /lib64/libc.so.6
#3  0x0000003f3a82ec62 in __assert_fail () from /lib64/libc.so.6
#4  0x000000000043ac66 in visit_decref (
    op=Frame 0x7f013c001398, for file x.py, line 43, in task (self=<WorkerThread(_kwargs={}, loop=<_UnixSelectorEventLoop(_scheduled=[], _default_executor=None, _running=True, _ready=<collections.deque at remote 0x7f014bbed6e0>, _selector=<EpollSelector(_map=<_SelectorMapping(_selector=<...>) at remote 0x7f014c3bff60>, _epoll=<select.epoll at remote 0x7f014d5bce08>, _fd_to_key={5: <SelectorKey at remote 0x7f014bbecaf8>}) at remote 0x7f014c3bfae8>, _granularity=<float at remote 0x7f014e8c76b8>, _ssock=<socket at remote 0x7f014c3c5a78>, _internal_fds=1, _csock=<socket at remote 0x7f014bbeb5f8>, _signal_handlers={}) at remote 0x7f014c437400>, _is_stopped=False, _target=None, _daemonic=False, executor=<ThreadPoolExecutor(_max_workers=5, _shutdown=False, _work_queue=<Queue(not_empty=<Condition(release=<built-in method release of _thread.lock object at remote 0x7f014c3bb1a0>, acquire=<built-in method acquire of _thread.lock object at remote 0x7f014c3bb1a0>, _lock=<_thread.lock at remote 0x7f014c3bb1a0>, _waiters=<collecti...(truncated), data=0x0) at Modules/gcmodule.c:379
#5  0x00000000004336bd in tb_traverse (tb=0x7f01493a66e8, visit=0x43abb4 <visit_decref>, arg=0x0) at Python/traceback.c:64
#6  0x000000000043acdc in subtract_refs (containers=0x8f1a20 <generations+64>) at Modules/gcmodule.c:398
#7  0x000000000043bdee in collect (generation=2, n_collected=0x7fff499317c0, n_uncollectable=0x7fff499317b8, nofail=0)
    at Modules/gcmodule.c:957
#8  0x000000000043c455 in collect_with_callback (generation=2) at Modules/gcmodule.c:1128
#9  0x000000000043d1d5 in PyGC_Collect () at Modules/gcmodule.c:1604
#10 0x000000000041e959 in Py_Finalize () at Python/pythonrun.c:605
#11 0x000000000043a890 in Py_Main (argc=2, argv=0x22bb020) at Modules/main.c:771
#12 0x000000000041aba9 in main (argc=2, argv=0x7fff49931ab8) at ./Modules/python.c:69

(gdb) frame 4
#4  0x000000000043ac66 in visit_decref (

(gdb) print op
$3 = Frame 0x7f013c001398, for file x.py, line 43, in task (self=<WorkerThread(_kwargs={}, loop=<_UnixSelectorEventLoop(_scheduled=[], _default_executor=None, _running=True, _ready=<collections.deque at remote 0x7f014bbed6e0>, _selector=<EpollSelector(_map=<_SelectorMapping(_selector=<...>) at remote 0x7f014c3bff60>, _epoll=<select.epoll at remote 0x7f014d5bce08>, _fd_to_key={5: <SelectorKey at remote 0x7f014bbecaf8>}) at remote 0x7f014c3bfae8>, _granularity=<float at remote 0x7f014e8c76b8>, _ssock=<socket at remote 0x7f014c3c5a78>, _internal_fds=1, _csock=<socket at remote 0x7f014bbeb5f8>, _signal_handlers={}) at remote 0x7f014c437400>, _is_stopped=False, _target=None, _daemonic=False, executor=<ThreadPoolExecutor(_max_workers=5, _shutdown=False, _work_queue=<Queue(not_empty=<Condition(release=<built-in method release of _thread.lock object at remote 0x7f014c3bb1a0>, acquire=<built-in method acquire of _thread.lock object at remote 0x7f014c3bb1a0>, _lock=<_thread.lock at remote 0x7f014c3bb1a0>, _waiters=<collecti...(truncated)
---

----------
messages: 210368
nosy: gvanrossum, haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  6 10:19:32 2014
From: report at bugs.python.org (OscaTutenchamon)
Date: Thu, 06 Feb 2014 09:19:32 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue20527=5D_multiprocessing=2E?=
 =?utf-8?q?Queue_deadlocks_after_=E2=80=9Creader=E2=80=9D_process_death?=
Message-ID: <1391678372.4.0.26319787903.issue20527@psf.upfronthosting.co.za>


New submission from OscaTutenchamon:

I've experienced that queue can be deadlocked for reading when:
1. The "reader" process is using `get` with timeout > 0:
  self.queue.get(timeout=3)
2. "reader" dies while `get` is blocking due to timeout.

After that queue's `_rlock` is never being released so reading becomes impossible.

Application demonstrating the problem.
I create two child processes "Worker" (putting into queue) and "Receiver" (getting from queue). Also parent process periodically checks if his children are alive and starts new child if needed.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import multiprocessing
import procname
import time

class Receiver(multiprocessing.Process):
    ''' Reads from queue with 3 secs timeout '''

    def __init__(self, queue):
        multiprocessing.Process.__init__(self)
        self.queue = queue

    def run(self):
        procname.setprocname('Receiver')
        while True:
            try:
                msg = self.queue.get(timeout=3)
                print '<<< `{}`, queue rlock: {}'.format(
                    msg, self.queue._rlock)
            except multiprocessing.queues.Empty:
                print '<<< EMPTY, Queue rlock: {}'.format(
                    self.queue._rlock)
                pass


class Worker(multiprocessing.Process):
    ''' Puts into queue with 1 sec sleep '''

    def __init__(self, queue):
        multiprocessing.Process.__init__(self)
        self.queue = queue

    def run(self):
        procname.setprocname('Worker')
        while True:
            time.sleep(1)
            print 'Worker: putting msg, Queue size: ~{}'.format(
                self.queue.qsize())
            self.queue.put('msg from Worker')


if __name__ == '__main__':
    queue = multiprocessing.Queue()

    worker = Worker(queue)
    worker.start()

    receiver = Receiver(queue)
    receiver.start()

    while True:
        time.sleep(1)
        if not worker.is_alive():
            print 'Restarting worker'
            worker = Worker(queue)
            worker.start()
        if not receiver.is_alive():
            print 'Restarting receiver'
            receiver = Receiver(queue)
            receiver.start()

Colored version here: http://pastebin.com/YifY63vE

Console output.
$ python queuetest.py
Worker: putting msg, Queue size: ~0
<<< `msg from Worker`, queue rlock: <Lock(owner=None)>
Worker: putting msg, Queue size: ~0
<<< `msg from Worker`, queue rlock: <Lock(owner=None)>
Restarting receiver                        <-- killed Receiver with SIGTERM
Worker: putting msg, Queue size: ~0
Worker: putting msg, Queue size: ~1
Worker: putting msg, Queue size: ~2
<<< EMPTY, Queue rlock: <Lock(owner=SomeOtherProcess)>
Worker: putting msg, Queue size: ~3
Worker: putting msg, Queue size: ~4
Worker: putting msg, Queue size: ~5
<<< EMPTY, Queue rlock: <Lock(owner=SomeOtherProcess)>
Worker: putting msg, Queue size: ~6
Worker: putting msg, Queue size: ~7 

System information.
$ uname -sr
Linux 3.11.8-200.fc19.x86_64
$ python -V
Python 2.7.5
In [3]: multiprocessing.__version__
Out[3]: '0.70a1'

----------
components: Library (Lib)
messages: 210369
nosy: OscaTutenchamon
priority: normal
severity: normal
status: open
title: multiprocessing.Queue deadlocks after ?reader? process death
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  6 11:08:45 2014
From: report at bugs.python.org (Gunnar Aastrand Grimnes)
Date: Thu, 06 Feb 2014 10:08:45 +0000
Subject: [New-bugs-announce] [issue20528] fileinput module will read whole
	file into memory when	using fileinput.hook_encoded due to
	codecs.StreamReader.readlines
Message-ID: <1391681325.2.0.183803213887.issue20528@psf.upfronthosting.co.za>


New submission from Gunnar Aastrand Grimnes:

When reading large files with fileinput, it will work as expected and only process a line at a time when used normally, but if you add an hook_encoded openhook it will read the whole file into memory before returning the first line. 

Verify by running this program on a large text file: 

import fileinput

for l in fileinput.input(openhook=fileinput.hook_encoded('iso-8859-1')):
    raw_input()

and check how much memory it uses. Remove the openhook and memory usage goes down to nothing.

The problem is that fileinput calls readlines with a size-hint and in codecs.StreamReader, readlines explicitly ignores this hint and reads all lines into memory. 

http://bugs.python.org/issue20501 is open for fixing up the documentation for fileinput, but a fix would also be nice.

I see two options: 

1. As suggested by r.david.murray: Give us a way of signaling to fileinput that it should not use readlines, for instance by setting buffer=None

2. Fix the codecs module to allow StreamReader to respect the hint if given. Although the comment there says it's no efficient way to do this, at least an inefficient way would be better than reading a possibly infinite stream in. A simple solution would be to repeatedly call readline. A more complicated solution would be to read chunks from the stream, and then encode them, just like the readline method does. 

BTW - this issue is py2.7 only, I tested a file object from io.open with encoding in 3.3 and it supports readlines just fine.

----------
components: IO
messages: 210371
nosy: gromgull
priority: normal
severity: normal
status: open
title: fileinput module will read whole file into memory when using fileinput.hook_encoded due to codecs.StreamReader.readlines
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  6 13:13:42 2014
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 06 Feb 2014 12:13:42 +0000
Subject: [New-bugs-announce] [issue20529] Unittest displays ResourceWarning
	warnings when running	tests, it probably should not
Message-ID: <1391688822.97.0.233110009283.issue20529@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna:

Given the following file test_reswarn.py:

====
import unittest


class TestResourceWarning(unittest.TestCase):
    def test_it(self):
        self.assertIn("TestResourceWarning", open(__file__).read())
====

Running the test:

====
$ python -m unittest test_reswarn.py
./test_reswarn.py:6: ResourceWarning: unclosed file <_io.TextIOWrapper name='./test_reswarn.py' mode='r' encoding='UTF-8'>
  self.assertIn("TestResourceWarning", open(__file__).read())
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
====

When running the unit test using unittest, ResourceWarning warnings are displayed. In my experience using open("filename") without explicitly closing the file is pretty common and would usually not be an error, since the file will be closed when the reference goes out of scope (or am I wrong?).

Therefore I believe that unittest should not emit ResourceWarning warnings.

----------
components: Library (Lib)
messages: 210377
nosy: Bernt.R?skar.Brenna
priority: normal
severity: normal
status: open
title: Unittest displays ResourceWarning warnings when running tests, it probably should not
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb  6 15:09:10 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 06 Feb 2014 14:09:10 +0000
Subject: [New-bugs-announce] [issue20530] Change the text signature format
	(again) to be more	robust
Message-ID: <1391695750.05.0.146053236138.issue20530@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Following a new discussion of the format of the text signature, I decided to go with this:
    <name-of-function>(...)\n--\n\n

See here for the discussion:
   https://mail.python.org/pipermail/python-dev/2014-February/132271.html

Patch attached implementing this approach.  Can I get a review?  I want this in before tagging for rc1 on Saturday.

Other changes:

* clinic.py now generates the "/" marker in sigantures to denote
  positional-only parameters.

* clinic.py --make is a lot faster; it prescans the file for any
  clinic block signatures, and if it doesn't see any it skips the file.

* When generating the docstring for a function with optional groups,
  the signature generated is not intended to be machine-readable.
  So it omits the "$", the "/", and the "--" markers.  (See
  Modules/_cursesmodule.c for the one and only example.)

----------
assignee: larry
files: larry.even.newerer.signature.syntax.1.diff
keywords: patch
messages: 210380
nosy: georg.brandl, larry, ncoghlan, serhiy.storchaka, yselivanov, zach.ware
priority: release blocker
severity: normal
stage: patch review
status: open
title: Change the text signature format (again) to be more robust
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33941/larry.even.newerer.signature.syntax.1.diff

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

From report at bugs.python.org  Thu Feb  6 15:44:54 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 06 Feb 2014 14:44:54 +0000
Subject: [New-bugs-announce] [issue20531] TypeError in e-mail.parser when
	non-ASCII is present
Message-ID: <1391697894.48.0.687210900333.issue20531@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

As reported in https://bitbucket.org/dholth/wheel/issue/104, the email.parser no longer accepts Unicode content as it did in 3.3. I searched the What's New and module documentation, but found no indication that this behavior is no longer supported, so it appears to be a regression. If it's an intentional change, the behavior should be documented in one of the aforementioned documents.

Consider this simple test case:

# -*- coding: utf-8 -*-
import email.parser
meta = """
Header: ?
"""
email.parser.Parser().parsestr(meta)

Run that on Python 3.3.3 or Python 2 and it executes silently. Run it on Python 3.4.0b3 and it produces this traceback:

Traceback (most recent call last):
  File "C:\Users\jaraco\projects\public\wheel\test.py", line 6, in <module>
    email.parser.Parser().parsestr(meta)
  File "C:\Program Files\Python34\lib\email\parser.py", line 70, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "C:\Program Files\Python34\lib\email\parser.py", line 60, in parse
    return feedparser.close()
  File "C:\Program Files\Python34\lib\email\feedparser.py", line 170, in close
    self._call_parse()
  File "C:\Program Files\Python34\lib\email\feedparser.py", line 163, in _call_parse
    self._parse()
  File "C:\Program Files\Python34\lib\email\feedparser.py", line 449, in _parsegen
    self._cur.set_payload(EMPTYSTRING.join(lines))
  File "C:\Program Files\Python34\lib\email\message.py", line 311, in set_payload
    " payload") from None
TypeError: charset argument must be specified when non-ASCII characters are used in the payload

----------
components: email
keywords: 3.4regression
messages: 210390
nosy: barry, jason.coombs, r.david.murray
priority: normal
severity: normal
status: open
title: TypeError in e-mail.parser when non-ASCII is present
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  6 18:59:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2014 17:59:44 +0000
Subject: [New-bugs-announce] [issue20532] Mark all tests which use _testcapi
	as CPython only
Message-ID: <1391709584.86.0.554035328709.issue20532@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch marks all tests which use _testcapi as CPython only. Usually such tests don't make sense in alternative implementations. In particular tests which test integer overflow rely on implementation details.

This should help to use common tests for different implementations.

----------
components: Tests
files: testcapi_cpython_only.patch
keywords: patch
messages: 210409
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark all tests which use _testcapi as CPython only
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33946/testcapi_cpython_only.patch

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

From report at bugs.python.org  Thu Feb  6 21:07:50 2014
From: report at bugs.python.org (Rihards)
Date: Thu, 06 Feb 2014 20:07:50 +0000
Subject: [New-bugs-announce] [issue20533] bug?
Message-ID: <1391717270.59.0.361887326054.issue20533@psf.upfronthosting.co.za>


New submission from Rihards:

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 11.29-6.29
4.999999999999999
>>> 11.30-6.30
5.000000000000001
>>>

----------
messages: 210412
nosy: Rihards
priority: normal
severity: normal
status: open
title: bug?

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

From report at bugs.python.org  Thu Feb  6 22:25:50 2014
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 06 Feb 2014 21:25:50 +0000
Subject: [New-bugs-announce] [issue20534] Enum tests fail with pickle
	protocol 4
Message-ID: <1391721950.3.0.401090497621.issue20534@psf.upfronthosting.co.za>


New submission from Ethan Furman:

enum34, the Enum backport, specifically uses `protocol=HIGHEST_PROTOCOL`, while the current enum tests just use the default.

Running the enum34 test expose an issue with pickle protocol 4:

======================================================================
ERROR: test_subclasses_with_getnewargs (__main__.TestEnum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_enum.py", line 1022, in test_subclasses_with_getnewargs
    self.assertEqual(loads(dumps(NI5, protocol=HIGHEST_PROTOCOL)), 5)
_pickle.PicklingError: Can't pickle <class '__main__.TestEnum.test_subclasses_with_getnewargs.<locals>.NamedInt'>: attribute lookup TestEnum.test_subclasses_with_getnewargs.<locals>.NamedInt on __main__ failed

======================================================================
ERROR: test_tuple_subclass (__main__.TestEnum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_enum.py", line 1100, in test_tuple_subclass
    self.assertTrue(loads(dumps(SomeTuple.first, protocol=HIGHEST_PROTOCOL)) is SomeTuple.first)
_pickle.PicklingError: Can't pickle <enum 'SomeTuple'>: attribute lookup TestEnum.test_tuple_subclass.<locals>.SomeTuple on __main__ failed

----------
messages: 210419
nosy: alexandre.vassalotti, ethan.furman, pitrou
priority: high
severity: normal
stage: test needed
status: open
title: Enum tests fail with pickle protocol 4
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  6 22:55:17 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 06 Feb 2014 21:55:17 +0000
Subject: [New-bugs-announce] [issue20535] run_tests.py: Work around issues
	20355 and 20361
Message-ID: <1391723717.25.0.167441884978.issue20535@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Tools/scripts/run_tests.py contains:

def main(regrtest_args):
    args = [sys.executable,
            '-W', 'default',      # Warnings set to 'default'
            '-bb',                # Warnings about bytes/bytearray
            '-E',                 # Ignore environment variables
            ]


As described in issues #20355 and #20361, -bb fails to enable BytesWarning errors.

I suggest to include a small workaround, which will be deleted in Python 3.5. I attach patch.

----------
components: Tests
files: run_tests.py.patch
keywords: patch
messages: 210423
nosy: Arfrever, serhiy.storchaka
priority: normal
severity: normal
status: open
title: run_tests.py: Work around issues 20355 and 20361
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33948/run_tests.py.patch

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

From report at bugs.python.org  Fri Feb  7 00:42:19 2014
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Feb 2014 23:42:19 +0000
Subject: [New-bugs-announce] [issue20536] statistics._decimal_to_ratio()
	produces non-integer ratio
Message-ID: <1391730139.77.0.406178455931.issue20536@psf.upfronthosting.co.za>


New submission from Stefan Krah:

As I understand, _decimal_to_ratio() should always produce an
integer ratio.  But it does not for positive exponents:

>>> import statistics
>>> statistics.mean([Decimal("100"), Decimal("200")])
Decimal('150')
>>> statistics.mean([Decimal("1e2"), Decimal("2e2")])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/statistics.py", line 308, in mean
    return _sum(data)/n
  File "/usr/local/lib/python3.4/statistics.py", line 166, in _sum
    total += Fraction(n, d)
  File "/usr/local/lib/python3.4/fractions.py", line 163, in __new__
    raise TypeError("both arguments should be "
TypeError: both arguments should be Rational instances
>>> 
>>> statistics._decimal_to_ratio(Decimal("1e2"))     
(1, 0.01)
>>> 1e2.as_integer_ratio()
(100, 1)

----------
components: Library (Lib)
messages: 210427
nosy: skrah, stevenjd
priority: high
severity: normal
stage: needs patch
status: open
title: statistics._decimal_to_ratio() produces non-integer ratio
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb  7 00:53:08 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Feb 2014 23:53:08 +0000
Subject: [New-bugs-announce] [issue20537] logging exc_info parameter should
	accept exception	instances
Message-ID: <1391730788.17.0.188838717397.issue20537@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

A bunch of logging methods accept optional parameter exc_info, that is supposed to be either 'True' or a tuple of three elements (type, exc, tb).

If, however, someone passes an actual exception instance, Logger._log function will interpret it as True and get the current exception from sys.exc_info, ignoring the passed exception completely.

Attached is a patch that fixes this: if exc_info is an instance of BaseException, Logger._log creates the tuple out of it automatically.

----------
files: logging_01.patch
keywords: patch
messages: 210428
nosy: vinay.sajip, yselivanov
priority: normal
severity: normal
status: open
title: logging exc_info parameter should accept exception instances
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33950/logging_01.patch

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

From report at bugs.python.org  Fri Feb  7 10:32:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 09:32:08 +0000
Subject: [New-bugs-announce] [issue20538] Segfault in UTF-7 incremental
	decoder
Message-ID: <1391765528.81.0.362071183373.issue20538@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

UTF-7 incremental decoder can crash in debug build when decodes unfinished base-64 section. In non-debug build it just produces inconsistent unicode string. Minimal examples:

$ ./python -c "import codecs; codecs.utf_7_decode(b'a+AIA', 'strict')"
python: Objects/unicodeobject.c:403: _PyUnicode_CheckConsistency: Assertion `maxchar >= 128' failed.
Aborted (core dumped)

$ ./python -c "import codecs; codecs.utf_7_decode(b'+AIA-+AQA', 'strict')"
python: Objects/unicodeobject.c:410: _PyUnicode_CheckConsistency: Assertion `maxchar >= 0x100' failed.
Aborted (core dumped)

$ ./python -c "import codecs; codecs.utf_7_decode(b'+AQA-+2ADcAA', 'strict')"
python: Objects/unicodeobject.c:414: _PyUnicode_CheckConsistency: Assertion `maxchar >= 0x10000' failed.
Aborted (core dumped)

This happens because _PyUnicodeWriter reverts position back before unfinished base-64 section, but its buffer was already widened for characters in unfinished base-64 section.

        if (inShift) {
            writer.pos = shiftOutStart; /* back off output */
            *consumed = startinpos;
        }

And now _PyUnicodeWriter generates a string with a kind larger then needed for decoded characters.

This bug causes a lot of crashes on buildbots. E.g:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1197
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.3/builds/1446

----------
components: Interpreter Core, Unicode
messages: 210444
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: Segfault in UTF-7 incremental decoder
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  7 11:54:29 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Feb 2014 10:54:29 +0000
Subject: [New-bugs-announce] [issue20539] math.factorial may throw
	OverflowError
Message-ID: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I believe this is mostly a curiousity (since actually calculating a factorial this big would take an interminable amount of time), but math.factorial can be provoked into throwing OverflowError by a large enough input:

>>> math.factorial(10**19)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

>>> math.factorial(1e19)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

----------
messages: 210448
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: math.factorial may throw OverflowError

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

From report at bugs.python.org  Fri Feb  7 13:06:28 2014
From: report at bugs.python.org (Irvin Probst)
Date: Fri, 07 Feb 2014 12:06:28 +0000
Subject: [New-bugs-announce] [issue20540] Python 3.3/3.4 regression in
	multiprocessing manager ?
Message-ID: <1391774788.17.0.649419287978.issue20540@psf.upfronthosting.co.za>


New submission from Irvin Probst:

After checking with the kind people of help at python.org I think I found a bug in the way connections are handled in the multiprocessing module.

Using python 3.3 I've noticed a performance drop of about 70 times when running some code performing basic requests on a SyncManager. As this code was burried deep into a big project I made a test case attached to this report to reproduce this behavior.

Here is what this code does:
- define a class SharedData with several instance variables (a,b and c here)
- this class has two methods exposed through a proxy (good() ans bad()) both see a huge performance drop using 3.3 and can be used to reproduce this behavior. The only difference is that good() uses a mutex whereas bad() does not, I wished to check that mutexes were not to blame for this problem.
- create a Syncmanager giving access to a SharedData instance
- launch a multiprocessing.Process() running the do_stuff() function, this function calls 10 times the good() (or bad()) method of SharedData through the Syncmanager, passes some values to it and gets back the result.
- after each call to the proxy the time elapsed, roughly measured with time.time(), is printed

System specs:
Linux turing 3.12-1-686-pae #1 SMP Debian 3.12.6-2 (2013-12-29) i686 GNU/Linux

Python version:
latests 2.6,2.7,3.2 and 3.3 from standard debian repos
3.3.0 and 3.4.0 beta3 compiled from source

time elapsed in each call to the proxy using Python 2.6, 2.7 and 3.2:
first call to proxy ~ 0.04 seconds, next calls ~0.001 sec

time elapsed in each call to the proxy using Python 3.3.0, 3.3.2, 3.3.3 , 3.4.0b3:
first call to proxy ~0.27 seconds, next calls: 0.07 sec

I reproduced this behavior using python 2.7 and 3.3.3 on an ubuntu computer running the latest amd64 release.

Of course I tried without a print() after each call but it does not change anything, python 3.3 is *much* slower here.

Using cProfile I tracked this down to the builtin read() method and indeed timing the read() syscall in posix_read() using gettimeofday() confirms it takes ages, posix_write() is fine though. I think the problem comes from the underlying socket the interpreter is reading from.

connections.py from multiprocessing has been rewrittend between 3.2 and 3.3 but I can't see what's wrong in the way it has been done, basic socket options seem to be exactly the same.

One interesting point is that it seems to only affect the last bytes sent through the socket, e.g if you send a numpy.array big enough to fill the socket's read() buffer the first calls to read() are done at a normal speed, only the last one takes time.

If you confirm my test code is not to blame it makes IMHO the SyncManager in 3.3 and 3.4 completely unusable for frequent data exchanges between processes.

Thanks for your time.

----------
components: Library (Lib)
files: test_manager.py
messages: 210457
nosy: Irvin.Probst
priority: normal
severity: normal
status: open
title: Python 3.3/3.4 regression in multiprocessing manager ?
type: performance
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33956/test_manager.py

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

From report at bugs.python.org  Fri Feb  7 13:47:34 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Feb 2014 12:47:34 +0000
Subject: [New-bugs-announce] [issue20541] os.path.exists() gives wrong
	answer for Windows special	files
Message-ID: <1391777254.4.0.885932258701.issue20541@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In trying to figure out why my fix for issue 20053 wasn't working on Windows, I eventually traced it back to the fact that "os.path.exists(os.devnull)" returns False on Windows, so pip isn't picking up my config file override in ensurepip, and reads the global default config file anyway.

However, if you do "if exist NUL (echo exists) ELSE (echo missing)" in cmd, it will print "exists", so this looks like a bug in our os.path.exists implementation.

That is currently implemented in genericpath and assumes that a file exists if-and-only-if os.stat(name) doesn't throw an exception.

It turns out this assumption isn't really correct on Windows - 'NUL' and 'CON' (and presumably other special files) can be opened, but trying to do os.stat() on them throws an exception.

----------
components: Library (Lib), Windows
messages: 210460
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: os.path.exists() gives wrong answer for Windows special files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Feb  7 14:33:33 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Feb 2014 13:33:33 +0000
Subject: [New-bugs-announce] [issue20542] Assertion failure in test_readline
Message-ID: <1391780013.0.0.395448319598.issue20542@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

test_readline is consistently failing with an assertion failure in debug builds. I'm going to add a skip for the time being, because I don't know the UnicodeWriter or UTF7 code well enough to guess where the inconsistency may be being introduced.

Relevant extract from faulthandler stack dump:

Current thread 0x00007f83a3e14740 (most recent call first):
  File "/home/ncoghlan/devel/py3k/Lib/codecs.py", line 494 in read
  File "/home/ncoghlan/devel/py3k/Lib/codecs.py", line 548 in readline
  File "/home/ncoghlan/devel/py3k/Lib/test/test_codecs.py", line 168 in test_readline


Relevant extract from gdb trace:

#4  0x00000000004f092f in _PyUnicode_CheckConsistency (
    op='xxx\naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', check_content=1)
    at Objects/unicodeobject.c:410
#5  0x0000000000544b75 in _PyUnicodeWriter_Finish (writer=0x7ffffffd7d40) at Objects/unicodeobject.c:13503
#6  0x0000000000510f5b in PyUnicode_DecodeUTF7Stateful (s=0x7fffed18b5b8 "", size=72, 
    errors=0x7ffff19db0e8 "strict", consumed=0x7ffffffd7e48) at Objects/unicodeobject.c:4472
#7  0x0000000000607922 in utf_7_decode (self=<module at remote 0x7ffff197cd58>, 
    args=(b'xxx\naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+ICg', 'strict'))
    at ./Modules/_codecsmodule.c:271

----------
assignee: serhiy.storchaka
keywords: 3.4regression, buildbot
messages: 210467
nosy: larry, ncoghlan, serhiy.storchaka
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Assertion failure in test_readline
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb  7 19:44:35 2014
From: report at bugs.python.org (Keith Randall)
Date: Fri, 07 Feb 2014 18:44:35 +0000
Subject: [New-bugs-announce] [issue20543] ** operator does not overflow to
	inf
Message-ID: <1391798675.64.0.456943405881.issue20543@psf.upfronthosting.co.za>


New submission from Keith Randall:

>>> 1e200*1e200
inf
>>> 1e200**2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: (34, 'Numerical result out of range')

Shouldn't floating-point operations overflow to inf, not generate exceptions?

----------
components: Interpreter Core
messages: 210517
nosy: Keith.Randall
priority: normal
severity: normal
status: open
title: ** operator does not overflow to inf
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  7 21:25:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:25:10 +0000
Subject: [New-bugs-announce] [issue20544] Use specific asserts in operator
	tests
Message-ID: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the operator module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_operator_asserts.patch
keywords: easy, patch
messages: 210540
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in operator tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33969/test_operator_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:25:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:25:25 +0000
Subject: [New-bugs-announce] [issue20545] Use specific asserts in unicode
	tests
Message-ID: <1391804725.49.0.807419128336.issue20545@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes unicode related tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests, Unicode
files: test_unicode_asserts.patch
keywords: easy, patch
messages: 210541
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, loewis, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in unicode tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33970/test_unicode_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:25:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:25:44 +0000
Subject: [New-bugs-announce] [issue20546] Use specific asserts in int tests
Message-ID: <1391804744.01.0.671211669548.issue20546@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the int class tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_long_asserts.patch
keywords: easy, patch
messages: 210543
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in int tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33971/test_long_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:25:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:25:56 +0000
Subject: [New-bugs-announce] [issue20547] Use specific asserts in bigmem
	tests
Message-ID: <1391804756.75.0.781107542362.issue20547@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes bigmem tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_bigmem_asserts.patch
keywords: easy, patch
messages: 210544
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in bigmem tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33972/test_bigmem_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:26:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:26:12 +0000
Subject: [New-bugs-announce] [issue20548] Use specific asserts in warnings
	and exceptions tests
Message-ID: <1391804772.02.0.729156315156.issue20548@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes warnings and exceptions related tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_warnexc_asserts.patch
keywords: easy, patch
messages: 210545
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in warnings and exceptions tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33973/test_warnexc_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:26:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:26:45 +0000
Subject: [New-bugs-announce] [issue20549] Use specific asserts in mailbox,
	smtplib and poplib tests
Message-ID: <1391804805.68.0.562354478477.issue20549@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the mailbox, smtplib and poplib modules tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_mailbox_asserts.patch
keywords: easy, patch
messages: 210546
nosy: giampaolo.rodola, petri.lehtinen, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in mailbox, smtplib and poplib tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33974/test_mailbox_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:26:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:26:56 +0000
Subject: [New-bugs-announce] [issue20550] Use specific asserts in
	collections tests
Message-ID: <1391804816.95.0.0835407946311.issue20550@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes collections tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
keywords: easy
messages: 210547
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in collections tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  7 21:27:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:27:16 +0000
Subject: [New-bugs-announce] [issue20551] Use specific asserts in decimal
	tests
Message-ID: <1391804836.31.0.134510679108.issue20551@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the decimal module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_decimal_asserts.patch
keywords: easy, patch
messages: 210548
nosy: facundobatista, mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in decimal tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33975/test_decimal_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:27:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:27:36 +0000
Subject: [New-bugs-announce] [issue20552] Use specific asserts in bytes tests
Message-ID: <1391804856.25.0.0710909652112.issue20552@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes bytes tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_bytes_asserts.patch
keywords: easy, patch
messages: 210549
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in bytes tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33976/test_bytes_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 21:27:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 20:27:44 +0000
Subject: [New-bugs-announce] [issue20553] Use specific asserts in ipaddress
	tests
Message-ID: <1391804864.8.0.447928748965.issue20553@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the ipaddress module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_ipaddress_asserts.patch
keywords: easy, patch
messages: 210550
nosy: ncoghlan, pmoody, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in ipaddress tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33977/test_ipaddress_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 22:34:19 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 21:34:19 +0000
Subject: [New-bugs-announce] [issue20554] Use specific asserts in argparse
	and optparse tests
Message-ID: <1391808859.25.0.0531028969207.issue20554@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes argparse and optparse modules tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_optparse_asserts.patch
keywords: patch
messages: 210560
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use specific asserts in argparse and optparse tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33979/test_optparse_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 22:34:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 21:34:25 +0000
Subject: [New-bugs-announce] [issue20555] Use specific asserts in urllib
	related tests
Message-ID: <1391808865.17.0.101662916847.issue20555@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the urllib, httplib, ftplib, cgi, and wsgiref modules tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_urllib_asserts.patch
keywords: patch
messages: 210561
nosy: giampaolo.rodola, orsenthil, pje, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in urllib related tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33980/test_urllib_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 22:34:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 21:34:38 +0000
Subject: [New-bugs-announce] [issue20556] Use specific asserts in threading
	tests
Message-ID: <1391808878.85.0.661174932104.issue20556@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the threading module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_threading_asserts.patch
keywords: patch
messages: 210562
nosy: brett.cannon, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in threading tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33981/test_threading_asserts.patch

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

From report at bugs.python.org  Fri Feb  7 22:34:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2014 21:34:57 +0000
Subject: [New-bugs-announce] [issue20557] Use specific asserts in io tests
Message-ID: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the io module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_io_asserts.patch
keywords: patch
messages: 210563
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in io tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33982/test_io_asserts.patch

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

From report at bugs.python.org  Sat Feb  8 01:55:43 2014
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 08 Feb 2014 00:55:43 +0000
Subject: [New-bugs-announce] [issue20558] ECONNRESET value in logging.config
	is valid with Linux	[distros]; not valid with *BSD
Message-ID: <1391820943.88.0.107305353589.issue20558@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

The logging module checks for ECONNRESET if it's equal to 104. This is valid on Linux, but not [some] other OSes. On FreeBSD and OpenBSD [*] it's 54, not 104.

The attached patch fixes the logging code to check for errno.ECONNRESET in !win32 environments.

http://www.openbsd.org/cgi-bin/man.cgi?query=errno&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=htmlvim

----------
files: patch
messages: 210580
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Added file: http://bugs.python.org/file33985/patch

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

From report at bugs.python.org  Sat Feb  8 05:34:24 2014
From: report at bugs.python.org (Bill Winslow)
Date: Sat, 08 Feb 2014 04:34:24 +0000
Subject: [New-bugs-announce] [issue20559] urllib/http fail to sanitize a
	non-ascii url
Message-ID: <1391834064.13.0.416589140445.issue20559@psf.upfronthosting.co.za>


New submission from Bill Winslow:

The following code will produce a UnicodeEncodeError about a character being non-ascii:

    from urllib import request, parse, error
    url = 'http://en.wikipedia.org/wiki/Antonio Vallejo-N?jera'
    req = request.Request(url)
    response = request.urlopen(req)

This fails as follows:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/urllib/request.py", line 156, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.3/urllib/request.py", line 469, in open
    response = self._open(req, data)
  File "/usr/lib/python3.3/urllib/request.py", line 487, in _open
    '_open', req)
  File "/usr/lib/python3.3/urllib/request.py", line 447, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.3/urllib/request.py", line 1268, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.3/urllib/request.py", line 1248, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/usr/lib/python3.3/http/client.py", line 1067, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.3/http/client.py", line 1095, in _send_request
    self.putrequest(method, url, **skips)
  File "/usr/lib/python3.3/http/client.py", line 959, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 27: ordinal not in range(128)

I examined the library code in question: line 958 in http/client.py, the line before the one that barfs, contains the following comment: 

# Non-ASCII characters should have been eliminated earlier

I added a print statement to the library code:

    print(request)
    self._output(request.encode('ascii'))

This prints the following: 

>>> response = request.urlopen(req)
GET /wiki/Antonio Vallejo-N?jera HTTP/1.1
Traceback (most recent call last): ...

I confirmed that the 27th character as mentioned in the traceback is in fact the ? in the last name. Clearly either urllib or http is not properly sanitizing the url -- unfortunately, my knowledge is useless as to determining where the actual error is; hopefully this report contains enough detail to make it easy enough.

----------
components: Library (Lib), Unicode
messages: 210587
nosy: Dubslow, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: urllib/http fail to sanitize a non-ascii url
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb  8 11:14:31 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Feb 2014 10:14:31 +0000
Subject: [New-bugs-announce] [issue20560] tkFileFilter.c: ostypeCount not
	initialized?
Message-ID: <1391854471.94.0.0196154123534.issue20560@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Fresh Win7 VC express debug build (F7), 2.7 only: fairly recent (last 3 months?) regression.

In debug console, import idlelib.idle. Try to Open a file. Get message that ostypeCount is used before initialized. If open python_d with F5 in VC, [break] takes me to VS debugger, which points to line 341 in tkFileFilter.c (where is that in the directory tree?).
    if (ostypeCount > 0 && ostypeList != NULL) {
I am slightly puzzled because it appears that line 234
    for (i=0; i<ostypeCount; i++) {
should have been executed first.

----------
messages: 210608
nosy: serhiy.storchaka, terry.reedy
priority: high
severity: normal
stage: needs patch
status: open
title: tkFileFilter.c: ostypeCount not initialized?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  8 12:10:27 2014
From: report at bugs.python.org (Wolfgang Maier)
Date: Sat, 08 Feb 2014 11:10:27 +0000
Subject: [New-bugs-announce] [issue20561] Decimal handling error in
	statistics module
Message-ID: <1391857827.55.0.926154753892.issue20561@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

Can this still be fixed in 3.4 ??

I came across this bug in the statistics module today:

>>> import statistics
>>> data = [Decimal('1e4')]
>>> statistics.mean(data)
Traceback (most recent call last):
  File "<pyshell#465>", line 1, in <module>
    statistics.mean(data)
  File "C:/Python33\statistics.py", line 316, in mean
    return _sum(data)/n
  File "C:/Python33\statistics.py", line 167, in _sum
    total += Fraction(n, d)
  File "C:\Python33\lib\fractions.py", line 163, in __new__
    raise TypeError("both arguments should be "
TypeError: both arguments should be Rational instances

The reason for this is that the statistics module converts Decimals to exact ratios internally like this:

def _decimal_to_ratio(d):
    """Convert Decimal d to exact integer ratio (numerator, denominator).

    >>> from decimal import Decimal
    >>> _decimal_to_ratio(Decimal("2.6"))
    (26, 10)

    """
    sign, digits, exp = d.as_tuple()
    if exp in ('F', 'n', 'N'):  # INF, NAN, sNAN
        assert not d.is_finite()
        raise ValueError
    num = 0
    for digit in digits:
        num = num*10 + digit
    if sign:
        num = -num
    den = 10**-exp
    #if type(den) != int:
    #    print (d, sign, digits, exp, num, den)
    return (num, den)
	
The important part here is the line:

den = 10**-exp

which makes den an int if - and **only** if - exp is negative.

However, the exponent in the namedtuple returned by Decimal.as_tuple() is not guaranteed to be negative and in fact:

>>>Decimal('1e4').as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=4)

With this den in the above function becomes a float, which raises an error subsequently in _sum, when it essentially tries to do:
Fraction(num, den)

IMPORTANT: I have been running this example on my laptop with Python3.3.0 and the statistics module imported from sys.path.
Thus, I cannot exclude that the decimal module has changed since 3.3.0 and is now always returning a negative exponent with
.as_tuple(). I'm abroad and cannot verify this against the Python3.4dev build.
Could somebody confirm this for 3.4 and reject this issue immediately if the error doesn't occur ?

If this is not version dependent though, then there is a very simple bug-fix for it, which I suggest should still be incorporated into 3.4:

if exp >= 0:
    return int(x), 1

inserted right after the raise ValueError line is doing the job.
I cannot generate the diff for this myself, so could somebody do this.

Thanks a lot for your efforts!

----------
messages: 210613
nosy: oscarbenjamin, python-dev, skrah, stevenjd, wolma
priority: normal
severity: normal
status: open
title: Decimal handling error in statistics module
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  8 13:43:08 2014
From: report at bugs.python.org (Johnny Wezel)
Date: Sat, 08 Feb 2014 12:43:08 +0000
Subject: [New-bugs-announce] [issue20562] sqlite3 returns result set with
	doubled first entry
Message-ID: <1391863388.33.0.362303830227.issue20562@psf.upfronthosting.co.za>


New submission from Johnny Wezel:

I could isolate a bug where sqlite3 returns a result set from a select where the first entry occurs twice.

>>> sys.version_info  
sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0)
>>> import sqlite3
>>> sqlite3.version_info
(2, 6, 0)

$ uname -a
Linux 3.10.25-gentoo #1 SMP PREEMPT Wed Jan 29 18:05:47 CET 2014 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux

----------
components: Extension Modules
files: t.py
messages: 210622
nosy: jwezel
priority: normal
severity: normal
status: open
title: sqlite3 returns result set with doubled first entry
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33992/t.py

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

From report at bugs.python.org  Sat Feb  8 14:49:53 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 08 Feb 2014 13:49:53 +0000
Subject: [New-bugs-announce] [issue20563] Mark ipaddress as stable?
Message-ID: <1391867393.51.0.348238863582.issue20563@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Peter, with issue 18805 fixed, what do you think about removing the provisional status from the ipaddress API?

Aside from issue 19157 (where I'm not sure the behaviour even needs changing), the other open ipaddress issues appear to be docs related or RFEs.

At this point, making ipaddress subject to the usual backwards compatibility guarantees seems fairly low risk.

----------
assignee: pmoody
messages: 210641
nosy: larry, ncoghlan, pmoody
priority: normal
severity: normal
stage: commit review
status: open
title: Mark ipaddress as stable?
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  8 19:19:44 2014
From: report at bugs.python.org (Remi Pointel)
Date: Sat, 08 Feb 2014 18:19:44 +0000
Subject: [New-bugs-announce] [issue20564] test_threadsignals.py "failed" on
	OpenBSD because too	slow (> 3sec)
Message-ID: <1391883584.64.0.946216274397.issue20564@psf.upfronthosting.co.za>


New submission from Remi Pointel:

Hi,

I have 2 tests which "failed" on OpenBSD (tested on i386, amd64 and sparc64) in:

- test_threadsignals.py/test_lock_acquire_interruption
- test_threadsignals.py/test_rlock_acquire_interruption


======================================================================
FAIL: test_lock_acquire_interruption (__main__.ThreadSignals)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_threadsignals.py", line 94, in test_lock_acquire_interruption
    self.assertLess(dt, 3.0)
AssertionError: 5.020112991333008 not less than 3.0

======================================================================
FAIL: test_rlock_acquire_interruption (__main__.ThreadSignals)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_threadsignals.py", line 122, in test_rlock_acquire_interruption
    self.assertLess(dt, 3.0)
AssertionError: 5.0101478099823 not less than 3.0

On the 3 machines it took ~ 5sec.
I'm asking why it's 3 seconds by default in the tests? Could we modify the value to 6 instead of 3, is it acceptable?

Thanks for your response,

Remi.

----------
components: Tests
messages: 210672
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_threadsignals.py "failed" on OpenBSD because too slow (> 3sec)
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  8 19:26:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Feb 2014 18:26:34 +0000
Subject: [New-bugs-announce] [issue20565] Update Tcl/Tk version for buildbots
Message-ID: <1391883994.31.0.277087136027.issue20565@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently Windows buildbots use old versions of Tcl/Tk. These versions contain bugs (for example see issue20560).

Versions mentioned in Tools/buildbot/external-common.bat:
On 2.7: 8.5.2.1/8.5.2.0
On 3.3: 8.5.11.0
On 3.4: 8.6.1.0

Some buildbots even use beta version of 8.6 (I needed write workaround in testsuite for behavior differences).

Recent Tcl/Tk versions:

Tcl/Tk 8.6.1 Sep 20, 2013 
Tcl/Tk 8.5.15 Sep 18, 2013 
Tcl/Tk 8.4.20 Jun 1, 2013

Perhaps it is time to update Tcl/Tk to recent versions?

----------
messages: 210674
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Update Tcl/Tk version for buildbots
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  8 21:18:14 2014
From: report at bugs.python.org (Glenn Langford)
Date: Sat, 08 Feb 2014 20:18:14 +0000
Subject: [New-bugs-announce] [issue20566] asyncio as_completed() thrashes
	adding and removing	callbacks
Message-ID: <1391890694.33.0.714223329819.issue20566@psf.upfronthosting.co.za>


New submission from Glenn Langford:

In asyncio, tasks.py as_completed() appears to trigger adding and removing callbacks multiple times for the pending set of futures, each time a single future completes. 

For example, to wait for 5 futures which complete at different times:
- as_completed() uses _wait()
- _wait() will add 5 callbacks, one for each future
- when one future completes, a callback is triggered and all 5 callbacks are removed; this is because _wait() was called with FIRST_COMPLETED
- for the 4 remaining futures - 4 callbacks have to be added back again
- when the next future completes, the 4 callbacks are removed
etc?

The worst case is if as_completed() is called to wait for all of a larger number of futures, which complete at different times. For example, with 100 futures worst case, ~10,000 callback adds and removes would be performed.

(I am very new to the asyncio code, so I don't have a patch to offer at this point).

----------
components: Library (Lib)
messages: 210679
nosy: glangford, gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio as_completed() thrashes adding and removing callbacks
type: performance
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Feb  9 00:36:18 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 08 Feb 2014 23:36:18 +0000
Subject: [New-bugs-announce] [issue20567] test_ttk_guionly gets 'can't
	invoke "event" command:	application has been destroyed'
	messages from Tk
Message-ID: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za>


New submission from Ned Deily:

Seen with default (3.4.0) framework builds on OS X 10.9 with ActiveTcl 8.5.15.0:

./configure --enable-universalsdk=/ --with-universal-archs=intel --enable-framework=/tmp/t/Library/Frameworks
make && make install
cd /tmp/t
/tmp/t/bin/python3.4 -m test -w -uall
[...]
[343/389/1] test_ttk_guionly
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
[344/389/1] test_ttk_textonly
[...]

When running test_ttk_guionly by itself (or in combination with a few neighboring tests):

  /tmp/t/bin/python3.4 -m test -w -uall test_ttk_guionly

the message is not seen.  I had not seen this behavior prior to somewhere in the 3.4.0 development cycle.

----------
components: Tests, Tkinter
messages: 210704
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ttk_guionly gets 'can't invoke "event" command: application has been destroyed' messages from Tk
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  9 01:08:05 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Feb 2014 00:08:05 +0000
Subject: [New-bugs-announce] [issue20568] Pass --default-install to
	ensurepip in the Windows	installers?
Message-ID: <1391904485.94.0.961786946534.issue20568@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Installing 3.4b3 on Windows to test issue 20053, I was surprised to find that after installation, "pip install <package>" didn't work.

I had forgotten that due to the flat executable namespace on POSIX systems, we only install pip3 and pip3.4 by default - you have to pass "--default-install" to ensurepip to get it to install the unqualified "pip".

For virtual environments, we handle that in the venv module - it passes "--default-pip" when invoking the ensurepip CLI.

Given that Windows uses "python" for both Python 2 & 3 (in contrast to the POSIX python/python3 and python2/python3 conventions), perhaps we should be passing --default-install to ensurepip in the Windows installers as well?

----------
components: Installation
messages: 210705
nosy: dstufft, larry, loewis, ncoghlan, pmoore
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Pass --default-install to ensurepip in the Windows installers?
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  9 03:46:31 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 09 Feb 2014 02:46:31 +0000
Subject: [New-bugs-announce] [issue20569] IDLE : Add clipboard history
	feature
Message-ID: <1391913991.05.0.696306257044.issue20569@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Hi,
this patch adds clipboard history feature to idle.with this,we can retrieve any cut/copied text after the start of idle.
it uses a list to store the messages called _clipboard_history
it creates a dialog window to present a listbox and a paste button to the user.
further ideas for this patch could include making the clipboard history accessible across files(which is not possible in this patch)

----------
components: IDLE
files: python-clipboard-history-enhancement.patch
keywords: patch
messages: 210714
nosy: sahutd
priority: normal
severity: normal
status: open
title: IDLE : Add clipboard history feature
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file34002/python-clipboard-history-enhancement.patch

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

From report at bugs.python.org  Sun Feb  9 05:20:15 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Feb 2014 04:20:15 +0000
Subject: [New-bugs-announce] [issue20570] Bundle pip 0.15.3 in Python 3.4rc2
Message-ID: <1391919615.88.0.398800251792.issue20570@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Larry, we currently have 0.15.2 bundled for 3.4rc1. This is the latest release of pip: http://www.pip-installer.org/en/latest/news.html#changelog

However, there are a few additional fixes that have been merged to the pip 1.5.X maintenance branch that could be included in a 0.15.3 release:

- the workaround to resolve issue 20053 on Windows
- a number of fixes related to wheel downloads
- ensuring hash fragments in URLs are checked properly

It would be good to get those resolved prior to the final 3.4 release.

----------
assignee: larry
messages: 210717
nosy: dstufft, larry, ncoghlan, pmoore
priority: deferred blocker
severity: normal
status: open
title: Bundle pip 0.15.3 in Python 3.4rc2
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  9 10:16:49 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Feb 2014 09:16:49 +0000
Subject: [New-bugs-announce] [issue20571] test_codecs currently failing on
	several Windows	buildbots
Message-ID: <1391937409.03.0.728071863469.issue20571@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The Windows buildbots are currently broken due to a codec issue.  I populated the "nosy" list based on the "unicode" experts from the Experts Index.


http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4040


test_streamreaderwriter (test.test_codecs.WithStmtTest) ... test test_codecs failed
ok

======================================================================
ERROR: test_readline (test.test_codecs.CP65001Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_codecs.py", line 157, in test_readline
    self.assertEqual(readalllines("".join(vw), True), "|".join(vw))
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_codecs.py", line 136, in readalllines
    line = reader.readline(size=size, keepends=keepends)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\codecs.py", line 548, in readline
    data = self.read(readsize, firstline=True)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\codecs.py", line 494, in read
    newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'CP_UTF8' codec can't decode bytes in position 0--1: No mapping for the Unicode character exists in the target code page.

----------
components: Tests
messages: 210732
nosy: benjamin.peterson, ezio.melotti, haypo, larry, loewis, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_codecs currently failing on several Windows buildbots
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  9 11:23:20 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 09 Feb 2014 10:23:20 +0000
Subject: [New-bugs-announce] [issue20572] subprocess.Popen.wait()
	undocumented "endtime" parameter
Message-ID: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

http://hg.python.org/cpython/file/29d9638bf449/Lib/subprocess.py#l1144
This was introduced in revision 6b627e121573  and is currently not documented.
I'm not sure whether this is a documentation issue or "endtime" should have been "_endtime" instead.

----------
messages: 210740
nosy: giampaolo.rodola, rnk
priority: normal
severity: normal
status: open
title: subprocess.Popen.wait() undocumented "endtime" parameter
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  9 11:59:22 2014
From: report at bugs.python.org (Vladimir Rutsky)
Date: Sun, 09 Feb 2014 10:59:22 +0000
Subject: [New-bugs-announce] [issue20573] "built-in repr()" function link on
	the repr module	documentation is incorrect
Message-ID: <1391943562.07.0.0261710580563.issue20573@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

http://docs.python.org/2/library/repr.html page contains several links on built-in function `repr()` (search for "built-in repr()" on page), but links goes to `Repr.repr()` functions of `Repr` module instead of http://docs.python.org/library/functions.html#repr

This is reverse situation to bug described in http://bugs.python.org/issue14489

----------
messages: 210748
nosy: rutsky
priority: normal
severity: normal
status: open
title: "built-in repr()" function link on the repr module documentation is incorrect
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  9 14:18:25 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Feb 2014 13:18:25 +0000
Subject: [New-bugs-announce] [issue20574] Implement incremental decoder for
	cp65001
Message-ID: <1391951905.18.0.272262636483.issue20574@psf.upfronthosting.co.za>


New submission from STINNER Victor:

(Follow up of issue #20538 and #20571.) Attached patch implements incremental decoders for multibyte code pages (on Windows), especially for CP_UTF8 aka "cp65001" in Python.

Code pages 932, 936, 949, 950 and 1361 already have an incremental decoder since:
---
changeset:   38817:549c547700af
branch:      legacy-trunk
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Wed Jun 14 05:21:04 2006 +0000
files:       Doc/api/concrete.tex Include/unicodeobject.h Lib/encodings/mbcs.py Misc/NEWS Modules/_codecsmodule.c Objects/unicodeobject.c
description:
Patch #1455898: Incremental mode for "mbcs" codec.
---

Python currently uses IsDBCSLeadByteEx():
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318667%28v=vs.85%29.aspx

And CharPrevA():
http://msdn.microsoft.com/en-us/library/windows/desktop/ms647471%28v=vs.85%29.aspx

But IsDBCSLeadByteEx() only supports code pages 932, 936, 949, 950 and 1361.

Python supports the code page 65001 (codec "cp65001") since Python 3.3. New tests on incremental decoders were added in Python 3.4: I addedd a skip for cp65001 since it was not supported (#20571). This issue implements the incremental decoder and so removes the skip.

I prefer to wait for Python 3.5 (not rush for add this new feature after 3.4 beta 3). cp65001 is mostly used for output (sys.stdout/sys.stderr) on Windows, not for input.

----------
files: incremental_cp_utf8.patch
keywords: patch
messages: 210759
nosy: haypo, larry, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Implement incremental decoder for cp65001
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34008/incremental_cp_utf8.patch

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

From report at bugs.python.org  Sun Feb  9 14:29:43 2014
From: report at bugs.python.org (Oscar Benjamin)
Date: Sun, 09 Feb 2014 13:29:43 +0000
Subject: [New-bugs-announce] [issue20575] Type handling policy for the
	statistics module
Message-ID: <1391952583.31.0.349942146298.issue20575@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

As of issue20481, the statistics module for Python 3.4 will disallow any mixing of numeric types with the exception of int that can mix with any other type (but only one at a time). My understanding is that this change was not necessarily considered to be a permanent policy but rather a quick fix for Python 3.4 in order to explicitly prevent certain confusing situations arising from mixing Decimal with other stdlib numeric types.

issue20499 has a lot of discussion about different ways to improve accuracy and speed for the mean, variance etc. functions in the statistics module. It's tricky though to come up with a concrete implementation without having a clear specification for how the module should handle different numeric types.

There are several related issues to do with type handling. Should the statistics module
1) Use the same coercion rules as the numeric tower (pep-3141)?
2) Allow Decimal to mix with any types from the numeric tower?
3) Allow non-stdlib types that don't use the numeric tower?
4) Allow any mixing of types at all?
5) Strive to achieve the maximum possible accuracy for every type that it accepts?

I don't personally see much of a use-case for mixing e.g. Decimal and Fraction. I don't think it's unreasonable to require users to choose a numeric type and stick to it. The common cases will almost certainly be either all int or all float so those should be the main targets of any speed optimisation.

If a user is using Fraction/Decimal then they must have gone out of their way to do so and they may as well do so  consistently for all of their data. When choosing to use Fraction you do so because you want perfect accuracy. Mixing those Fractions with floating point types such as float and Decimal doesn't make any sense. Although there is a sense in which Decimals are also exact since they are always exact in their constructor. However I don't think there's any case where the Decimal constructor can be used but the Fraction constructor cannot so this mixing of types is unnecessary.

As with Fraction a user who chooses to use Decimal is going out of their way to do so because of the kind of accuracy guarantees that the type provides. It doesn't make any sense to mix these with floats that are inherently tainted with the wrong kind of rounding error. So mixing Decimal and float doesn't make any sense either.

Note that ordinary arithmetic prohibits the mixing of Decimal with Fraction/float so that on this point the statistics module is essentially maintaining a consistent position with respect to the policy of the Decimal type.

On the other hand ordinary arithmetic allows all of int, float, Fraction and complex and indeed any other type subscribing to the ABCs in the numeric tower to be mixed. As of issue20481 the statistics module does not allow any type mixing except for int:
http://hg.python.org/cpython/rev/5db74cd953ab
Note also that it uses type identity rather than subclass relationships or ABCs so that it is not even possible to mix e.g. float with a float subclass.

The most common case of mixing will almost certainly be int and float which will work. However I doubt that the current policy would be considered to be in keeping with Python's general policy on numeric types and anticipate that there will be a desire to change it in the future. The obvious candidate for a policy is the numeric tower and ABCs of PEP-3141. In that case the statistics module has a partial precedent on which to base its policy. The only tricky part is that Decimal is not part of the numeric tower. So there needs to be a special rule for Decimal such as "it only mixes with int/Integral".

Basing the policy on the numeric tower is attractive but it is worth noting that the std lib types int, float, Fraction and Decimal are the only types that actually implement and register with these ABCs. So it's not much different from saying that those particular types (and subclasses of) are accepted but I think that that is better than the current policy. 

Third party numeric types don't implement the interfaces described in PEP-3141. However one thing that is implemented by every third-party numeric type that I know of is __float__. So if there was to be a desire to support those in the statistics module then the simplest extension of the policy on types is to say that any non-numeric-tower types will simply be coerced with float. This still leaves the issue about how type mixing works there but, again, perhaps the safest option before the need arises is just to say that no type mixing is allowed if any input object is not from the numeric tower.

What do you think?

----------
components: Library (Lib)
messages: 210762
nosy: ncoghlan, oscarbenjamin, skrah, stevenjd, wolma
priority: normal
severity: normal
status: open
title: Type handling policy for the statistics module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Feb  9 14:47:33 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Feb 2014 13:47:33 +0000
Subject: [New-bugs-announce] [issue20576] Default signatures for slots
	should be positional-only
Message-ID: <1391953653.09.0.426145547934.issue20576@psf.upfronthosting.co.za>


New submission from Larry Hastings:

I just realized that the signatures for builtin slot functions (__iadd__, __delitem__, etc) only accept positional-only arguments.  But when I added the signatures by hand to all the slots I didn't mark them as positional-only.  The attached patch remedies that oversight.

----------
assignee: larry
components: Library (Lib)
files: larry.slots.are.positional.only.1.diff
keywords: patch
messages: 210763
nosy: larry, ncoghlan, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Default signatures for slots should be positional-only
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34009/larry.slots.are.positional.only.1.diff

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

From report at bugs.python.org  Sun Feb  9 20:28:36 2014
From: report at bugs.python.org (Tal Einat)
Date: Sun, 09 Feb 2014 19:28:36 +0000
Subject: [New-bugs-announce] [issue20577] IDLE: Remove FormatParagraph's
	width setting from config	dialog
Message-ID: <1391974116.91.0.4701294104.issue20577@psf.upfronthosting.co.za>


New submission from Tal Einat:

Following up issue3068, this is a separate patch which moves the "paragraph reformat width" setting from the "general" tab in IDLE's config dialog to the relevant place in the extensions configuration.

----------
components: IDLE
files: taleinat.20140209.IDLE__Remove_format_paragraph_width_from_config_dialog.patch
keywords: patch
messages: 210779
nosy: taleinat
priority: normal
severity: normal
status: open
title: IDLE: Remove FormatParagraph's width setting from config dialog
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34013/taleinat.20140209.IDLE__Remove_format_paragraph_width_from_config_dialog.patch

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

From report at bugs.python.org  Mon Feb 10 01:13:49 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 10 Feb 2014 00:13:49 +0000
Subject: [New-bugs-announce] [issue20578] BufferedIOBase.readinto1 is missing
Message-ID: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

It would be nice to have a readinto1 method to complement the existing read, readinto, and read1 methods of io.BufferedIOBase.

----------
components: Library (Lib)
messages: 210794
nosy: nikratio
priority: normal
severity: normal
status: open
title: BufferedIOBase.readinto1 is missing
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb 10 11:10:42 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Feb 2014 10:10:42 +0000
Subject: [New-bugs-announce] [issue20579] OS X IDLE <option-> keyboard
	accelerators fail or	misbehave with Cocoa Tk
Message-ID: <1392027042.62.0.0419013450349.issue20579@psf.upfronthosting.co.za>


New submission from Ned Deily:

On OS X, most of the IDLE command keyboard accelerators that use the OS X <Option> modifier key do not work correctly with Cocoa Tk, the current native version of Tk 8.5 and 8.6 used on OS X 10.6 and later releases (and with the 64-/32-bit OS X binary installers from python.org).  These include the event bindings found in config-extensions.def:
    format-paragraph=<Option-Key-q>
    expand-word=<Option-Key-slash>
    zoom-height=<Option-Key-0>
    check-module=<Option-Key-x>
and in config-keys.def (IDLE Classic OSX set): 
    save-copy-of-window-as-file = <Option-Command-Key-s>

These all work (mostly) correctly with the older Carbon Tk, the original 32-bit-only native Tk for OS X, still shipped as Tk 8.4 in current systems (and still used with the 32-bit-only python.org binary installers), which was the Tk in use when native support for IDLE on OS X was originally implemented.

Modifier key support in Tk has long been problematic, with significant differences among platforms and even among the three implementations of Tk in use on OS X (besides the Cocoa and Carbon versions, there is an older OS X X11 version that differs in some respects from other Unix X11 versions).  Some of these differences have their origins lost in the mists of time or were due to no-longer relevant operating systems or hardware differences.  On the Tcl/Tk wiki, there is a page that attempts to document the differences based on empirical evidence (http://wiki.tcl.tk/28331).  Of particular relevance to IDLE is that the OS X Tk implementations do not use Alt binding modifiers since there was historically no Alt key on Mac keyboards.  In its place the Option key and binding modifier is used.  Likewise, the Command/Apple/? key is used in place of the Windows key and is a binding modifier.  To that end, on OS X IDLE converts <Alt-> bindings and accelerators to <Opt-> ones, either during the build of IDLE or at run-time.  As noted above, that works pretty well for the older, now obsolete Carbon Tk.  However, it doesn't with the newer, current Cocoa Tk.  I believe this is primarily because Cocoa Tk supports the more sophisticated Cocoa text input system which maps most <Opt-> key combinations either directly to extended characters (like opt-s -> ? on US keyboard input methods) or as the first key of a two key composing sequence (e.g. opt-u a -> ?).  Cocoa Tk applications do not see these keys as separate events, only the final composed character.  Thus, the config-extension bindings above cause various characters to be input as text rather than triggering menu options.

The "save-copy-of-window-as-file" binding behaves somewhat differently: when typing Opt-Cmd-s, two instances of the Save File popup window appear with Cocoa Tk.  That erroneous behavior can be fixed by the straightforward change of the binding to <Control-Command-Key-s>.  Similar remapping to unused key bindings should be made for the extension bindings and documented accordingly so that all keyboard accelerators shown in IDLE menus are actually usable.

(For completeness sake, I'll note that the situation with OS X X11-based Tk in conjunction with the OS X XQuartz X server is much more bizarre.  Behavior differs depending on server preferences: either the roles of the Option and Command key modifiers are reversed or the Option modifier is not usable in Tk at all other than as an extended character set composing key.  The Tk wiki page documents much of this.  It isn't clear how a Tk application could accommodate all these different behaviors automatically so the current strategy of not trying to seems prudent.)

----------
components: IDLE
messages: 210815
nosy: ned.deily
priority: normal
severity: normal
status: open
title: OS X IDLE <option-> keyboard accelerators fail or misbehave with Cocoa Tk
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 10 11:19:11 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Feb 2014 10:19:11 +0000
Subject: [New-bugs-announce] [issue20580] IDLE should support
	platform-specific default config	defaults
Message-ID: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za>


New submission from Ned Deily:

There is a need for IDLE to provide different default settings depending on which platform it is running, e.g. Windows, OS X, or other UNIX.  That need need has been most acute for OS X where, for various reasons, tailoring of default key bindings for IDLE commands and extensions is either necessary or desirable to conform to platform user interface guidlines or, more importantly, platform-specific Tk behavior.  For OS X, that customization is provided in part by brute force editing of the config-main.def and config-extensions.def in Mac/Makefile target install_IDLE which is run during installation of framework builds.  While that works for that case, it is brittle and opaque and does not help for non-framework OS X installs or when running from a build directory.  And it doesn't help for other platforms.  Other OS X customization is done at run time to convert any <Alt-Key-> events to <Option-Key-> events, since none of the OS X Tk implementations support <Alt-Key-> events (see Issue20579).  It would be better to provide some way to specify these various conditional settings directly in config-main.def and config-extensions.def themselves, perhaps with platform-specific sections in the files that would be merged with and override the current general sections.  For example, in config-main.def, a possible implementation might be:

[Keys]
default= 1
name= IDLE Classic Windows

[Keys-OSX]
name= IDLE Classic OSX

[Keys-Unix]
name= IDLE Classic Unix

This might also be used to support different options for different versions of IDLE since today all versions by default share the same user configuration files.

[Keys]
...

[Keys-2.7]
...

[Keys-3]
...

----------
components: IDLE
messages: 210816
nosy: ned.deily
priority: normal
severity: normal
status: open
title: IDLE should support platform-specific default config defaults
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 10 13:13:22 2014
From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=A9mie_Detrey?=)
Date: Mon, 10 Feb 2014 12:13:22 +0000
Subject: [New-bugs-announce] [issue20581] Incorrect behaviour of super() in
	a metaclass-created	subclass
Message-ID: <1392034402.21.0.850574829042.issue20581@psf.upfronthosting.co.za>


New submission from J?r?mie Detrey:

Dear all,

I've been noticing a strange (and probably incorrect) behaviour of the super() function when using a metaclass in order to automatically replace a class declaration by a subclass of itself.

In the attached test case, the function `wrap' is used to create such a subclass: given the original class `cls' in input, it declares and returns the subclass `Wrapper(cls)' whose constructor calls the original one from `cls':

    >>> def wrap(cls):
    ...     print("In wrap() for class %s" % cls.__name__)
    ...     name = cls.__name__
    ...     class Wrapper(cls):
    ...         def __init__(self, *args, **kwargs):
    ...             print("In Wrapper(%s).__init__()" % name)
    ...             super().__init__(*args, **kwargs)
    ...     return Wrapper
    ... 

When `wrap' is used as a decorator (as for class `B' in the test case), the correct behaviour is observed: the identifier `B' now represents the `Wrapper(B)' subclass, the MRO is as expected (`Wrapper', then the original class `B', then `object'), and instantiating a `B' object correctly calls the constructors in the right order:

    >>> @wrap
    ... class B:
    ...     def __init__(self):
    ...         print("In B.__init__()")
    ...         super().__init__()
    ... 
    In wrap() for class B
    >>> B.mro()
    [<class '__main__.wrap.<locals>.Wrapper'>, <class '__main__.B'>, <class 'object'>]
    >>> B()
    In Wrapper(B).__init__()
    In B.__init__()
    <__main__.wrap.<locals>.Wrapper object at 0x7fa8c6adb410>

Now, let us automatically call the `wrap' function from a metaclass' `__new__' method upon declaration of the class (such as class `A' in the test case):

    >>> class Metaclass(type):
    ...     def __new__(meta, name, bases, namespace):
    ...         print("In Metaclass.__new__() for class %s" % name)
    ...         cls = super().__new__(meta, name, bases, namespace)
    ...         return cls if cls.__name__ == 'Wrapper' else wrap(cls)
    ... 
    >>> class A(metaclass = Metaclass):
    ...     def __init__(self):
    ...         print("In A.__init__()")
    ...         super().__init__()
    ... 
    In Metaclass.__new__() for class A
    In wrap() for class A
    In Metaclass.__new__() for class Wrapper

The MRO still looks correct:

    >>> A.mro()
    [<class '__main__.wrap.<locals>.Wrapper'>, <class '__main__.A'>, <class 'object'>]

However, instantiating the class `A' creates an infinite recursion in the original constructor `A.__init__', just as if the `super()' call had somehow gotten confused between the original class declared as `A' and its subclass, which is now referred to by the identifier `A':

    >>> A()
    In Wrapper(A).__init__()
    In A.__init__()
    In A.__init__()
    In A.__init__()
    In A.__init__()
    [...]

Maybe I'm doing something wrong somewhere, but it seems to me that the behaviour should at least be the same for classes `A' and `B'.

Kind regards,
J?r?mie.

----------
components: Interpreter Core
files: bug.py
messages: 210829
nosy: jdetrey
priority: normal
severity: normal
status: open
title: Incorrect behaviour of super() in a metaclass-created subclass
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34020/bug.py

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

From report at bugs.python.org  Mon Feb 10 15:24:25 2014
From: report at bugs.python.org (Roy Smith)
Date: Mon, 10 Feb 2014 14:24:25 +0000
Subject: [New-bugs-announce] [issue20582] socket.getnameinfo() does not
	document flags
Message-ID: <1392042265.22.0.885252016144.issue20582@psf.upfronthosting.co.za>


New submission from Roy Smith:

http://docs.python.org/2/library/socket.html

The description for getnameinfo() says, "... Depending on the settings of flags, the result can contain a fully-qualified domain name or numeric address representation in host.", but does not say what to pass for flags to get those behaviors.

----------
assignee: docs at python
components: Documentation
messages: 210838
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: socket.getnameinfo() does not document flags
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 10 15:46:48 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Feb 2014 14:46:48 +0000
Subject: [New-bugs-announce] [issue20583] Hide underscored parameters
Message-ID: <1392043608.85.0.259455766177.issue20583@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Underscored parameters of functions sometimes are used for different purposes. For example see random.Random.randrange(), subprocess.Popen.__del__() or codecs.CodecInfo.__new__(). These parameters are not a part of public API and should be excluded from help() or pydoc output.

----------
components: Library (Lib)
messages: 210842
nosy: ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Hide underscored parameters
type: enhancement

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

From report at bugs.python.org  Mon Feb 10 18:36:38 2014
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Mon, 10 Feb 2014 17:36:38 +0000
Subject: [New-bugs-announce] [issue20584] On FreeBSD,
	signal.NSIG is smaller than biggest signal value
Message-ID: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za>


New submission from Jan-Philip Gehrcke:

On FreeBSD, signal.NSIG is smaller than what the documentation promises: "One more than the number of the highest signal number".

On Linux, the highest numerical signal value is smaller/equal signal.NSIG (expected behavior):

>>> import signal
>>> signals = [s for s in dir(signal) if s.startswith("SIG")]
>>> max([(getattr(signal, s), s) for s in signals])
(64, 'SIGRTMAX')
>>> signal.NSIG
65

On FreeBSD (since version 7, when SIGRTMIN/MAX have been introduced), Python's signal.NSIG is either 32 (if defined by the system, depending on __BSD_VISIBLE, see http://svnweb.freebsd.org/base/head/sys/sys/signal.h?revision=233519&view=markup#l331) or 64 (if chosen by signalmodule.c as a fallback). In any case, on FreeBSD the numerical values of SIGRTMIN/MAX are 65 and 126 and therefore both greater than Python's signal.NSIG:
http://svnweb.freebsd.org/base/head/sys/sys/signal.h?revision=233519&view=markup#l117

Consequently, Python's signal module exposes a number NSIG which is not 'true'. Two disadvantages:

- signal.NSIG is just not meaningful on FreeBSD. It is part of the signal module's public interface, and should do what its documentation says: "One more than the number of the highest signal number".

- this might lead to unexpected behavior when for instance calling signal.signal(signal.SIGRTMAX, signal.SIG_DFL). This works on Linux, but fails with a ValueError on FreeBSD: raised directly by signalmodule.c, because sig_num >= NSIG, i.e. sig_num seemingly is an invalid signal number, although it is not (https://github.com/python/cpython/blob/3.3/Modules/signalmodule.c#L323). This is the reason why I became aware of this topic.


I see three arguments here:

- if the system does not provide NSIG via signal.h and Python's signalvalue makes the wrong guess (i.e. fallback to 64), then signalmodule.c would be to blame.

- if the system provides NSIG via signal.h and this is not the true maximum, then one could say that Python is not to blame.

- on the other hand, signalmodule.c is aware of all signals that it actively checked for and therefore could derive "One more than the number of the highest signal number" on its own via something in the lines of max(signal_values)+1.

Regarding the latter point: if Python misses to check for a valid signal on a certain platform, then this actively derived NSIG value would not be entirely correct, either, seen from the platform's perspective. But the signal module would then at least be consistent with itself.

In case of FreeBSD, I am actually not sure if signal.NSIG *is* provided by the system or determined by the fallback method in signalmodule.c (I can't get my hands on a FreeBSD machine at the moment).


What do you think?

Btw, parts of this have already been mentioned here: http://bugs.python.org/issue12060

----------
components: Library (Lib)
messages: 210854
nosy: jgehrcke, neologix, sdaoden
priority: normal
severity: normal
status: open
title: On FreeBSD, signal.NSIG is smaller than biggest signal value
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 10 19:46:03 2014
From: report at bugs.python.org (Andrew Gross)
Date: Mon, 10 Feb 2014 18:46:03 +0000
Subject: [New-bugs-announce] [issue20585] urllib2 unrelease KQUEUE on Mac
	OSX 10.9+
Message-ID: <1392057963.63.0.832878598113.issue20585@psf.upfronthosting.co.za>


New submission from Andrew Gross:

In the latest OSX, 10.9, it looks like there have been some security changes related to inheriting file descriptors from parent to child processes.  While in the past it would allow you to inherit the parents open FDs, now it will kill the process. 

It looks like urllib2 does not properly unsubscribe from the KQUEUE after opening a remote connection, causing the process to be killed if you try use "evecv" style commands, or fork.

Simple Reproduction:
import urllib2
request = urllib2.urlopen('http://www.python.org')
response = request.read()
request.close()
os.execvp('ssh', ['ssh', 'user at 1.2.3.4'])
# Killed: 9

I have attached the diagnostic crash report from OSX, appended to the end is a snippet from `lsof` showing the open KQUEUE file descriptor.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: urllib2.crash
messages: 210860
nosy: Andrew.Gross, ronaldoussoren
priority: normal
severity: normal
status: open
title: urllib2 unrelease KQUEUE on Mac OSX 10.9+
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file34024/urllib2.crash

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

From report at bugs.python.org  Mon Feb 10 21:28:26 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Feb 2014 20:28:26 +0000
Subject: [New-bugs-announce] [issue20586] Argument Clinic: functions with
	valid sig but no	docstring have no __text_signature__
Message-ID: <1392064106.25.0.899710933953.issue20586@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Builtins with a valid signature embedded in the docstring, but with no other docstring content are not picked up by the __text_signature__ getter because the docstring ends with ")\n--" rather than ")\n--\n\n".  The attached patch adjusts clinic.CLanguage.docstring_for_c_string to make sure that the rendered docstring ends in "--\n\n" rather than "--".

The result is a correct __text_signature__ and a __doc__ of ''.

----------
components: Demos and Tools
files: clinic_sig_no_docstring.diff
keywords: patch
messages: 210864
nosy: larry, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic: functions with valid sig but no docstring have no __text_signature__
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34025/clinic_sig_no_docstring.diff

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

From report at bugs.python.org  Mon Feb 10 22:52:57 2014
From: report at bugs.python.org (Kathryn M Kowalski)
Date: Mon, 10 Feb 2014 21:52:57 +0000
Subject: [New-bugs-announce] [issue20587] sqlite3 converter not being called
Message-ID: <1392069177.84.0.794324739968.issue20587@psf.upfronthosting.co.za>


New submission from Kathryn M Kowalski:

I have a timestamp converter that works on 2.5 but doesn't on 2.7.2 (ActiveState 2.7.2.5  Attached is some pared down test code and output from a machine running 2.5 and one running 2.7.  At one point I even put print statements in the converter - they show up under 2.5 not 2.7.  I don't think it is getting called.

----------
components: Windows
files: check_with_output.txt
messages: 210873
nosy: kmk
priority: normal
severity: normal
status: open
title: sqlite3 converter not being called
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34026/check_with_output.txt

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

From report at bugs.python.org  Tue Feb 11 02:33:12 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 11 Feb 2014 01:33:12 +0000
Subject: [New-bugs-announce] [issue20588] Code generated by asdl_c.py not
	C89-compliant
Message-ID: <1392082392.14.0.904741154725.issue20588@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

The code within Python/Python-ast.c does not currently conform to C89 standard.  Within the function PyAST_obj2mod(), the array 'req_type' is initialized using runtime values, which is not allowed by the standard, causing building to fail on a C89 compiler.

This code is automatically generated by asdl_c.py.  I've attached a patch which corrects the problem.  Python/Python-ast.c will need to be regenerated if this patch is accepted.

----------
components: Interpreter Core
files: asdl_c.py.trunk.patch
keywords: patch
messages: 210894
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Code generated by asdl_c.py not C89-compliant
type: compile error
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34032/asdl_c.py.trunk.patch

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

From report at bugs.python.org  Tue Feb 11 04:25:09 2014
From: report at bugs.python.org (James Skinner)
Date: Tue, 11 Feb 2014 03:25:09 +0000
Subject: [New-bugs-announce] [issue20589] pathlib.owner() and
	pathlib.group() raise ImportError on	Windows
Message-ID: <1392089109.39.0.748049843739.issue20589@psf.upfronthosting.co.za>


New submission from James Skinner:

When using the Path class in Lib/pathlib.py under Windows, calling p.owner() or p.group() fails with an ImportError due to importing the pwd and grp modules respectively, as neither of those exist. The documentation doesn't mention this behaviour.

The precedent for handling this is set by os.stat(), which simply sets the st_uid and st_gid fields to 0 under Windows, and this behaviour underlies p.stat(). Therefore both p.owner() and p.group() should return 0 under Windows as well.

>>> p = Path("foo.py")
>>> p.stat()
os.stat_result(st_mode=33206, st_ino=434125405408, st_dev=318314347, st_nlink=1, st_uid=0, st_gid=0, st_size=40, st_atime=1392076800, st_mtime=1392084010, st_ctime=1392083969)
>>> p.owner()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Python34\Lib\pathlib.py", line 1051, in owner
    import pwd
ImportError: No module named 'pwd'
>>> p.group()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Python34\Lib\pathlib.py", line 1058, in group
    import grp
ImportError: No module named 'grp'

After the patch, the behaviour is:

>>> p = Path("foo.py")
>>> p.stat()
os.stat_result(st_mode=33206, st_ino=434125405408, st_dev=318314347, st_nlink=1, st_uid=0, st_gid=0, st_size=40, st_atime=1392076800, st_mtime=1392084010, st_ctime=1392083969)
>>> p.owner()
0
>>> p.group()
0
>>> p.owner() == p.stat().st_uid
True
>>> p.group() == p.stat().st_gid
True

The supplied patch just creates overriden versions of owner() and group() that return 0 under the WindowsPath class.

----------
components: Library (Lib)
files: win_owner_group_error_fix.patch
keywords: patch
messages: 210896
nosy: spiralx
priority: normal
severity: normal
status: open
title: pathlib.owner() and pathlib.group() raise ImportError on Windows
versions: Python 3.4
Added file: http://bugs.python.org/file34033/win_owner_group_error_fix.patch

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

From report at bugs.python.org  Tue Feb 11 04:31:01 2014
From: report at bugs.python.org (Alfonso Andalon Jr.)
Date: Tue, 11 Feb 2014 03:31:01 +0000
Subject: [New-bugs-announce] [issue20590] Download Talkray...
Message-ID: <CAOyy2Nvchs2tgXGhQ2m2PWLvURDr9Wa_rzhRSnSM1sjHpnnasg@mail.gmail.com>


New submission from Alfonso Andalon Jr.:

Download this http://talkray.com/dl/ee

----------
messages: 210897
nosy: Alfonso.Andalon.Jr.
priority: normal
severity: normal
status: open
title: Download Talkray...

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

From report at bugs.python.org  Tue Feb 11 11:55:56 2014
From: report at bugs.python.org (DhilipSiva)
Date: Tue, 11 Feb 2014 10:55:56 +0000
Subject: [New-bugs-announce] [issue20591] Let "braces" be a constant
Message-ID: <1392116156.79.0.361572324225.issue20591@psf.upfronthosting.co.za>


New submission from DhilipSiva:

Make the "braces" in the "Python/future.c" as a constant declared in "Include/compile.h"

----------
files: constant_braces.patch
keywords: patch
messages: 210919
nosy: dhilipsiva
priority: normal
severity: normal
status: open
title: Let "braces" be a constant
type: enhancement
Added file: http://bugs.python.org/file34036/constant_braces.patch

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

From report at bugs.python.org  Tue Feb 11 12:31:09 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2014 11:31:09 +0000
Subject: [New-bugs-announce] [issue20592] test_frozen fails on 3.4.0rc1,
	windows
Message-ID: <1392118269.82.0.725211504067.issue20592@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Installed 3.4.0c1:
C:\Programs\Python34.32>python -m test test_frozen
[1/1] test_frozen
test test_frozen failed -- Traceback (most recent call last):
  File "C:\Programs\Python34.32\lib\test\test_frozen.py", line 23, in test_frozen
    self.assertEqual(set(dir(__hello__)), expect)
AssertionError: Items in the first set but not the second:
'__spec__'
Items in the second set but not the first:
'__cached__'

This was noted in #18864 by Eric Snow about 70 days ago in msg203340 but seems to have been lost. I think it needs a separate issue so it does not get lost and so the failing test might temporarily be disabled while there is a corresponding open issue.

On freshly compiled 3.4.0c1+, I have a separate problem:

F:\Python\dev>4\py34\pcbuild\python_d.exe -m test test_frozen
[1/1] test_frozen
test test_frozen crashed -- Traceback (most recent call last):
  File "F:\Python\dev\4\py34\lib\test\regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "F:\Python\dev\4\py34\lib\importlib\__init__.py", line 104, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2230, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2213, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2200, in _find_and_load_unlocked
ImportError: No module named 'test.test_frozen'

Indeed, it is not there and hg does not report anything amiss.

----------
components: Interpreter Core, Tests
messages: 210921
nosy: brett.cannon, eric.snow, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: test_frozen fails on 3.4.0rc1, windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 12:42:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2014 11:42:33 +0000
Subject: [New-bugs-announce] [issue20593] test_importhooks fails on 3.4
Message-ID: <1392118953.81.0.0509761659488.issue20593@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

installed 3.4.0c1:

C:\Programs\Python34.32>python -m test test_importhooks
[1/1] test_importhooks
test test_importhooks failed -- Traceback (most recent call last):
  File "C:\Programs\Python34.32\lib\test\test_importhooks.py", line 241, in testImpWrapper
    m = __import__(mname, globals(), locals(), ["__dummy__"])
ImportError: spec missing loader

3.3.4 is ok.

----------
components: Library (Lib), Tests
messages: 210924
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importhooks fails on 3.4
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 13:20:08 2014
From: report at bugs.python.org (ncopa)
Date: Tue, 11 Feb 2014 12:20:08 +0000
Subject: [New-bugs-announce] [issue20594] fail to compile posixmodule due to
	name clash with	posix_close
Message-ID: <1392121208.86.0.742222636486.issue20594@psf.upfronthosting.co.za>


New submission from ncopa:

This happens when building with musl libc:

./Modules/posixmodule.c:7849:1: error: conflicting types for 'posix_close'
 posix_close(PyObject *self, PyObject *args)
 ^
In file included from Include/Python.h:36:0,
                 from ./Modules/posixmodule.c:28:
/usr/include/unistd.h:38:5: note: previous declaration of 'posix_close' was here
 int posix_close(int, int);
     ^
Makefile:1511: recipe for target 'Modules/posixmodule.o' failed
make: *** [Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs....


Apparently 'posix_close' has made it to the POSIX standard so that name should be avoided in python's posix module.c.
https://sourceware.org/ml/glibc-bugs/2013-12/msg00099.html

Fix is trivial:
--- ./Modules/posixmodule.c.orig
+++ ./Modules/posixmodule.c
@@ -7846,7 +7846,7 @@
 Close a file descriptor (for low level IO).");
 
 static PyObject *
-posix_close(PyObject *self, PyObject *args)
+posix_closex(PyObject *self, PyObject *args)
 {
     int fd, res;
     if (!PyArg_ParseTuple(args, "i:close", &fd))
@@ -11262,7 +11262,7 @@
     {"open",            (PyCFunction)posix_open,\
                         METH_VARARGS | METH_KEYWORDS,
                         posix_open__doc__},
-    {"close",           posix_close, METH_VARARGS, posix_close__doc__},
+    {"close",           posix_closex, METH_VARARGS, posix_close__doc__},
     {"closerange",      posix_closerange, METH_VARARGS, posix_closerange__doc__},
     {"device_encoding", device_encoding, METH_VARARGS, device_encoding__doc__},
     {"dup",             posix_dup, METH_VARARGS, posix_dup__doc__},

----------
components: Build
messages: 210930
nosy: ncopa
priority: normal
severity: normal
status: open
title: fail to compile posixmodule due to name clash with posix_close
type: compile error
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Feb 11 13:40:10 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 11 Feb 2014 12:40:10 +0000
Subject: [New-bugs-announce] [issue20595] C89 compliance issue in
	Python/getargs.c
Message-ID: <1392122410.75.0.259128466993.issue20595@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

The file Python/getargs.c currently uses an array initializer with a runtime variable, causing compile errors on strict C89 compilers.  The variables named freelist in vgetargs1() and vgetargskeywords() both use non-constant initializers.  The attached patch should correct the issue for the default branch.

----------
components: Interpreter Core
files: getargs.c.default.patch
keywords: patch
messages: 210933
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: C89 compliance issue in Python/getargs.c
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file34037/getargs.c.default.patch

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

From report at bugs.python.org  Tue Feb 11 14:03:36 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 11 Feb 2014 13:03:36 +0000
Subject: [New-bugs-announce] [issue20596] Support for alternate wcstok
	syntax for Windows compilers
Message-ID: <1392123816.37.0.457546149708.issue20596@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

In two locations, the current interpreter code makes some assumptions concerning the syntax of the wcstok() function based solely on the operating system (Windows, in this case).  Compilers other than MSVC may (and do) provide alternative wcstok() syntaxes.

The first change in the attached patch changes a preprocessor check in Modules/main.c to determine if we're compiling with MSVC rather than just whether we're compiling with Windows.  If so, it uses Windows's basic two-argument wcstok() function as it always has.  If the compiler isn't MSVC, the code will now default to the Unix method of converting to ASCII first before tokenizing.  This change is more sensible because the code should really be checking for the compiler's wcstok() capabilities, not what operating system Python is being compiled for.

The second change in the attached patch adds some new code to PC/getpathp.c to support alternate wcstok() syntax in the find_env_config_value() function.  A preprocessor check will now determine if we're compiling for MSVC and, if so, default to the three-argument wcstok_s() function.  If the almost-compatible Open Watcom compiler is detected, a three-argument, POSIX-like wcstok() function is used.  If another compiler is detected, the original two-argument wcstok() is assumed to be adequate.

----------
components: Interpreter Core, Windows
files: wcstok.default.patch
keywords: patch
messages: 210935
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Support for alternate wcstok syntax for Windows compilers
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file34038/wcstok.default.patch

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

From report at bugs.python.org  Tue Feb 11 14:11:15 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 11 Feb 2014 13:11:15 +0000
Subject: [New-bugs-announce] [issue20597] PATH_MAX already defined on some
	Windows compilers
Message-ID: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

On some Windows compilers, the constant PATH_MAX may already be defined, which will cause compile errors on non-MSVC compilers (notably Open Watcom and MinGW).  Rather than assume it is not available and define it in all "#ifdef MS_WINDOWS" cases, it should first be checked for existence.

This patch adds said check to Modules/main.c and Python/pythonrun.c.  This patch should not affect any existing platforms (including MSVC builds).

----------
components: Interpreter Core, Windows
files: path_max.default.patch
keywords: patch
messages: 210936
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: PATH_MAX already defined on some Windows compilers
type: compile error
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34039/path_max.default.patch

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

From report at bugs.python.org  Tue Feb 11 16:28:25 2014
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 11 Feb 2014 15:28:25 +0000
Subject: [New-bugs-announce] [issue20598] argparse docs: '7'.split() is
	confusing magic
Message-ID: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

I think the docs of argparse still contain confusing magic:

parser.parse_args('7'.split())


You know what it does and I know it. But a lot of people new to Python, don't understand what this should be.

Please use:

parser.parse_args(['7'])


Close this ticket, if you don't care for people new to Python.

----------
assignee: docs at python
components: Documentation
messages: 210950
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: argparse docs: '7'.split() is confusing magic
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 11 17:37:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2014 16:37:29 +0000
Subject: [New-bugs-announce] [issue20599] test_cleanup() of test_builtin
	failed
Message-ID: <1392136649.31.0.71011921705.issue20599@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

======================================================================
FAIL: test_cleanup (test.test_builtin.ShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_builtin.py", line 1621, in test_cleanup
    self.assertEqual(["before", "after"], out.decode().splitlines())
AssertionError: Lists differ: ['before', 'after'] != []

First list contains 2 additional elements.
First extra element 0:
before

- ['before', 'after']
+ []

----------
messages: 210965
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_cleanup() of test_builtin failed
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 17:39:41 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2014 16:39:41 +0000
Subject: [New-bugs-announce] [issue20600]
	test_create_server_ssl_verify_failed() failure on "PPC64	AIX
	3.x" buildbot
Message-ID: <1392136781.96.0.859159765022.issue20600@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1694/steps/test/logs/stdio

======================================================================
FAIL: test_create_server_ssl_verify_failed (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py", line 692, in test_create_server_ssl_verify_failed
    self.loop.run_until_complete(f_c)
AssertionError: "certificate verify failed " does not match "A failure in the SSL library occurred (_ssl.c:598)"

======================================================================
FAIL: test_create_server_ssl_verify_failed (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py", line 692, in test_create_server_ssl_verify_failed
    self.loop.run_until_complete(f_c)
AssertionError: "certificate verify failed " does not match "A failure in the SSL library occurred (_ssl.c:598)"

----------
messages: 210967
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_create_server_ssl_verify_failed() failure on "PPC64 AIX 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 18:34:36 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 11 Feb 2014 17:34:36 +0000
Subject: [New-bugs-announce] [issue20601] tracing and tests that raise an
	exception in a SIGALRM	handler
Message-ID: <1392140076.31.0.721324007148.issue20601@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

After an alarm handler raises an exception while a tracing function is being invoked and when this exception is not caught by the tracing function, the call_trampoline() function in sysmodule.c returns NULL and its caller, trace_trampoline(), removes the trace function.  Therefore, tests that raise an exception in an alarm handler should use the support.no_tracing decorator as it is done in test_io.py at check_reentrant_write().

Patch attached.

----------
components: Library (Lib)
files: no_tracing.diff
keywords: patch
messages: 210984
nosy: xdegaye
priority: normal
severity: normal
status: open
title: tracing and tests that raise an exception in a SIGALRM handler
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34046/no_tracing.diff

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

From report at bugs.python.org  Tue Feb 11 20:22:01 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Feb 2014 19:22:01 +0000
Subject: [New-bugs-announce] [issue20602] sys.flags and sys.float_info
	disappear at shutdown
Message-ID: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

For some reason they are wiped to fix so-called reference leaks:
http://hg.python.org/cpython/rev/9639a73afa47/

This changeset is one of the culprits of the problems in issue19255.

----------
components: Interpreter Core
messages: 211001
nosy: christian.heimes, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sys.flags and sys.float_info disappear at shutdown
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 20:25:40 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Feb 2014 19:25:40 +0000
Subject: [New-bugs-announce] [issue20603] sys.path disappears at shutdown
Message-ID: <1392146740.92.0.319556816065.issue20603@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Original changeset in 1998:
http://hg.python.org/cpython/rev/185c1d47ce7a

Stated reason is to prevent new imports. Well, mission accomplished: this is one of the reasons for the problems in issue19255 :)

----------
components: Interpreter Core
messages: 211002
nosy: brett.cannon, eric.snow, ncoghlan, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sys.path disappears at shutdown
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 11 22:40:35 2014
From: report at bugs.python.org (Franck Michea)
Date: Tue, 11 Feb 2014 21:40:35 +0000
Subject: [New-bugs-announce] [issue20604] Missing invalid mode in error
	message of socket.makefile.
Message-ID: <1392154835.15.0.731068129173.issue20604@psf.upfronthosting.co.za>


New submission from Franck Michea:

Hi! Noticed that the wrong mode was missing from the error message of socket.makefile. Nothing important, but this patch fixes the thing anyway, if you want it.

----------
components: Library (Lib)
files: missing_mode_in_error.patch
keywords: patch
messages: 211026
nosy: kushou
priority: normal
severity: normal
status: open
title: Missing invalid mode in error message of socket.makefile.
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34049/missing_mode_in_error.patch

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

From report at bugs.python.org  Wed Feb 12 03:10:17 2014
From: report at bugs.python.org (Geoffrey Spear)
Date: Wed, 12 Feb 2014 02:10:17 +0000
Subject: [New-bugs-announce] [issue20605] test_socket (testGetaddrinfo)
	failing on OS X 10.6.8	(32-bit)
Message-ID: <1392171017.75.0.955682471073.issue20605@psf.upfronthosting.co.za>


New submission from Geoffrey Spear:

On OS X 10.6.8, I'm getting the following result for test_socket:

[cpython] % ./python.exe -m test test_socket
[1/1] test_socket
/Users/geoff/Documents/programming/cpython/Lib/test/test_socket.py:1721: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg(bufsize, *args)
/Users/geoff/Documents/programming/cpython/Lib/test/test_socket.py:1812: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg_into([buf], *args)
test test_socket failed -- Traceback (most recent call last):
  File "/Users/geoff/Documents/programming/cpython/Lib/test/test_socket.py", line 1169, in testGetaddrinfo
    socket.getaddrinfo("localhost", None, 0, 0, 0, socket.AI_NUMERICSERV)
socket.gaierror: [Errno 8] nodename nor servname provided, or not known

1 test failed:
    test_socket


According to the OS X manpage for getaddrinfo(3), (and RFC 3493) this error is the expected behavior for a POSIX socket implementation:

                    AI_NUMERICSERV  If the AI_NUMERICSERV bit is set, then a
                                    non-null servname string supplied shall be
                                    a numeric port string.  Otherwise, an
                                    EAI_NONAME error shall be returned.  This
                                    bit shall prevent any type of name resolu-
                                    tion service (for example, NIS+) from
                                    being invoked.

(servname is the 2nd argument to getaddrinfo(), where the test passes None. EAI_NONAME is Errno 8.)

Confirmed on 2.7.6, 3.3 and current HEAD of 3.4; the offending test code didn't exist in 3.2 and earlier.

----------
components: Library (Lib), Tests
messages: 211053
nosy: geoffreyspear
priority: normal
severity: normal
status: open
title: test_socket (testGetaddrinfo) failing on OS X 10.6.8 (32-bit)
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 12 11:40:34 2014
From: report at bugs.python.org (silentbat)
Date: Wed, 12 Feb 2014 10:40:34 +0000
Subject: [New-bugs-announce] [issue20606] Operator Documentation Example
	doesn't work
Message-ID: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za>


New submission from silentbat:

In the Docs for Python3.3
http://docs.python.org/3.3/library/operator.html#operator.__setitem__

the following example doesn't work.

----------
assignee: docs at python
components: Documentation
messages: 211079
nosy: docs at python, silent.bat
priority: normal
severity: normal
status: open
title: Operator Documentation Example doesn't work
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 12 14:00:07 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 12 Feb 2014 13:00:07 +0000
Subject: [New-bugs-announce] [issue20607] multiprocessing cx_Freeze windows
	GUI bug (& easy fixes)
Message-ID: <1392210007.55.0.703344543531.issue20607@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I have a Python Windows GUI application (using PySide) that uses multiprocessing.

When I freeze the application I get error messages, in particular that mulitprocessing cannot call flush on a null object.

ISTM That in a Windows GUI application, sys.stdout and sys.stderr may well be None since there is no attached console.

So, I added guards to accesses to sys.stdout and sys.stderr and the problems went away.

I'm not used to creating patch diffs but hopefully the attached (with just a few lines of changes) will be easy to understand.

----------
components: Windows
files: multiprocessing.diff
keywords: patch
messages: 211089
nosy: mark
priority: normal
severity: normal
status: open
title: multiprocessing cx_Freeze windows GUI bug (& easy fixes)
versions: Python 3.3
Added file: http://bugs.python.org/file34060/multiprocessing.diff

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

From report at bugs.python.org  Wed Feb 12 15:03:20 2014
From: report at bugs.python.org (Marius Gedminas)
Date: Wed, 12 Feb 2014 14:03:20 +0000
Subject: [New-bugs-announce] [issue20608] 'SyntaxError: invalid token' is
	unfriendly
Message-ID: <1392213800.84.0.505532685284.issue20608@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Type something like the following at the interpreter prompt:

>>> 04208
  File "<stdin>", line 1
    04208
        ^
SyntaxError: invalid token


This is not very descriptive.  I suggest "SyntaxError: invalid octal digit".

----------
components: Interpreter Core
messages: 211090
nosy: mgedmin
priority: normal
severity: normal
status: open
title: 'SyntaxError: invalid token' is unfriendly
versions: Python 3.5

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

From report at bugs.python.org  Wed Feb 12 15:26:55 2014
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 12 Feb 2014 14:26:55 +0000
Subject: [New-bugs-announce] [issue20609] Always running kill_python breaks
	building x64 on 32-bit	Windows machine
Message-ID: <1392215215.12.0.500409077942.issue20609@psf.upfronthosting.co.za>


New submission from Stephan R.A. Deibel:

The changes made in Issue19788 break the ability to build x64 build target on a 32-bit Windows machine because PreBuildEvent entries in pythoncore.vcxproj end up trying to run the 64-bit kill_python.exe, causing critical build steps to fail.  Removing those PreBuildEvents by manually editing pythoncore.vcxproj served as a work-around.

----------
components: Build
messages: 211093
nosy: sdeibel
priority: normal
severity: normal
status: open
title: Always running kill_python breaks building x64 on 32-bit Windows machine
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 12 15:55:47 2014
From: report at bugs.python.org (Daniel Ellis)
Date: Wed, 12 Feb 2014 14:55:47 +0000
Subject: [New-bugs-announce] [issue20610] Documentation with two slashes in
	URL links to v2.6.5c2
Message-ID: <1392216947.66.0.816905762086.issue20610@psf.upfronthosting.co.za>


New submission from Daniel Ellis:

I was searching for the documentation for itertools via Google and was sent here:

    http://www.python.org/doc//current/library/itertools.html

After glancing at the upper-left hand corner, I wondered why Google was sending people to the 2.6 documentation, and a release candidate at that.  After checking out the URL, it became obvious that there's an issue somewhere in the Python docs that is causing this.

Quite a bizarre and obscure bug, but probably should be fixed since a major search engine is passing front-page search traffic there.

----------
assignee: docs at python
components: Documentation
messages: 211094
nosy: Daniel.Ellis, docs at python
priority: normal
severity: normal
status: open
title: Documentation with two slashes in URL links to v2.6.5c2
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 12 16:13:52 2014
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 12 Feb 2014 15:13:52 +0000
Subject: [New-bugs-announce] [issue20611] socket.create_connection() doesn't
	handle EINTR properly
Message-ID: <1392218032.12.0.645790882431.issue20611@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

I had this sporadic traceback in a project:

  File "test.py", line 62, in <module>
    result = do_lqs(client, str(dnvn))
  File "test.py", line 25, in do_lqs
    qualif_service_id = client.create('ti.qualif.service', {})
  File "/srv/openerp/.buildout/eggs/ERPpeek-1.4.5-py2.6.egg/erppeek.py", line 894, in wrapper
    return self.execute(obj, method, *params, **kwargs)
  File "/srv/openerp/.buildout/eggs/ERPpeek-1.4.5-py2.6.egg/erppeek.py", line 636, in execute
    res = self._execute(obj, method, *params)
  File "/srv/openerp/.buildout/eggs/ERPpeek-1.4.5-py2.6.egg/erppeek.py", line 361, in <lambda>
    wrapper = lambda s, *args: s._dispatch(name, args)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.6/xmlrpclib.py", line 1235, in request
    self.send_content(h, request_body)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1349, in send_content
    connection.endheaders()
  File "/usr/lib/python2.6/httplib.py", line 908, in endheaders
    self._send_output()
  File "/usr/lib/python2.6/httplib.py", line 780, in _send_output
    self.send(msg)
  File "/usr/lib/python2.6/httplib.py", line 739, in send
    self.connect()
  File "/usr/lib/python2.6/httplib.py", line 1112, in connect
    sock = socket.create_connection((self.host, self.port), self.timeout)
  File "/usr/lib/python2.6/socket.py", line 561, in create_connection
    raise error, msg
socket.error: [Errno 4] Interrupted system call



It seems that the EINTR should be caught by the standard library in all cases: http://bugs.python.org/issue1628205

But it's not the case for the "socket.create_connection" method (verified in 3.3 and 2.7 source code).

----------
components: IO, Library (Lib)
messages: 211095
nosy: flox
priority: normal
severity: normal
status: open
title: socket.create_connection() doesn't handle EINTR properly
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 12 21:16:39 2014
From: report at bugs.python.org (Allan Crooks)
Date: Wed, 12 Feb 2014 20:16:39 +0000
Subject: [New-bugs-announce] [issue20612] cElementTree has problems with
	StringIO object	containing unicode content
Message-ID: <1392236199.28.0.287931665829.issue20612@psf.upfronthosting.co.za>


New submission from Allan Crooks:

There seems to be a specific issue when using cElementTree.parse on a StringIO object containing unicode text - it generates a ParseError.

I've tried variations of ElementTree and cElementTree, variations of StringIO and cStringIO, and used str and unicode types. It seems there is one combination of these that generates the problem. I tried this on Python 2.7.5 - this bit of code shows the inconsistency we've got:

>>> from xml.etree import ElementTree as ET, cElementTree as CET
>>> from StringIO import StringIO as SIO
>>> from cStringIO import StringIO as CSIO
>>> xml, uxml = '<simple />', u'<simple />'
>>> 
>>> def parse(etree_impl, strio_class, text):
...     try:
...         return etree_impl.parse(strio_class(text))
...     except Exception as e:
...         return 'ERROR: ' + repr(e)
... 
>>> for etree_var in 'ET CET'.split():
...     for sio_var in 'SIO CSIO'.split():
...         for xml_var in 'xml uxml'.split():
...             print etree_var, sio_var, xml_var,
...             print parse(vars()[etree_var], vars()[sio_var], vars()[xml_var])
... 
ET SIO xml <xml.etree.ElementTree.ElementTree object at 0x7f92c795ec90>
ET SIO uxml <xml.etree.ElementTree.ElementTree object at 0x7f92c795ec90>
ET CSIO xml <xml.etree.ElementTree.ElementTree object at 0x7f92c795ec90>
ET CSIO uxml <xml.etree.ElementTree.ElementTree object at 0x7f92c795ec90>
CET SIO xml <ElementTree object at 0x7f92c795ec90>
CET SIO uxml ERROR: ParseError('no element found: line 1, column 0',)
CET CSIO xml <ElementTree object at 0x7f92c795ec90>
CET CSIO uxml <ElementTree object at 0x7f92c795ec90>

----------
components: XML
messages: 211114
nosy: amcone
priority: normal
severity: normal
status: open
title: cElementTree has problems with StringIO object containing unicode content
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 13 04:17:09 2014
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 13 Feb 2014 03:17:09 +0000
Subject: [New-bugs-announce] [issue20613] Wrong line information in bytecode
	generated by compiler	module
Message-ID: <1392261429.58.0.605484301904.issue20613@psf.upfronthosting.co.za>


New submission from Arnaud Fontaine:

I know that compiler module is deprecated since 2.6, but I found a regression introduced in version 2.7 by the following cleanup commit (replacing pyassem.py modified in this commit by the one just before does not trigger this bug):

http://hg.python.org/releasing/2.7.6/rev/42faa8054c3d

Actually, there is nothing wrong when executing the generated bytecode, it's just that tracebacks and anything that display source code from the generated bytecode object gets sometimes completely wrong when there is if/elif/else because of compiler.pyassem.order_blocks().

This issue was found when noticing that tracebacks in Zope Python Script (using RestrictedPython which in turn uses compiler module) were displaying completely wrong line information and stepping with pdb into the source code was displaying wrong source code and line information too.

After investigating, I found out that the problem is actually in compiler module and wrote a small program triggering the bug (I know that some variables are undefined but it does not matter here):

if if1:
  if1_entered = 1

if if2:
  if subif1:
    subif1_entered = 1
  elif subif2:
    subif2_entered = 1

  subif_ended = 1

Using compiler module to generate the bytecode with the program attached returns two different bytecodes:

$ python2.7 compiler_wrong_ordering_block_test.py 
====================================
  1           0 LOAD_NAME                0 (if1)
              3 POP_JUMP_IF_FALSE       30

  2           6 LOAD_CONST               1 (1)
              9 STORE_NAME               1 (if1_entered)
             12 JUMP_FORWARD            15 (to 30)

  7     >>   15 LOAD_NAME                2 (subif2)
             18 POP_JUMP_IF_FALSE       51

  8          21 LOAD_CONST               1 (1)
             24 STORE_NAME               3 (subif2_entered)
             27 JUMP_FORWARD            21 (to 51)
        >>   30 LOAD_NAME                4 (if2)
             33 POP_JUMP_IF_FALSE       60
             36 LOAD_NAME                5 (subif1)
             39 POP_JUMP_IF_FALSE       15
             42 LOAD_CONST               1 (1)
             45 STORE_NAME               6 (subif1_entered)
             48 JUMP_FORWARD             0 (to 51)

 10     >>   51 LOAD_CONST               1 (1)
             54 STORE_NAME               7 (subif_ended)
             57 JUMP_FORWARD             0 (to 60)
        >>   60 LOAD_CONST               0 (None)
             63 RETURN_VALUE        
====================================
  1           0 LOAD_NAME                0 (if1)
              3 POP_JUMP_IF_FALSE       15

  2           6 LOAD_CONST               1 (1)
              9 STORE_NAME               1 (if1_entered)
             12 JUMP_FORWARD             0 (to 15)

  4     >>   15 LOAD_NAME                2 (if2)
             18 POP_JUMP_IF_FALSE       60

  5          21 LOAD_NAME                3 (subif1)
             24 POP_JUMP_IF_FALSE       36

  6          27 LOAD_CONST               1 (1)
             30 STORE_NAME               4 (subif1_entered)
             33 JUMP_FORWARD            15 (to 51)

  7     >>   36 LOAD_NAME                5 (subif2)
             39 POP_JUMP_IF_FALSE       51

  8          42 LOAD_CONST               1 (1)
             45 STORE_NAME               6 (subif2_entered)
             48 JUMP_FORWARD             0 (to 51)

 10     >>   51 LOAD_CONST               1 (1)
             54 STORE_NAME               7 (subif_ended)
             57 JUMP_FORWARD             0 (to 60)
        >>   60 LOAD_CONST               0 (None)
             63 RETURN_VALUE        

As you can see from the output above, the first generated bytecode gets all the line numbers (lnotab) messed up because 'subif2' block (and its children too) is emitted *before* its 'dominator' block, namely 'if2'.

Now, compiler.pyassem.order_blocks() arranges blocks to be emitted within a 'dominators' dict where the key is a block and the value a list of blocks which must be emitted *before* that one. However, for at least 'if/elif' blocks (created by compiler.pycodegen.CodeGenerator().visitIf()), the 'elif' block (subif2) does not have prev/next (where prev and next define respectively the parent and children blocks) sets to its parent (if2) as it is only set for the first 'if' (subif1) and furthermore for some reasons I don't know the code asserts that next list length must be equal to 1 anyway (anyone knows why BTW?)...

Thus, when creating 'dominators' dict using next/prev block attributes, the 'elif' block (subif2) ends up being considered kind of an orphan block because next/prev is not set and thus could be emitted anytime... Enabling debug mode in compiler.pyassem and adding a print call in order_blocks() to display 'dominators' dict confirms this (eg 'subif2' block (<block id=9>) dominators value list is empty):

=> Blocks:
        ('SET_LINENO', 0)
        ('SET_LINENO', 1)
        ('LOAD_NAME', 'if1')
        ('POP_JUMP_IF_FALSE', <block id=3>)
end <block id=0>
    next [<block id=4>]
    prev []
    [<block id=3>, <block id=4>]
<block id=4>
        ('SET_LINENO', 2)
        ('LOAD_CONST', 1)
        ('STORE_NAME', 'if1_entered')
        ('JUMP_FORWARD', <block id=2>)
end <block id=4>
    next []
    prev [<block id=0>]
    [<block id=2>]
<block id=3>
end <block id=3>
    next [<block id=2>]
    prev []
    [<block id=2>]
<block id=2>
        ('SET_LINENO', 4)
        ('LOAD_NAME', 'if2')
        ('POP_JUMP_IF_FALSE', <block id=6>)
end <block id=2>
    next [<block id=7>]
    prev [<block id=3>]
    [<block id=6>, <block id=7>]
end <block id=7>
    next [<block id=10>]
    prev [<block id=2>]
    [<block id=9>, <block id=10>]
<block id=10>
        ('SET_LINENO', 6)
        ('LOAD_CONST', 1)
        ('STORE_NAME', 'subif1_entered')
        ('JUMP_FORWARD', <block id=8>)
end <block id=10>
    next []
    prev [<block id=7>]
    [<block id=8>]
<block id=9>
        ('SET_LINENO', 7)
        ('LOAD_NAME', 'subif2')
        ('POP_JUMP_IF_FALSE', <block id=11>)
end <block id=9>
    next [<block id=12>]
    prev []
    [<block id=11>, <block id=12>]
<block id=12>
        ('SET_LINENO', 8)
        ('LOAD_CONST', 1)
        ('STORE_NAME', 'subif2_entered')
        ('JUMP_FORWARD', <block id=8>)
end <block id=12>
    next []
    prev [<block id=9>]
    [<block id=8>]
<block id=11>
end <block id=11>
    next [<block id=8>]
    prev []
    [<block id=8>]
<block id=8>
        ('SET_LINENO', 10)
        ('LOAD_CONST', 1)
        ('STORE_NAME', 'subif_ended')
        ('JUMP_FORWARD', <block id=5>)
end <block id=8>
    next []
    prev [<block id=11>]
    [<block id=5>]
<block id=6>
end <block id=6>
    next [<block id=5>]
    prev []
    [<block id=5>]
<block id=5>
        ('LOAD_CONST', None)
        ('RETURN_VALUE',)

=> Dominators:
{<block id=0>: set([]),
 <block id=2>: set([<block id=3>, <block id=4>]),
 <block id=3>: set([<block id=4>]),
 <block id=4>: set([<block id=0>]),
 <block id=5>: set([<block id=6>, <block id=8>]),
 <block id=6>: set([<block id=8>]),
 <block id=7>: set([<block id=2>]),
 <block id=8>: set([<block id=10>, <block id=11>, <block id=12>]),
 <block id=9>: set([]),
 <block id=10>: set([<block id=7>]),
 <block id=11>: set([<block id=10>, <block id=12>]),
 <block id=12>: set([<block id=9>])}

I have tried to write a patch for this issue but to be honest I could not come up with something nice, any idea about implementing a proepr fix is welcome?

----------
components: Library (Lib)
files: compiler_wrong_ordering_block_test.py
messages: 211124
nosy: arnau, nascheme, pitrou
priority: normal
severity: normal
status: open
title: Wrong line information in bytecode generated by compiler module
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34064/compiler_wrong_ordering_block_test.py

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

From report at bugs.python.org  Thu Feb 13 11:26:05 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2014 10:26:05 +0000
Subject: [New-bugs-announce] [issue20614] test.script_helper should copy
	SYSTEMROOT environment	variable for __cleanenv=True
Message-ID: <1392287165.51.0.792620084259.issue20614@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows, if Python is started with an empty environment (no environment variable at all), Python fails with:

"Fatal Python error: Failed to initialize Windows random API (CryptoGen)"

It's the Windows error 0x80090006 which is not displayed in the error message :-(

In fact, it's because Python 3 cannot be started without SYSTEMROOT environment variable. Otherwise, CryptAcquireContext() is unable to find some DLL.

IMO the script_helper should be fixed to copy the variable.

Recent example of this issue:
http://bugs.python.org/issue20599#msg211111

----------
components: Tests
messages: 211138
nosy: brian.curtin, haypo, serhiy.storchaka, tim.golden
priority: normal
severity: normal
status: open
title: test.script_helper should copy SYSTEMROOT environment variable for __cleanenv=True
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb 13 11:44:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2014 10:44:13 +0000
Subject: [New-bugs-announce] [issue20615] Replace PyDict_GetItem() with
	PyDict_GetItemWithError()
Message-ID: <1392288253.13.0.332874319538.issue20615@psf.upfronthosting.co.za>


New submission from STINNER Victor:

See this huge warning in the definition of PyDict_GetItem:

/* Note that, for historical reasons, PyDict_GetItem() suppresses all errors
 * that may occur (originally dicts supported only string keys, and exceptions
 * weren't possible).  So, while the original intent was that a NULL return
 * meant the key wasn't present, in reality it can mean that, or that an error
 * (suppressed) occurred while computing the key's hash, or that some error
 * (suppressed) occurred when comparing keys in the dict's internal probe
 * sequence.  A nasty example of the latter is when a Python-coded comparison
 * function hits a stack-depth error, which can cause this to return NULL
 * even if the key is present.
 */
PyObject *
PyDict_GetItem(PyObject *op, PyObject *key)
{ ... }

PyDict_GetItem() should avoided because it may hide important exceptions like KeyboardInterrupt or MemoryError.

See for example #14537 for a specific error.

By the way, the PyDict_GetItem() documentation should contain a big red warning and suggest to use PyDict_GetItemWithError() instead.

----------
messages: 211142
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Replace PyDict_GetItem() with PyDict_GetItemWithError()
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb 13 12:43:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2014 11:43:40 +0000
Subject: [New-bugs-announce] [issue20616] Add tracemalloc.Traceback.format()
	method
Message-ID: <1392291820.41.0.346286510038.issue20616@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds a Traceback.format() to the new tracemalloc module.

Since the tracemalloc is new in Python 3.4 and my patch adds a new (simple and tested) method, I consider that it's not so late to add it :-)

I chose a different API than traceback.format_tb() because I would like to use directly print or use functions of the logging module (logging doesn't expect newlines).

I set the priority to release blocker because I want to know Larry's opinion on this issue.

@Larry: Change the priority if you consider that it's really too late for such change.

----------
files: traceback_format.patch
keywords: patch
messages: 211147
nosy: gvanrossum, haypo, larry, neologix
priority: release blocker
severity: normal
status: open
title: Add tracemalloc.Traceback.format() method
versions: Python 3.4
Added file: http://bugs.python.org/file34067/traceback_format.patch

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

From report at bugs.python.org  Thu Feb 13 12:48:24 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 13 Feb 2014 11:48:24 +0000
Subject: [New-bugs-announce] [issue20617] test_ssl does not use mock
Message-ID: <1392292104.23.0.984787666166.issue20617@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following line should be removed from test_ssl.py:

from unittest import mock

----------
components: Library (Lib)
messages: 211148
nosy: xdegaye
priority: normal
severity: normal
status: open
title: test_ssl does not use mock
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 13 17:52:29 2014
From: report at bugs.python.org (Tammy)
Date: Thu, 13 Feb 2014 16:52:29 +0000
Subject: [New-bugs-announce] [issue20618] Unable to pip install
	pyjasperclient
Message-ID: <1392310349.37.0.170557208968.issue20618@psf.upfronthosting.co.za>


New submission from Tammy:

We used to be able to perform a "pip install pyjasperclient" with success.  The last time I did this was within the last couple months.
I tried this today and received an error,
...
Downloading/unpacking elementtree (from pyjasperclient)
  Could not find any downloads that satisfy the requirement elementtree (from pyjasperclient)
  Some externally hosted files were ignored (use --allow-external elementtree to allow).
Cleaning up...
No distributions at all found for elementtree (from pyjasperclient)
Storing debug log for failure in /home/belairlab/.pip/pip.log

----------
components: Installation
messages: 211161
nosy: viel
priority: normal
severity: normal
status: open
title: Unable to pip install pyjasperclient
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 13 21:00:24 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 13 Feb 2014 20:00:24 +0000
Subject: [New-bugs-announce] [issue20619] tracemalloc changes col_offset
	attribute for _ast.arg	objects
Message-ID: <1392321624.4.0.262730610366.issue20619@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Here's a strange bug. I don't know if this is legitimate or not, but it seems like there is some sort of overflow.

Given the following code:

  data = """
  def function(*, foot):
    print(foot)
  """
  from ast import parse
  import tracemalloc
  tracemalloc.start()
  node = parse(data)
  tracemalloc.stop()
  arg = node.body[0].args.kwonlyargs[0]
  print(arg.lineno, arg.col_offset)

it yields on a freshly build the following, which is obviously wrong. It should have printed `1 1`.

  <_ast.arg object at 0x80103bcf8>
  1681660160 -2124152704

Also, there is no need to call tracemalloc.start, it has the same behaviour just by importing it.

----------
components: Library (Lib)
messages: 211165
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: tracemalloc changes col_offset attribute for _ast.arg objects
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 13 21:08:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Feb 2014 20:08:49 +0000
Subject: [New-bugs-announce] [issue20620] Update the min()/max() docs for
	the new default argument
Message-ID: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

There is a new "default" argument for min() and max():

    >>> min([], default=10)
    10

The new argument is not currently shown by help():

    >>> help(min)
    Help on built-in function min in module builtins:

    min(...)
        min(iterable[, key=func]) -> value
        min(a, b, c, ...[, key=func]) -> value
        
        With a single iterable argument, return its smallest item.
        With two or more arguments, return the smallest argument.

----------
assignee: docs at python
components: Documentation
messages: 211168
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Update the min()/max() docs for the new default argument
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 13 21:50:36 2014
From: report at bugs.python.org (Paul Moore)
Date: Thu, 13 Feb 2014 20:50:36 +0000
Subject: [New-bugs-announce] [issue20621] Issue with zipimport in 3.3.4
Message-ID: <1392324636.47.0.967775665476.issue20621@psf.upfronthosting.co.za>


New submission from Paul Moore:

There appears to be a significant issue with importing from zip files on Python 3.3.4. I have tested this on Windows 7, 64-bit, using the MSI installer from python.org.

To reproduce, download virtualenv and extract the C:\Work\Scratch\virtualenv-pfm\virtualenv_support\pip-1.5.2-py2.py3-none-any.whl file. Set PYTHONPATH to the full path of that wheel.

python -c "import pip" should work without error, but I see

PS 20:44 C:\Work\Scratch\virtualenv-pfm
>$env:PYTHONPATH="C:\Work\Scratch\virtualenv-pfm\virtualenv_support\pip-1.5.2-py2.py3-none-any.whl"
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>C:\Apps\Python33\python.exe -c "import pip"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'pip'

For comparison, the 32-bit version works perfectly:

PS 20:44 C:\Work\Scratch\virtualenv-pfm
>$env:PYTHONPATH="C:\Work\Scratch\virtualenv-pfm\virtualenv_support\pip-1.5.2-py2.py3-none-any.whl"
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>C:\Apps\Python33\python.exe -c "import pip"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'pip'

----------
keywords: 3.3regression
messages: 211170
nosy: georg.brandl, pmoore
priority: critical
severity: normal
status: open
title: Issue with zipimport in 3.3.4
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 14 02:53:15 2014
From: report at bugs.python.org (FeralBytes)
Date: Fri, 14 Feb 2014 01:53:15 +0000
Subject: [New-bugs-announce] [issue20622] Python3.3 venv pip fails to run if
	path contains spaces
Message-ID: <1392342795.85.0.42431459762.issue20622@psf.upfronthosting.co.za>


New submission from FeralBytes:

Well trying to test out venv on Python 3.3.2 on Linux Mint 16 x64 I was not able to get pip to execute correctly after it had been installed. The error from bash is:

(venv) wolfrage at wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects/The Strategist $ pip install pysdl2
bash: /home/wolfrage/Projects/The Strategist/venv/bin/pip: /home/wolfrage/Projects/The: bad interpreter: No such file or directory

Same exact setup procedures in a path with out any spaces works as expected:

(venv) wolfrage at wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects $ pip install pysdl2 --allow-external pysdl2 --allow-unverified pysdl2
Downloading/unpacking pysdl2
  pysdl2 is potentially insecure and unverifiable.
  Downloading PySDL2-0.8.0.zip (1.1MB): 1.1MB downloaded
  Running setup.py (path:/media/ShareDrives/HomePlus/Jordan/Projects/venv/build/pysdl2/setup.py) egg_info for package pysdl2
    
Installing collected packages: pysdl2
  Running setup.py install for pysdl2
    
Successfully installed pysdl2
Cleaning up...
(venv) wolfrage at wolfrage-KGP-M-E-D16 /media/ShareDrives/HomePlus/Jordan/Projects $ python3
Python 3.3.2+ (default, Oct  9 2013, 14:50:09) 
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sdl2
>>> exit()

I hope that this can be fixed prior to 3.4 being released.
This not only affected pip but easy_install too.

----------
components: Library (Lib)
messages: 211193
nosy: FeralBytes
priority: normal
severity: normal
status: open
title: Python3.3 venv pip fails to run if path contains spaces
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 14 06:28:56 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Feb 2014 05:28:56 +0000
Subject: [New-bugs-announce] [issue20623] Run test_htmlparser with
	unbuffered source
Message-ID: <1392355736.12.0.789515790833.issue20623@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Currently test_htmlparser feeds the HTML source to the parser one char at the time (except a couple of buffering-specific tests that feed the parser with chunks of text).  This ensures that the parser doesn't break when the source is fed in smaller chunks (that might end in the middle of a tag).  However #20288 revealed a bug that doesn't happen while feeding the parser char by char.

In order to avoid similar problems, all the tests should feed the source to the parser both char by char and as a single string.
So my plan is:
1) wait until #15114 is resolved and the strict mode and the strict tests are removed;
2) either change TestCaseBase._run_check() to run every test twice (possibly by using subTest), or use a subclass-based approach with a different _run_check in the two subclasses.

A few notes about this:
* a third kind of test that feeds the parser with chunk of arbitrary length (e.g. 5 chars) could be added as well;
* the increase in run-time shouldn't matter, since all the tests take very little time to run;
* I don't think it's necessary to backport this to 2.7/3.3/3.4 because it's a somewhat major refactoring, and if a bug is introduced by other changes the tests in 3.5 will find it (I expect all the bug fixes and new features to land in 3.5 too);

----------
assignee: ezio.melotti
components: Tests
messages: 211201
nosy: ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Run test_htmlparser with unbuffered source
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Feb 14 12:31:29 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 Feb 2014 11:31:29 +0000
Subject: [New-bugs-announce] [issue20624] Clarify recommendation to inherit
	from Exception
Message-ID: <1392377489.91.0.767550317256.issue20624@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

>From http://docs.python.org/3.4/library/exceptions.html:

"... programmers are encouraged to at least derive new exceptions from the Exception class and not BaseException."

This wording had someone I've talked to recently thinking that user-defined exceptions should inherit *directly* from Exception.

Suggested rewording, dropping the "at least" qualification that as far as I can tell serves no real purpose:

"... programmers are encouraged to derive new exceptions from the Exception class or one of its subclasses, and not from BaseException."

----------
assignee: docs at python
components: Documentation
messages: 211214
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Clarify recommendation to inherit from Exception
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 14 12:57:28 2014
From: report at bugs.python.org (Jonas Wielicki)
Date: Fri, 14 Feb 2014 11:57:28 +0000
Subject: [New-bugs-announce] [issue20625] Argument names in __annotations__
	are not mangled for	functions defined inside class scope
Message-ID: <1392379048.74.0.239094025936.issue20625@psf.upfronthosting.co.za>


New submission from Jonas Wielicki:

Assume I have this code:

class Spam:
    def eggs(__some_kwarg:int=None):
        print(__some_kwarg)

I can call Spam.bar with keyword arguments as expected from mangling:

>>> Spam.eggs(10)
10
>>> Spam.eggs(_Spam__some_kwarg=10)
10

However, in the __annotations__ field, the argument name is not mangled:

>>> Spam.eggs.__annotations__
{'__some_kwarg': <class 'int'>}

This is an inconsistency which makes it difficult to work with function annotations in this case.

----------
components: Interpreter Core
messages: 211215
nosy: jonasw
priority: normal
severity: normal
status: open
title: Argument names in __annotations__ are not mangled for functions defined inside class scope
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 14 15:56:06 2014
From: report at bugs.python.org (Irvin Probst)
Date: Fri, 14 Feb 2014 14:56:06 +0000
Subject: [New-bugs-announce] [issue20626] Manager documentation unclear
	about lists and thread	safeness
Message-ID: <1392389766.44.0.393784619009.issue20626@psf.upfronthosting.co.za>


New submission from Irvin Probst:

In the the Manager's lists documentation one can read:

"""
list()
list(sequence)
Create a shared list object and return a proxy for it.
"""

IMHO it is really unclear whether these lists have something more than traditionnal lists or not. 

When you have a look at managers.py it is quite obvious, unless I'm completely wrong, that the underlying shared object is a standard list with a basic proxy to expose all the "underscore underscore stuff".

"""
BaseListProxy = MakeProxyType('BaseListProxy', (
    '__add__', '__contains__', '__delitem__', '__getitem__', '__len__',
    '__mul__', '__reversed__', '__rmul__', '__setitem__',
    'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove',
    'reverse', 'sort', '__imul__'
    ))

class ListProxy(BaseListProxy):
    def __iadd__(self, value):
        self._callmethod('extend', (value,))
        return self
    def __imul__(self, value):
        self._callmethod('__imul__', (value,))
        return self

    [snip a couple of lines]

SyncManager.register('list', list, ListProxy)
"""

That's really confusing because, unless reading managers.py, you have the feeling that the manager's lists() are somehow different than standard lists.

The other problem is that, if you don't know what level of thread-safeness the GIL guarantees on the lists in the manager's server thread, you have the feeling that the safeness comes from some obscure Manager's black magic managing concurrent access for you.

May I suggest to add in the documentation:


1/

"""
list()
list(sequence)
Create a shared list (add here a link to http://docs.python.org/3.3/library/stdtypes.html#list) object and return a proxy for it.
"""

2/ 

Clearly state somewhere in the manager's documentation that it's the developper's job to ensure that the proxied methods are thread safe. Write it in bold and red please :-) 

3/ 
Perhaps add an example with a custom object like the code I attached to this report.


Thanks for your time.

----------
files: example.py
messages: 211220
nosy: Irvin.Probst
priority: normal
severity: normal
status: open
title: Manager documentation unclear about lists and thread safeness
Added file: http://bugs.python.org/file34080/example.py

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

From report at bugs.python.org  Fri Feb 14 17:19:42 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Feb 2014 16:19:42 +0000
Subject: [New-bugs-announce] [issue20627] Add context manager support to
	xmlrpc.client.ServerProxy
Message-ID: <1392394782.44.0.253579633939.issue20627@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Otherwise have to call client('close')() to close a server proxy and that's just ugly.

----------
components: Library (Lib)
messages: 211221
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add context manager support to xmlrpc.client.ServerProxy
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Feb 14 18:43:34 2014
From: report at bugs.python.org (Roger Erens)
Date: Fri, 14 Feb 2014 17:43:34 +0000
Subject: [New-bugs-announce] [issue20628] csv.DictReader
Message-ID: <1392399814.31.0.309043975377.issue20628@psf.upfronthosting.co.za>


New submission from Roger Erens:

The sections on DictReader and DictWriter do not give information on what the type is of the parameter 'fieldnames'. The source code comments that it is a 'list of keys for the dict'.

----------
assignee: docs at python
components: Documentation
messages: 211226
nosy: docs at python, rogererens
priority: normal
severity: normal
status: open
title: csv.DictReader
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Feb 14 22:43:22 2014
From: report at bugs.python.org (Alan Ning)
Date: Fri, 14 Feb 2014 21:43:22 +0000
Subject: [New-bugs-announce] [issue20629] Python ctypes BigEndianStructure
	bitfield assignment	misbehavior in Linux
Message-ID: <1392414202.99.0.0705946156557.issue20629@psf.upfronthosting.co.za>


New submission from Alan Ning:

I am seeing a strange issue with bitfields and BigEndianStructure under Ubuntu 12.04 x64, Python 2.7.3.

This bug only occurs if I define my bitfields using c_uint. If I switch to c_ushort, it goes away.

Below is a simple code that highlights the problem. I have two structures - BitField1U and BitField2U. It is a union of a 4 bytes array and a bitfield definition.

Under Linux, by simply setting fields.a = 1 twice, it modifies the underlying byte array twice in a very different way. This behavior does not occur in Windows.

Output: Ubuntu 12.04x64 Python 2.7.3
20000000
20000020 <- problem
20000000
20000000

Output: Window 7 x64 Python 2.7.3
20000000
20000000
20000000
20000000

This bug was originally reported as a question in StackOverflow. 
http://stackoverflow.com/questions/21785874/python-ctypes-bitfield-windows-vs-linux


Source code:

import ctypes
import binascii

class BitField1(ctypes.BigEndianStructure):
    _pack_ = 1
    _fields_ = [
    ('a', ctypes.c_uint, 3),
    ('b', ctypes.c_uint, 1),
    ]

class BitField1U(ctypes.Union):
    _pack_ = 1
    _fields_ = [("fields", BitField1), 
        ("raw_bytes", ctypes.c_ubyte * 4)]

class BitField2(ctypes.BigEndianStructure):
    _pack_ = 1
    _fields_ = [
    ('a', ctypes.c_ushort, 3),
    ('b', ctypes.c_ushort, 1),
    ]

class BitField2U(ctypes.Union):
    _pack_ = 1
    _fields_ = [("fields", BitField2), 
        ("raw_bytes", ctypes.c_ubyte * 4)]

def printBytes(raw_bytes) :
    ba = bytearray(raw_bytes)
    print(binascii.hexlify(ba))
    
def printFields(fields) :
    print(fields.a),
    print(fields.b),
    print

b1 = BitField1U()
b2 = BitField2U()

# Simply set fields.a = 1 twice, and notice how the raw_bytes changes.

b1.fields.a = 1
printBytes(b1.raw_bytes)
b1.fields.a = 1
printBytes(b1.raw_bytes)

b2.fields.a = 1
printBytes(b2.raw_bytes)
b2.fields.a = 1
printBytes(b2.raw_bytes)

----------
components: ctypes
messages: 211241
nosy: Alan.Ning
priority: normal
severity: normal
status: open
title: Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 15 01:06:16 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Feb 2014 00:06:16 +0000
Subject: [New-bugs-announce] [issue20630] Add sorting helpers for
	collections containing None	values
Message-ID: <1392422776.28.0.82059564147.issue20630@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, it's a bit annoying to sort collections containing "None" values in Python 3. While the default behaviour isn't going to change, it would be good to offer standard "none_first" and "none_last" helps (inspired by the SQL NULL FIRST and NULL LAST ordering control).

Suggested home: functools (since that is where the total_ordering class decorator already lives), but collections would also be a reasonable choice (as this feature mostly relates to sorting containers)

The minimal option (suggested by Peter Otten):

    def none_first(v):
        return v is not None, v

    def none_last(v):
        return v is None, v

A more complex alternative would be to provide general purpose SortsFirst and SortsLast singletons:

    @functools.total_ordering
    class _AlwaysLesser:
        def __eq__(self, other):
            return isinstance(other, _AlwaysLesser):
        def __lt__(self, other):
            return not isinstance(other, _AlwaysLesser):

    @functools.total_ordering
    class _AlwaysGreater:
        def __eq__(self, other):
            return isinstance(other, _AlwaysGreater):
        def __gt__(self, other):
            return not isinstance(other, _AlwaysGreater):

    SortsFirst = _AlwaysLesser()
    SortsLast = _AlwaysGreater()

    def none_first(v):
        return SortsFirst if v is None else v
    def none_last(v):
        return SortsLast if v is None else v

The advantage of the latter more complex approach is that you can embed the SortsFirst and SortsLast values inside a tuple as part of a more complex key, whereas the simple solution only handles the case where the entire value is None.

(Inspired by Chris Withers's python-dev thread: https://mail.python.org/pipermail/python-dev/2014-February/132332.html)

----------
messages: 211251
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add sorting helpers for collections containing None values
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Feb 15 01:12:11 2014
From: report at bugs.python.org (Todd Fiala)
Date: Sat, 15 Feb 2014 00:12:11 +0000
Subject: [New-bugs-announce] [issue20631] python readline module crashing on
	NULL access
Message-ID: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za>


New submission from Todd Fiala:

Hi all,

In working on the LLVM/LLDB project, I've been hitting a bug in the
embedded interpreter that causes a NULL dereference in the Python
readline module. There is a call to the history_get() function with an
assumption that it returns a non-NULL value. This is not guaranteed to
be true of the history_get function, and causes the readline module to
crash when it hits this condition.

I'm attaching a patch to the Python 2.7.6 source code that addresses
this issue. It adds an explicit NULL test of the history_get() return
value before accessing it.

This issue was discovered in top of tree LLDB (LLVM.org debugger project).  See here for details:

http://llvm.org/bugs/show_bug.cgi?id=18841

----------
files: python_2.7.6_module_readline_null.diff
keywords: patch
messages: 211252
nosy: tfiala
priority: normal
severity: normal
status: open
title: python readline module crashing on NULL access
versions: Python 2.7
Added file: http://bugs.python.org/file34086/python_2.7.6_module_readline_null.diff

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

From report at bugs.python.org  Sat Feb 15 01:17:55 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Feb 2014 00:17:55 +0000
Subject: [New-bugs-announce] [issue20632] Define a new __key__ protocol
Message-ID: <1392423475.26.0.500398402328.issue20632@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This is an idea that would require a PEP, just writing it down here as a permanent record in case someone else wants to run with it.

Currently, the *simplest* way to define a non-identity total ordering on an immutable object is to define __hash__, __eq__ and __lt__ appropriately, and then use functools.total_ordering to add the other comparison methods.

However, many such implementations follow a very similar pattern:

    def __hash__(self):
        return hash(self._calculate_key())
    def __eq__(self, other):
        if isinstance(other, __class__):
            return self._calculate_key() == other._calculate_key()
        return NotImplemented
    def __lt__(self, other):
        if isinstance(other, __class__):
            return self._calculate_key() < other._calculate_key()
        return NotImplemented

A "__key__" protocol as an inherent part of the type system could greatly simplify that:

    def __key__(self):
        return self._calculate_key()

The interpreter would then derive appropriate implementations for __hash__ and all the rich comparison methods based on that key calculation and install them when the type object was created.

If the type is mutable (and hence orderable but not hashable), then setting "__hash__ = None" would disable the implicit hashing support (just as it can already be used to explicitly disable hash inheritance).

(Inspired by Chris Withers's python-dev thread: https://mail.python.org/pipermail/python-dev/2014-February/132332.html)

----------
components: Interpreter Core
messages: 211253
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Define a new __key__ protocol
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Feb 15 09:08:12 2014
From: report at bugs.python.org (Amr Ali)
Date: Sat, 15 Feb 2014 08:08:12 +0000
Subject: [New-bugs-announce] [issue20633] SystemError: Parent module
	'multiprocessing' not loaded, cannot perform relative import
Message-ID: <1392451692.15.0.381545648867.issue20633@psf.upfronthosting.co.za>


New submission from Amr Ali:

Using `multiprocessing.Manager` to share a `dict` between two processes raises the below exception at main process termination. Child process is joined and terminates gracefully before the main process.

Replacing multiprocessing/forking.py:135 with `from multiprocessing.connection import wait` fixes the issue.

Python 3.3.1 (default, Sep 25 2013, 19:29:01) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'3.3.1 (default, Sep 25 2013, 19:29:01) \n[GCC 4.7.3]'

# multiprocessing/forking.py:135

132         def wait(self, timeout=None):                                            
133             if self.returncode is None:                                          
134                 if timeout is not None:                                          
135                     from .connection import wait                                 
136                     if not wait([self.sentinel], timeout):                       
137                         return None                                              
138                 # This shouldn't block if wait() returned successfully.          
139                 return self.poll(os.WNOHANG if timeout == 0.0 else 0)            
140             return self.returncode                                               

# Traceback

Traceback (most recent call last):
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/util.py", line 255, in _run_finalizers
    finalizer()
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/util.py", line 188, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/managers.py", line 588, in _finalize_manager
    process.join(timeout=1.0)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/process.py", line 127, in join
    res = self._popen.wait(timeout)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/forking.py", line 135, in wait
    from .connection import wait
SystemError: Parent module 'multiprocessing' not loaded, cannot perform relative import
Traceback (most recent call last):
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/util.py", line 255, in _run_finalizers
    finalizer()
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/util.py", line 188, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/managers.py", line 588, in _finalize_manager
    process.join(timeout=1.0)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/process.py", line 127, in join
    res = self._popen.wait(timeout)
  File "/home/d4de/work/redacted/redacted-engine/venv/lib/python3.3/multiprocessing/forking.py", line 135, in wait
    from .connection import wait
SystemError: Parent module 'multiprocessing' not loaded, cannot perform relative import

----------
components: Library (Lib)
messages: 211262
nosy: Amr.Ali, jnoller, sbt
priority: normal
severity: normal
status: open
title: SystemError: Parent module 'multiprocessing' not loaded, cannot perform relative import
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 15 11:17:23 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sat, 15 Feb 2014 10:17:23 +0000
Subject: [New-bugs-announce] [issue20634] IDLE test : Typo in readme file
Message-ID: <1392459443.25.0.568669819622.issue20634@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

There is a typo in the readme.txt file which uses "text" instead of "test" in an example to demonstrate how to run tests.

----------
components: IDLE, Tests
files: idle-tests-readme-typo-fix.diff
keywords: patch
messages: 211265
nosy: sahutd
priority: normal
severity: normal
status: open
title: IDLE test : Typo in readme file
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file34087/idle-tests-readme-typo-fix.diff

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

From report at bugs.python.org  Sat Feb 15 12:38:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2014 11:38:22 +0000
Subject: [New-bugs-announce] [issue20635] Fix the grid geometry manager and
	add
Message-ID: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which adds tests for Tk geometry managers (pack, place and grid). In additional it fixes the grid_columnconfigure() and grid_rowconfigure() methods which did not worked with wantobject=True (preferable and default mode).

----------
components: Library (Lib), Tests, Tkinter
files: test_geometry_managers.patch
keywords: patch
messages: 211268
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Fix the grid geometry manager and add
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34088/test_geometry_managers.patch

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

From report at bugs.python.org  Sat Feb 15 12:53:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2014 11:53:01 +0000
Subject: [New-bugs-announce] [issue20636] Better repr for tkinter widgets
Message-ID: <1392465181.79.0.530455860021.issue20636@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which adds more helpful repr for Tkinter widgets. Was

    <tkinter.Button object at 0xb6aa6964>

Becomes:

    <tkinter.Button object .3070343372.3066782348>

or (if you assigned names to widgets)

    <tkinter.Button object .panel.b1>

This is very helpful for debugging.

----------
components: Tkinter
files: tkinter_misc_repr.patch
keywords: patch
messages: 211269
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Better repr for tkinter widgets
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34089/tkinter_misc_repr.patch

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

From report at bugs.python.org  Sat Feb 15 23:49:04 2014
From: report at bugs.python.org (Peter Ingebretson)
Date: Sat, 15 Feb 2014 22:49:04 +0000
Subject: [New-bugs-announce] [issue20637] Support key-sharing dictionaries
	in subclasses
Message-ID: <1392504544.21.0.429278926318.issue20637@psf.upfronthosting.co.za>


New submission from Peter Ingebretson:

PEP 412 shared keys are not created for subclasses in Python 3.3 and 3.4:

>>> import sys
>>> class A:
...     pass
... 
>>> class B(A):
...     pass
... 
>>> a, b = A(), B()
>>> sys.getsizeof(vars(a))
96
>>> sys.getsizeof(vars(b))
288

(Actual sizes depend on platform and configuration).

This patch allows subclasses to share keys:

>>> import sys
>>> class A:
...     pass
... 
>>> class B(A):
...     pass
... 
>>> a, b = A(), B()
>>> sys.getsizeof(vars(a))
96
>>> sys.getsizeof(vars(b))
96

----------
components: Interpreter Core
files: subclass-keys-pep-412.patch
keywords: patch
messages: 211302
nosy: pingebretson
priority: normal
severity: normal
status: open
title: Support key-sharing dictionaries in subclasses
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file34096/subclass-keys-pep-412.patch

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

From report at bugs.python.org  Sun Feb 16 11:39:16 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 16 Feb 2014 10:39:16 +0000
Subject: [New-bugs-announce] [issue20638] KeyError building the Python html
	doc with sphinx
Message-ID: <1392547156.76.0.116028176695.issue20638@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Occurs on the tip of the Python default branch on ArchLinux when running 'make html PYTHON=python2' from Doc/.
Traceback attached.

----------
assignee: docs at python
components: Documentation
files: sphinx-err-DH3qAl.log
messages: 211311
nosy: docs at python, georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: KeyError building the Python html doc with sphinx
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34098/sphinx-err-DH3qAl.log

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

From report at bugs.python.org  Sun Feb 16 14:28:50 2014
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 16 Feb 2014 13:28:50 +0000
Subject: [New-bugs-announce] [issue20639] pathlib.PurePath.with_suffix()
	does not allow removing	the suffix
Message-ID: <1392557330.28.0.692268458915.issue20639@psf.upfronthosting.co.za>


New submission from July Tikhonov:

The changeset ef2b2ddd27c8 restricted the argument of Path.with_suffix() too much, and caused some strange behavior.

Case 1: removing suffix completely is disallowed now.
The following code worked before the fix:

>>> pathlib.PurePath('a', 'b.c').with_suffix('')
PurePosixPath('a/b')

but now fails with ValueError:

>>> pathlib.PurePath('a', 'b.c').with_suffix('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/july/source/python/Lib/pathlib.py", line 760, in with_suffix
    raise ValueError("Invalid suffix %r" % (suffix))
ValueError: Invalid suffix ''

It was the only one obvious way of removing the suffix, and I think it should remain so. (BTW: There is a XXX note in the code questioning if Path.with_suffix(None) should remove the suffix.)

Case 2: while the output is now always a correct Path, the suffix can still contain separator.
The following code produced incorrect path before the fix:

>>> pathlib.PurePath('a', 'b.c').with_suffix('./.s/.')
PurePosixPath('a/b./.s/.')
>>> _.parts
('a', 'b./.s/.')

Now, the produced path is correct, but the code itself is still allowed:

>>> pathlib.PurePath('a', 'b.c').with_suffix('./.s/.')
PurePosixPath('a/b.s')

while I would expect it to fail with ValueError.

Attached: proposed test patch.

----------
components: Library (Lib)
files: pathlib-with_suffix-test.diff
keywords: patch
messages: 211316
nosy: july, pitrou
priority: normal
severity: normal
status: open
title: pathlib.PurePath.with_suffix() does not allow removing the suffix
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34099/pathlib-with_suffix-test.diff

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

From report at bugs.python.org  Sun Feb 16 16:08:45 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 16 Feb 2014 15:08:45 +0000
Subject: [New-bugs-announce] [issue20640] Adds idle test for
	configHelpSourceEdit
Message-ID: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

This patch adds tests for Idle's configHelpSourceEdit.py module.

There is however, a minor issue related to this patch,which is an attribute error occurring due to lines 108,115,128,139 on http://hg.python.org/cpython/file/eef7899ea7ab/Lib/idlelib/configHelpSourceEdit.py 
The error occurring is an attribute error,wherein 'entryMenu' and 'entryPath' attributes are not found. Clearly,the two attributes are created in CreateWidgets() defined on lines 52 and 57.
Other attributes defined in the same CreateWidgets() like menu and path dont raise any attribute error.

I have asked the same in irc,where i was advised to post this patch with the issue mentioned.

Bear with me,i have tried a lot to overcome this issue,but no avail.Please let me know how to fix this.

The test other than this issue,should integrate well.

----------
components: IDLE, Tests
files: idle-test-config-help-source.patch
keywords: patch
messages: 211319
nosy: sahutd, serhiy.storchaka, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: Adds idle test for configHelpSourceEdit
versions: Python 3.4
Added file: http://bugs.python.org/file34101/idle-test-config-help-source.patch

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

From report at bugs.python.org  Sun Feb 16 22:31:14 2014
From: report at bugs.python.org (Patrick Westerhoff)
Date: Sun, 16 Feb 2014 21:31:14 +0000
Subject: [New-bugs-announce] [issue20641] Python installer needs elevated
	rights to install pip
Message-ID: <1392586274.91.0.59304299954.issue20641@psf.upfronthosting.co.za>


New submission from Patrick Westerhoff:

When installing Python 3.4 with the MSI, you can choose to install pip as part of the setup. With activated UAC on Windows (which is the recommended default), the installer will ask for elevated rights during the setup to copy the files over to the installation directory.

However, when the setup then attempts to install pip, the Python interpreter running the `ensurepip` library to install it is *not* run with elevated rights. This obviously results in a permission error when it then tries to copy over pip into the `\Scripts\` install directory.

This is similar to the advanced installer option ?Compile .py files to byte code?, which has been failing forever because of the same problem. But now, with pip, this is an actual problem.

I suggest that you either run the pip install process from within the elevated setup, inheriting the rights?if that?s even possible?or explicitely request elevated rights for it again.

----------
components: Windows
messages: 211360
nosy: poke
priority: normal
severity: normal
status: open
title: Python installer needs elevated rights to install pip
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 16 22:46:07 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 16 Feb 2014 21:46:07 +0000
Subject: [New-bugs-announce] [issue20642] Enhance deepcopy-ing for tuples
Message-ID: <1392587167.09.0.0900280350163.issue20642@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello!

Here's a patch for improving the performance of tuple deepcopy-ing.

Without patch:

# ./python -m timeit -s "import copy; a=tuple(range(1000000))" -p "copy.deepcopy(a)"
10 loops, best of 3: 1.45 sec per loop

With patch:

# ./python -m timeit -s "import copy; a=tuple(range(1000000))" -p "copy.deepcopy(a)"
10 loops, best of 3: 1.32 sec per loop

----------
components: Library (Lib)
files: copy.patch
keywords: patch
messages: 211362
nosy: Claudiu.Popa, alexandre.vassalotti
priority: normal
severity: normal
status: open
title: Enhance deepcopy-ing for tuples
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file34108/copy.patch

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

From report at bugs.python.org  Sun Feb 16 22:57:51 2014
From: report at bugs.python.org (Vladimir Rutsky)
Date: Sun, 16 Feb 2014 21:57:51 +0000
Subject: [New-bugs-announce] [issue20643] Strange dot in documentation
	(after generator.close)
Message-ID: <1392587871.68.0.444276628486.issue20643@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

In 3.4 docs after generator.close() description there is strange dot:
http://docs.python.org/3.4/reference/expressions.html#generator.close

Looks like it's due to following code in Doc/reference/expressions.rst:452:

.. class:: .

This line should be removed.

----------
assignee: docs at python
components: Documentation
messages: 211364
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: Strange dot in documentation (after generator.close)
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 16 23:43:21 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 16 Feb 2014 22:43:21 +0000
Subject: [New-bugs-announce] [issue20644] OS X installer build broken by
	changes to documentation	build
Message-ID: <1392590601.44.0.499989411789.issue20644@psf.upfronthosting.co.za>


New submission from Ned Deily:

eef7899ea7ab introduces changes to the documentation build process which inadvertently breaks OS X installer builds.  See, for example:

http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513

Mac/BuildInstaller/build-installer.py should be modified to accommodate the changes and, if necessary, the dmg buildbot updated.

BTW, the above change should not be cherry-picked into 3.4 until this issue is addressed.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 211365
nosy: georg.brandl, ned.deily
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: OS X installer build broken by changes to documentation build
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb 17 00:32:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Feb 2014 23:32:19 +0000
Subject: [New-bugs-announce] [issue20645] 3.4 cherry-pick: 1166b3321012
	Revert changes of issue	#19466 (clear thread state earlier)
Message-ID: <1392593539.2.0.11468516428.issue20645@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I modified Python shutdown process in issue #19466 to clear Python thread state earlier, but it introduced a regression: #20526. So I simply reverted my changes until the real bugs are fixed.

Changeset of the revert: 1166b3321012.

----------
assignee: larry
messages: 211373
nosy: haypo, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 1166b3321012 Revert changes of issue #19466 (clear thread state earlier)
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 00:34:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Feb 2014 23:34:35 +0000
Subject: [New-bugs-announce] [issue20646] 3.4 cherry-pick: 180e4b678003
	select and kqueue round	the timeout aways from zero
Message-ID: <1392593675.89.0.447373005495.issue20646@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3.4, poll and epoll were modified to round the timeout away from zero to fix a performance issue in asyncio. I also modified select and kqueue for the same reason.

changeset:   89230:180e4b678003
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Mon Feb 17 00:02:43 2014 +0100
files:       Include/pytime.h Lib/test/test_time.py Misc/NEWS Modules/_datetimemodule.c Modules/_testcapimod
description:
Issue #20320: select.select() and select.kqueue.control() now round the timeout
aways from zero, instead of rounding towards zero.

It should make test_asyncio more reliable, especially test_timeout_rounding() test.

----------
assignee: larry
messages: 211374
nosy: haypo, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 180e4b678003 select and kqueue round the timeout aways from zero
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 00:35:58 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Feb 2014 23:35:58 +0000
Subject: [New-bugs-announce] [issue20647] 3.4 cherry-pick: d50a95fab002
	add	tracemalloc.Traceback.format() method
Message-ID: <1392593758.89.0.463975396834.issue20647@psf.upfronthosting.co.za>


New submission from STINNER Victor:

As the author of the new tracemalloc of Python 3.4, I would to see this new method in Python 3.4 final. See issue #20616 for more information.

changeset:   89229:d50a95fab002
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Sun Feb 16 23:53:38 2014 +0100
files:       Doc/library/tracemalloc.rst Lib/test/test_tracemalloc.py Lib/tracemalloc.py Misc/NEWS
description:
Issue #20616: Add a format() method to tracemalloc.Traceback.

----------
assignee: larry
messages: 211375
nosy: haypo, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: d50a95fab002 add tracemalloc.Traceback.format() method
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 00:54:20 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Feb 2014 23:54:20 +0000
Subject: [New-bugs-announce] [issue20648] 3.4 cherry-pick: multiple
	changesets for asyncio
Message-ID: <1392594860.24.0.287895763388.issue20648@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I consider that it's not too late to include these changes to Python 3.4 final because asyncio module is new in Python 3.4. Very few people outside asyncio developers are testing asyncio, so it's not surprising to see these changes only recently. asyncio received a lot of love recently, and it was even more improved.

Most recent to oldest.
----------------------------------------
changeset:   89183:3b0a1b3c0022
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Thu Feb 13 10:46:05 2014 +0100
files:       Lib/test/test_asyncio/test_events.py
description:
Fix test_asyncio/test_events.py: skip IPv6 if IPv6 is disabled on the host


changeset:   89179:95de14f53cf5
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Thu Feb 13 09:24:37 2014 +0100
files:       Doc/library/asyncio-eventloop.rst Lib/asyncio/base_events.py Lib/asyncio/proactor_events.py Lib
description:
ayncio, Tulip issue 129: BaseEventLoop.sock_connect() now raises an error if
the address is not resolved (hostname instead of an IP address) for AF_INET and
AF_INET6 address families.


changeset:   89176:6e04027ed53e
user:        Guido van Rossum <guido at python.org>
date:        Wed Feb 12 17:58:19 2014 -0800
files:       Lib/asyncio/tasks.py Lib/test/test_asyncio/test_tasks.py
description:
asyncio: Change as_completed() to use a Queue, to avoid O(N**2) behavior. Fixes issue #20566.


changeset:   89175:920304e1f36b
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Wed Feb 12 17:01:52 2014 -0500
files:       Lib/asyncio/events.py
description:
asyncio.events: Use __slots__ in Handle and TimerHandle


changeset:   89157:2ba583191550
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Feb 11 18:40:56 2014 +0100
files:       Lib/test/test_asyncio/test_events.py
description:
Issue #20495: Skip test_read_pty_output() of test_asyncio on FreeBSD older than
FreeBSD 8


changeset:   89147:15a6be05e970
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Feb 11 11:54:08 2014 +0100
files:       Lib/asyncio/tasks.py Lib/test/test_asyncio/test_tasks.py
description:
asyncio, Tulip issue 131: as_completed() and wait() now raises a TypeError if
the list of futures is not a list but a Future, Task or coroutine object


changeset:   89146:f729e9ee5dfc
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Feb 11 11:44:56 2014 +0100
files:       Lib/asyncio/base_events.py Lib/asyncio/subprocess.py Lib/test/test_asyncio/test_base_events.py
description:
asyncio, Tulip issue 130: Add more checks on subprocess_exec/subprocess_shell
parameters


changeset:   89145:3ba4742a6fde
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Feb 11 11:34:30 2014 +0100
files:       Lib/asyncio/base_events.py Lib/asyncio/test_utils.py Lib/test/test_asyncio/test_base_events.py 
description:
asyncio, Tulip issue 126: call_soon(), call_soon_threadsafe(), call_later(),
call_at() and run_in_executor() now raise a TypeError if the callback is a
coroutine function.
----------------------------------------

Changesets related to debug can be ignored (03cb6ddc7040, 9c1840e8d643, a631b01d1715, 360976a6d8b9).

----------
assignee: larry
messages: 211379
nosy: gvanrossum, haypo, larry, yselivanov
priority: normal
severity: normal
status: open
title: 3.4 cherry-pick: multiple changesets for asyncio
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 03:38:24 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Feb 2014 02:38:24 +0000
Subject: [New-bugs-announce] [issue20649] Minor grammatical mistake for
	asyncio dev docs
Message-ID: <1392604704.61.0.488879832991.issue20649@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://docs.python.org/3.4/library/asyncio-dev.html

"While a task in running in the event loop" should be "a task is running".

----------
assignee: brett.cannon
components: Documentation
messages: 211389
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Minor grammatical mistake for asyncio dev docs
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 17 03:46:29 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 Feb 2014 02:46:29 +0000
Subject: [New-bugs-announce] [issue20650]
	asyncio.BaseEventLoop.run_in_executor docs have awkward	wording
Message-ID: <1392605189.0.0.398827219779.issue20650@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://docs.python.org/3.4/library/asyncio-eventloop.html#asyncio.BaseEventLoop.run_in_executor

"executor is a Executor instance, the default executor is used if executor is None." could maybe be "The executor argument should be an Executor instance. The default executor is used if executor is None."

----------
assignee: brett.cannon
components: Documentation
messages: 211390
nosy: brett.cannon
priority: low
severity: normal
status: open
title: asyncio.BaseEventLoop.run_in_executor docs have awkward wording
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 17 04:12:59 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 17 Feb 2014 03:12:59 +0000
Subject: [New-bugs-announce] [issue20651] 3.4 cherry-pick: 52ab9e1ff46a
	rolls back bad zipimport	changes
Message-ID: <1392606779.0.0.518989364771.issue20651@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Please cherry-pick 52ab9e1ff46a to roll back the zipimport brokenness.
This is the change that fixes issue20621 which is causing a rapid 3.3.5 brown bag release.

----------
assignee: larry
messages: 211391
nosy: gregory.p.smith, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 52ab9e1ff46a rolls back bad zipimport changes
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 07:33:22 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 17 Feb 2014 06:33:22 +0000
Subject: [New-bugs-announce] [issue20652] Example in asyncio task gives
	resource warning
Message-ID: <1392618802.39.0.436656290548.issue20652@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>From http://docs.python.org/3.4/library/asyncio-task.html#example-future-with-run-until-complete

there is an example code:
import asyncio

@asyncio.coroutine
def slow_operation(future):
    yield from asyncio.sleep(1)
    future.set_result('Future in done!')

def got_result(future):
    print(future.result())
    loop.stop()

loop = asyncio.get_event_loop()
future = asyncio.Future()
asyncio.Task(slow_operation(future))
future.add_done_callback(got_result)
loop.run_forever()


I got this:
ethan at amiau:~/Documents/code/python/cpython3.4$ ./python /tmp/demo.py
Future in done!
sys:1: ResourceWarning: unclosed <socket object at 0x7feb49df1058>
sys:1: ResourceWarning: unclosed <socket object at 0x7feb493b48c8>

Here is the patch to shut off the resource warning.

----------
assignee: docs at python
components: Documentation
files: shut_off_resource_warning_run_forever_asyncio_example.patch
keywords: patch
messages: 211392
nosy: docs at python, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Example in asyncio task gives resource warning
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file34111/shut_off_resource_warning_run_forever_asyncio_example.patch

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

From report at bugs.python.org  Mon Feb 17 08:03:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Feb 2014 07:03:56 +0000
Subject: [New-bugs-announce] [issue20653] Pickle enums by name
Message-ID: <1392620636.86.0.161132453218.issue20653@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently enums are pickled by values. It means that if the value of enum is platform depending, pickling one enum you can unpickle other enum on other platform.

Here is a patch which makes enum pickling by name. It also get rid of not needed __getnewargs__().

See also discussions in issue20534 and on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/145536.

----------
components: Library (Lib)
files: enum_pickle_by_name.patch
keywords: patch
messages: 211394
nosy: alexandre.vassalotti, barry, eli.bendersky, ethan.furman, larry, pitrou, serhiy.storchaka
priority: release blocker
severity: normal
stage: patch review
status: open
title: Pickle enums by name
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34113/enum_pickle_by_name.patch

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

From report at bugs.python.org  Mon Feb 17 08:25:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Feb 2014 07:25:53 +0000
Subject: [New-bugs-announce] [issue20654] Pydoc (and help) fails with
	socket.AddressFamily
Message-ID: <1392621953.19.0.978789852007.issue20654@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m pydoc socket.AddressFamily
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2600, in <module>
    cli()
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2565, in cli
    help.help(arg)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1847, in help
    elif request: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1585, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 357, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1284, in docclass
    lambda t: t[1] == 'data')
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1248, in spilldata
    getattr(object, name, None) or homecls.__dict__[name],
KeyError: 'AF_UNSPEC'

But it works with other enum types: socket.SocketType, plistlib.PlistFormat, ssl.Purpose.

----------
components: Library (Lib)
messages: 211395
nosy: barry, eli.bendersky, ethan.furman, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Pydoc (and help) fails with socket.AddressFamily
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 09:28:15 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 17 Feb 2014 08:28:15 +0000
Subject: [New-bugs-announce] [issue20655] test_subprocess is not executed in
	python -m	test.test_asyncio
Message-ID: <1392625695.57.0.333016920564.issue20655@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

ethan at amiau:~/Documents/code/python/cpython3.4$ cat Lib/test/test_asyncio/tests.txt 
test_asyncio.test_base_events
test_asyncio.test_events
test_asyncio.test_futures
test_asyncio.test_locks
test_asyncio.test_proactor_events
test_asyncio.test_queues
test_asyncio.test_selector_events
test_asyncio.test_streams
test_asyncio.test_tasks
test_asyncio.test_transports
test_asyncio.test_unix_events
test_asyncio.test_windows_events
test_asyncio.test_windows_utils
ethan at amiau:~/Documents/code/python/cpython3.4$ ls Lib/test/test_asyncio/test_subprocess.py 
Lib/test/test_asyncio/test_subprocess.py

I provide two alternatives to fix this problem.

The first is to add subprocess in tests.txt.

----------
components: Tests
files: add_subprocess_to_tests.patch
keywords: patch
messages: 211398
nosy: gvanrossum, haypo, vajrasky
priority: normal
severity: normal
status: open
title: test_subprocess is not executed in python -m test.test_asyncio
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34114/add_subprocess_to_tests.patch

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

From report at bugs.python.org  Mon Feb 17 12:46:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2014 11:46:52 +0000
Subject: [New-bugs-announce] [issue20656] OpenBSD: timeval.tv_sec type is
	long, not time_t
Message-ID: <1392637612.12.0.776525840436.issue20656@psf.upfronthosting.co.za>


New submission from STINNER Victor:

select.select() doesn't work on OpenBSD 64-bit because timeval.tv_sec is a long, whereas Python uses a time_t.

Attached patch should fix this issue.

----------
messages: 211410
nosy: belopolsky, haypo, neologix, rpointel
priority: normal
severity: normal
status: open
title: OpenBSD: timeval.tv_sec type is long, not time_t
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 17 13:13:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2014 12:13:27 +0000
Subject: [New-bugs-announce] [issue20657] OpenBSD: Merge patches
Message-ID: <1392639207.52.0.881152822714.issue20657@psf.upfronthosting.co.za>


New submission from STINNER Victor:

OpenBSD has its own collection of patches for Python 3.3:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/3.3/patches/

These patches should be merged into Python directly.

----------
messages: 211413
nosy: haypo, rpointel
priority: normal
severity: normal
status: open
title: OpenBSD: Merge patches
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 17 14:06:08 2014
From: report at bugs.python.org (daniel hahler)
Date: Mon, 17 Feb 2014 13:06:08 +0000
Subject: [New-bugs-announce] [issue20658] os.environ.clear() fails with
	empty keys (posix.unsetenv)
Message-ID: <1392642368.27.0.300660634921.issue20658@psf.upfronthosting.co.za>


New submission from daniel hahler:

posix.unsetenv fails to clear the environment if there's an entry with an empty key.

TEST CASE:

    Python 2.7.6 (default, Jan  6 2014, 17:05:19) 
    [GCC 4.8.1] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.environ['']='foo'
    >>> os.environ.clear()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/path/to/python/2.7.6/lib/python2.7/os.py", line 499, in clear
        unsetenv(key)
    OSError: [Errno 22] Invalid argument

I believe that os.environ.clear() via unsetenv should handle empty keys.

----------
components: Interpreter Core
messages: 211415
nosy: blueyed
priority: normal
severity: normal
status: open
title: os.environ.clear() fails with empty keys (posix.unsetenv)
type: crash
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Feb 17 14:43:57 2014
From: report at bugs.python.org (the mulhern)
Date: Mon, 17 Feb 2014 13:43:57 +0000
Subject: [New-bugs-announce] [issue20659] Want to make a class method a
	property by combining	decorators
Message-ID: <1392644637.44.0.107261446205.issue20659@psf.upfronthosting.co.za>


New submission from the mulhern:

The problems is that it is quite possible to define a property using @property in a class and then later to realize that it really ought to be a class method, not an instance method. But then, if you change it to a class method, using @classmethod annotation, the @property annotation will fail to work. If you are a pedantic person, and name your properties differently than you name your methods, you have to:
1) Change all uses of this former property back to method invocations, with a "()"
2) Change the name, so it now reflects that it is an actual function, not a property any longer.

I think an @classproperty and an @staticproperty decorator would take this problem away.

An alternative would be to make it possible to chain @property and @classmethod. I know that this is sort of doable for ABC.abstractproperty which is now deprecated in favor of @property combined with @ABC.abstractmethod. This would be ideal, but I can not pretend to know if it would be possible. Also, I suspect that the order would matter as it does for ABC as described in http://bugs.python.org/issue16267.

----------
components: Library (Lib)
messages: 211416
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: Want to make a class method a property by combining decorators
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 17 16:47:05 2014
From: report at bugs.python.org (mythsmith)
Date: Mon, 17 Feb 2014 15:47:05 +0000
Subject: [New-bugs-announce] [issue20660] Starting a second
	multiprocessing.Manager causes INCREF	on all object created
	by the first one.
Message-ID: <1392652025.76.0.144236203024.issue20660@psf.upfronthosting.co.za>


New submission from mythsmith:

I seems that upon the start of a second manager, all objects referenced in the first one gets an INCREF. On the third start, all objects created by the first and the second manager get another INCREF. And so on. I cannot understand why the start of a totally new manager, in a new process, will cause all these INCREF about object hosted on other managers - which cause the program to take forever to start/stop.

This small script fully reproduces the behaviour, tested in python 2.7 and 3.2:

from __future__ import print_function
import multiprocessing, logging
# # Activate multiprocessing logging
mplog = multiprocessing.get_logger()
mplog.setLevel(multiprocessing.util.DEBUG)
mplog.addHandler(logging.StreamHandler())
objs=[]
def newman(n=50):
    global objs
    m=multiprocessing.Manager()
    print('created')
    for i in range(n):
        objs.append(m.Value('i',i)) 
    return m    

print('#### first man')
m1=newman()

print ('#### second man')
m2=newman()

print ('#### third man')
m3=newman(0)

(Output is attached)

After the start of the first manager, the logger prints out the messages relative to the creation of the first 50 objects.

But when the second manager is starting - before any object was created by it - the logger prints out exactly 50 INCREF messages.Then follows the messages relating to the creation of the 50 new objects on manager 2.

When the third manager starts - before any object was created by it - 100 more INCREF messages are printed.

No object creation message is seen after m3 creation, as I passed 0 to the newman() function.

When the program ends, a similar amount of DECREF messages is printed.

It seems that, when I start a new manager, it creates a reference to all objects referenced by previous managers. In a big application this translates into extremely slow startup/shutdown.

----------
components: Library (Lib)
files: output.txt
messages: 211421
nosy: mythsmith
priority: normal
severity: normal
status: open
title: Starting a second multiprocessing.Manager causes INCREF on all object created by the first one.
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file34121/output.txt

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

From report at bugs.python.org  Mon Feb 17 17:35:57 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 17 Feb 2014 16:35:57 +0000
Subject: [New-bugs-announce] [issue20661] 3.4 cherry-pick: eef7899ea7ab use
	system doc toolchain	instead of checking out of svn
Message-ID: <1392654957.39.0.555402470038.issue20661@psf.upfronthosting.co.za>


New submission from Georg Brandl:

3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn

----------
assignee: larry
messages: 211423
nosy: georg.brandl, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 18:08:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Feb 2014 17:08:17 +0000
Subject: [New-bugs-announce] [issue20662] Pydoc doesn't escape parameter
	defaults in html
Message-ID: <1392656897.9.0.470928651824.issue20662@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Pydoc doesn't escape parameter defaults in generated html files. For example for the socket.__init__() method in the socket module following html code is generated:

<dl><dt><a name="socket-__init__"><strong>__init__</strong></a>(self, family=<AddressFamily.AF_INET: 2>, type=<SocketType.SOCK_STREAM: 1>, proto=0, fileno=None)</dt></dl>

As result <AddressFamily.AF_INET: 2> and <SocketType.SOCK_STREAM: 1> aren't visible in browser (they are illegal html tags).

----------
components: Library (Lib)
messages: 211426
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Pydoc doesn't escape parameter defaults in html
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 17 18:43:47 2014
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 17 Feb 2014 17:43:47 +0000
Subject: [New-bugs-announce] [issue20663] Introduce exception argument to
	iter
Message-ID: <1392659027.56.0.320916972318.issue20663@psf.upfronthosting.co.za>


New submission from Ram Rachum:

See discussion: https://groups.google.com/forum/#!searchin/python-ideas/iter/python-ideas/UCaNfAHkBlQ/5vX7JbpCxDkJ

`iter` has a very cool `sentinel` argument. I suggest an additional argument `exception`; when it's supplied, instead of waiting for a sentinel value, we wait for a sentinel exception to be raised, and then the iteration is finished.

This'll be useful to construct things like this: 

    my_iterator = iter(my_deque.popleft, exception=IndexError)

I also suggest being able to pass multiple exceptions in a tuple to have any of them trigger a `StopIteration`.

----------
components: Interpreter Core
messages: 211431
nosy: cool-RR, terry.reedy
priority: normal
severity: normal
status: open
title: Introduce exception argument to iter
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb 17 21:25:40 2014
From: report at bugs.python.org (Ryan Gordon)
Date: Mon, 17 Feb 2014 20:25:40 +0000
Subject: [New-bugs-announce] [issue20664] _findLib_crle and _get_soname
	broken on latest SunOS 5.11
Message-ID: <1392668740.39.0.330236898998.issue20664@psf.upfronthosting.co.za>


New submission from Ryan Gordon:

On SunOS 5.11, both the _findLib_crle and _get_soname are broken.

With _findLib_crle, the function returns the following:

# env LC_ALL=C /usr/bin/crle -64

Default configuration file (/var/ld/64/ld.config) not found
  Platform:     64-bit LSB AMD64
  Default Library Path (ELF):   /lib/64:/usr/lib/64  (system default)
  Trusted Directories (ELF):    /lib/secure/64:/usr/lib/secure/64  (system default)

# env LC_ALL=C /usr/bin/crle

Configuration file [version 4]: /var/ld/ld.config  
  Platform:     32-bit LSB 80386
  Default Library Path (ELF):   /lib:/usr/lib
  Trusted Directories (ELF):    /lib/secure:/usr/lib/secure  (system default)

Command line:
  crle -c /var/ld/ld.config -l /lib:/usr/lib

The "Default Library Path (ELF):   /lib:/usr/lib" is extracted to "/lib:/usr/lib" and only those two paths are checked for the library in question. Unfortunately this means that there is absolutely no way to configure any environment variable to check on other paths and both /lib and /usr/lib are read-only directories mounted from the global zone:

[ /usr/lib] # touch test.txt
touch: cannot touch `test': Read-only file system
[ /lib] # touch test.txt
touch: cannot touch `test': Read-only file system

An environment variable should be read in that can be configured to override this functionality.

The second issue with _get_soname is that is calls /usr/ccs/bin/dump which doesn't exist at all: (/usr/ccs/bin/ is an old deprecated directory which has since been removed)

# ll /usr/ccs/bin/dump
ls: cannot access /usr/ccs/bin/dump: No such file or directory

----------
components: ctypes
messages: 211438
nosy: rygorde4
priority: normal
severity: normal
status: open
title: _findLib_crle and _get_soname broken on latest SunOS 5.11
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/issue20664>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:24:18 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 17 Feb 2014 21:24:18 +0000
Subject: [New-bugs-announce] [issue20665] 3.4 cherry-pick: 400a8e4599d9
	rename posix_close to	avoid namespace clash
Message-ID: <1392672258.73.0.515748013959.issue20665@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Creating new issue from #20594 to track cherry-picking this into 3.4.0.

----------
assignee: larry
components: Build
messages: 211439
nosy: larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: 400a8e4599d9 rename posix_close to avoid namespace clash
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 00:42:54 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2014 23:42:54 +0000
Subject: [New-bugs-announce] [issue20666] asyncio/OpenBSD: make
	concurrent.futures dependency	optional
Message-ID: <1392680574.83.0.750264153214.issue20666@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On old FreeBSD versions and on the latest OpenBSD (5.4), the multiprocessing module is not available because POSIX semaphores are not supported by the OS. See issues #5725 and #10348 to use SysV semaphores. #10348 was closed because "implementing SysV semaphores would be a step backwards, plus the API is a real pain" (wrote Charles-Fran?ois Natali).

Would it be possible to make concurrent.futures dependency optional? In Trollius project (port of asyncio on Python 2), I implemented a very simple synchronous executor used by default as a fallback when concurrent.futures is not available (Trollius uses futures, backport of concurrent.futures for Python 2).

Attached patch is the synchronous executor adapted again on asyncio.

asyncio.executor.Future (when concurrent.futures is missing) is the simplest class and has a different API than concurrent.futures.Future. It is directly created with known result (value or exeption).

----------
files: synchronous_executor.patch
keywords: patch
messages: 211457
nosy: gvanrossum, haypo, rpointel
priority: normal
severity: normal
status: open
title: asyncio/OpenBSD: make concurrent.futures dependency optional
Added file: http://bugs.python.org/file34122/synchronous_executor.patch

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

From report at bugs.python.org  Tue Feb 18 00:48:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2014 23:48:55 +0000
Subject: [New-bugs-announce] [issue20667] asyncio: test_read_pty_output() of
	test_asyncio hangs on	OpenBSD 5.4
Message-ID: <1392680935.11.0.3683180426.issue20667@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_read_pty_output() hangs on OpenBSD 5.4, as it hangs on Mac OS older than 10.9 and FreeBSD. Attached patch skips the test.

See also issue #20666: asyncio is not available yet on OpenBSD.

----------
messages: 211458
nosy: haypo
priority: normal
severity: normal
status: open
title: asyncio: test_read_pty_output() of test_asyncio hangs on OpenBSD 5.4
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 05:45:42 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 18 Feb 2014 04:45:42 +0000
Subject: [New-bugs-announce] [issue20668] Remove dependency on tests.txt
	when running test_asyncio	suite
Message-ID: <1392698742.57.0.282211048507.issue20668@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

We can run the whole asyncio tests by using this command:
./python -m test.test_asyncio

But this way depends on the Lib/test/test_asyncio/tests.txt which contains all the tests that need to be executed. The problem is the core developer may forget to modify the tests.txt if he/she wants to add new test in asyncio test suite. Guido may not forget about it. But Victor forgot to modify the tests.txt when he added test_subprocess.py in asyncio tests suite.

So the proposed patch removes dependency on tests.txt file. When core developers add new test in asyncio tests suite, they just need to add the new file in test_asyncio directory itself. This patch was inspired by Lib/test/test_json/__init__.py.

----------
components: Tests
files: automatic_find_tests_inside_asyncio_test_suite.patch
keywords: patch
messages: 211477
nosy: gvanrossum, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Remove dependency on tests.txt when running test_asyncio suite
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34129/automatic_find_tests_inside_asyncio_test_suite.patch

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

From report at bugs.python.org  Tue Feb 18 09:41:31 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2014 08:41:31 +0000
Subject: [New-bugs-announce] [issue20669] OpenBSD: socket.recvmsg tests fail
	with OSError: [Errno	40] Message too long
Message-ID: <1392712891.31.0.830541329801.issue20669@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/14/steps/test/logs/stdio

======================================================================
ERROR: testCmsgTrunc1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2857, in testCmsgTrunc1
    self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTrunc2Int (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2867, in testCmsgTrunc2Int
    SIZEOF_INT * 2))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2907, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0Minus1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2874, in testCmsgTruncLen0Minus1
    socket.CMSG_LEN(0) - 1))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0Plus1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2913, in testCmsgTruncLen0Plus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2920, in testCmsgTruncLen1
    maxdata=SIZEOF_INT)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen2Minus1 (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2927, in testCmsgTruncLen2Minus1
    maxdata=(2 * SIZEOF_INT) - 1)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1872, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2722, in _testFDPassSeparate
    array.array("i", [fd1]))]),
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2746, in _testFDPassSeparateMinSpace
    array.array("i", [fd1]))]),
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testCmsgTrunc1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2857, in testCmsgTrunc1
    self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTrunc2Int (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2867, in testCmsgTrunc2Int
    SIZEOF_INT * 2))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2907, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0Minus1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2874, in testCmsgTruncLen0Minus1
    socket.CMSG_LEN(0) - 1))
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen0Plus1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2913, in testCmsgTruncLen0Plus1
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2920, in testCmsgTruncLen1
    maxdata=SIZEOF_INT)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testCmsgTruncLen2Minus1 (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2927, in testCmsgTruncLen2Minus1
    maxdata=(2 * SIZEOF_INT) - 1)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2888, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1963, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
OSError: [Errno 40] Message too long

======================================================================
ERROR: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2722, in _testFDPassSeparate
    array.array("i", [fd1]))]),
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2746, in _testFDPassSeparateMinSpace
    array.array("i", [fd1]))]),
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
FAIL: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2710, in testFDPassSeparate
    maxcmsgs=2)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2734, in testFDPassSeparateMinSpace
    maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2710, in testFDPassSeparate
    maxcmsgs=2)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2734, in testFDPassSeparateMinSpace
    maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

----------
messages: 211493
nosy: haypo, rpointel
priority: normal
severity: normal
status: open
title: OpenBSD: socket.recvmsg tests fail with OSError: [Errno 40] Message too long
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 10:07:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2014 09:07:33 +0000
Subject: [New-bugs-announce] [issue20670] 3.4 cherry-pick: 2dd4922c9371 set
	line and column	numbers for keyword-only arg nodes (#20619)
Message-ID: <1392714453.12.0.141679189869.issue20670@psf.upfronthosting.co.za>


New submission from STINNER Victor:

New changeset 2dd4922c9371 by Benjamin Peterson in branch 'default':
set line and column numbers for keyword-only arg nodes (closes #20619)
http://hg.python.org/cpython/rev/2dd4922c9371

----------
assignee: larry
messages: 211497
nosy: haypo, larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 2dd4922c9371 set line and column numbers for keyword-only arg nodes (#20619)
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 10:48:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2014 09:48:46 +0000
Subject: [New-bugs-announce] [issue20671]
	test_create_at_shutdown_with_encoding() of test_io hangs	on
	"SPARC Solaris 10 OpenCSW 3.x"
Message-ID: <1392716926.59.0.731308582438.issue20671@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20OpenCSW%203.x/builds/813/steps/test/logs/stdio

[162/389/1] test_io
Timeout (1:00:00)!
Current thread 0x00000001 (most recent call first):
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/subprocess.py", line 1378 in _execute_child
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/subprocess.py", line 850 in __init__
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/script_helper.py", line 43 in _assert_python
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/script_helper.py", line 69 in assert_python_ok
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/test_io.py", line 2667 in _check_create_at_shutdown
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/test_io.py", line 2680 in test_create_at_shutdown_with_encoding
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/case.py", line 574 in run
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/case.py", line 622 in __call__
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 125 in run
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 87 in __call__
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 125 in run
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 87 in __call__
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 125 in run
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/suite.py", line 87 in __call__
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/unittest/runner.py", line 168 in run
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/regrtest.py", line 1277 in <lambda>
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/regrtest.py", line 967 in runtest
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/regrtest.py", line 763 in main
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/__main__.py", line 3 in <module>
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/runpy.py", line 86 in _run_code
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/runpy.py", line 171 in _run_module_as_main

----------
components: Tests
keywords: buildbot
messages: 211502
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_create_at_shutdown_with_encoding() of test_io hangs on "SPARC Solaris 10 OpenCSW 3.x"
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 10:51:09 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2014 09:51:09 +0000
Subject: [New-bugs-announce] [issue20672] test_list() of test_tarfile fails
	on
Message-ID: <1392717069.18.0.979881425204.issue20672@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1728/steps/test/logs/stdio

======================================================================
FAIL: test_list (test.test_tarfile.Bz2ListTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_tarfile.py", line 244, in test_list
    br'\udcc4\udcd6\udcdc\udce4\udcf6\udcfc\udcdf', out)
AssertionError: b'ustar/umlauts-\\udcc4\\udcd6\\udcdc\\udce4\\udcf6\\udcfc\\udcdf' not found in b'ustar/conttype \nustar/regtype \nustar/dirtype/ \nustar/dirtype-with-size/ \nustar/lnktype \nustar/symtype \nustar/blktype \nustar/chrtype \nustar/fifotype \nustar/sparse \nustar/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nustar/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/1234567/longname \n./ustar/linktest2/symtype \nustar/linktest1/regtype \n./ustar/linktest2/lnktype \nsymtype2 \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \ngnu/sparse \ngnu/sparse-0.0 \ngnu/sparse-0.1 \ngnu/sparse-1.0 \ngnu/regtype-gnu-uid \nmisc/regtype-old-v7 \nmisc/regtype-hpux-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/regtype-old-v7-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/dirtype-old-v7/ \nmisc/regtype-suntar \nmisc/regtype-xstar \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \npax/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \npax/regtype1 \npax/regtype2 \npax/regtype3 \npax/regtype4 \npax/bad-pax-\\xe4\\xf6\\xfc \npax/hdrcharset-\\xe4\\xf6\\xfc \nmisc/eof \n'

======================================================================
FAIL: test_list (test.test_tarfile.GzipListTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_tarfile.py", line 244, in test_list
    br'\udcc4\udcd6\udcdc\udce4\udcf6\udcfc\udcdf', out)
AssertionError: b'ustar/umlauts-\\udcc4\\udcd6\\udcdc\\udce4\\udcf6\\udcfc\\udcdf' not found in b'ustar/conttype \nustar/regtype \nustar/dirtype/ \nustar/dirtype-with-size/ \nustar/lnktype \nustar/symtype \nustar/blktype \nustar/chrtype \nustar/fifotype \nustar/sparse \nustar/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nustar/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/1234567/longname \n./ustar/linktest2/symtype \nustar/linktest1/regtype \n./ustar/linktest2/lnktype \nsymtype2 \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \ngnu/sparse \ngnu/sparse-0.0 \ngnu/sparse-0.1 \ngnu/sparse-1.0 \ngnu/regtype-gnu-uid \nmisc/regtype-old-v7 \nmisc/regtype-hpux-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/regtype-old-v7-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/dirtype-old-v7/ \nmisc/regtype-suntar \nmisc/regtype-xstar \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \npax/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \npax/regtype1 \npax/regtype2 \npax/regtype3 \npax/regtype4 \npax/bad-pax-\\xe4\\xf6\\xfc \npax/hdrcharset-\\xe4\\xf6\\xfc \nmisc/eof \n'

======================================================================
FAIL: test_list (test.test_tarfile.ListTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_tarfile.py", line 244, in test_list
    br'\udcc4\udcd6\udcdc\udce4\udcf6\udcfc\udcdf', out)
AssertionError: b'ustar/umlauts-\\udcc4\\udcd6\\udcdc\\udce4\\udcf6\\udcfc\\udcdf' not found in b'ustar/conttype \nustar/regtype \nustar/dirtype/ \nustar/dirtype-with-size/ \nustar/lnktype \nustar/symtype \nustar/blktype \nustar/chrtype \nustar/fifotype \nustar/sparse \nustar/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nustar/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/12345/1234567/longname \n./ustar/linktest2/symtype \nustar/linktest1/regtype \n./ustar/linktest2/lnktype \nsymtype2 \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \ngnu/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \ngnu/sparse \ngnu/sparse-0.0 \ngnu/sparse-0.1 \ngnu/sparse-1.0 \ngnu/regtype-gnu-uid \nmisc/regtype-old-v7 \nmisc/regtype-hpux-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/regtype-old-v7-signed-chksum-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \nmisc/dirtype-old-v7/ \nmisc/regtype-suntar \nmisc/regtype-xstar \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longname \npax/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/123/longlink \npax/umlauts-\\xc4\\xd6\\xdc\\xe4\\xf6\\xfc\\xdf \npax/regtype1 \npax/regtype2 \npax/regtype3 \npax/regtype4 \npax/bad-pax-\\xe4\\xf6\\xfc \npax/hdrcharset-\\xe4\\xf6\\xfc \nmisc/eof \n'

----------
components: Tests
keywords: buildbot
messages: 211503
nosy: haypo, lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_list() of test_tarfile fails on
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 18:19:33 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Feb 2014 17:19:33 +0000
Subject: [New-bugs-announce] [issue20673] asyncio: Add support for UNIX
	Domain Sockets.
Message-ID: <1392743973.08.0.666395149529.issue20673@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This is a proxy issue for: https://code.google.com/p/tulip/issues/detail?id=81

----------
assignee: yselivanov
messages: 211523
nosy: yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Add support for UNIX Domain Sockets.
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 18:33:15 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Feb 2014 17:33:15 +0000
Subject: [New-bugs-announce] [issue20674] Update comments in dictobject.c
Message-ID: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The hash function comments in Objects/dictobject.c no longer match the implementation:

"""
/*                                                                                                                                
Major subtleties ahead:  Most hash schemes depend on having a "good" hash                                                         
function, in the sense of simulating randomness.  Python doesn't:  its most                                                       
important hash functions (for strings and ints) are very regular in common                                                        
cases:                                                                                                                            
                                                                                                                                  
  >>> map(hash, (0, 1, 2, 3))                                                                                                     
  [0, 1, 2, 3]                                                                                                                    
  >>> map(hash, ("namea", "nameb", "namec", "named"))                                                                             
  [-1658398457, -1658398460, -1658398459, -1658398462]                                                                            
  >>>                                                                                                                             
                                                                                                                                  
This isn't necessarily bad!  To the contrary, in a table of size 2**i, taking                                                     
the low-order i bits as the initial table index is extremely fast, and there                                                      
are no collisions at all for dicts indexed by a contiguous range of ints.                                                         
The same is approximately true when keys are "consecutive" strings.  So this                                                      
gives better-than-random behavior in common cases, and that's very desirable. 
"""

----------
assignee: christian.heimes
messages: 211525
nosy: christian.heimes, rhettinger
priority: low
severity: normal
status: open
title: Update comments in dictobject.c
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 18:44:23 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 18 Feb 2014 17:44:23 +0000
Subject: [New-bugs-announce] [issue20675] 3.4 cherry-pick: 69d13cdc4eeb fix
	64-bit build on 32-bit	Windows
Message-ID: <1392745463.33.0.631274313095.issue20675@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I broke cross-building 64-bit binaries on 32-bit Windows in issue #19788, 69d13cdc4eeb fixes it.

----------
assignee: larry
components: Build, Windows
messages: 211529
nosy: larry, zach.ware
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: 69d13cdc4eeb fix 64-bit build on 32-bit Windows
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 19:01:59 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Feb 2014 18:01:59 +0000
Subject: [New-bugs-announce] [issue20676] 3.4 cherry-pick: a63327162063
	Mangle __parameters in	__annotations__ dict properly
Message-ID: <1392746519.33.0.906509190596.issue20676@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Revision: a63327162063

Larry, please consider including this in 3.4.

It's a small bug, that was in python since the time
annotations were introduced. It's a shame that it
was undiscovered for such a long time, and I think
it should absolutely be fixed in 3.4, especially
if taking into account all improvements of 
'inspect.signature()'.

The patch is really small, so it's easily reviewable.

----------
assignee: larry
messages: 211533
nosy: larry, yselivanov
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: a63327162063 Mangle __parameters in __annotations__ dict properly
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 19:25:07 2014
From: report at bugs.python.org (flashk)
Date: Tue, 18 Feb 2014 18:25:07 +0000
Subject: [New-bugs-announce] [issue20677] Minor typo in enum docs
Message-ID: <1392747907.16.0.237533745689.issue20677@psf.upfronthosting.co.za>


New submission from flashk:

On line 142 in the enum library documentation, I believe the text is missing "you". It should be changed from:

"If have an enum member and need its name or value:"

to:

"If you have an enum member and need its name or value:"

----------
assignee: docs at python
components: Documentation
messages: 211536
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Minor typo in enum docs
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 21:43:28 2014
From: report at bugs.python.org (steven Michalske)
Date: Tue, 18 Feb 2014 20:43:28 +0000
Subject: [New-bugs-announce] [issue20678] re does not allow back references
	in {} matching operator
Message-ID: <1392756208.32.0.772076498816.issue20678@psf.upfronthosting.co.za>


New submission from steven Michalske:

When writing a regular expression to match the following text.

d = """num interesting lines: 3
1
2
3
foo"""

# I only want to match the interesting lines.

m = re.match(".+?: (\d+)\n((?:.+\n){\1})", d)
print(m)
# prints: None
# Expected a match object.
print(m.groups())
# Causes Exception.
# Expected: ('3', '1\n2\n3\n')

# Works with hard coded match length.
m = re.match(".+?: (\d+)\n((?:.+\n){3})", d)
print(m.groups())
('3', '1\n2\n3\n')

Workaround it to have two regular expressions.  one to extract the desired length the second to extract the interesting lines.

----------
components: Regular Expressions
messages: 211551
nosy: ezio.melotti, hardkrash, mrabarnett
priority: normal
severity: normal
status: open
title: re does not allow back references in {} matching operator
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Feb 18 21:47:05 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 18 Feb 2014 20:47:05 +0000
Subject: [New-bugs-announce] [issue20679] 3.4 cherry-pick: 587fd4b91120
	improve Enum subclass	behavior
Message-ID: <1392756425.14.0.333766602859.issue20679@psf.upfronthosting.co.za>


New submission from Ethan Furman:

587fd4b91120: Better pickle support for Enum subclasses.

----------
assignee: larry
messages: 211552
nosy: ethan.furman, larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: 587fd4b91120  improve Enum subclass behavior
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 18 22:13:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Feb 2014 21:13:59 +0000
Subject: [New-bugs-announce] [issue20680] Pickle socket enums by names
Message-ID: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

As far as socked enums are platform depending, pickling them by value makes not much sense. Here is a patch which makes AddressFamily and SocketType members be pickled by name.

----------
components: Library (Lib)
files: socket_enums_pickle_by_name.patch
keywords: patch
messages: 211559
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle socket enums by names
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34140/socket_enums_pickle_by_name.patch

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

From report at bugs.python.org  Tue Feb 18 23:57:25 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Feb 2014 22:57:25 +0000
Subject: [New-bugs-announce] [issue20681] asyncio: New error handling API
Message-ID: <1392764245.62.0.108852858224.issue20681@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This is a proxy issue for https://code.google.com/p/tulip/issues/detail?id=80

----------
assignee: yselivanov
messages: 211566
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: New error handling API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 19 02:01:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Feb 2014 01:01:55 +0000
Subject: [New-bugs-announce] [issue20682] test_create_ssl_unix_connection()
	of test_asyncio failed	on "x86 Tiger 3.x"
Message-ID: <1392771715.34.0.287107007832.issue20682@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7907/steps/test/logs/stdio

======================================================================
FAIL: test_create_ssl_unix_connection (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 581, in test_create_ssl_unix_connection
    self._basetest_create_ssl_connection(conn_fut)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 556, in _basetest_create_ssl_connection
    self.assertIsNotNone(tr.get_extra_info('sockname'))
AssertionError: unexpectedly None

======================================================================
FAIL: test_create_ssl_unix_connection (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 581, in test_create_ssl_unix_connection
    self._basetest_create_ssl_connection(conn_fut)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 556, in _basetest_create_ssl_connection
    self.assertIsNotNone(tr.get_extra_info('sockname'))
AssertionError: unexpectedly None

======================================================================
FAIL: test_create_ssl_unix_connection (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 581, in test_create_ssl_unix_connection
    self._basetest_create_ssl_connection(conn_fut)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 556, in _basetest_create_ssl_connection
    self.assertIsNotNone(tr.get_extra_info('sockname'))
AssertionError: unexpectedly None

----------
messages: 211579
nosy: haypo, yselivanov
priority: normal
severity: normal
status: open
title: test_create_ssl_unix_connection() of test_asyncio failed on "x86 Tiger 3.x"

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

From report at bugs.python.org  Wed Feb 19 09:27:32 2014
From: report at bugs.python.org (Karl Richter)
Date: Wed, 19 Feb 2014 08:27:32 +0000
Subject: [New-bugs-announce] [issue20683] [doc] Ease comprehension of
	section 9.2 of docs for	Python 2 and 3 with example
Message-ID: <1392798452.78.0.903259935516.issue20683@psf.upfronthosting.co.za>


New submission from Karl Richter:

The explanation of namespaces in section 9.2 in documentation (http://docs.python.org/3/tutorial/classes.html#python-scopes-and-namespaces) is just so complicated without (at least one tiny) example. The example would ease the comprehension of the section by a high factor.

----------
assignee: docs at python
components: Documentation
messages: 211607
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: [doc] Ease comprehension of section 9.2 of docs for Python 2 and 3 with example
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 19 13:40:21 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Feb 2014 12:40:21 +0000
Subject: [New-bugs-announce] [issue20684] inspect.getfullargspec (etc)
	incorrectly follow	__wrapped__ chains
Message-ID: <1392813621.68.0.712139176055.issue20684@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In a comment on issue 17482, Mike Bayer pointed out a backwards incompatibility resulting from changing inspect.getfullargspec (etc) to rely on inspect.signature: they now follow __wrapped__ chains, where previously they ignored them.

This means that instead of reporting the exact signature of the *wrapper*, they now report the signature of the wrapped function instead.

Since switching these functions from ignoring __wrapped__ to following it is an unintended backwards incompatible change, I'll tweak the code to bypass the unravelling of wrapper chains in the getfullargspec case.

----------
components: Library (Lib)
keywords: 3.4regression
messages: 211609
nosy: larry, ncoghlan, yselivanov
priority: release blocker
severity: normal
stage: test needed
status: open
title: inspect.getfullargspec (etc) incorrectly follow __wrapped__ chains
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 19 14:41:00 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Feb 2014 13:41:00 +0000
Subject: [New-bugs-announce] [issue20685] 3.4 cherry pick: 9f76adbac8b7
	better handling of missing	SSL/TLS in ensurepip
Message-ID: <1392817260.29.0.689452969721.issue20685@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This change ensures make install and make altinstall still work in builds without SSL/TLS.

New changeset 9f76adbac8b7 by Nick Coghlan in branch 'default':
Issue #19744: Handle missing SSL/TLS in ensurepip
http://hg.python.org/cpython/rev/9f76adbac8b7

----------
assignee: larry
messages: 211618
nosy: larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: 3.4 cherry pick: 9f76adbac8b7 better handling of missing SSL/TLS in ensurepip

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

From report at bugs.python.org  Wed Feb 19 17:24:55 2014
From: report at bugs.python.org (Daniel U. Thibault)
Date: Wed, 19 Feb 2014 16:24:55 +0000
Subject: [New-bugs-announce] [issue20686] Confusing statement
Message-ID: <1392827095.92.0.836578340147.issue20686@psf.upfronthosting.co.za>


New submission from Daniel U. Thibault:

Near the end of 3.1.3 http://docs.python.org/2/tutorial/introduction.html#unicode-strings you can read:

"When a Unicode string is printed, written to a file, or converted with str(), conversion takes place using this default encoding."

This can be interpreted as stating that stating that printing a Unicode string (using the print function or the shell's default print behaviour) results in ASCII printout.  It can likewise be interpreted as stating that any write of a Unicode string to a file converts the string to ASCII.  Experimentation shows this is not true.  Perhaps you meant something like this:

"When a Unicode string is converted with str() in order to be printed or written to a file, conversion takes place using this default encoding."

Grammatical comments: In the statement "When a Unicode string is printed, written to a file, or converted with str(), conversion takes place using this default encoding.", the ", or" puts the three elements of the enumeration on the same level (respectively "printed", "written to a file", and "converted with str()"). The confusion seems to arise because "with str()" was meant to apply to the list as a whole, not just its last element.

----------
assignee: docs at python
components: Documentation
messages: 211627
nosy: Daniel.U..Thibault, docs at python
priority: normal
severity: normal
status: open
title: Confusing statement
type: enhancement

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

From report at bugs.python.org  Wed Feb 19 19:20:23 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Feb 2014 18:20:23 +0000
Subject: [New-bugs-announce] [issue20687] Change in expectedFailure breaks
	testtools
Message-ID: <1392834023.44.0.231798434214.issue20687@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

The change for issue #16997 82844:5c09e1c57200 introduced a regression with testtools.  See attached file and instructions for reproducing it (it requires the testtools package).

----------
components: Library (Lib)
files: test_expected_failure.py
keywords: 3.4regression
messages: 211636
nosy: barry
priority: normal
severity: normal
status: open
title: Change in expectedFailure breaks testtools
versions: Python 3.4
Added file: http://bugs.python.org/file34144/test_expected_failure.py

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

From report at bugs.python.org  Wed Feb 19 22:34:35 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Feb 2014 21:34:35 +0000
Subject: [New-bugs-announce] [issue20688] 3.4 cherry-pick: 65fb95578f94
	inspect: Fix	getfullargspec() to not to follow __wrapped__ chains
Message-ID: <1392845675.91.0.000370581603386.issue20688@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Larry, please consider cherry-picking this in 3.4.0.

The main motivation to have this in 3.4.0 is to avoid introducing a backwards incompatible change in inspect.getfullargspec() and inspect.getargspec() semantics.


changeset:   89284:65fb95578f94
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Wed Feb 19 16:27:23 2014 -0500
files:       Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS
description:
inspect: Fix getfullargspec() to not to follow __wrapped__ chains

Initial patch by Nick Coghlan.

----------
assignee: larry
messages: 211660
nosy: larry, ncoghlan, yselivanov
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 65fb95578f94 inspect: Fix getfullargspec() to not to follow __wrapped__ chains
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 19 22:43:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Feb 2014 21:43:51 +0000
Subject: [New-bugs-announce] [issue20689] socket.AddressFamily is absent in
	html pydoc
Message-ID: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation for socket.AddressFamily (unlike to SocketType) isn't generated in html page by pydoc.

May be issue20654 is similar to this issue.

----------
components: Library (Lib)
messages: 211662
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: socket.AddressFamily is absent in html pydoc
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 19 23:08:56 2014
From: report at bugs.python.org (Justin Barker)
Date: Wed, 19 Feb 2014 22:08:56 +0000
Subject: [New-bugs-announce] [issue20690] IDLE Indents convert to spaces and
	then throws error
Message-ID: <1392847736.21.0.941536847555.issue20690@psf.upfronthosting.co.za>


New submission from Justin Barker:

When I add some lines to my module code, some of the tabs that I enter convert to spaces.  This throws an inconsistency error and I can't get it to stop!

----------
components: IDLE
files: test.py
messages: 211664
nosy: Justin.Barker
priority: normal
severity: normal
status: open
title: IDLE Indents convert to spaces and then throws error
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file34148/test.py

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

From report at bugs.python.org  Wed Feb 19 23:21:01 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Feb 2014 22:21:01 +0000
Subject: [New-bugs-announce] [issue20691] inspect.signature: Consider
	exposing	'follow_wrapper_chains' option in public API
Message-ID: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

In the issue #20684, Nick had an idea of exposing 'follow_wrapper_chains' option to the public API.  This might be actually very useful.

----------
assignee: yselivanov
messages: 211668
nosy: larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Feb 19 23:50:24 2014
From: report at bugs.python.org (Jon Shemitz)
Date: Wed, 19 Feb 2014 22:50:24 +0000
Subject: [New-bugs-announce] [issue20692] Tutorial section 9.4
Message-ID: <1392850224.09.0.571764135364.issue20692@psf.upfronthosting.co.za>


New submission from Jon Shemitz:

The tutorial says "Each value is an object, and therefore has a class (also called its type). It is stored as object.__class__."

So, I tried

  >>> 3.__class__
    File "<stdin>", line 1
      3.__class__
                ^
  SyntaxError: invalid syntax

Yet, "foo".__class__ worked, as did 3j.__class__ and 3.5.__class__.

When my son (!) suggested that I try (3).__class__, I did indeed get <type 'int'>, while (3,).__class__ gave <type 'tuple'>.

This *looks like* a minor error in the parser, where seeing \d+\. puts it in a state where it expects \d+ and it can't handle \w+

This may be the sort of thing that only a newbie would even think to try, so may not be worth fixing. If so, it may be worth mentioning in the tutorial.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 211670
nosy: Jon.Shemitz, docs at python
priority: normal
severity: normal
status: open
title: Tutorial section 9.4
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 20 01:01:10 2014
From: report at bugs.python.org (Nick Timkovich)
Date: Thu, 20 Feb 2014 00:01:10 +0000
Subject: [New-bugs-announce] [issue20693] Sidebar scrolls down 2x as fast as
	page content
Message-ID: <1392854470.16.0.730014647108.issue20693@psf.upfronthosting.co.za>


New submission from Nick Timkovich:

When scrolling down in the Python 3.4 docs (e.g. http://docs.python.org/3.4/library/index.html ) the Sphinx sidebar's top value increases twice as fast as the user moves down the page, resulting in it "running away".

I don't know sufficient JS to identify the problem, but I'm guessing it's somewhere in the sidebar.js:scroll_sidebar() function or whatever might configure it.

(apologies, I *think* I may have sent a similar mail to the docs list already)

----------
assignee: docs at python
components: Documentation
files: py34sidebar.png
messages: 211675
nosy: docs at python, nicktimko
priority: normal
severity: normal
status: open
title: Sidebar scrolls down 2x as fast as page content
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34149/py34sidebar.png

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

From report at bugs.python.org  Thu Feb 20 01:38:24 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2014 00:38:24 +0000
Subject: [New-bugs-announce] [issue20694] asyncio.docs: Document
	subprocess_exec and	subprocess_shell
Message-ID: <1392856704.9.0.440221374877.issue20694@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov.ml at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, gvanrossum, haypo, larry, yselivanov
priority: release blocker
severity: normal
status: open
title: asyncio.docs: Document subprocess_exec and subprocess_shell
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 01:58:41 2014
From: report at bugs.python.org (Eric Naeseth)
Date: Thu, 20 Feb 2014 00:58:41 +0000
Subject: [New-bugs-announce] [issue20695]
	test_urllibnet.urlretrieveNetworkTests fails due to
	new	python.org website
Message-ID: <1392857921.36.0.071841445883.issue20695@psf.upfronthosting.co.za>


New submission from Eric Naeseth:

The www.python.org website was just redesigned, and apparently is running on some new infrastructure which always responds to `GET /` requests with a body using `Content-Encoding: gzip`.

Python's test suite includes some tests which fetch http://www.python.org/, and some of the tests in `test.test_urllibnet.urlretrieveNetworkTests` are now failing, because they expect the server to return un-gzip'd UTF-8 text. :(

The full test output (from Python 3.3.4) is attached.

----------
components: Tests
files: python-3.3.4-urllibnet-failure.txt
messages: 211679
nosy: ericnaeseth
priority: normal
severity: normal
status: open
title: test_urllibnet.urlretrieveNetworkTests fails due to new python.org website
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file34150/python-3.3.4-urllibnet-failure.txt

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

From report at bugs.python.org  Thu Feb 20 02:53:52 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2014 01:53:52 +0000
Subject: [New-bugs-announce] [issue20696] asyncio.docs: Document
	StreamReader an other streams	module APIs
Message-ID: <1392861232.52.0.883455527971.issue20696@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Patch is attached, please review.

----------
assignee: yselivanov
components: Documentation
files: asyncio_docs_streams_01.patch
keywords: patch
messages: 211681
nosy: gvanrossum, haypo, larry, yselivanov
priority: release blocker
severity: normal
stage: patch review
status: open
title: asyncio.docs: Document StreamReader an other streams module APIs
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file34151/asyncio_docs_streams_01.patch

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

From report at bugs.python.org  Thu Feb 20 05:08:11 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Feb 2014 04:08:11 +0000
Subject: [New-bugs-announce] [issue20697] cherry-pick 0399e842073a
Message-ID: <1392869291.37.0.590663664574.issue20697@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Otherwise people's tests won't pass, which will lead to general sadness.

----------
assignee: larry
components: Tests
messages: 211685
nosy: benjamin.peterson, larry
priority: release blocker
severity: normal
status: open
title: cherry-pick 0399e842073a
versions: Python 3.5

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

From report at bugs.python.org  Thu Feb 20 07:13:29 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 20 Feb 2014 06:13:29 +0000
Subject: [New-bugs-announce] [issue20698] 3.4 cherry-pick: b328f8ccbccf
	pickle shouldn't look up	dunder methods on instances
Message-ID: <1392876809.12.0.488138797579.issue20698@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Benjamin, Barry: I take it #20261 should go in to 3.4.0?

----------
assignee: larry
messages: 211693
nosy: barry, benjamin.peterson, larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: b328f8ccbccf pickle shouldn't look up dunder methods on instances
type: crash

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

From report at bugs.python.org  Thu Feb 20 10:49:52 2014
From: report at bugs.python.org (Henning von Bargen)
Date: Thu, 20 Feb 2014 09:49:52 +0000
Subject: [New-bugs-announce] [issue20699] Behavior of ZipFile with file-like
	object and	BufferedWriter.
Message-ID: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>


New submission from Henning von Bargen:

Regression: Behavior of ZipFile with file-like object and BufferedWriter.

The following code worked with Python 2.6:


LOB_BLOCKSIZE = 1024*1024 # 1 MB

class UnbufferedBlobWriter(io.RawIOBase):
    """
    A file-like wrapper for a write-only cx_Oracle BLOB object.
    """
    def __init__(self, blobLocator):
        self.blobLocator = blobLocator
        self.offset = 0
        self.blobLocator.open()

    def seekable(self):
        return True
        
    def seek(self, offset, whence):
        if whence == 0:
            self.offset = offset
        elif whence == 1:
            self.offset += offset
            if self.offset < 0:
                self.offset = 0
        elif whence == 2:
            if offset <= 0 and -offset <= self.blobLocator.size():
                self.offset = self.blobLocator.size() + offset
            else:
                raise IOError(96, "Invalid offset for BlobWriter")
        else:
            self._unsupported("seek")
        return self.offset
        
    def writable(self):
        return True

    def write(self, data, offset=None):
        if offset is None:
            offset = self.offset
        self.blobLocator.write(bytes(data), offset + 1)
        self.offset = offset + len(data)
        return len(data)

    def close(self):
        self.flush()
        self.blobLocator.close()        


def BlobWriter(blobLocator):
    """
    A file-like wrapper (buffered) for a write-only cx_Oracle BLOB object.
    """
    return io.BufferedWriter(UnbufferedBlobWriter(blobLocator), LOB_BLOCKGROESSE)


Note: The cx_Oracle BLOB object is used to store binary content inside a database.
It's basically a file-like-like object.

I'm using it in conjunction with a ZipFile object to store a ZipFile as a BLOB
inside the DB, like this:

    curs.execute("""
		 insert into ...  values (..., Empty_BLOB())
		 returning BDATA into :po_BDATA
		 """,
		 [..., blobvar])
    blob = BlobWriter(blobvar.getvalue())
    archive = ZipFile(blob, "w", ZIP_DEFLATED)
    for filename in ...:
	self.log.debug("Saving to ZIP file in the DB: %s", filename)
	archive.write(filename, filename)
    archive.close()

This used to work with Python 2.6.

With Python 2.7.5 however, somethin like this gets written into the blob:
<memory at 0x......>

Digging deeper, I found out that when using the UnbufferedBlobWriter directly
(without BufferedWriter), the problem does not occur.

It seems like the behaviour of the BufferedWriter class changed from 2.6 to 2.7,
most probably caused by the internal optimization of using the memoryview class.

As a workaround, I had to change my write method, calling tobytes() if necessary:

    def write(self, data, offset=None):
        if offset is None:
            offset = self.offset
        if hasattr(data, "tobytes"):
            self.blobLocator.write(data.tobytes(), offset + 1)
        else:
            self.blobLocator.write(bytes(data), offset + 1)
        self.offset = offset + len(data)
        return len(data)


I'm not sure if this is actually a bug in 2.7 or if my usage of BufferedWriter
is incorrect (see remark).

For understanding the problem it is important to know that the ZipFile.write
method often calls write and seek.

Remark:
If I am mis-using BufferedWriter: What precisely is wrong? And if so,
why is it so complicated to support a buffered-random-writer?
I cannot use io.BufferedRandom because I don't have a read method
(and ZipFile.write does not need that).

----------
components: IO
messages: 211714
nosy: Henning.von.Bargen
priority: normal
severity: normal
status: open
title: Behavior of ZipFile with file-like object and BufferedWriter.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 20 16:29:20 2014
From: report at bugs.python.org (David Felix)
Date: Thu, 20 Feb 2014 15:29:20 +0000
Subject: [New-bugs-announce] [issue20700] Docs sidebar scrolls strangely in
	3.4 docs
Message-ID: <1392910160.23.0.342984738746.issue20700@psf.upfronthosting.co.za>


New submission from David Felix:

On longer documentation pages, the sidebar is scrolling out of view and in an unexpected manner when the main page is scrolled. Seems to only affect 3.4 docs, but I'm not positive.

http://docs.python.org/3.4/whatsnew/3.4.html is a good example. Using Firefox 27.0.1 I view this page and scroll down. When I scroll down in the main area (the page is moving upwards in my view) past the summary section, the left side bar/navigation begins scrolling in the opposite direction, presumably to keep up with my scrolling. Its movement is not proportional to my downward scrolling and it is quickly lost "below" the view.

----------
assignee: docs at python
components: Documentation
messages: 211729
nosy: David.Felix, docs at python
priority: normal
severity: normal
status: open
title: Docs sidebar scrolls strangely in 3.4 docs
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 17:11:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Feb 2014 16:11:25 +0000
Subject: [New-bugs-announce] [issue20701] warning in compileall.rst
Message-ID: <1392912685.12.0.93082248857.issue20701@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

When building the docs, I get the following message:

/home/antoine/cpython/default/Doc/library/compileall.rst:23: WARNING: Malformed option description u'[directory|file]...', should look like "-opt args", "--opt args" or "/opt args"

----------
assignee: docs at python
components: Documentation
messages: 211733
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: warning in compileall.rst
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 17:11:51 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Feb 2014 16:11:51 +0000
Subject: [New-bugs-announce] [issue20702] warning in cmdline.rst
Message-ID: <1392912711.56.0.068160127769.issue20702@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

When building the docs, I get the following message:

/home/antoine/cpython/default/Doc/using/cmdline.rst:167: WARNING: Malformed option description u'-?', should look like "-opt args", "--opt args" or "/opt args"

----------
assignee: docs at python
components: Documentation
messages: 211734
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: warning in cmdline.rst
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 17:47:20 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 20 Feb 2014 16:47:20 +0000
Subject: [New-bugs-announce] [issue20703] RuntimeError caused by lazy
	imports in pdb
Message-ID: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Issuing the 'continue' pdb command with a lazy_import.py script as:

# START of lazy_import.py
import sys, pdb

for m in sys.modules:
    if m == 'sys':
        pdb.set_trace()

# END of lazy_import.py


gives the following output:

$ python lazy_import.py
> lazy_import.py(3)<module>()
-> for m in sys.modules:
(Pdb) continue
Traceback (most recent call last):
  File "lazy_import.py", line 3, in <module>
    for m in sys.modules:
RuntimeError: dictionary changed size during iteration

----------
components: Library (Lib)
messages: 211737
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: RuntimeError caused by lazy imports in pdb
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 19:53:23 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2014 18:53:23 +0000
Subject: [New-bugs-announce] [issue20704] asyncio: Implement debug API
Message-ID: <1392922403.14.0.900526342022.issue20704@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This is a proxy issue for https://code.google.com/p/tulip/issues/detail?id=136

----------
assignee: haypo
messages: 211740
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: committed/rejected
status: open
title: asyncio: Implement debug API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 20:08:14 2014
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=)
Date: Thu, 20 Feb 2014 19:08:14 +0000
Subject: [New-bugs-announce] [issue20705] distutils.extension.Extension with
	empty 'sources' list
Message-ID: <1392923294.74.0.945315907553.issue20705@psf.upfronthosting.co.za>


New submission from R?mi Rampin:

While this is obviously a programming error, distutils currently has no check for the 'sources' list being empty, which might or might not result in a self-explanatory error message once the CCompiler's link() method is called (the exact error depends on the subclass's implementation).

It seems that some code had been put in initially to handle this case ('objects or []' constructs) but this has been broken since (objects[0] used by most subclasses).

Since objects can only be empty if sources was empty, I think catching this case in build_extension() (only caller of link_shared_object) makes sense.

Trivial patch attached, should apply on all versions.

----------
components: Distutils
files: distutils-catch-empty-sources.diff
keywords: patch
messages: 211743
nosy: remram
priority: normal
severity: normal
status: open
title: distutils.extension.Extension with empty 'sources' list
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34154/distutils-catch-empty-sources.diff

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

From report at bugs.python.org  Thu Feb 20 22:20:14 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2014 21:20:14 +0000
Subject: [New-bugs-announce] [issue20706] asyncio.docs: Fix wording in 'this
	method returns a	coroutine object'
Message-ID: <1392931214.26.0.574912921943.issue20706@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Codereview: https://codereview.appspot.com/66430046/

----------
assignee: yselivanov
messages: 211751
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.docs: Fix wording in 'this method returns a coroutine object'
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 22:56:14 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 20 Feb 2014 21:56:14 +0000
Subject: [New-bugs-announce] [issue20707] 3.4 cherry-pick: bf413a97f1a9 fix
	conflicting hypot	definition with VS 2010
Message-ID: <1392933374.17.0.141811860716.issue20707@psf.upfronthosting.co.za>


New submission from Zachary Ware:

PC/pyconfig.h does "#define hypot _hypot", but VS 2010 and above already define a hypot function (implemented by _hypot), which results in a warning if you have warning 4211 enabled (which warning level 4 does) or a recursive definition which results in a crash at runtime, depending on how you use Python.h.  Python itself doesn't suffer from the runtime crash, but Blender does because of Python.

bf413a97f1a9 fixes it by guarding the #define with #if _MSC_VER < 1600.

This one is kind of borderline for RC phase in my mind, so I leave it up to you to decide, Larry.  It is a serious issue for at least Blender and one other extension author.  On the other hand, this issue has been around since 3.3.0 (the first VS 2010-supporting release) and was only reported this January.

----------
assignee: larry
components: Build, Windows
messages: 211756
nosy: larry, zach.ware
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: bf413a97f1a9 fix conflicting hypot definition with VS 2010
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 20 23:55:09 2014
From: report at bugs.python.org (Yanming Xiao)
Date: Thu, 20 Feb 2014 22:55:09 +0000
Subject: [New-bugs-announce] [issue20708] commands has no "RANDOM"
	environment?
Message-ID: <1392936909.36.0.153013593454.issue20708@psf.upfronthosting.co.za>


New submission from Yanming Xiao:

I saw this issue on Python 2.7.3 running on FreeBSD 9.1-64 and ubuntu 12.04-64. All under BASH. 

It seems that the shell for the external script does not have the access to RANDOM environment variable. If I run the script directly, 
the results are OK. 


# python -V
Python 2.7.3

# ls *.sh
arquery.sh      randomnumber.sh
#  ./commands_bug.py
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION0.log
# ./randomnumber.sh
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION0.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION279970795912919.log
# ./randomnumber.sh
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION0.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION279970795912919.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION309000060807371.log
# ./randomnumber.sh
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION0.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION20000681632594.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION279970795912919.log
-rw-r--r--  1 root  netvcr  9 Feb 20 17:31 SESSION309000060807371.log

# 
# randomnumber.sh
#set -x
#
randomnumber=$((RANDOM*10000000000+RANDOM*100000+RANDOM))
sid=SESSION${randomnumber}
echo "whatever" > ${sid}.log
ls -l SESSION*.log



#!/usr/local/bin/python
#
# bug_in_python.py
#
import os
import commands

def main():
    cmdString = './randomnumber.sh'
    outputString =  commands.getstatusoutput(cmdString)
    print outputString[1]
    
#
# program starts 
#
if __name__ == '__main__':
    main()
os._exit(0)

----------
components: Library (Lib)
files: commands_bug.py
messages: 211759
nosy: addict2tux
priority: normal
severity: normal
status: open
title: commands has no "RANDOM" environment?
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34157/commands_bug.py

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

From report at bugs.python.org  Thu Feb 20 23:57:36 2014
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Thu, 20 Feb 2014 22:57:36 +0000
Subject: [New-bugs-announce] [issue20709] os.utime(path_to_directory): wrong
	documentation for	Windows.
Message-ID: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za>


New submission from Jan-Philip Gehrcke:

The os.utime() docs for Python 2 (http://docs.python.org/2/library/os.html#os.utime) and 3 (http://docs.python.org/3/library/os.html#os.utime) both contain the sentence

"Whether a directory can be given for path depends on whether the operating system implements directories as files (for example, *Windows does not*)"

"Windoes does not" is wrong. CPython 2.7 on Windows 7:

>>> os.utime(".", (100, 100))
>>> os.stat(".").st_mtime
100.0

We should
- either name a specific system for which this does not work
- or remove this example.

Windows XP and newer support this operation via SetFileTime (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724933%28v=vs.85%29.aspx): "Sets the date and time that the specified file or directory was created, last accessed, or last modified."

I have grepped myself through a couple of CPython source trees and found

posixmodule.c:        if (!SetFileTime(hFile, NULL, &atime, &mtime)

in 2.5, 2.6, 2.7. I guess the statement comes from 2.4 times, where `SetFileTime` only appears in `PC/bdist_wininst/extract.c`.

So, do we just remove the hint or does someone have an example at hand for which combination of Python and platform this does not work for directories? Once we have a decision, I will be happy to provide the mini patch.

----------
assignee: docs at python
components: Documentation
messages: 211760
nosy: docs at python, jgehrcke
priority: normal
severity: normal
status: open
title: os.utime(path_to_directory): wrong documentation for Windows.
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/issue20709>
_______________________________________

From report at bugs.python.org  Fri Feb 21 01:19:31 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 21 Feb 2014 00:19:31 +0000
Subject: [New-bugs-announce] [issue20710] Make inspect and pydoc consistent
	about bound methods
Message-ID: <1392941971.24.0.348510537369.issue20710@psf.upfronthosting.co.za>


New submission from Larry Hastings:

inspect has a bug:
* inspect.ismethod() returns False for bound methods on builtins.

If I fix that, that exposes a bug in pydoc:
* pydoc's two docroutine() functions assume that bound methods
  have a __func__; bound builtins do not.

The only reason pydoc assumed the __func__ attribute was so it could use that instead of the bound function when getting the signature.  I don't know why it cared, but: when it does so, that means it displays "self" for bound methods implemented in Python.

However, since it doesn't do that for bound methods implemented in C, now the behavior is inconsistent.  Should it display self or not?  The consensus was, it should not.  This would make pydoc consistent with inspect.signature.

This patch therefore changes a third thing:

* pydoc: don't display "self" for bound methods implemented in Python.

I propose to merge this for 3.4.0rc2.

----------
assignee: larry
components: Library (Lib)
files: larry.fix.help.on.bound.methods.1.diff
keywords: patch
messages: 211768
nosy: larry, ncoghlan, yselivanov
priority: release blocker
severity: normal
status: open
title: Make inspect and pydoc consistent about bound methods
versions: Python 3.4
Added file: http://bugs.python.org/file34162/larry.fix.help.on.bound.methods.1.diff

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

From report at bugs.python.org  Fri Feb 21 01:54:27 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Feb 2014 00:54:27 +0000
Subject: [New-bugs-announce] [issue20711] inspect.getfullargspec does not
	correctly work with	builtin module-level functions
Message-ID: <1392944067.4.0.263463112127.issue20711@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

current behaviour:


>>> import inspect
>>> import os
>>> inspect.getfullargspec(os.stat)
<module 'posix' (built-in)>
FullArgSpec(args=['module', 'path'], varargs=None, varkw=None, defaults=None, kwonlyargs=['dir_fd', 'follow_symlinks'], kwonlydefaults={'dir_fd': None, 'follow_symlinks': True}, annotations={})


'module' argument should not be there.

Patch is attached, please review.

----------
assignee: yselivanov
files: sig_bound_01.patch
keywords: patch
messages: 211776
nosy: larry, ncoghlan, yselivanov
priority: release blocker
severity: normal
status: open
title: inspect.getfullargspec does not correctly work with builtin module-level functions
versions: Python 3.4
Added file: http://bugs.python.org/file34164/sig_bound_01.patch

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

From report at bugs.python.org  Fri Feb 21 02:19:46 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 21 Feb 2014 01:19:46 +0000
Subject: [New-bugs-announce] [issue20712] Make inspect agnostic about
	whether functions are	implemented in Python or C
Message-ID: <1392945586.96.0.797819673401.issue20712@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Some of the methods on the inspect module behave differently depending on whether the callable passed in was implemented in C or in Python.  For example, ismethod() only returns True for bound methods implemented in Python.

I assert that the interface presented by inspect should be agnostic about the underlying implementation.  So for example ismethod() should return True for bound methods on builtin classes.

----------
assignee: larry
messages: 211783
nosy: larry, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Make inspect agnostic about whether functions are implemented in Python or C
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Feb 21 02:56:59 2014
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 21 Feb 2014 01:56:59 +0000
Subject: [New-bugs-announce] [issue20713] 3.4 cherry-pick: d57df3f72715
	Upgrade pip to 1.5.3
Message-ID: <1392947819.39.0.803565430307.issue20713@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Please pull in the upgrade from pip 1.5.2 to 1.5.3 into CPython 3.4.0, the revision is d57df3f72715

----------
assignee: larry
messages: 211787
nosy: dstufft, larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: d57df3f72715 Upgrade pip to 1.5.3
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 03:04:09 2014
From: report at bugs.python.org (Artur R. Czechowski)
Date: Fri, 21 Feb 2014 02:04:09 +0000
Subject: [New-bugs-announce] [issue20714] Please allow for ]]> in CDATA in
	minidom.py
Message-ID: <1392948249.58.0.639879526179.issue20714@psf.upfronthosting.co.za>


New submission from Artur R. Czechowski:

Current support for ]]> inside CDATA is to raise an Exception. However, it could be solved by dividing the ]]> to two strings:
- ]]
- >
and each one is a separate CDATA inside elemement. So, to put ]]> inside CDATA one can write:
<element>
<![CDATA[]]]]><![CDATA[>]]>
</element>

----------
components: XML
files: minidom.patch
keywords: patch
messages: 211791
nosy: arturcz
priority: normal
severity: normal
status: open
title: Please allow for ]]> in CDATA in minidom.py
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file34167/minidom.patch

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

From report at bugs.python.org  Fri Feb 21 07:41:44 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Feb 2014 06:41:44 +0000
Subject: [New-bugs-announce] [issue20715] 3.4 cherry-pick: 2000c27ebe80
	inspect: Fix	getfullargspec to support builtin module-level
	functions
Message-ID: <1392964904.87.0.488691862125.issue20715@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Larry, please consider cherry-picking 2000c27ebe80.

Another bug in newly renovated 'inspect.getfullargspec()', this time with module-level builtins. Would be great if it supports them well in 3.4.

changeset:   89314:2000c27ebe80
tag:         tip
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Fri Feb 21 01:32:42 2014 -0500
files:       Lib/inspect.py Lib/test/test_inspect.py
description:
inspect: Fix getfullargspec to support builtin module-level functions. Issue #20711

----------
assignee: larry
keywords: 3.4regression
messages: 211810
nosy: larry, yselivanov
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 2000c27ebe80 inspect: Fix getfullargspec to support builtin module-level functions
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 08:36:08 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 21 Feb 2014 07:36:08 +0000
Subject: [New-bugs-announce] [issue20716] 3.4 cherry-pick: 5e73bb72662e
	pydoc shouldn't display	"self" for bound methods
Message-ID: <1392968168.98.0.403308728506.issue20716@psf.upfronthosting.co.za>


New submission from Larry Hastings:

5e73bb72662e

----------
assignee: larry
components: Library (Lib)
messages: 211817
nosy: larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 5e73bb72662e pydoc shouldn't display "self" for bound methods
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 10:03:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Feb 2014 09:03:55 +0000
Subject: [New-bugs-announce] [issue20717] test_4_daemon_threads() fails
	randomly on "x86 Windows	Server 2003 [SB] 3.x"
Message-ID: <1392973435.96.0.316031564004.issue20717@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The test test_4_daemon_threads() does crash randomly on the buildbot "x86 Windows Server 2003 [SB] 3.x". It may be an old bug which was not seen before because it was hidden by another bug (#19424 which is now fixed).

Charles-Fran?ois Natali repeated that daemons threads can crash randomly at exit if they are waiting for a blocking call with the GIL released, and still use memory that is being freed by the main thread at exit.

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/2166/steps/test/logs/stdio

======================================================================
FAIL: test_4_daemon_threads (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_threading.py", line 773, in test_4_daemon_threads
    rc, out, err = assert_python_ok('-c', script)
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 3221225477, stderr follows:


Related issues:

- #19424: _warnings: patch to avoid conversions from/to UTF-8
- #19442: Python crashes when a warning is emitted during shutdown
- #19466: Clear state of threads earlier in Python shutdown => my changes from this issue have been reverted

----------
messages: 211830
nosy: haypo, neologix, pitrou, sbt
priority: normal
severity: normal
status: open
title: test_4_daemon_threads() fails randomly on "x86 Windows Server 2003 [SB] 3.x"
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 10:14:17 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Feb 2014 09:14:17 +0000
Subject: [New-bugs-announce] [issue20718] OpenBSD/AIX: tests passing a file
	descriptor with	sendmsg/recvmsg failures
Message-ID: <1392974057.71.0.420386610945.issue20718@psf.upfronthosting.co.za>


New submission from STINNER Victor:

OpenBSD failures:

http://bugs.python.org/issue20669#msg211493

AIX failures:

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1760/steps/test/logs/stdio

======================================================================
ERROR: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2722, in _testFDPassSeparate
    array.array("i", [fd1]))]),
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2746, in _testFDPassSeparateMinSpace
    array.array("i", [fd1]))]),
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2722, in _testFDPassSeparate
    array.array("i", [fd1]))]),
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 258, in _tearDown
    raise exc
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 270, in clientRun
    test_func()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2746, in _testFDPassSeparateMinSpace
    array.array("i", [fd1]))]),
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1864, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
OSError: [Errno 22] Invalid argument

======================================================================
FAIL: testIPv4toString (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 955, in testIPv4toString
    assertInvalid(f, '0.0.0.')
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 947, in <lambda>
    (OSError, ValueError), func, a
AssertionError: (<class 'OSError'>, <class 'ValueError'>) not raised by inet_aton

======================================================================
FAIL: testIPv6toString (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 1012, in testIPv6toString
    assertInvalid('1:2:3:4:5:6:7:8:')
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 990, in <lambda>
    (OSError, ValueError), f, a
AssertionError: (<class 'OSError'>, <class 'ValueError'>) not raised by <lambda>

======================================================================
FAIL: testFDPassSeparate (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2710, in testFDPassSeparate
    maxcmsgs=2)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2734, in testFDPassSeparateMinSpace
    maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparate (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2710, in testFDPassSeparate
    maxcmsgs=2)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

======================================================================
FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2734, in testFDPassSeparateMinSpace
    maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_socket.py", line 2637, in checkRecvmsgFDs
    self.assertEqual(msg, MSG)
AssertionError: b'' != b'Michael Gilfix was here\xe1\x88\xb4\r\n'

----------
components: Tests
keywords: buildbot
messages: 211832
nosy: haypo
priority: normal
severity: normal
status: open
title: OpenBSD/AIX: tests passing a file descriptor with sendmsg/recvmsg failures
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 10:20:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Feb 2014 09:20:19 +0000
Subject: [New-bugs-announce] [issue20719] test_robotparser failure on "SPARC
	Solaris 10 (cc%2C	64b) [SB] 3.x" buildbot
Message-ID: <1392974419.69.0.59989767526.issue20719@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I read somewhere that python.org has a new website and the new website has gzip compression enabled which makes some urllib tests failing. It's probably related.

http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20%28cc%2C%2064b%29%20%5BSB%5D%203.x/builds/1750/steps/test/logs/stdio

======================================================================
ERROR: testPythonOrg (test.test_robotparser.NetworkTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/test_robotparser.py", line 283, in testPythonOrg
    parser.read()
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/urllib/robotparser.py", line 64, in read
    self.parse(raw.decode("utf-8").splitlines())
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

----------
messages: 211836
nosy: haypo
priority: normal
severity: normal
status: open
title: test_robotparser failure on "SPARC Solaris 10 (cc%2C 64b) [SB] 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 10:46:41 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Feb 2014 09:46:41 +0000
Subject: [New-bugs-announce] [issue20720] test_create_server() of
	test_asyncio failure on "x86	Windows Server 2008 [SB] 3.x" buildbot
Message-ID: <1392976001.38.0.882867755146.issue20720@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the overlapped AcceptEx() operation was cancelled by something. But when the test_asyncio was replayed in verbose mode, the test passed.

Is it possible that a local firewall or antivirus cancelled the operation? It would be surprising since the test passed at the second try.

Related discussion on Apache HTTPD mailing list:
" My guess... you have a package that installed a network service provider filter and that filter is somehow doing a close on the event handle in the overlapped structure."
http://marc.info/?l=apache-httpd-dev&m=105959505627302&w=2

---

AcceptEx() documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737524%28v=vs.85%29.aspx

test_create_server (test.test_asyncio.test_events.ProactorEventLoopTests) ...

Future/Task exception was never retrieved
future: _OverlappedFuture<exception=OSError(22, 'The I/O operation has been aborted because of either a thread exit or an application request', None, 995, None)>
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\windows_events.py", line 428, in _poll
    value = callback(transferred, key, ov)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\windows_events.py", line 253, in finish_accept
    ov.getresult()
OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/2365/steps/test/logs/stdio

======================================================================
FAIL: test_create_server (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\test_events.py", line 642, in test_create_server
    self.assertEqual('CONNECTED', proto.state)
AssertionError: 'CONNECTED' != 'INITIAL'
- CONNECTED
+ INITIAL

---

test_create_server (test.test_asyncio.test_events.SelectEventLoopTests) ... ok
test_create_server (test.test_asyncio.test_proactor_events.BaseProactorEventLoopTests) ... FAIL
... later ...
test_create_server (test.test_asyncio.test_events.SelectEventLoopTests) ... ok
test_create_server (test.test_asyncio.test_proactor_events.BaseProactorEventLoopTests) ... ok

----------
messages: 211839
nosy: brian.curtin, gvanrossum, haypo, sbt, tim.golden, yselivanov
priority: normal
severity: normal
status: open
title: test_create_server() of test_asyncio failure on "x86 Windows Server 2008 [SB] 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 13:46:44 2014
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 21 Feb 2014 12:46:44 +0000
Subject: [New-bugs-announce] [issue20721] 3.4 cherry-pick: 005d0678f93c
	Update pip to 1.5.4
Message-ID: <1392986804.5.0.957467448226.issue20721@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Please cherry-pick 005d0678f93c into 3.4.0. It upgrades pip to 1.5.4, the only change is a fix for an errant deprecation warning which was displaying all the time instead of only when you used the deprecated feature.

Sorry for making you need to cherry-pick another one so soon larry :(

----------
assignee: larry
messages: 211851
nosy: dstufft, larry, ncoghlan, ned.deily
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 005d0678f93c Update pip to 1.5.4
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 14:24:07 2014
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 21 Feb 2014 13:24:07 +0000
Subject: [New-bugs-announce] [issue20722] newline is (partially) independent
	of universal newlines; needs to be made more clear in docs
Message-ID: <1392989047.5.0.441949548663.issue20722@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

http://docs.python.org/3.4/library/functions.html#open says "newline controls how universal newlines mode works (it only applies to text mode)."

My reading of this when I saw it was that newline= doesn't do anything unless universal newlines mode is enabled. This is untrue, and you can infer it's untrue from the following lines, but then the docs appear to contradict themselves. Please fix to say something more along the lines of "newline controls how newlines are read and written. It only applies to text mode."

The interactions with universal newlines mode are explained in the following text, so they don't need to be called out upfront. newline does more than just that.

----------
assignee: docs at python
components: Documentation
messages: 211854
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: newline is (partially) independent of universal newlines; needs to be made more clear in docs
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 21 16:48:10 2014
From: report at bugs.python.org (Daniel)
Date: Fri, 21 Feb 2014 15:48:10 +0000
Subject: [New-bugs-announce] [issue20723] Make test (Python 3.3.4)
Message-ID: <1392997690.23.0.430791964317.issue20723@psf.upfronthosting.co.za>


New submission from Daniel:

5 Error to make test with Python v.3.3.4

----------
files: makeTest-python3-3-4.log
messages: 211867
nosy: datienzalopez
priority: normal
severity: normal
status: open
title: Make test (Python 3.3.4)
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file34175/makeTest-python3-3-4.log

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

From report at bugs.python.org  Sat Feb 22 00:36:52 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Feb 2014 23:36:52 +0000
Subject: [New-bugs-announce] [issue20724] 3.4 cherry-pick: d6aa3fa646e2
	inspect.signature: Check	for function-like objects before builtins
Message-ID: <1393025812.53.0.229625778918.issue20724@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Another tweak in signature. Fixes #17159 once and for all (and will save Stefan from adding ugly hacks in Cython).

I'm not sure if it is a release blocker or can wait till 3.4.1; all I can say is that the change is relatively simple, as it shouldn't matter what we try first - from_function() or from_builtin(). It's your call.

changeset:   89320:d6aa3fa646e2
tag:         tip
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Fri Feb 21 18:30:53 2014 -0500
files:       Lib/inspect.py Lib/test/test_inspect.py
description:
inspect.signature: Check for function-like objects before builtins. Issue #17159

----------
assignee: larry
messages: 211894
nosy: larry, yselivanov
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: d6aa3fa646e2 inspect.signature: Check for function-like objects before builtins
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb 22 03:57:31 2014
From: report at bugs.python.org (Tom Brander)
Date: Sat, 22 Feb 2014 02:57:31 +0000
Subject: [New-bugs-announce] [issue20725] Fail to build on Windows x64 with
	VS Express
Message-ID: <1393037851.28.0.0915666367689.issue20725@psf.upfronthosting.co.za>


New submission from Tom Brander:

Trying to build a Win 32 version using VS express on Win 7 (since it cannot do x64) Rev 89320 tried to build python 3.4 from source using VS 2010 express no dice.  It complains about solutions folder that is not supported in VS 2010 express. While this is noted in the read me, I still cannot build whether by GUI or via the build.bat file (I removed the reference to the solutions folder reference) to get it to run at all via the command prompt. Friend next door using full VS 2010 seems ok..

----------
components: Build
files: failedbld.txt
messages: 211902
nosy: TomBrander
priority: normal
severity: normal
status: open
title: Fail to build on Windows x64 with VS Express
versions: Python 3.4
Added file: http://bugs.python.org/file34178/failedbld.txt

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

From report at bugs.python.org  Sat Feb 22 04:21:53 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 22 Feb 2014 03:21:53 +0000
Subject: [New-bugs-announce] [issue20726] inspect: Make Signature instances
	picklable
Message-ID: <1393039313.92.0.449452904974.issue20726@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

There is no reason for Signature objects to be not picklable.
Patch is attached (it will require merging #19573 before).

----------
assignee: yselivanov
files: sig_picklable_01.patch
keywords: patch
messages: 211903
nosy: larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect: Make Signature instances picklable
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34179/sig_picklable_01.patch

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

From report at bugs.python.org  Sat Feb 22 07:36:58 2014
From: report at bugs.python.org (David Lindquist)
Date: Sat, 22 Feb 2014 06:36:58 +0000
Subject: [New-bugs-announce] [issue20727] Improved roundrobin itertools
	recipe
Message-ID: <1393051018.22.0.696460210134.issue20727@psf.upfronthosting.co.za>


New submission from David Lindquist:

The roundrobin example in the Recipes section of the itertools documentation (http://docs.python.org/3/library/itertools.html#itertools-recipes) is overly complex. Here is a more straightforward implementation:

def roundrobin(*iterables):
    "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
    sentinel = object()
    it = chain.from_iterable(zip_longest(fillvalue=sentinel, *iterables))
    return (i for i in it if i is not sentinel)

Not only is it one-third the lines of the existing example, benchmarks show it to be more than twice as fast.

See attached patch file.

----------
assignee: docs at python
components: Documentation
files: roundrobin.patch
keywords: patch
messages: 211907
nosy: david.lindquist, docs at python
priority: normal
severity: normal
status: open
title: Improved roundrobin itertools recipe
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/file34180/roundrobin.patch

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

From report at bugs.python.org  Sat Feb 22 11:08:17 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 22 Feb 2014 10:08:17 +0000
Subject: [New-bugs-announce] [issue20728] Remove unused import from base64
Message-ID: <1393063697.39.0.80310482036.issue20728@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

base64 imports `itertools`, but doesn't use it at all.

----------
components: Library (Lib)
files: base64_remove_unused_import.patch
keywords: patch
messages: 211917
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Remove unused import from base64
versions: Python 3.5
Added file: http://bugs.python.org/file34182/base64_remove_unused_import.patch

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

From report at bugs.python.org  Sat Feb 22 13:45:39 2014
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 22 Feb 2014 12:45:39 +0000
Subject: [New-bugs-announce] [issue20729] mailbox.Mailbox does odd hasattr()
	check
Message-ID: <1393073139.05.0.18044867544.issue20729@psf.upfronthosting.co.za>


New submission from Chris Angelico:

Only noticed because I was searching the stdlib for hasattr calls, but in mailbox.Mailbox.update(), a check is done thus:

        if hasattr(arg, 'iteritems'):
            source = arg.items()
        elif hasattr(arg, 'items'):
            source = arg.items()
        else:
            source = arg

If this is meant to support Python 2, it should probably use iteritems() in the first branch, but for Python 3, it's probably simpler to just drop the first check altogether:

        if hasattr(arg, 'items'):
            source = arg.items()
        else:
            source = arg

Or possibly switch to EAFP:

        try:
            source = arg.items()
        except AttributeError:
            source = arg

----------
messages: 211920
nosy: Rosuav
priority: normal
severity: normal
status: open
title: mailbox.Mailbox does odd hasattr() check

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

From report at bugs.python.org  Sat Feb 22 15:31:14 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 22 Feb 2014 14:31:14 +0000
Subject: [New-bugs-announce] [issue20730] Typo in idlelib.GrepDialog
Message-ID: <1393079474.26.0.534605025021.issue20730@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

There is a typo in idlelib.GrepDialog.findfiles: OSerror instead of OSError.

----------
components: IDLE
files: idle_typo.patch
keywords: patch
messages: 211927
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Typo in idlelib.GrepDialog
versions: Python 3.4
Added file: http://bugs.python.org/file34183/idle_typo.patch

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

From report at bugs.python.org  Sat Feb 22 20:20:15 2014
From: report at bugs.python.org (OPi)
Date: Sat, 22 Feb 2014 19:20:15 +0000
Subject: [New-bugs-announce] [issue20731] Python 3.3.4: SyntaxError with
	correct source code	encoding # -*- coding: latin-1 -*-
Message-ID: <1393096815.65.0.473917822073.issue20731@psf.upfronthosting.co.za>


New submission from OPi:

The test program:
#!/usr/bin/env python
# -*- coding: latin-1 -*-

print('test')

is correct in Python 3.3.3, but cause this error with Python 3.3.4:
  File "./test.py", line 3
    -
    ^
SyntaxError: invalid syntax

I use Windows 7, with bash (of Cygwin) and
Python 3.3.4 (v3.3.4:7ff62415e426, Feb 10 2014, 18:13:51) [MSC v.1600 64 bit (AMD64)] on win32

----------
components: Interpreter Core
files: test.py
messages: 211942
nosy: OPi
priority: normal
severity: normal
status: open
title: Python 3.3.4: SyntaxError with correct source code encoding  # -*- coding: latin-1 -*-
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file34190/test.py

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

From report at bugs.python.org  Sat Feb 22 21:31:55 2014
From: report at bugs.python.org (Derek Wallace)
Date: Sat, 22 Feb 2014 20:31:55 +0000
Subject: [New-bugs-announce] [issue20732] Custom logging formatter doesnt
	work in 3.3.4
Message-ID: <1393101115.55.0.4326996305.issue20732@psf.upfronthosting.co.za>


New submission from Derek Wallace:

Hi,
I use the logging module and have created a custom formatter to format the log messages different for each logging level.
This was developed with 3.3.3.

When i upgraded to 3.3.4 it no longer worked.
I got the error
TypeError: 'tuple' object is not callable



Here is the original code.
class SpecialFormatter(logging.Formatter):
    FORMATS = {logging.DEBUG : logging._STYLES['{']("{module} DEBUG: {lineno}: {message}"),
           logging.ERROR : logging._STYLES['{']("{module} ERROR: {message}"),
           logging.INFO : logging._STYLES['{']("{module}: {message}"),
           'DEFAULT' : logging._STYLES['{']("{module}: {message}")}

    def format(self, record):
        # Ugly. Should be better
        self._style = self.FORMATS.get(record.levelno, self.FORMATS['DEFAULT'])
        return logging.Formatter.format(self, record)

hdlr = logging.StreamHandler(sys.stderr)
hdlr.setFormatter(SpecialFormatter())
logging.root.addHandler(hdlr)
logging.root.setLevel(logging.INFO)



In the 3.3.4 release the strucutre of the 
logging._STYLES
changed in logging/__init__.py.

It changed from a value to a tuple.

Therefore the above code needed to change
logging._STYLES['{']("{module} DEBUG: {lineno}: {message}")

to

logging._STYLES['{'][0]("{module} DEBUG: {lineno}: {message}")


Derek

----------
components: Library (Lib)
messages: 211949
nosy: derekwallace
priority: normal
severity: normal
status: open
title: Custom logging formatter doesnt work in 3.3.4
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 22 21:34:58 2014
From: report at bugs.python.org (Elazar Gershuni)
Date: Sat, 22 Feb 2014 20:34:58 +0000
Subject: [New-bugs-announce] [issue20733] Typo in itertools docs -
	"itertool-functions"
Message-ID: <1393101298.1.0.906876299112.issue20733@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

typo - should be "itertools-functions" instead of "itertool-functions"

http://docs.python.org/3.4/library/itertools.html#itertool-functions

----------
assignee: docs at python
components: Documentation
messages: 211950
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: Typo in itertools docs - "itertool-functions"
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb 22 22:17:18 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 22 Feb 2014 21:17:18 +0000
Subject: [New-bugs-announce] [issue20734] 3.4 cherry-pick: 13edfab6c3c0
	disable 2 pydoc tests
Message-ID: <1393103838.31.0.179459342729.issue20734@psf.upfronthosting.co.za>


New submission from Eric Snow:

New changeset 13edfab6c3c0 by Eric Snow in branch 'default':
Issue #20484: Disable the 2 remaining "modules" tests in test_pydoc

----------
assignee: larry
messages: 211957
nosy: eric.snow, larry, ned.deily
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry-pick: 13edfab6c3c0 disable 2 pydoc tests
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb 22 23:16:07 2014
From: report at bugs.python.org (abcdef)
Date: Sat, 22 Feb 2014 22:16:07 +0000
Subject: [New-bugs-announce] [issue20735] Documentation: mark stringprep as
	deprecated
Message-ID: <1393107367.35.0.913025016095.issue20735@psf.upfronthosting.co.za>


New submission from abcdef:

This is a nitpick, but the documentation is not clear whether the stringprep module is deprecated or not. It is listed as "Deprecated" on http://docs.python.org/3.3/py-modindex.html#cap-s but there's no information on http://docs.python.org/3.3/library/stringprep.html. Contrast with http://docs.python.org/3.3/library/optparse.html which has a clear warning.

----------
assignee: docs at python
components: Documentation
messages: 211964
nosy: abcdef, docs at python
priority: normal
severity: normal
status: open
title: Documentation: mark stringprep as deprecated
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb 22 23:16:08 2014
From: report at bugs.python.org (David Watson)
Date: Sat, 22 Feb 2014 22:16:08 +0000
Subject: [New-bugs-announce] [issue20736] test_socket: testSendmsgDontWait
	needlessly skipped on	Linux
Message-ID: <1393107368.02.0.430895744792.issue20736@psf.upfronthosting.co.za>


New submission from David Watson:

In test_socket, the decorator on SendmsgStreamTests.testSendmsgDontWait still checks for the old sys.platform value of "linux2", with the result that the test is always skipped, when in fact the test is for a Linux facility.  Patch attached for 3.3 and above.

----------
components: Tests
files: test_socket-platform.diff
keywords: patch
messages: 211965
nosy: baikie
priority: normal
severity: normal
status: open
title: test_socket: testSendmsgDontWait needlessly skipped on Linux
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34194/test_socket-platform.diff

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

From report at bugs.python.org  Sat Feb 22 23:20:26 2014
From: report at bugs.python.org (raruler)
Date: Sat, 22 Feb 2014 22:20:26 +0000
Subject: [New-bugs-announce] [issue20737] 3.3 _thread lock.acquire() timeout
	and	threading.Event().wait() do not wake for certain values
	on Windows
Message-ID: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za>


New submission from raruler:

I've tried this with both the 32-bit and 64-bit versions of 3.3.4 on two Windows 7 x64 machines. 

threading.Event().wait(2148) and a lock obtained from _thread used as lock.acquire(True, 2148) will never return. Anything under 2148 seems to work just fine, but anything 2148 or larger never wakes up.

The same call works on 3.3.4/x64 on OS X.

----------
components: Library (Lib), Windows
messages: 211966
nosy: pitrou, raruler
priority: normal
severity: normal
status: open
title: 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 22 23:47:06 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 22 Feb 2014 22:47:06 +0000
Subject: [New-bugs-announce] [issue20738] 3.4 cherry-pick: 7b80f57f904e fix
	20641
Message-ID: <1393109226.36.0.387164045667.issue20738@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

Fix 7b80f57f904e for issue20641.

----------
assignee: larry
messages: 211970
nosy: larry, loewis
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 7b80f57f904e fix 20641
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 23 00:56:57 2014
From: report at bugs.python.org (Thomas Wouters)
Date: Sat, 22 Feb 2014 23:56:57 +0000
Subject: [New-bugs-announce] [issue20739] PEP 463 (except expression)
	implementation
Message-ID: <1393113417.21.0.308711390279.issue20739@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

Here is a preliminary implementation of PEP 463, minus mandatory parentheses and with the most straightforward precedence rule: equal to if-expr -- which means this:

A if C else B except E: D

is parsed as

A if C else (B except E: D)

(because of associativity, not precedence) and not as

(A if C else B) except E: D

as suggested by the PEP with the hand-wavy words 'between lambda and if/else in precedence'. The latter is possible but means a little more hoop-jumping in the grammar.

The tests included are rudimentary (at the end of test_grammar.py) and could probably do with some fleshing out, partially as tests and partially to try out how the precedence rules work out in practice.

----------
components: Interpreter Core
files: exceptexpr.diff
keywords: patch
messages: 211973
nosy: twouters
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 463 (except expression) implementation
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34195/exceptexpr.diff

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

From report at bugs.python.org  Sun Feb 23 08:10:54 2014
From: report at bugs.python.org (Pavel Kazakov)
Date: Sun, 23 Feb 2014 07:10:54 +0000
Subject: [New-bugs-announce] [issue20740] Remove invalid number from squares
	in introduction	section
Message-ID: <1393139454.24.0.23441362157.issue20740@psf.upfronthosting.co.za>


New submission from Pavel Kazakov:

This is probably being nitpicky, but in the introduction section, the squares list include a 2:
squares = [1, 2, 4, 9, 16, 25]

However, 2 is not a square number (perfect square). So it should be:
[1, 4, 9, 16, 25]

I've included a patch that removes the 2.

----------
assignee: docs at python
components: Documentation
files: fix_squares.patch
keywords: patch
messages: 211982
nosy: docs at python, nullishzero
priority: normal
severity: normal
status: open
title: Remove invalid number from squares in introduction section
type: enhancement
Added file: http://bugs.python.org/file34196/fix_squares.patch

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

From report at bugs.python.org  Sun Feb 23 09:05:20 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 23 Feb 2014 08:05:20 +0000
Subject: [New-bugs-announce] [issue20741] Documentation archives should be
	available also in	tar.xz format
Message-ID: <1393142720.31.0.255845110134.issue20741@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Source archives (e.g. in [1]) are available in tgz and tar.xz formats, but documentation archives (e.g. in [2]) are available only in tar.bz2 and zip formats.
I suggest that documentation archives be available also in tar.xz format.

[1] http://www.python.org/ftp/python/3.3.4/
[2] http://www.python.org/ftp/python/doc/3.3.4/

----------
keywords: easy
messages: 211985
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: Documentation archives should be available also in tar.xz format
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 23 12:11:47 2014
From: report at bugs.python.org (David Jones)
Date: Sun, 23 Feb 2014 11:11:47 +0000
Subject: [New-bugs-announce] [issue20742] 2to3 zip fixer doesn't fix for
	loops.
Message-ID: <1393153907.74.0.496388533035.issue20742@psf.upfronthosting.co.za>


New submission from David Jones:

Consider the following code:

for z in zip([1]):pass

2to3 does not convert the zip in this code to list(zip(...)); it does not change this code at all.

That can be an (obscure) bug because the zip in Python 2 has different semantics from the zip in Python 3.

The output of this program

from __future__ import print_function
S = []

def l(c):
  for i in [0,1]:
    S.append(c)
    yield i
  S.append(c.upper())

la = l('a')
lb = l('b')

for a,b in zip(la, lb):
  S.append("#")
print(''.join(S))

is different in Python 2 and Python 3 (when converted with 2to3, which doesn't change the program).

In Python 2 the output is:

ababA##

In Python 3 the output is:

ab#ab#A


Obviously this example is somewhat contrived, but I have a non-contrived example involving decoding PNG images (if anyone is interested).

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 211989
nosy: drj
priority: normal
severity: normal
status: open
title: 2to3 zip fixer doesn't fix for loops.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb 23 18:13:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Feb 2014 17:13:45 +0000
Subject: [New-bugs-announce] [issue20743] test_tcl memory leak
Message-ID: <1393175625.97.0.752348039062.issue20743@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Witnessed on 2.7, 3.3, 3.4:

$ ./python -m test -uall -R3:3 test_tcl 
[1/1] test_tcl
beginning 6 repetitions
123456
......
test_tcl leaked [12, 12, 12] references, sum=36
test_tcl leaked [5, 5, 5] memory blocks, sum=15

----------
components: Library (Lib), Tkinter
messages: 212006
nosy: pitrou, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: test_tcl memory leak
type: resource usage
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 23 18:15:44 2014
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 23 Feb 2014 17:15:44 +0000
Subject: [New-bugs-announce] [issue20744] shutil should not use distutils
Message-ID: <1393175744.01.0.39444598447.issue20744@psf.upfronthosting.co.za>


New submission from Matthias Klose:

shutil imports distutils in _call_external_zip just for the calling of an external command.  This should be done using subprocess these days.

----------
components: Library (Lib)
messages: 212007
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: shutil should not use distutils
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 23 18:17:46 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Feb 2014 17:17:46 +0000
Subject: [New-bugs-announce] [issue20745] test_statistics fails in refleak
	mode
Message-ID: <1393175866.55.0.0751300817927.issue20745@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -m test -W -R3:3 test_statistics
[1/1] test_statistics
[...]

======================================================================
FAIL: assertApproxEqual (test.test_statistics.NumericTestCase)
Doctest: test.test_statistics.NumericTestCase.assertApproxEqual
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_statistics.NumericTestCase.assertApproxEqual
  File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 153, in assertApproxEqual

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 165, in test.test_statistics.NumericTestCase.assertApproxEqual
Failed example:
    class MyTest(NumericTestCase):
        def test_number(self):
            x = 1.0/6
            y = sum([x]*6)
            self.assertApproxEqual(y, 1.0, tol=1e-15)
        def test_sequence(self):
            a = [1.001, 1.001e-10, 1.001e10]
            b = [1.0, 1e-10, 1e10]
            self.assertApproxEqual(a, b, rel=1e-3)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics.NumericTestCase.assertApproxEqual[0]>", line 1, in <module>
        class MyTest(NumericTestCase):
    NameError: name 'NumericTestCase' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 177, in test.test_statistics.NumericTestCase.assertApproxEqual
Failed example:
    suite = unittest.TestLoader().loadTestsFromTestCase(MyTest)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics.NumericTestCase.assertApproxEqual[3]>", line 1, in <module>
        suite = unittest.TestLoader().loadTestsFromTestCase(MyTest)
    NameError: name 'MyTest' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 178, in test.test_statistics.NumericTestCase.assertApproxEqual
Failed example:
    unittest.TextTestRunner(stream=StringIO()).run(suite)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics.NumericTestCase.assertApproxEqual[4]>", line 1, in <module>
        unittest.TextTestRunner(stream=StringIO()).run(suite)
    NameError: name 'suite' is not defined


======================================================================
FAIL: _DoNothing (test.test_statistics)
Doctest: test.test_statistics._DoNothing
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_statistics._DoNothing
  File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 99, in _DoNothing

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 112, in test.test_statistics._DoNothing
Failed example:
    approx_equal(12.345, 12.346, tol=1e-3)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._DoNothing[0]>", line 1, in <module>
        approx_equal(12.345, 12.346, tol=1e-3)
    NameError: name 'approx_equal' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 114, in test.test_statistics._DoNothing
Failed example:
    approx_equal(12.345e6, 12.346e6, tol=1e-3)  # tol is too small.
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._DoNothing[1]>", line 1, in <module>
        approx_equal(12.345e6, 12.346e6, tol=1e-3)  # tol is too small.
    NameError: name 'approx_equal' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 120, in test.test_statistics._DoNothing
Failed example:
    approx_equal(12.345, 12.346, rel=1e-4)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._DoNothing[2]>", line 1, in <module>
        approx_equal(12.345, 12.346, rel=1e-4)
    NameError: name 'approx_equal' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 122, in test.test_statistics._DoNothing
Failed example:
    approx_equal(12.345e6, 12.346e6, rel=1e-4)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._DoNothing[3]>", line 1, in <module>
        approx_equal(12.345e6, 12.346e6, rel=1e-4)
    NameError: name 'approx_equal' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 131, in test.test_statistics._DoNothing
Failed example:
    approx_equal(12.345e6, 12.346e6, tol=1e-3, rel=1e-4)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._DoNothing[4]>", line 1, in <module>
        approx_equal(12.345e6, 12.346e6, tol=1e-3, rel=1e-4)
    NameError: name 'approx_equal' is not defined


======================================================================
FAIL: _calc_errors (test.test_statistics)
Doctest: test.test_statistics._calc_errors
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_statistics._calc_errors
  File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 25, in _calc_errors

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 28, in test.test_statistics._calc_errors
Failed example:
    _calc_errors(100, 75)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._calc_errors[0]>", line 1, in <module>
        _calc_errors(100, 75)
    NameError: name '_calc_errors' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 30, in test.test_statistics._calc_errors
Failed example:
    _calc_errors(100, 100)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics._calc_errors[1]>", line 1, in <module>
        _calc_errors(100, 100)
    NameError: name '_calc_errors' is not defined


======================================================================
FAIL: approx_equal (test.test_statistics)
Doctest: test.test_statistics.approx_equal
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_statistics.approx_equal
  File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 41, in approx_equal

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 54, in test.test_statistics.approx_equal
Failed example:
    approx_equal(1.2589, 1.2587, tol=0.0003, rel=0)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics.approx_equal[0]>", line 1, in <module>
        approx_equal(1.2589, 1.2587, tol=0.0003, rel=0)
    NameError: name 'approx_equal' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_statistics.py", line 56, in test.test_statistics.approx_equal
Failed example:
    approx_equal(1.2589, 1.2587, tol=0.0001, rel=0)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_statistics.approx_equal[1]>", line 1, in <module>
        approx_equal(1.2589, 1.2587, tol=0.0001, rel=0)
    NameError: name 'approx_equal' is not defined

----------
assignee: stevenjd
components: Library (Lib), Tests
messages: 212008
nosy: pitrou, stevenjd
priority: high
severity: normal
status: open
title: test_statistics fails in refleak mode
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 23 18:19:49 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Feb 2014 17:19:49 +0000
Subject: [New-bugs-announce] [issue20746] test_pdb fails in refleak mode
Message-ID: <1393175989.77.0.544484586748.issue20746@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -m test -W -R3:3 test_pdb
[1/1] test_pdb
[...]

======================================================================
FAIL: test_list_commands (test.test_pdb)
Doctest: test.test_pdb.test_list_commands
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_list_commands
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 288, in test_list_commands

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 311, in test.test_pdb.test_list_commands
Failed example:
    with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
        'list',      # list first function
        'step',      # step into second function
        'list',      # list second function
        'list',      # continue listing to EOF
        'list 1,3',  # list specific lines
        'list x',    # invalid argument
        'next',      # step to import
        'next',      # step over import
        'step',      # step into do_nothing
        'longlist',  # list all lines
        'source do_something',  # list all lines of function
        'source fooxxx',        # something that doesn't exit
        'continue',
    ]):
       test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_list_commands[2]>", line 1, in <module>
        with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_next_until_return_at_return_event (test.test_pdb)
Doctest: test.test_pdb.test_next_until_return_at_return_event
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_next_until_return_at_return_event
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 603, in test_next_until_return_at_return_event

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 617, in test.test_pdb.test_next_until_return_at_return_event
Failed example:
    with PdbTestInput(['break test_function_2',
                       'continue',
                       'return',
                       'next',
                       'continue',
                       'return',
                       'until',
                       'continue',
                       'return',
                       'return',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_next_until_return_at_return_event[2]>", line 1, in <module>
        with PdbTestInput(['break test_function_2',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_basic_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_basic_commands
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_basic_commands
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 62, in test_pdb_basic_commands

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 81, in test.test_pdb.test_pdb_basic_commands
Failed example:
    with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
        'step',       # entering the function call
        'args',       # display function args
        'list',       # list function source
        'bt',         # display backtrace
        'up',         # step up to test_function()
        'down',       # step down to test_function_2() again
        'next',       # stepping to print(foo)
        'next',       # stepping to the for loop
        'step',       # stepping into the for loop
        'until',      # continuing until out of the for loop
        'next',       # executing the print(bar)
        'jump 8',     # jump over second for loop
        'return',     # return out of function
        'retval',     # display return value
        'continue',
    ]):
       test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_basic_commands[2]>", line 1, in <module>
        with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_breakpoint_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_breakpoint_commands
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_breakpoint_commands
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 172, in test_pdb_breakpoint_commands

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 194, in test.test_pdb.test_pdb_breakpoint_commands
Failed example:
    with PdbTestInput([  # doctest: +NORMALIZE_WHITESPACE
        'break 3',
        'disable 1',
        'ignore 1 10',
        'condition 1 1 < 2',
        'break 4',
        'break 4',
        'break',
        'clear 3',
        'break',
        'condition 1',
        'enable 1',
        'clear 1',
        'commands 2',
        'p "42"',
        'print("42", 7*6)',     # Issue 18764 (not about breakpoints)
        'end',
        'continue',  # will stop at breakpoint 2 (line 4)
        'clear',     # clear all!
        'y',
        'tbreak 5',
        'continue',  # will stop at temporary breakpoint
        'break',     # make sure breakpoint is gone
        'continue',
    ]):
       test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_breakpoint_commands[5]>", line 1, in <module>
        with PdbTestInput([  # doctest: +NORMALIZE_WHITESPACE
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_continue_in_bottomframe (test.test_pdb)
Doctest: test.test_pdb.test_pdb_continue_in_bottomframe
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_continue_in_bottomframe
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 517, in test_pdb_continue_in_bottomframe

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 529, in test.test_pdb.test_pdb_continue_in_bottomframe
Failed example:
    with PdbTestInput([  # doctest: +ELLIPSIS
        'next',
        'break 7',
        'continue',
        'next',
        'continue',
        'continue',
    ]):
       test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_continue_in_bottomframe[1]>", line 1, in <module>
        with PdbTestInput([  # doctest: +ELLIPSIS
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_displayhook (test.test_pdb)
Doctest: test.test_pdb.test_pdb_displayhook
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_displayhook
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 33, in test_pdb_displayhook

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 40, in test.test_pdb.test_pdb_displayhook
Failed example:
    with PdbTestInput([
        'foo',
        'bar',
        'for i in range(5): print(i)',
        'continue',
    ]):
        test_function(1, None)
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_displayhook[1]>", line 1, in <module>
        with PdbTestInput([
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_next_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_generator
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_next_command_for_generator
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 666, in test_pdb_next_command_for_generator

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 684, in test.test_pdb.test_pdb_next_command_for_generator
Failed example:
    with PdbTestInput(['step',
                       'step',
                       'step',
                       'next',
                       'next',
                       'step',
                       'step',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_next_command_for_generator[2]>", line 1, in <module>
        with PdbTestInput(['step',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_next_command_in_generator_for_loop (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_in_generator_for_loop
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_next_command_in_generator_for_loop
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 820, in test_pdb_next_command_in_generator_for_loop

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 833, in test.test_pdb.test_pdb_next_command_in_generator_for_loop
Failed example:
    with PdbTestInput(['break test_gen',
                       'continue',
                       'next',
                       'next',
                       'next',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_next_command_in_generator_for_loop[2]>", line 1, in <module>
        with PdbTestInput(['break test_gen',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_next_command_subiterator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_subiterator
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_next_command_subiterator
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 861, in test_pdb_next_command_subiterator

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 878, in test.test_pdb.test_pdb_next_command_subiterator
Failed example:
    with PdbTestInput(['step',
                       'step',
                       'next',
                       'next',
                       'next',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_next_command_subiterator[3]>", line 1, in <module>
        with PdbTestInput(['step',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_return_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_return_command_for_generator
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_return_command_for_generator
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 723, in test_pdb_return_command_for_generator

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 742, in test.test_pdb.test_pdb_return_command_for_generator
Failed example:
    with PdbTestInput(['step',
                       'step',
                       'step',
                       'return',
                       'step',
                       'step',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_return_command_for_generator[2]>", line 1, in <module>
        with PdbTestInput(['step',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_run_with_code_object (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_code_object
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_run_with_code_object
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 581, in test_pdb_run_with_code_object

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 584, in test.test_pdb.test_pdb_run_with_code_object
Failed example:
    with PdbTestInput(['step','x', 'continue']):  # doctest: +ELLIPSIS
        pdb_invoke('run', compile('x=1', '<string>', 'exec'))
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_run_with_code_object[0]>", line 1, in <module>
        with PdbTestInput(['step','x', 'continue']):  # doctest: +ELLIPSIS
    NameError: name 'PdbTestInput' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 594, in test.test_pdb.test_pdb_run_with_code_object
Failed example:
    with PdbTestInput(['x', 'continue']):
        x=0
        pdb_invoke('runeval', compile('x+1', '<string>', 'eval'))
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_run_with_code_object[1]>", line 1, in <module>
        with PdbTestInput(['x', 'continue']):
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_run_with_incorrect_argument (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_incorrect_argument
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_run_with_incorrect_argument
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 565, in test_pdb_run_with_incorrect_argument

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 568, in test.test_pdb.test_pdb_run_with_incorrect_argument
Failed example:
    pti = PdbTestInput(['continue',])
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_run_with_incorrect_argument[0]>", line 1, in <module>
        pti = PdbTestInput(['continue',])
    NameError: name 'PdbTestInput' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 569, in test.test_pdb.test_pdb_run_with_incorrect_argument
Failed example:
    with pti:
        pdb_invoke('run', lambda x: x)
Expected:
    Traceback (most recent call last):
    TypeError: exec() arg 1 must be a string, bytes or code object
Got:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_run_with_incorrect_argument[1]>", line 1, in <module>
        with pti:
    NameError: name 'pti' is not defined
----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 574, in test.test_pdb.test_pdb_run_with_incorrect_argument
Failed example:
    with pti:
        pdb_invoke('runeval', lambda x: x)
Expected:
    Traceback (most recent call last):
    TypeError: eval() arg 1 must be a string, bytes or code object
Got:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_run_with_incorrect_argument[2]>", line 1, in <module>
        with pti:
    NameError: name 'pti' is not defined


======================================================================
FAIL: test_pdb_skip_modules (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_skip_modules
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 446, in test_pdb_skip_modules

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 454, in test.test_pdb.test_pdb_skip_modules
Failed example:
    with PdbTestInput([
        'step',
        'continue',
    ]):
        skip_module()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_skip_modules[1]>", line 1, in <module>
        with PdbTestInput([
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_skip_modules_with_callback (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules_with_callback
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_skip_modules_with_callback
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 474, in test_pdb_skip_modules_with_callback

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 483, in test.test_pdb.test_pdb_skip_modules_with_callback
Failed example:
    with PdbTestInput([
        'step',
        'step',
        'step',
        'step',
        'step',
        'continue',
    ]):
        skip_module()
        pass  # provides something to "step" to
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_skip_modules_with_callback[1]>", line 1, in <module>
        with PdbTestInput([
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_pdb_until_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_until_command_for_generator
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_until_command_for_generator
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 776, in test_pdb_until_command_for_generator

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 791, in test.test_pdb.test_pdb_until_command_for_generator
Failed example:
    with PdbTestInput(['step',
                       'until 4',
                       'step',
                       'step',
                       'continue']):
        test_function()
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_pdb_until_command_for_generator[2]>", line 1, in <module>
        with PdbTestInput(['step',
    NameError: name 'PdbTestInput' is not defined


======================================================================
FAIL: test_post_mortem (test.test_pdb)
Doctest: test.test_pdb.test_post_mortem
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/doctest.py", line 2193, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_post_mortem
  File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 384, in test_post_mortem

----------------------------------------------------------------------
File "/home/antoine/cpython/default/Lib/test/test_pdb.py", line 398, in test.test_pdb.test_post_mortem
Failed example:
    with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
        'next',      # step over exception-raising call
        'bt',        # get a backtrace
        'list',      # list code of test_function()
        'down',      # step into test_function_2()
        'list',      # list code of test_function_2()
        'continue',
    ]):
       try:
           test_function()
       except ZeroDivisionError:
           print('Correctly reraised.')
Exception raised:
    Traceback (most recent call last):
      File "/home/antoine/cpython/default/Lib/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest test.test_pdb.test_post_mortem[2]>", line 1, in <module>
        with PdbTestInput([  # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE
    NameError: name 'PdbTestInput' is not defined

----------
components: Library (Lib), Tests
messages: 212009
nosy: georg.brandl, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_pdb fails in refleak mode
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 23 18:59:37 2014
From: report at bugs.python.org (Rik)
Date: Sun, 23 Feb 2014 17:59:37 +0000
Subject: [New-bugs-announce] [issue20747] Charset.header_encode in
	email.charset doesn't take a	maxlinelen argument and has
	inconsistent behavior with	different encodings
Message-ID: <1393178377.04.0.906048305625.issue20747@psf.upfronthosting.co.za>


New submission from Rik:

If you look at the `header_encode` method in the `Charset` class in `email.charset`, you'll see that depending on the `header_encoding` that is set on the `Charset` instance, it will either encode it using base64 or quoted-printable (QP):

http://hg.python.org/cpython/file/3a1db0d2747e/Lib/email/charset.py#l351

However, QP always uses `maxlinelen=None` and base64 doesn't. This results in the following behaviour:

- If you use base64 encoding and your header size is longer than the default `maxlinelen`, it will be split over multiple lines.
- If you use QP encoding with the same header it doesn't get split over multiple lines.

You can easily test it with this snippet:

    from email.charset import Charset, BASE64, QP

    header = (
        'tejkstj tlkjes takldjf aseio neaoiflk asnfoieas nflkdan foeias '
        'naskln ioeasn kldan flkansoie naslk dnaslk fndaslk fneoisaf '
        'neklasn dfklasnf oiasenf lkadsn lkfanldk fas dfknaioe nas'
    )

    charset = Charset('utf-8')

    charset.header_encoding = BASE64
    print 'BASE64:'
    print charset.header_encode(header)

    charset.header_encoding = QP
    print 'QP:'
    print charset.header_encode(header)

Which will output:

    BASE64:
    =?utf-8?b?dGVqa3N0aiB0bGtqZXMgdGFrbGRqZiBhc2VpbyBuZWFvaWZsayBhc25mb2llYXMg?=
     =?utf-8?b?bmZsa2RhbiBmb2VpYXMgbmFza2xuIGlvZWFzbiBrbGRhbiBmbGthbnNvaWUgbmFz?=
     =?utf-8?b?bGsgZG5hc2xrIGZuZGFzbGsgZm5lb2lzYWYgbmVrbGFzbiBkZmtsYXNuZiBvaWFz?=
     =?utf-8?b?ZW5mIGxrYWRzbiBsa2ZhbmxkayBmYXMgZGZrbmFpb2UgbmFz?=
    QP:
    =?utf-8?q?tejkstj_tlkjes_takldjf_aseio_neaoiflk_asnfoieas_nflkdan_foeias_naskln_ioeasn_kldan_flkansoie_naslk_dnaslk_fndaslk_fneoisaf_neklasn_dfklasnf_oiasenf_lkadsn_lkfanldk_fas_dfknaioe_nas?=

This is inconsistent behavior.

Aside from that, I think the `header_encode` method should accept an argument `maxlinelen` that defaults to an appropriate value (probably 76), but which you can overwrite on free will.

This is (I think) also necessary because the `Header` class in `email.header` has a `maxlinelen` attribute that is used for the same purpose. Normally this works fine, but when you specified a charset for your header, it uses the `Charset` class and the `maxlinelen` is lost. This is happening here:

http://hg.python.org/cpython/file/3a1db0d2747e/Lib/email/header.py#l368

You see, the `_encode_chunks` takes the `maxlinelen` argument but doesn't pass it on to the `header_encode` method of `charset` (which is a `Charset` instance).

As such, you can see this issue in action with the following snippet:

    from email.header import Header

    maxlinelen = 9999999

    print 'No charset:'
    print Header(
        u'asdfjk lasjdf sajdfl ajsdfaj sdlkfjas kfladjs flkajsdflk jsadklf jadslkfj adslkfj asdlkjf lksadjfkldas jfkldasj fkadsj fladsjf kladsjfk asdjfkldasasd kfaj  kfladsj fkadsjf asdf ',
        maxlinelen=maxlinelen
    ).encode()

    print 'Charset with special characters:'
    print Header(
        u'attachment; filename="ajdsklfj klasdjfkl asdjfkl jadsfja sdflkads fad fads adsf dasjfkl jadslkfj dlasf asd \u6211\u6211\u6211 jo \u6211\u6211 jo \u6211\u6211"',
        charset='utf-8',
        maxlinelen=9999999
    ).encode()

Which will output:

    No charset:
    asdfjk lasjdf sajdfl ajsdfaj sdlkfjas kfladjs flkajsdflk jsadklf jadslkfj adslkfj asdlkjf lksadjfkldas jfkldasj fkadsj fladsjf kladsjfk asdjfkldasasd kfaj  kfladsj fkadsjf asdf
    Charset with special characters:
    =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImFqZHNrbGZqIGtsYXNkamZrbCBhc2RqZmts?=
     =?utf-8?b?IGphZHNmamEgc2RmbGthZHMgZmFkIGZhZHMgYWRzZiBkYXNqZmtsIGphZHNsa2Zq?=
     =?utf-8?b?IGRsYXNmIGFzZCDmiJHmiJHmiJEgam8g5oiR5oiRIGpvIOaIkeaIkSI=?=

This is currently an issue we're experiencing in Django, see our issue in the issue tracker:
https://code.djangoproject.com/ticket/20889#comment:4

----------
components: Library (Lib), email
messages: 212011
nosy: barry, r.david.murray, rednaw
priority: normal
severity: normal
status: open
title: Charset.header_encode in email.charset doesn't take a maxlinelen argument and has inconsistent behavior with different encodings
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb 23 19:17:01 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Feb 2014 18:17:01 +0000
Subject: [New-bugs-announce] [issue20748] 3.4rc2 MSI uninstallation leaves
	behind ensurepip	_uninstall .pyc
Message-ID: <1393179421.3.0.600062954886.issue20748@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

The installer currently leaves behind a single pyc file, namely 

Lib\ensurepip\__pycache__\_uninstall.cpython-34.pyc

I believe that the problem is that installer computes the list of files to be removed in the script generation phase, finding out what files match __pycache__\*.*. The _uninstall .pyc is not there yet. Then, during script execution, first pip uninstallation is run, creating the pyc file, then the (precomputed) list of files is removed.

In rc1, this was not a problem because PIP removal happened in the UI phase (i.e. before script execution); this was changed to support elevated privileges in #20641.

The simplest work-around could be to run pip uninstallation with -B. I just edited the MSI with orca, and that seems to work fine.

If anybody can suggest how installer could be instructed to remove the .pyc regularly through the RemoveFiles action, I'd appreciate any help.

----------
messages: 212014
nosy: loewis
priority: release blocker
severity: normal
status: open
title: 3.4rc2 MSI uninstallation leaves behind ensurepip _uninstall .pyc

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

From report at bugs.python.org  Sun Feb 23 22:13:37 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 23 Feb 2014 21:13:37 +0000
Subject: [New-bugs-announce] [issue20749] shutil.unpack_archive(): security
	concerns not documented
Message-ID: <1393190017.96.0.0939250007559.issue20749@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

shutil.unpack_archive() uses tarfile.extractall() under the hood, so it's not suitable for unpacking untrusted archives. But this fact is not documented.

Please add a security warning to shutil.unpack_archive() documentation.

----------
assignee: docs at python
components: Documentation
messages: 212029
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: shutil.unpack_archive(): security concerns not documented

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

From report at bugs.python.org  Sun Feb 23 23:07:06 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Feb 2014 22:07:06 +0000
Subject: [New-bugs-announce] [issue20750] Roundtrip-test
	tokenize.untokenize(iterable_of_5_tuples)
Message-ID: <1393193226.83.0.860669897793.issue20750@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Currently, test_tokenize.roundtrip only tests the 2-tuple mode of untokenize. The currently buggy 5-tuple mode needs to be tested also, as far as possible, to reduce the chance of introducing more bugs when fixing current bugs. When this is done, all the constructed tests pass. Good so far.

The doctest normally tests 10 files selected from test/test_*.py and a few tries showed no problem. However, when testing all with -ucpu. 
F:\Python\dev> 3\py33\pcbuild\python_d -m test -ucpu test_tokenize
7 failed. So we must remove these from the list of candidates until the failure cause is determined and either fixed or determined not fixable (as with test_3131.py).

As suggested in the revised docstring, finding the failure items for these 7 would be much easier if the file roundtrip test were removed from the doctest and made into a unittest with assertEqual.

----------
assignee: terry.reedy
components: Library (Lib), Tests
messages: 212034
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Roundtrip-test tokenize.untokenize(iterable_of_5_tuples)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 23 23:13:56 2014
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 23 Feb 2014 22:13:56 +0000
Subject: [New-bugs-announce] [issue20751] Misleading examples indDescriptor
	protocol documentation
Message-ID: <1393193636.36.0.125202538555.issue20751@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

1. One misleading detail in the descriptor protocol documentation for super bindings is that the following fragment of the http://docs.python.org/reference/datamodel.html#invoking-descriptors page:

"""
Super Binding
    If a is an instance of super, then the binding super(B, obj).m() searches obj.__class__.__mro__ for the base class A immediately preceding B and then invokes the descriptor with the call: A.__dict__['m'].__get__(obj, obj.__class__).
"""

...introduces the method *call* (".m()") which AFAIK has nothing to do with the actual matter of the description (attribute resolution).

Also, the "If *a* is an instance of super" fragment is strange, as *a* is not used in the following sentences at all.

I believe the description should be:

"""
Super Binding
    If binding to a super instance, super(B, obj).x searches obj.__class__.__mro__ for the base class A immediately preceding B and then invokes the descriptor with the call: A.__dict__['x'].__get__(obj, obj.__class__).
"""

(using 'x' as the attribute name, as for the other kinds of binding).

***

2. Also, in some earlier fragment of the same page:

"""
Direct Call
    The simplest and least common call is when user code directly invokes a descriptor method: x.__get__(a).
"""

The call x.__get__(a) without the second argument seems to be wrong if  __get__ is implemented according to the specification "object.__get__(self, instance, owner)" from the same documentation page.

----------
assignee: docs at python
components: Documentation
messages: 212035
nosy: docs at python, zuo
priority: normal
severity: normal
status: open
title: Misleading examples indDescriptor protocol documentation
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/issue20751>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:16:56 2014
From: report at bugs.python.org (Chris Rose)
Date: Sun, 23 Feb 2014 22:16:56 +0000
Subject: [New-bugs-announce] [issue20752] Difflib should provide the option
	of overriding the	SequenceMatcher
Message-ID: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za>


New submission from Chris Rose:

It should be possible to provide subclasses or implementations of the SequenceMatcher interface to difflib's various methods that do formatting (for example, unified_diff/context_diff et al).

I've included a patch for it that satisfies my personal itch on the subject (attached). I'd like to have this reviewed for inclusion in 3.5.

----------
components: Library (Lib)
files: difflib-sm.patch
keywords: patch
messages: 212036
nosy: offby1
priority: normal
severity: normal
status: open
title: Difflib should provide the option of overriding the SequenceMatcher
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34203/difflib-sm.patch

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

From report at bugs.python.org  Mon Feb 24 00:25:13 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 23 Feb 2014 23:25:13 +0000
Subject: [New-bugs-announce] [issue20753] disable test_robotparser
Message-ID: <1393197913.25.0.58929774722.issue20753@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Lib/tests/test_robotparser.py uses the following url:
    http://mueblesmoraleda.com/robots.txt

That file now serves a 404.

This should be disabled for 3.4, and the test rewritten for 3.5.  If we get a patch quickly I would probably cherry-pick it for 3.4 final.

Aside: it is REALLY IRRITATING that we have tests in the standard library that hit external web sites.  The standard library regression test suite should *not* rely on network access.  Can the rewritten test please spin up a local web server (http.server) and serve a robotx.txt that way?

----------
messages: 212044
nosy: larry
priority: high
severity: normal
stage: needs patch
status: open
title: disable test_robotparser
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 24 01:27:50 2014
From: report at bugs.python.org (Alex Brandt)
Date: Mon, 24 Feb 2014 00:27:50 +0000
Subject: [New-bugs-announce] [issue20754] distutils should use
	SafeConfigParser
Message-ID: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>


New submission from Alex Brandt:

I first noticed this issue when configuring nose via setup.cfg and reported the behavior in this issue on their tracker: https://github.com/nose-devs/nose/issues/733

I'll repaste the important bits here:

When using a setup.cfg with the following contents (including minor variations):

[nosetests]
logging-format = %(lineno)d: %(process)d: %(message)s
With any setup.py file the following error is raised when trying to run setup.py (python2.7 used for example, error also occurs in 3.3):

alunduil at elijah margarine % python2.7 setup.py nosetests
Traceback (most recent call last):
  File "setup.py", line 108, in <module>
    setup(**PARAMS)
  File "/usr/lib64/python2.7/distutils/core.py", line 125, in setup
    dist.parse_config_files()
  File "/usr/lib64/python2.7/distutils/dist.py", line 397, in parse_config_files
    val = parser.get(section,opt)
  File "/usr/lib64/python2.7/ConfigParser.py", line 623, in get
    return self._interpolate(section, option, value, d)
  File "/usr/lib64/python2.7/ConfigParser.py", line 669, in _interpolate
    option, section, rawval, e.args[0])
ConfigParser.InterpolationMissingOptionError: Bad value substitution:
        section: [nosetests]
        option : logging-format
        key    : pathname
        rawval : %(pathname)s:%(lineno)d: %(process)d: %(message)s

The suggested fix of using %% to pass the interpolation through to nose requires that distutils use SafeConfigParser rather than ConfigParser.

I've verified that this does indeed appear to work (at least fixing the distutils interaction).  The only place the change needs to be made is on lines 378 and 386 in distutils/dist.py.

I can attach a patch or send a pull request with this fix if there are no objections to this solution.

----------
components: Distutils
messages: 212048
nosy: alunduil
priority: normal
severity: normal
status: open
title: distutils should use SafeConfigParser
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Feb 24 01:33:44 2014
From: report at bugs.python.org (fk)
Date: Mon, 24 Feb 2014 00:33:44 +0000
Subject: [New-bugs-announce] [issue20755] 3.3.4: doc build fails on Sphinx <
	1.2
Message-ID: <1393202024.84.0.959375038368.issue20755@psf.upfronthosting.co.za>


New submission from fk:

With 5d1324b20804, building the docs with Sphinx < 1.2 doesn't work anymore. Unfortunately, I don't have the specific exception handy, but in line 34, `versionlabels[node['type']]` produces a KeyError because versionlabels is missing a 'deprecated-removed' key. Re-adding the "versionlabels['deprecated-removed'] = ..." lines seems to help; see also https://bitbucket.org/fk/deadsnakes-python3.3/src/8e82e76578cd20ba08ab5addd04651c8abc7f05b/debian/patches/fix-non-1.2-sphinx-builds.diff

----------
components: Build
messages: 212050
nosy: fkrull
priority: normal
severity: normal
status: open
title: 3.3.4: doc build fails on Sphinx < 1.2
type: compile error
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 24 03:13:53 2014
From: report at bugs.python.org (Sworddragon)
Date: Mon, 24 Feb 2014 02:13:53 +0000
Subject: [New-bugs-announce] [issue20756] Segmentation fault with unoconv
Message-ID: <1393208033.51.0.325325143651.issue20756@psf.upfronthosting.co.za>


New submission from Sworddragon:

With Python 3.4.0 RC1 on using the command "unoconv -o test.pdf test.odt" I'm getting a segmentation fault. In the attachments are the used LibreOffice document and a GDB backtrace. The used version of unoconv was 0.6-6 from Ubuntu 14.04 dev and can be currently found here: http://packages.ubuntu.com/de/source/trusty/unoconv

----------
components: Interpreter Core
files: backtrace.txt
messages: 212052
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Segmentation fault with unoconv
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file34206/backtrace.txt

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

From report at bugs.python.org  Mon Feb 24 08:10:07 2014
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Mon, 24 Feb 2014 07:10:07 +0000
Subject: [New-bugs-announce] [issue20757] 3.4rc2 Traceback on Windows
	compilation script
Message-ID: <1393225807.54.0.352328433353.issue20757@psf.upfronthosting.co.za>


New submission from Jeroen Ruigrok van der Werven:

Just tried the rc2 MSI on Windows 7 x64. Go through the normal setup I always pick the Advanced option of compiling the .py files. In rc1 the script it spawns works as it should, with rc2 I see it pop up, have a Traceback before it quickly closes again.

And this fails the install.

----------
keywords: 3.4regression
messages: 212062
nosy: asmodai, larry
priority: release blocker
severity: normal
status: open
title: 3.4rc2 Traceback on Windows compilation script
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 24 10:10:38 2014
From: report at bugs.python.org (Charley Peng)
Date: Mon, 24 Feb 2014 09:10:38 +0000
Subject: [New-bugs-announce] [issue20758] mimetypes initialization order
Message-ID: <1393233038.02.0.945903372957.issue20758@psf.upfronthosting.co.za>


New submission from Charley Peng:

I thought that it would make more sense to check that the registry entry starts with a . before it attempts to request it in mimetypes.py.

In any case, this fixed issue 9291 for me. (I realize it's just an incidental fix)

----------
components: Windows
messages: 212075
nosy: chid
priority: normal
severity: normal
status: open
title: mimetypes initialization order
type: crash
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/issue20758>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:39:12 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Mon, 24 Feb 2014 09:39:12 +0000
Subject: [New-bugs-announce] [issue20759] unittest.mock documentation typo
Message-ID: <1393234752.67.0.021930442298.issue20759@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

Python unittest.mock documentation has typo:
  indvidually
instead of
  individually

Can be seen in the documentation source file at:

http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock-examples.rst#l429

----------
assignee: docs at python
components: Documentation
messages: 212079
nosy: Jurko.Gospodneti?, docs at python
priority: normal
severity: normal
status: open
title: unittest.mock documentation typo
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 24 14:06:34 2014
From: report at bugs.python.org (Vipul Borikar)
Date: Mon, 24 Feb 2014 13:06:34 +0000
Subject: [New-bugs-announce] [issue20760] test_compileall test getting
	failed on 3.4 RC
Message-ID: <1393247194.23.0.0410918224117.issue20760@psf.upfronthosting.co.za>


New submission from Vipul Borikar:

Hi,
    I getting python trace when running test_compileall test case 

OS:
 
$ uname -a
Linux vipul-desktop 3.8.13.8 #1 SMP Thu Oct 3 17:54:03 IST 2013 x86_64 x86_64 x86_64 GNU/Linux


Python Version:
 
$ ./bin/python3 -V
Python 3.4.0rc2


Output and Error:

$ ./bin/python3 -m test -v test_compileall
== CPython 3.4.0rc2 (default, Feb 24 2014, 16:28:23) [GCC 4.7.3]
==   Linux-3.8.13.8-x86_64-with-debian-wheezy-sid little-endian
==   hash algorithm: siphash24 64bit
==   /tmp/test_python_6884
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_compileall
test_compiles_as_much_as_possible (test.test_compileall.CommandLineTests) ... ok
test_d_compile_error (test.test_compileall.CommandLineTests) ... ok
test_d_runtime_error (test.test_compileall.CommandLineTests) ... ok
test_d_takes_exactly_one_dir (test.test_compileall.CommandLineTests) ... ok
test_force (test.test_compileall.CommandLineTests) ... ok
test_include_bad_file (test.test_compileall.CommandLineTests) ... ok
test_include_file_no_arg (test.test_compileall.CommandLineTests) ... ok
test_include_file_with_arg (test.test_compileall.CommandLineTests) ... ok
test_include_on_stdin (test.test_compileall.CommandLineTests) ... ok
test_invalid_arg_produces_message (test.test_compileall.CommandLineTests) ... ok
test_legacy_paths (test.test_compileall.CommandLineTests) ... ok
test_multiple_dirs (test.test_compileall.CommandLineTests) ... ok
test_multiple_runs (test.test_compileall.CommandLineTests) ... ok
test_no_args_compiles_path (test.test_compileall.CommandLineTests) ... ok
test_no_args_respects_force_flag (test.test_compileall.CommandLineTests) ... FAIL
test_no_args_respects_quiet_flag (test.test_compileall.CommandLineTests) ... ok
test_pep3147_paths_doubleoptimize (test.test_compileall.CommandLineTests) ... ok
test_pep3147_paths_normal (test.test_compileall.CommandLineTests) ... ok
test_pep3147_paths_optimize (test.test_compileall.CommandLineTests) ... ok
test_quiet (test.test_compileall.CommandLineTests) ... ok
test_recursion_control (test.test_compileall.CommandLineTests) ... ok
test_regexp (test.test_compileall.CommandLineTests) ... ok
test_compile_files (test.test_compileall.CompileallTests) ... ok
test_magic_number (test.test_compileall.CompileallTests) ... ok
test_mtime (test.test_compileall.CompileallTests) ... ok
test_no_pycache_in_non_package (test.test_compileall.CompileallTests) ... ok
test_optimize (test.test_compileall.CompileallTests) ... ok
test_error (test.test_compileall.EncodingTest) ... ok

======================================================================
FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/Python3.4/lib/python3.4/test/test_compileall.py", line 194, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "/opt/Python3.4/lib/python3.4/test/test_compileall.py", line 144, in assertRunOK
    *self._get_run_args(args), **env_vars)
  File "/opt/Python3.4/lib/python3.4/test/script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/opt/Python3.4/lib/python3.4/test/script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:


----------------------------------------------------------------------
Ran 28 tests in 1.791s

FAILED (failures=1)
test test_compileall failed
1 test failed:
    test_compileall

----------
components: Tests
messages: 212091
nosy: vipulb
priority: normal
severity: normal
status: open
title: test_compileall test getting failed on 3.4 RC
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 24 15:10:29 2014
From: report at bugs.python.org (Tiberiu Dragulinescu)
Date: Mon, 24 Feb 2014 14:10:29 +0000
Subject: [New-bugs-announce] [issue20761] os.path.join doesn't strip LF or CR
Message-ID: <1393251029.08.0.170694764366.issue20761@psf.upfronthosting.co.za>


New submission from Tiberiu Dragulinescu:

>>>d="asdasd"+chr(10)
>>>print os.path.normpath(os.path.join('a/b',d,'d'))
a\b\asdasd
\d

LF or CR cannot be part of a URI (rfc1738)

----------
components: Windows
messages: 212099
nosy: ExtraVeral
priority: normal
severity: normal
status: open
title: os.path.join doesn't strip LF or CR
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 24 18:21:43 2014
From: report at bugs.python.org (Enrico Bianchi)
Date: Mon, 24 Feb 2014 17:21:43 +0000
Subject: [New-bugs-announce] [issue20762] SSLSocket.read() not documented
Message-ID: <1393262503.02.0.956219773808.issue20762@psf.upfronthosting.co.za>


New submission from Enrico Bianchi:

although exists, read() method isn't reported in the SSLSocket documentation. Please, fix it

----------
assignee: docs at python
components: Documentation
messages: 212115
nosy: docs at python, ebianchi
priority: normal
severity: normal
status: open
title: SSLSocket.read() not documented
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 25 04:36:04 2014
From: report at bugs.python.org (Yukihiro Nakadaira)
Date: Tue, 25 Feb 2014 03:36:04 +0000
Subject: [New-bugs-announce] [issue20763] old sys.path_hooks importer does
	not work with Python	3.4.0rc1
Message-ID: <1393299364.35.0.447125292603.issue20763@psf.upfronthosting.co.za>


New submission from Yukihiro Nakadaira:

Steps to reproduce:

$ cat a.py
import sys

class MyFinder:
    def __init__(self, path):
        if path != "__myfinder__":
            raise ImportError()

    def find_module(self, fullname, path=None):
        return None

sys.path_hooks.append(MyFinder)
sys.path.insert(0, '__myfinder__')

import time
print('OK')

$ python3.3 -V
Python 3.3.2+

$ python3.3 a.py
OK

$ python3.4 -V
Python 3.4.0rc1

$ python3.4 a.py
Traceback (most recent call last):
  File "a.py", line 14, in <module>
    import time
ImportError: spec missing loader


On Ubuntu 13.10.
python3.3 is ubuntu's package.
python3.4.0rc1 is built by myself.

Vim's custom importer does not work for it.

[vim_dev] Problem with Python 3.4
https://groups.google.com/d/msg/vim_dev/RfuOG7_Jabs/h3YzLTsRgv0J

----------
messages: 212158
nosy: ynkdir
priority: normal
severity: normal
status: open
title: old sys.path_hooks importer does not work with Python 3.4.0rc1
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 25 05:26:55 2014
From: report at bugs.python.org (Sworddragon)
Date: Tue, 25 Feb 2014 04:26:55 +0000
Subject: [New-bugs-announce] [issue20764] os.walk recurses down even with
	dirnames deleted
Message-ID: <1393302415.5.0.321729780429.issue20764@psf.upfronthosting.co.za>


New submission from Sworddragon:

The following was tested on Linux. In the attachments is the example code and here is my output:

sworddragon at ubuntu:/tmp$ ./test.py
1


I'm deleting the list of directories on every recursion and skipping if I'm directly in /proc (which is theoretically already unneeded). Also the default value for topdown is True and followlinks is False. I have already read the documentation but I'm not seeing any way how the condition could be True so I'm assuming this is a bug.

----------
components: Library (Lib)
files: test.py
messages: 212159
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: os.walk recurses down even with dirnames deleted
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file34219/test.py

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

From report at bugs.python.org  Tue Feb 25 05:37:53 2014
From: report at bugs.python.org (Antony Lee)
Date: Tue, 25 Feb 2014 04:37:53 +0000
Subject: [New-bugs-announce] [issue20765] Pathlib docs fail to mention
	with_name, with_suffix
Message-ID: <1393303073.92.0.0729490655848.issue20765@psf.upfronthosting.co.za>


New submission from Antony Lee:

I actually thought that Path.with_{name,suffix} had been removed before 3.4 when I didn't find them in the official docs...

----------
assignee: docs at python
components: Documentation
messages: 212160
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Pathlib docs fail to mention with_name, with_suffix
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 25 12:02:34 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 25 Feb 2014 11:02:34 +0000
Subject: [New-bugs-announce] [issue20766] reference leaks in pdb
Message-ID: <1393326154.87.0.194575074306.issue20766@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

After the pdb 'continue' command, the signal module owns a reference to Pdb.sigint_handler. On the next instantiation of pdb, the signal module owns a reference to a new sigint_handler method that owns a reference to the previous sigint_handler. As a consequence, the first pdb instance is never freed (as well as the frames that are referenced by this pdb instance). The following test demonstrates the problem that is fixed by the attached patch.

Run the following script:

# START of refleak.py
import sys, gc, pdb

i = 1
while i:
    pdb.set_trace()
    x = 1
    gc.collect(); print(sys.gettotalrefcount())

# END of refleak.py


With the following pdb commands:

$ python refleak.py
> /tmp/test/refleak.py(6)<module>()
-> x = 1
(Pdb) continue
95898
> /home/xavier/tmp/test/refleak.py(5)<module>()
-> pdb.set_trace()
(Pdb) continue
95983
> /tmp/test/refleak.py(6)<module>()
-> x = 1
(Pdb) continue
96068
> /tmp/test/refleak.py(5)<module>()
-> pdb.set_trace()
(Pdb) i = 0
(Pdb) continue
96153

----------
components: Library (Lib)
files: refleak.patch
keywords: patch
messages: 212171
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: reference leaks in pdb
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34220/refleak.patch

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

From report at bugs.python.org  Tue Feb 25 14:33:18 2014
From: report at bugs.python.org (Antoine Brodin.FreeBSD)
Date: Tue, 25 Feb 2014 13:33:18 +0000
Subject: [New-bugs-announce] [issue20767] Some python extensions can't be
	compiled with clang 3.4
Message-ID: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>


New submission from Antoine Brodin.FreeBSD:

Hi,

On FreeBSD -current,  clang 3.4 is now the default compiler.
Clang 3.4 rejects "-R/path/to/lib" flag (previously in version 3.3 it just ignored it).

This leads to some errors with some python extensions:

cc -shared -O2 -pipe -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/connection.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cursor.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/microprotocols.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/module.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/prepare_protocol.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/row.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/statement.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/util.o -L/usr/local/lib -R/usr/local/lib -lsqlite3 -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_sqlite3.so
cc: error: unknown argument: '-R/usr/local/lib'
error: command 'cc' failed with exit status 1


cc -shared -O2 -pipe -DLDAP_DEPRECATED -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/LDAPObject.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/ldapcontrol.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/common.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/constants.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/errors.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/functions.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/schema.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/ldapmodule.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/message.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/version.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/options.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/berval.o -L/usr/local/lib -L/usr/lib -R/usr/local/lib -R/usr/lib -lldap_r -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_ldap.so
cc: error: unknown argument: '-R/usr/local/lib'
cc: error: unknown argument: '-R/usr/lib'
error: command 'cc' failed with exit status 1


cc -shared -O2 -pipe -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/_bsddb.o -L/usr/local/lib -R/usr/local/lib -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/bsddb3/_pybsddb.so -ldb-4.3
cc: error: unknown argument: '-R/usr/local/lib'
error: command 'cc' failed with exit status 1


I found the patch below to help, it is for function runtime_library_dir_option in Lib/distutils/unixccompiler.py
-Wl,-rpath works for both gcc and clang on freebsd

--- ./Lib/distutils/unixccompiler.py.orig
+++ ./Lib/distutils/unixccompiler.py
@@ -228,6 +228,8 @@
         if sys.platform[:6] == "darwin":
             # MacOSX's linker doesn't understand the -R flag at all
             return "-L" + dir
+        elif sys.platform[:7] == "freebsd":
+            return "-Wl,-rpath=" + dir
         elif sys.platform[:5] == "hp-ux":
             if self._is_gcc(compiler):
                 return ["-Wl,+s", "-L" + dir]

----------
components: Distutils
messages: 212176
nosy: Antoine.Brodin.FreeBSD, koobs
priority: normal
severity: normal
status: open
title: Some python extensions can't be compiled with clang 3.4
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 25 15:03:30 2014
From: report at bugs.python.org (Felipe Sateler)
Date: Tue, 25 Feb 2014 14:03:30 +0000
Subject: [New-bugs-announce] [issue20768] pyconfig.h #defines macros in
	global namespace
Message-ID: <1393337010.57.0.329094843269.issue20768@psf.upfronthosting.co.za>


New submission from Felipe Sateler:

I reported the following in the debian bug tracker[1], and it was requested that I report it here.

pyconfig.h has definitions like the following:

    #define HAVE_DIRENT_H 1
    #define HAVE_DLFCN_H 1

These are the general form feature test macros take in practically any
software project. This means that when building a python module these
feature macros conflict. In the best scenario, you get a redefinition
warning. In the worst scenario, the build breaks because of inconsistent
#defines between the module and pyconfig.h.

Please either don't include pycongfig.h from Python.h, or appropiately
namespace the test macros (PYTHON_HAVE_* or something like that).


[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738726

----------
components: Installation
messages: 212178
nosy: fsateler
priority: normal
severity: normal
status: open
title: pyconfig.h #defines macros in global namespace
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Feb 25 17:23:55 2014
From: report at bugs.python.org (Roy Smith)
Date: Tue, 25 Feb 2014 16:23:55 +0000
Subject: [New-bugs-announce] [issue20769] Reload() description is unclear
Message-ID: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>


New submission from Roy Smith:

http://docs.python.org/2/library/functions.html#reload says:

It is legal though generally not very useful to reload built-in or dynamically loaded modules, except for sys, __main__ and __builtin__.

It is unclear what the "except for ..." part is referring to.  Is it not legal to reload those modules?  Or is it not very useful to reload them?

----------
assignee: docs at python
components: Documentation
messages: 212187
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: Reload() description is unclear
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 25 19:20:19 2014
From: report at bugs.python.org (And Clover)
Date: Tue, 25 Feb 2014 18:20:19 +0000
Subject: [New-bugs-announce] [issue20770] Inform caller of smtplib STARTTLS
	failures
Message-ID: <1393352419.14.0.647705184863.issue20770@psf.upfronthosting.co.za>


New submission from And Clover:

When an SMTP server responds to the STARTTLS command with an error, the smtplib.SMTP.starttls() method does not raise an exception, as it would if TLS negotiation itself failed. Consequently na?ve callers of the function may assume that a TLS connection has actually been established and continue to send sensitive mail through the interface.

In reality starttls() returns a tuple of response code and message from which the fail state can be detected, but this is not documented and no caller code I've met does anything with it.

Either:

1. Treat it as a doc bug for 3.4. The return value should be documented and callers warned that they need to check that value[0]==220 before assuming they have negotiated TLS. Or,

2. starttls() should raise SMTPResponseException for responses other than 220 in a future Python version, especially if moving towards validate-by-default. Possibly only raise an exception if the SSLContext.verify_mode is REQUIRED?

----------
components: Library (Lib)
messages: 212192
nosy: aclover
priority: normal
severity: normal
status: open
title: Inform caller of smtplib STARTTLS failures
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 25 20:03:27 2014
From: report at bugs.python.org (Alfonso Andalon Jr.)
Date: Tue, 25 Feb 2014 19:03:27 +0000
Subject: [New-bugs-announce] [issue20771] Download Talkray...
Message-ID: <CAOyy2NsF9Yfqm4miE1zeORT5i34K7sYevcRmNo-VViRG8=ZAdg@mail.gmail.com>


New submission from Alfonso Andalon Jr.:

Download this http://talkray.com/dl/ee

----------
messages: 212199
nosy: Alfonso.Andalon.Jr.
priority: normal
severity: normal
status: open
title: Download Talkray...

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

From report at bugs.python.org  Tue Feb 25 20:37:50 2014
From: report at bugs.python.org (LuisC)
Date: Tue, 25 Feb 2014 19:37:50 +0000
Subject: [New-bugs-announce] [issue20772] You only live once
Message-ID: <530CEEE0.509030@nacha.org>


New submission from LuisC:

DR.RecomendYou will feel slimmer right away.CLick here for more details
If it is not for you, then send it back

----------
messages: 212205
nosy: lcarrionr
priority: normal
severity: normal
status: open
title: You only live once

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

From report at bugs.python.org  Tue Feb 25 22:12:29 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 25 Feb 2014 21:12:29 +0000
Subject: [New-bugs-announce] [issue20773] Improve docs for
	DynamicClassAttribute
Message-ID: <1393362749.08.0.709900927194.issue20773@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Per RDM in issue19030, the docs could be better.

----------
messages: 212214
nosy: ethan.furman, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Improve docs for DynamicClassAttribute

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

From report at bugs.python.org  Tue Feb 25 22:15:50 2014
From: report at bugs.python.org (Chris Adams)
Date: Tue, 25 Feb 2014 21:15:50 +0000
Subject: [New-bugs-announce] [issue20774] collections.deque should ship with
	a stdlib json	serializer
Message-ID: <1393362950.58.0.308283739635.issue20774@psf.upfronthosting.co.za>


New submission from Chris Adams:

Currently the stdlib json module requires a custom serializer to avoid throwing a TypeError on collections.deque instances:

Python 3.3.4 (default, Feb 12 2014, 09:35:54) 
[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 collections import deque
>>> import json
>>> d = deque(range(0, 10))
>>> json.dumps(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.3.4/Frameworks/Python.framework/Versions/3.3/lib/python3.3/json/__init__.py", line 233, in dumps
    return _default_encoder.encode(obj)
  File "/usr/local/Cellar/python3/3.3.4/Frameworks/Python.framework/Versions/3.3/lib/python3.3/json/encoder.py", line 191, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/local/Cellar/python3/3.3.4/Frameworks/Python.framework/Versions/3.3/lib/python3.3/json/encoder.py", line 249, in iterencode
    return _iterencode(o, 0)
  File "/usr/local/Cellar/python3/3.3.4/Frameworks/Python.framework/Versions/3.3/lib/python3.3/json/encoder.py", line 173, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: deque([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is not JSON serializable

----------
messages: 212215
nosy: acdha
priority: normal
severity: normal
status: open
title: collections.deque should ship with a stdlib json serializer
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Feb 25 23:00:00 2014
From: report at bugs.python.org (Naftali Harris)
Date: Tue, 25 Feb 2014 22:00:00 +0000
Subject: [New-bugs-announce] [issue20775] Modifications to global variables
	ignored after	instantiating multiprocessing.Pool
Message-ID: <1393365600.9.0.351514373601.issue20775@psf.upfronthosting.co.za>


New submission from Naftali Harris:

Hi everyone,

It appears that if you use a global variable in a function that you pass to Pool.map, but modify that global variable after instantiating the Pool, then the modification will not be reflected when Pool.map calls that function.

Here's a short script, (also attached), that demonstrates what I mean:

$ cat reproduces.py
from multiprocessing import Pool

name = "Not Updated"
def f(ignored):
    print(name)


def main():
    global name
    p = Pool(3)
    name = "Updated"
    p.map(f, range(3))

if __name__ == "__main__":
    main()
$ python reproduces.py 
Not Updated
Not Updated
Not Updated


If the `name = "Updated"' line is moved above the `p = Pool(3)' line, then the script will print "Updated" three times instead.

This behavior is present in versions 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4. I run Linux Mint 14 (nadia), on an Intel i5-3210M processor (four cores).

Is this expected behavior?

Thanks very much,

Naftali

----------
components: Library (Lib)
files: reproduces.py
messages: 212221
nosy: Naftali.Harris
priority: normal
severity: normal
status: open
title: Modifications to global variables ignored after instantiating multiprocessing.Pool
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34223/reproduces.py

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

From report at bugs.python.org  Wed Feb 26 01:09:11 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Feb 2014 00:09:11 +0000
Subject: [New-bugs-announce] [issue20776] Add tests for
	importlib.machinery.PathFinder
Message-ID: <1393373351.13.0.19162591832.issue20776@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Specifically tests that exercise uses of importlib.abc.PathEntryFinder (i.e. find_module() successfully, find_loader() failing and successful, find_spec() failing and successful).

----------
components: Library (Lib)
messages: 212231
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add tests for importlib.machinery.PathFinder
versions: Python 3.5

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

From report at bugs.python.org  Wed Feb 26 04:25:15 2014
From: report at bugs.python.org (Carlos Ferreira)
Date: Wed, 26 Feb 2014 03:25:15 +0000
Subject: [New-bugs-announce] [issue20777] PyArg_ParseTupleAndKeywords does
	not respect arguments	format.
Message-ID: <1393385115.15.0.117931989302.issue20777@psf.upfronthosting.co.za>


New submission from Carlos Ferreira:

PyArg_ParseTupleAndKeywords is not respecting the format string "sy*ss"

When using the format "sbss" with the following valid arguments
"enp0s8", 0, "08:00:27:da:b3:47", "08:00:27:11:22:33"
there is no error and the function succeeds in parsing the arguments.

But when passing the following valid arguments,
"8bf2f93c-8f44-4960-a2de-71f87130882e", bytes(list([0,0,0,1])), "08:00:27:11:22:33", "10.0.0.3"
it will fail stating that the 3rd argument has a null character.

----------
components: Extension Modules
messages: 212236
nosy: Claymore
priority: normal
severity: normal
status: open
title: PyArg_ParseTupleAndKeywords does not respect arguments format.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 26 10:49:14 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 26 Feb 2014 09:49:14 +0000
Subject: [New-bugs-announce] [issue20778] ModuleFinder.load_module skips
	incorrect number of bytes	in pyc files
Message-ID: <1393408154.81.0.798109041302.issue20778@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

ModuleFinder.load_module currently only skips 8 bytes before trying to marshal.load the rest of the file, but it should skip 12 since 3.3 (magic, date, file size). I'm attaching a patch with test case.

BTW this was very painful to find out, since I couldn't find any reference to written pyc files - am I searching wrong or is this really not documented anywhere?

(Note, that this was originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1060338).

----------
components: Library (Lib)
files: fix-bytes-skipped-in-load_module.patch
keywords: patch
messages: 212244
nosy: bkabrda
priority: normal
severity: normal
status: open
title: ModuleFinder.load_module skips incorrect number of bytes in pyc files
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34226/fix-bytes-skipped-in-load_module.patch

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

From report at bugs.python.org  Wed Feb 26 10:51:50 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 26 Feb 2014 09:51:50 +0000
Subject: [New-bugs-announce] [issue20779] Add pathlib.chown method
Message-ID: <1393408310.22.0.917230781145.issue20779@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

For pragmatic and philosophical reasons, I would argue that we should add chown to pathlib library.

----------
components: Library (Lib)
files: add_chown_to_pathlib.patch
keywords: patch
messages: 212245
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Add pathlib.chown method
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34227/add_chown_to_pathlib.patch

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

From report at bugs.python.org  Wed Feb 26 11:43:17 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 26 Feb 2014 10:43:17 +0000
Subject: [New-bugs-announce] [issue20780] Shadowed (duplicate name but
	different body) test in	test_statistics
Message-ID: <1393411397.34.0.693108095146.issue20780@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Line 994 of Lib/test/test_statistics.py:

    def test_decimal_mismatched_infs_to_nan(self):
        # Test adding Decimal INFs with opposite sign returns NAN.
        inf = Decimal('inf')
        data = [1, 2, inf, 3, -inf, 4]
        with decimal.localcontext(decimal.ExtendedContext):
            self.assertTrue(math.isnan(statistics._sum(data)))

    def test_decimal_mismatched_infs_to_nan(self):
        # Test adding Decimal INFs with opposite sign raises InvalidOperation.
        inf = Decimal('inf')
        data = [1, 2, inf, 3, -inf, 4]
        with decimal.localcontext(decimal.BasicContext):
            self.assertRaises(decimal.InvalidOperation, statistics._sum, data)

Here is the patch. I also removed unnecessary import.

----------
components: Tests
files: fix_shadowed_test_in_test_statistics.patch
keywords: patch
messages: 212247
nosy: stevenjd, vajrasky
priority: normal
severity: normal
status: open
title: Shadowed (duplicate name but different body) test in test_statistics
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34228/fix_shadowed_test_in_test_statistics.patch

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

From report at bugs.python.org  Wed Feb 26 12:59:20 2014
From: report at bugs.python.org (James Dominy)
Date: Wed, 26 Feb 2014 11:59:20 +0000
Subject: [New-bugs-announce] [issue20781] BZ2File does decompress some .bz2
	files correctly
Message-ID: <1393415960.86.0.411484359826.issue20781@psf.upfronthosting.co.za>


New submission from James Dominy:

bz2.BZ2File does not decompress a file (see attached) correctly. This file can be decompressed and compressed via stadard unix tools (bzip2 and bunzip2) without change.

Consider ...

$ python
Python 2.7.6 (default, Dec  7 2013, 22:49:16) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> import hashlib
>>> len(bz2.BZ2File("example-file.csv.bz2", "r", 0).read())
900000
>>> hashlib.md5(bz2.BZ2File("example-file.csv.bz2", "r", 0).read()).hexdigest()
'e2d4ce212a040c879cb256f88c9faab9'
>>> len(bz2.BZ2File("example-file.csv.bz2", "rb", 0).read())
900000
>>> hashlib.md5(bz2.BZ2File("example-file.csv.bz2", "rb", 0).read()).hexdigest()
'e2d4ce212a040c879cb256f88c9faab9'
>>> 

It looks like bz2 is not dealing with the second block. This is not the first file I've come across that has this problem, and initially I thought it was the file not the module. I've attached a copy of the file.

I use gentoo on a 64bit intel core i5.

----------
components: IO
files: example-file.csv.bz2
messages: 212250
nosy: James.Dominy
priority: normal
severity: normal
status: open
title: BZ2File does decompress some .bz2 files correctly
versions: Python 2.7
Added file: http://bugs.python.org/file34230/example-file.csv.bz2

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

From report at bugs.python.org  Wed Feb 26 16:08:28 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Feb 2014 15:08:28 +0000
Subject: [New-bugs-announce] [issue20782] base64 module docs do not use the
	terms 'bytes' and	'string' consistently.
Message-ID: <1393427308.42.0.0461164572304.issue20782@psf.upfronthosting.co.za>


New submission from R. David Murray:

The base64 documentation (http://docs.python.org/3/library/base64.html) does not use the new python3 byte/string terminology consistently (sometimes not even within the same paragraph).

----------
assignee: docs at python
components: Documentation
messages: 212258
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: base64 module docs do not use the terms 'bytes' and 'string' consistently.
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Feb 26 19:10:15 2014
From: report at bugs.python.org (Andrew P. Lentvorski, Jr.)
Date: Wed, 26 Feb 2014 18:10:15 +0000
Subject: [New-bugs-announce] [issue20783] bytearray init fails when \x00 is
	present
Message-ID: <1393438215.16.0.542095625334.issue20783@psf.upfronthosting.co.za>


New submission from Andrew P. Lentvorski, Jr.:

The byte array init fails when \x00 is present

This fails:
ggRAM = bytearray(RAM_SIZE_BYTES, '\x00'*RAM_SIZE_BYTES)

However, this works:
ggRAM = bytearray(RAM_SIZE_BYTES)
ggRAM[:] = '\x00'*RAM_SIZE_BYTES

----------
components: Interpreter Core
messages: 212281
nosy: bsder
priority: normal
severity: normal
status: open
title: bytearray init fails when \x00 is present
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 26 19:25:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Feb 2014 18:25:38 +0000
Subject: [New-bugs-announce] [issue20784] 'collections.abc' is no longer
	defined when collections	is imported
Message-ID: <1393439138.94.0.309642790057.issue20784@psf.upfronthosting.co.za>


New submission from R. David Murray:

collections.abc was renamed _collections_abc in issue 19218.  The __init__ file was modified to load all the abc into the collections namespace, but the 'abc' name itself is no longer defined:

Python 3.3.2 (default, Dec 17 2013, 17:24:42) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> collections.abc
<module 'collections.abc' from '/usr/lib/python3.3/collections/abc.py'>

Python 3.4.0rc1+ (default:1bc585ba5df2, Feb 24 2014, 15:04:31) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> collections.abc
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'abc'

It looks like the import statement for _collections_abc in the __init__ file as has missing "as abc" phrase.

This is probably not important enough to require fixing in the RC, since 'import collections.abc' works fine, but it is a regression.

----------
keywords: 3.4regression
messages: 212284
nosy: Arfrever, barry, christian.heimes, eric.snow, haypo, larry, pitrou, python-dev, r.david.murray, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: 'collections.abc' is no longer defined when collections is imported
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 26 22:30:21 2014
From: report at bugs.python.org (Victor Lazzarini)
Date: Wed, 26 Feb 2014 21:30:21 +0000
Subject: [New-bugs-announce] [issue20785] Missing symbols in Python27.lib
	(Windows 64bit)
Message-ID: <1393450221.97.0.598907595215.issue20785@psf.upfronthosting.co.za>


New submission from Victor Lazzarini:

It appears various symbols are missing from Python27.lib, 64bit build.
Here is a list of undefined symbols (from link errors):

/debug/Opcodes && /c/mingw-builds/x64-4.8.1-posix-seh-rev5/mingw64/bin/gcc.exe -Wl,--add-stdcall-alias -shared -o ../py.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/py.dir/objects.a -Wl,--no-whole-archive /C/Python27/libs/python27.lib -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x14a):
undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x973):
undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x99d):
undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0xa83):
undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0xc23):
undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0xc4b):
more undefined references to `__imp_PyExc_RuntimeError' follow
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x1b22):
 undefined reference to `__imp__Py_NoneStruct'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x1b7c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x1d19):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x1d6d):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x205c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x21f5):
 undefined reference to `__imp__Py_NoneStruct'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2251):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2388):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2404):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x263c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x291c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2a33):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2b23):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2bc0):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2c44):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2e4b):
 undefined reference to `__imp__Py_NoneStruct'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x2ece):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x312c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x340c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x36ac):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x38e9):
 undefined reference to `__imp__Py_NoneStruct'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x3941):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x3cfe):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x40ac):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x431c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x45ac):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x486c):
 more undefined references to `__imp_PyExc_RuntimeError' follow
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x6c99):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x6cdd):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x6e03):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x7093):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x72cc):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x754c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x77dc):
 more undefined references to `__imp_PyExc_RuntimeError' follow
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x7c3b):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x7c7f):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x7d7c):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x7df4):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x806c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8173):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x81e4):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x82b3):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x84b9):
 undefined reference to `__imp__Py_NoneStruct'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8511):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x85e2):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8664):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x891c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8acb):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8b1f):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8c93):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8df3):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8f03):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x8fe3):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x9163):
 more undefined references to `__imp_PyExc_RuntimeError' follow
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x95c6):
 undefined reference to `__imp_PyFloat_Type'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x960c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x987c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x9bcc):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0x9eac):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0xa14c):
 undefined reference to `__imp_PyExc_RuntimeError'
CMakeFiles/py.dir/objects.a(pythonopcodes.c.obj):pythonopcodes.c:(.text+0xa3fc):
 more undefined references to `__imp_PyExc_RuntimeError' follow

These symbols do not exist in 64bit, but are there in the 32bit library.See for instance PyFloat_Type:

victor at ligetipc ~/csound6/debug
$ nm /c/Python27/libs/Python27.lib | grep "PyFloat_Type"

victor at ligetipc ~/csound6/debug
$ nm /c/Python27-i386/libs/libpython27.a | grep "PyFloat_Type"
00000000 I __imp__PyFloat_Type
00000000 T _PyFloat_Type

----------
components: Build
messages: 212308
nosy: Victor.Lazzarini
priority: normal
severity: normal
status: open
title: Missing symbols in Python27.lib (Windows 64bit)
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 26 23:10:16 2014
From: report at bugs.python.org (mike bayer)
Date: Wed, 26 Feb 2014 22:10:16 +0000
Subject: [New-bugs-announce] [issue20786] inspect.getargspec() returns wrong
	answer with	property.__delete__()
Message-ID: <1393452616.0.0.994094049294.issue20786@psf.upfronthosting.co.za>


New submission from mike bayer:

The Python builtin property() historically does not allow inspect.getargspec to be called on any of __get__(), __set__(), or __delete__().  As of 3.4, it seems that this call now succeeds.  However the answer it gives for __delete__() seems to be incorrect. Below illustrates that property.__delete__() accepts two arguments "self" and "instance" but inspect is giving a misleading answer:

import inspect

# userland descriptor
class Descriptor(object):
    def __get__(self, instance, owner):
        if instance is None:
            return self
    def __set__(self, instance, value):
        pass
    def __delete__(self, instance):
        pass

# class with property + userland descriptor
class X(object):
    @property
    def foo(self):
        pass
    @foo.deleter
    def foo(self):
        pass

    bar = Descriptor()

# property.__delete__ and Descriptor.__delete__ both accept two arguments:
property.__delete__(X.foo, X())
Descriptor.__delete__(X.bar, X())

# on all versions, userland __delete__ produces 'self', 'instance' for args
assert inspect.getargspec(Descriptor.__delete__) == (['self', 'instance'], None, None, None)


try:
    # but on python 3.4, it returns ['instance']
    insp = inspect.getargspec(property.__delete__)
    assert insp == (['self', 'instance'], None, None, None), insp
except TypeError as e:
    # on all other python versions, raises
    # <slot wrapper '__delete__' of 'property' objects> is not a Python function
    print("Exception: %s" % e)

----------
messages: 212313
nosy: zzzeek
priority: normal
severity: normal
status: open
title: inspect.getargspec() returns wrong answer with property.__delete__()
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 26 23:27:38 2014
From: report at bugs.python.org (akira)
Date: Wed, 26 Feb 2014 22:27:38 +0000
Subject: [New-bugs-announce] [issue20787] typo in asyncio docs for
	subprocess_exec()
Message-ID: <1393453658.86.0.247755965136.issue20787@psf.upfronthosting.co.za>


New submission from akira:

subprocess' stdout pipe is open for *reading* but its value is documented as an argument for `BaseEventLoop.connect_write_pipe`. It should be `BaseEventLoop.connect_read_pipe` instead. As it currently is for subprocess' stderr.

The patch is attached.

----------
assignee: docs at python
components: Documentation
files: typo-subprocess_exec-docs.patch
keywords: patch
messages: 212316
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: typo in asyncio docs for subprocess_exec()
versions: Python 3.4
Added file: http://bugs.python.org/file34235/typo-subprocess_exec-docs.patch

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

From report at bugs.python.org  Wed Feb 26 23:37:09 2014
From: report at bugs.python.org (Matt Goodman)
Date: Wed, 26 Feb 2014 22:37:09 +0000
Subject: [New-bugs-announce] [issue20788] distutils.msvccompiler - flags are
	hidden inside	initialize()
Message-ID: <1393454229.75.0.568305276882.issue20788@psf.upfronthosting.co.za>


New submission from Matt Goodman:

The flags that you need to compile against libpythonXX.lib are hidden inside of the distutils.msvccompiler class.  This is ok if you want to use distutils to compile extensions against the binary, but other build systems need to run initialize() to get access to the compiler_options attribute.  This call requires a bunch of things to be correct (think MSVC on the path, expected names, etc), and fails in a great quantity of vanilla Windows/Python configurations.   

One example includes the scraping function waf:
https://code.google.com/p/waf/source/browse/waflib/Tools/python.py#347

I am also sure SCons does this somewhere (or at least ought to).  

I think these values hard coded into the function ought to be exposed elsewhere to streamline other build systems finding them and linking against the core library.  I was thinking something like adding a function that looked something like get_flags(arch, debugTF), which then the initialize() function draws on.  

I am willing to write a patch, but I wanted to make sure there some consensus about the best way to do this before trooping off.  Thanks

----------
components: Distutils, Windows
messages: 212318
nosy: Matt.Goodman
priority: normal
severity: normal
status: open
title: distutils.msvccompiler - flags are hidden inside initialize()
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 27 00:28:40 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Feb 2014 23:28:40 +0000
Subject: [New-bugs-announce] [issue20789] [3.4] cherrypick 5dec1604322c
Message-ID: <1393457320.34.0.833965611924.issue20789@psf.upfronthosting.co.za>


New submission from Brett Cannon:

changeset 89406:5dec1604322c tip



Issue #20763: Fix importlib.machinery.PathFinder to support
PathEntryFinder instances which only define find_module().

Reported by Yukihiro Nakadaira. [#20763]
author	Brett Cannon <brett at python.org>
date	Wed, 26 Feb 2014 18:26:49 -0500 (19 seconds ago)
parents	1a38fa1f701d
children	
files	Lib/importlib/_bootstrap.py Lib/test/test_importlib/import_/test_path.py Python/importlib.h
diffstat	 3 files changed, 26 insertions(+), 2 deletions(-) [+]


Left out Misc/NEWS to prevent bad merging into 3.4.0final.

----------
assignee: larry
components: Interpreter Core
messages: 212326
nosy: brett.cannon, larry
priority: release blocker
severity: normal
status: open
title: [3.4] cherrypick 5dec1604322c
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 27 00:48:26 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Feb 2014 23:48:26 +0000
Subject: [New-bugs-announce] [issue20790] Make sure exec_module()
	implementations are documented
Message-ID: <1393458506.1.0.629772640029.issue20790@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. importlib.abc.InspectLoader() has load_module() deprecated by no equivalent exec_module() documented. Make sure that no other exec_module() instances have been added but undocumented.

----------
assignee: brett.cannon
components: Documentation
messages: 212330
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Make sure exec_module() implementations are documented
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 27 09:58:03 2014
From: report at bugs.python.org (Frank Millman)
Date: Thu, 27 Feb 2014 08:58:03 +0000
Subject: [New-bugs-announce] [issue20791] copy.copy(bytes) is slow
Message-ID: <1393491483.28.0.0745198504357.issue20791@psf.upfronthosting.co.za>


New submission from Frank Millman:

Using copy.copy on a byte string returns a new copy instead of the original immutable object. Using copy.deepcopy returns the original, as expected. Testing with timeit, copy.copy is much slower than copy.deepcopy.

>>> import copy
>>>
>>> a = 'a'*1000  # string
>>> copy.copy(a) is a
True
>>> copy.deepcopy(a) is a
True
>>>
>>> b = b'b'*1000  # bytes
>>> copy.copy(b) is b
False
>>> copy.deepcopy(b) is b
True

----------
components: Library (Lib)
messages: 212340
nosy: frankmillman
priority: normal
severity: normal
status: open
title: copy.copy(bytes) is slow
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 27 10:29:43 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 27 Feb 2014 09:29:43 +0000
Subject: [New-bugs-announce] [issue20792] IDLE: Extend tests for PathBrowser
Message-ID: <1393493383.85.0.956500002219.issue20792@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

This patch does 
1.Remove pep8 violations in PathBrowser.py . Replaces "file","dir","sorted" by "file_","dir_","sorted_" respectively.
2.Extends test coverage for PathBrowser.py in idle_test/test_PathBrowser.py

New modules now under tests include
1.dirBrowserTreeItem - getText,ispackagedir
2.pathBrowserTreeItem - getText,getSublist

Only method missing a test after this patch will be listmodules.I am not too sure whether it requires a test for itself.it is indirectly being tested from lines 8 and 9(in the current tip).

----------
components: IDLE, Tests
files: pathbrowser1.patch
keywords: patch
messages: 212343
nosy: sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Extend tests for PathBrowser
versions: Python 3.4
Added file: http://bugs.python.org/file34243/pathbrowser1.patch

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

From report at bugs.python.org  Thu Feb 27 12:56:07 2014
From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Fleschenberg?=)
Date: Thu, 27 Feb 2014 11:56:07 +0000
Subject: [New-bugs-announce] [issue20793] locale.setlocale()
Message-ID: <1393502167.29.0.618138255127.issue20793@psf.upfronthosting.co.za>


New submission from Ren? Fleschenberg:

locale.setlocale() does not work if you pass it a ``unicode`` object instead of a ``str`` (locale.py, line 576):

    ``if locale and type(locale) is not type(""):``

Maybe it would be better to do a check like this?

    ``if locale and not isinstance(locale, basestring):``

In particular, this can bite you if you use the ``unicode_literals`` future import, displaying a not-so-helpful error message ("ValueError: too many values to unpack" in _build_localename).

----------
messages: 212350
nosy: rene
priority: normal
severity: normal
status: open
title: locale.setlocale()
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 27 13:13:07 2014
From: report at bugs.python.org (Naval Gupta)
Date: Thu, 27 Feb 2014 12:13:07 +0000
Subject: [New-bugs-announce] [issue20794] ImportError: Bad magic number in
	.pyc file
Message-ID: <1393503187.81.0.323490537909.issue20794@psf.upfronthosting.co.za>


New submission from Naval Gupta:

Getting below compilation error:

ImportError: Bad magic number in xxxx.pyc

Ran a python abc.py module which is trying to import xxxx.pyc during compilation

Python Interpreter used to run: Python 2.7
Python pre-compiled file xxxx.pyc is compiled using Python 2.6

----------
components: Interpreter Core
messages: 212351
nosy: navalkgupta
priority: normal
severity: normal
status: open
title: ImportError: Bad magic number in .pyc file
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 27 15:04:46 2014
From: report at bugs.python.org (LuisC)
Date: Thu, 27 Feb 2014 14:04:46 +0000
Subject: [New-bugs-announce] [issue20795] Feel our love and care. Order
	medications from our	drugstore.
Message-ID: <530F4270.709080@nacha.org>


New submission from LuisC:

HelloKiss those diets good bye. Lose weight quick the easy way. Watch video!Just for you - visit now
Buy more, pay less! Be healthy with best meds for women.

----------
messages: 212355
nosy: lcarrionr
priority: normal
severity: normal
status: open
title: Feel our love and care. Order medications from our drugstore.

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

From report at bugs.python.org  Thu Feb 27 15:32:17 2014
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 27 Feb 2014 14:32:17 +0000
Subject: [New-bugs-announce] [issue20796] Test failures when running with
	PYTHONDONTWRITEBYTECODE
Message-ID: <1393511537.77.0.0251224920867.issue20796@psf.upfronthosting.co.za>


New submission from Chris Angelico:

$ find . -name \*.pyc -delete
$ PYTHONDONTWRITEBYTECODE=1 make test

Three test failures, which all seem to be duplicates of:

======================================================================
FAIL: test_timestamp_overflow (test.test_importlib.source.test_file_loader.Source_SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rosuav/cpython/Lib/test/test_importlib/source/test_file_loader.py", line 215, in test_timestamp_overflow
    self.assertTrue(os.path.exists(compiled))
AssertionError: False is not true

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


It goes looking for the .pyc cached file, does not find it, and fails. Test should probably be skipped if bytecode isn't being written.

----------
messages: 212356
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Test failures when running with PYTHONDONTWRITEBYTECODE

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

From report at bugs.python.org  Thu Feb 27 15:43:51 2014
From: report at bugs.python.org (Laurent Mazuel)
Date: Thu, 27 Feb 2014 14:43:51 +0000
Subject: [New-bugs-announce] [issue20797] zipfile.extractall should accept
	bytes path as parameter
Message-ID: <1393512231.07.0.576439646525.issue20797@psf.upfronthosting.co.za>


New submission from Laurent Mazuel:

Many methods which use path in Python now accept string or bytes in parameter (e.g. all methods in "os.path", the "open" method, etc.).

Actually, sometimes it is not possible to handle a file without using bytes path. For example, path coded in another encoding system than the current locale system (e.g. a Windows filename encoded in "cp1252" against a Linux "utf-8" system).

Since "zipfile.extractall" uses path, it should accept bytes as path. Currently it leads to an error:
  File "/usr/local/lib/python3.3/zipfile.py", line 1262, in _extract_member
    targetpath = os.path.join(targetpath, arcname)
  File "/usr/local/lib/python3.3/posixpath.py", line 92, in join
    "components.") from None
TypeError: Can't mix strings and bytes in path components.

This bug is closely related to bug 20329 but is not the same (but maybe this enhancement will create a good debate around bytes support in zipfile module :-) )

----------
components: Library (Lib)
messages: 212358
nosy: Laurent.Mazuel
priority: normal
severity: normal
status: open
title: zipfile.extractall should accept bytes path as parameter
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 27 17:40:42 2014
From: report at bugs.python.org (Pete Zaitcev)
Date: Thu, 27 Feb 2014 16:40:42 +0000
Subject: [New-bugs-announce] [issue20798] Reversed order in testtools
	messages
Message-ID: <1393519242.26.0.28804654783.issue20798@psf.upfronthosting.co.za>


New submission from Pete Zaitcev:

When using an assert such as self.assertEquals(tester(), expected), an error message suggests wrong argument order (as in, not the order in examples in the documentation). Apparently this is confusing enough that OpenStack even opened a whole bunch of bugs and filed patches to swap the order in the tests:
 https://bugs.launchpad.net/ceilometer/+bug/1277104

If the code is:

import testtools

class TestConfigTrueValue(testtools.TestCase):
    def test_testEquals(self):
        reference = "reference-0123456789012345678901234567890123456789"
        def function_under_test():
            return "actual-0123456789012345678901234567890123456789"
        self.assertEquals(function_under_test(), reference)

then running it yields

[zaitcev at guren xxx]$ python3 -c 'import nose; nose.main()'
F
======================================================================
FAIL: testic.TestConfigTrueValue.test_testEquals
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/q/zaitcev/tmp/xxx/testic.py", line 10, in test_testEquals
    self.assertEquals(function_under_test(), reference)
  File "/usr/lib/python3.3/site-packages/testtools/testcase.py", line 322, in assertEqual
    self.assertThat(observed, matcher, message)
  File "/usr/lib/python3.3/site-packages/testtools/testcase.py", line 417, in assertThat
    raise MismatchError(matchee, matcher, mismatch, verbose)
testtools.matchers._impl.MismatchError: !=:
reference = 'actual-0123456789012345678901234567890123456789'
actual    = 'reference-0123456789012345678901234567890123456789'

----------
components: Library (Lib)
messages: 212366
nosy: zaitcev
priority: normal
severity: normal
status: open
title: Reversed order in testtools messages
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Feb 27 17:46:44 2014
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2014 16:46:44 +0000
Subject: [New-bugs-announce] [issue20799] Turn on all tests
	in	test.test_importlib.source.test_file_loader
Message-ID: <1393519604.31.0.77308400069.issue20799@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Some tests have a leading underscore which means they were probably turned off for testing purposes but forgot to be flipped back on. Should turn them back on and make sure that they actually still pass.

----------
assignee: brett.cannon
components: Library (Lib)
keywords: easy
messages: 212367
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Turn on all tests in test.test_importlib.source.test_file_loader
versions: Python 3.5

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

From report at bugs.python.org  Fri Feb 28 01:06:01 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2014 00:06:01 +0000
Subject: [New-bugs-announce] [issue20800] Cannot run gui tests twice.
Message-ID: <1393545961.36.0.67475510111.issue20800@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

After the fix for #20567, running test_idle and then test_ttk_guionly works, but running either after itself does not. Example command and output, which is same running with installed 3.4.0rc1 (Feb 11) or fresh debug build.

F:\Python\dev> 4\py34\pcbuild\python_d.exe -m test -ugui test_ttk_guionly test_ttk_guionly
[1/2] test_ttk_guionly
Warning -- os.environ was modified by test_ttk_guionly
[2/2] test_ttk_guionly
test test_ttk_guionly crashed -- Traceback (most recent call last):
  File "F:\Python\dev\4\py34\lib\test\test_ttk_guionly.py", line 35, in test_main
    *runtktests.get_tests(text=False, packages=['test_ttk']))
  File "F:\Python\dev\4\py34\lib\test\support\__init__.py", line 1719, in run_unittest
    _run_suite(suite)
  File "F:\Python\dev\4\py34\lib\test\support\__init__.py", line 1694, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred; run in verbose mode for details

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Python\dev\4\py34\lib\test\regrtest.py", line 1278, in runtest_inner
    test_runner()
  File "F:\Python\dev\4\py34\lib\test\test_ttk_guionly.py", line 37, in test_main
    get_tk_root().destroy()
  File "F:\Python\dev\4\py34\lib\tkinter\test\support.py", line 60, in get_tk_root
    root = tkinter.Tk()
  File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 1807, 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:
    F:/Python/dev/4/py34/lib/tcl8.6 F:/Python/dev/4/py34/lib/tcl8.6 F:/Python/dev/4/lib/tcl8.6 F:/Python/dev/4/py34/library F:/Python/dev/4/library F:/Python/dev/4/tcl8.6.1/library F:/Python/dev/tcl8.6.1/library

init.tcl *is* in 4/tcl8.6.1.0/library and 4/tcltk/tcl8.6/lib. I believe it is usually found in the latter.

This might be Windows only.

----------
components: Tests, Tkinter
messages: 212397
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Cannot run gui tests twice.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 28 07:13:28 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Fri, 28 Feb 2014 06:13:28 +0000
Subject: [New-bugs-announce] [issue20801] WindowsError: [Error 2] The system
	cannot find the file	specified
Message-ID: <1393568008.72.0.918310069424.issue20801@psf.upfronthosting.co.za>


New submission from Pramod Jadhav:

Exception in thread Thread-18:
Traceback (most recent call last):
  File "C:\Anaconda\lib\threading.py", line 810, in __bootstrap_inner
    self.run()
  File "C:\Anaconda\lib\threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "C:\Anaconda\lib\site-packages\envoy\core.py", line 32, in target
  File "C:\Anaconda\lib\subprocess.py", line 709, in __init__
    errread, errwrite)
  File "C:\Anaconda\lib\subprocess.py", line 957, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

----------
messages: 212407
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: WindowsError: [Error 2] The system cannot find the file specified
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 28 07:48:58 2014
From: report at bugs.python.org (Pramod Jadhav)
Date: Fri, 28 Feb 2014 06:48:58 +0000
Subject: [New-bugs-announce] [issue20802] AttributeError: 'NoneType' object
	has no attribute	'returncode'
Message-ID: <1393570138.08.0.290620690258.issue20802@psf.upfronthosting.co.za>


New submission from Pramod Jadhav:

AttributeError                            Traceback (most recent call last)
<ipython-input-16-c985c6423e2d> in <module>()
      7 #F='C:\Users\Prashant\Documents\IPython Notebooks\resources\ch06-mailboxes'
      8 F='resources/ch06-mailboxes/data/enron.mbox.json.bz2'
----> 9 r = envoy.run("bunzip2 %s" % (F,))
     10 print r.std_out
     11 print r.std_err

C:\Anaconda\lib\site-packages\envoy\core.py in run(command, data, timeout)
    166 
    167         cmd = Command(c)
--> 168         out, err = cmd.run(data, timeout)
    169 
    170         r = Response(process=cmd)

C:\Anaconda\lib\site-packages\envoy\core.py in run(self, data, timeout)
     51             self.process=process;
     52             thread.join()
---> 53         self.returncode = self.process.returncode
     54         return self.out, self.err
     55 

AttributeError: 'NoneType' object has no attribute 'returncode'

----------
messages: 212409
nosy: pramod.jadhav
priority: normal
severity: normal
status: open
title: AttributeError: 'NoneType' object has no attribute 'returncode'

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

From report at bugs.python.org  Fri Feb 28 10:17:29 2014
From: report at bugs.python.org (Andrew P. Lentvorski, Jr.)
Date: Fri, 28 Feb 2014 09:17:29 +0000
Subject: [New-bugs-announce] [issue20803] struct.pack_into writes 0x00 for
	pad bytes
Message-ID: <1393579049.39.0.501282349647.issue20803@psf.upfronthosting.co.za>


New submission from Andrew P. Lentvorski, Jr.:

This code did something unexpected to me:
>>> a = bytearray('1234')
>>> a
bytearray(b'1234')
>>> struct.pack_into('xBxB', a, 0, 0x59, 0x5A)
>>> a
bytearray(b'\x00Y\x00Z')


The unexpected part was that the 'x' pad byte formatter actually *overwrote* the bytes to 0 rather than leaving them alone.

Not necessarily a bug, but the fact that the pad byte writes 0x00 rather than being untouched/ignored should be documented.

----------
components: Interpreter Core
messages: 212416
nosy: bsder
priority: normal
severity: normal
status: open
title: struct.pack_into writes 0x00 for pad bytes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 28 10:22:37 2014
From: report at bugs.python.org (=?utf-8?q?Vlastimil_Z=C3=ADma?=)
Date: Fri, 28 Feb 2014 09:22:37 +0000
Subject: [New-bugs-announce] [issue20804] Sentinels identity lost when
	pickled (unittest.mock)
Message-ID: <1393579357.22.0.503856996983.issue20804@psf.upfronthosting.co.za>


New submission from Vlastimil Z?ma:

Sentinels lose their identity when they are pickled, meaning they are no longer equal to sentinel with the same name.


>>> from mock import sentinel
>>> import pickle
>>> sentinel.foo == sentinel.foo
True
>>> pickle.loads(pickle.dumps(sentinel.foo)) == sentinel.foo
False


I found this bug using Python 2.7.3 and python-mock 1.0.1. Since mock 1.0 is part of Python 3.3 and 3.4 it affects these versions (tested in 3.3.3).

This behavior is tricky to find out if encountered in tests and sentinels can not be used in tests of code which uses pickle and possibly other serializations.

----------
components: Tests
messages: 212417
nosy: Vlastimil.Z?ma
priority: normal
severity: normal
status: open
title: Sentinels identity lost when pickled (unittest.mock)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 28 12:59:00 2014
From: report at bugs.python.org (Gene Anderson)
Date: Fri, 28 Feb 2014 11:59:00 +0000
Subject: [New-bugs-announce] [issue20805] Error in 3.3 Tutorial
Message-ID: <1393588740.3.0.309738412893.issue20805@psf.upfronthosting.co.za>


New submission from Gene Anderson:

In the tutorial for Python 3.3 the content for 9.3.4 Method Objects seems to have an error.  In the following lines:

xf = x.f
while True:
    print(xf())

... it seems to me that based on the x object's method f(), the command should be 

    print(x.f())

At least it did when I tried to run it without the endless loop.  I'm pretty new at this Python stuff, though, so I could be wrong.

----------
messages: 212421
nosy: Andesheng
priority: normal
severity: normal
status: open
title: Error in 3.3 Tutorial
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 28 13:33:25 2014
From: report at bugs.python.org (Geoffrey Spear)
Date: Fri, 28 Feb 2014 12:33:25 +0000
Subject: [New-bugs-announce] [issue20806] os.times document points to wrong
	section of non-Linux	manual
Message-ID: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za>


New submission from Geoffrey Spear:

The documentation for os.times directs the reader: "See the Unix manual page times(2) or the corresponding Windows Platform API documentation."

However, the POSIX manual page in question is times(3P), and on OS X and BSD systems it's times(3). Falling back to "man times" without specifying a manual section also doesn't work, since this finds the bash builtin rather than the library function.

----------
assignee: docs at python
components: Documentation
messages: 212424
nosy: docs at python, geoffreyspear
priority: normal
severity: normal
status: open
title: os.times document points to wrong section of non-Linux manual
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/issue20806>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:42:52 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Feb 2014 13:42:52 +0000
Subject: [New-bugs-announce] [issue20807] 3.4 cherry pick: 82ec02db7fe6 &
	ec42ab5e0cb3 Windows	installer fixes
Message-ID: <1393594972.92.0.224231899327.issue20807@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Larry, these two commits are the fixes for issue 20757 (making sure Windows uninstallation still works even if the user has independently updated pip) and issue 20568 (making sure the bare "pip" command is installed on Windows).

Their NEWS entries are in the 3.4.1 section on default, so that will likely need some tweaks.

----------
assignee: larry
components: Windows
messages: 212431
nosy: larry, loewis, ncoghlan
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry pick: 82ec02db7fe6 & ec42ab5e0cb3 Windows installer fixes
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 28 16:12:04 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Feb 2014 15:12:04 +0000
Subject: [New-bugs-announce] [issue20808] 3.4 cherry pick: 6a1711c96fa6
	(Popen.__del__ traceback)
Message-ID: <1393600324.8.0.737405951943.issue20808@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

This commit fixes the traceback we're seeing on Ubuntu with Python 3.4, in Popen.__del__ on interpreter shutdown.

----------
assignee: larry
components: Interpreter Core
messages: 212443
nosy: barry, doko, larry
priority: release blocker
severity: normal
stage: commit review
status: open
title: 3.4 cherry pick: 6a1711c96fa6 (Popen.__del__ traceback)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 28 17:18:36 2014
From: report at bugs.python.org (<--This Guy)
Date: Fri, 28 Feb 2014 16:18:36 +0000
Subject: [New-bugs-announce] [issue20809] isabspath fails if path is None
Message-ID: <1393604316.61.0.807355703845.issue20809@psf.upfronthosting.co.za>


New submission from <--This Guy:

So far I've noticed this is only reproducible when running quickly with python2.7. Still, the error message seems like it would be confusing to new users to Python.

user at host:~/foo/bar/project$ sudo python setup.py install
DEBUG: Adding /foo/bar/project to system path.
ERROR: Python module settings not found
ERROR: Python module settings not found
.... # basically, more DistUtilsExtra errors...
running install
DEBUG: Adding /foo/bar/project to system path.
running build
running build_py
running build_scripts
running build_i18n
DEBUG: Desktop files: ['project.desktop.in']
intltool-update -p -g ryode
running build_icons
running build_help
running install_lib
copying build/lib/__init__.py -> /usr/local/lib/python2.7/site-packages
copying build/lib/ryode/__init__.py -> /usr/local/lib/python2.7/site-packages/ryode
byte-compiling /usr/local/lib/python2.7/site-packages/__init__.py to __init__.pyc
byte-compiling /usr/local/lib/python2.7/site-packages/ryode/__init__.py to __init__.pyc
running install_scripts
copying build/scripts-2.7/project -> /usr/local/bin
changing mode of /usr/local/bin/project to 775
running install_data
copying build/share/applications/project.desktop -> /usr/local/share/applications
running install_egg_info
Removing /usr/local/lib/python2.7/site-packages/project-0.1-py2.7.egg-info
Writing /usr/local/lib/python2.7/site-packages/project-0.1-py2.7.egg-info
Traceback (most recent call last):
  File "setup.py", line 144, in <module>
    cmdclass={'install': InstallAndUpdateDataDirectory}
  File "/usr/local/lib/python2.7/site-packages/python_distutils_extra-2.38-py2.7.egg/DistUtilsExtra/auto.py", line 100, in setup
    distutils.core.setup(**attrs)
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "setup.py", line 116, in run
    target_data = '/' + os.path.relpath(self.install_data, self.root) + '/'
  File "/usr/local/lib/python2.7/posixpath.py", line 437, in relpath
    start_list = [x for x in abspath(start).split(sep) if x]
  File "/usr/local/lib/python2.7/posixpath.py", line 367, in abspath
    if not isabs(path):
  File "/usr/local/lib/python2.7/posixpath.py", line 61, in isabs
    return s.startswith('/')
AttributeError: 'NoneType' object has no attribute 'startswith'

----------
components: Build
messages: 212457
nosy: jordannh
priority: normal
severity: normal
status: open
title: isabspath fails if path is None
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 28 20:06:48 2014
From: report at bugs.python.org (Jonathan Epstein)
Date: Fri, 28 Feb 2014 19:06:48 +0000
Subject: [New-bugs-announce] [issue20810] literal re fails to match
Message-ID: <1393614408.15.0.703626628847.issue20810@psf.upfronthosting.co.za>


New submission from Jonathan Epstein:

All 3 of these regex's should match, but in practice only m2 does.  Found deep in the bowels of debugging a larger problem.


import re

mainProjectsPath = '/groups/larvalolympiad/larvalolympiad/Projects/'

m1 = re.match('larvalolympiad',mainProjectsPath)
m2 = re.match('.*larvalolympiad.*',mainProjectsPath)
m3 = re.match('/larvalolympiad/',mainProjectsPath)

print(m1)
print(m2)
print(m3)

----------
components: Regular Expressions
messages: 212463
nosy: Jonathan.Epstein, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: literal re fails to match
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Feb 28 22:53:49 2014
From: report at bugs.python.org (aubmoon)
Date: Fri, 28 Feb 2014 21:53:49 +0000
Subject: [New-bugs-announce] [issue20811] str.format for fixed width float
	can return a string	longer than the maximum specified
Message-ID: <1393624429.46.0.306499394467.issue20811@psf.upfronthosting.co.za>


New submission from aubmoon:

"{:+10.8}".format(0.12345678)

returns

'+0.12345678' (11 chars)

should return

'+.12345678' (10 chars)

----------
messages: 212478
nosy: aubmoon
priority: normal
severity: normal
status: open
title: str.format for fixed width float can return a string longer than the maximum specified
type: behavior
versions: Python 3.3

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