From report at bugs.python.org  Sat Aug  1 00:01:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jul 2015 22:01:33 +0000
Subject: [issue19007] precise time.time() under Windows 8: use
 GetSystemTimePreciseAsFileTime
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1438380093.32.0.110813200189.issue19007@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Good news! I got a new fresh Windows 8.1 VM with Visual Studio 2015. I'm now able to work on this issue.

I wrote a patch: time_precise.patch.

Resolution computed in Python by https://hg.python.org/peps/file/tip/pep-0418/clock_resolution.py:

GetSystemTimePreciseAsFileTime(): 715 ns
GetSystemTimeAsFileTime(): 14 ms

Obviously, the resolution is better...

GetSystemTimePreciseAsFileTime() uses internally the QueryPerformanceCounter() so I chose to use QueryPerformanceFrequency() to fill time.get_clock_info('time').resolution, same code than time.get_clock_info('perf_counter').resolution

----------
keywords: +patch
Added file: http://bugs.python.org/file40088/time_precise.patch

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

From report at bugs.python.org  Sat Aug  1 00:05:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jul 2015 22:05:18 +0000
Subject: [issue19007] precise time.time() under Windows 8: use
 GetSystemTimePreciseAsFileTime
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1438380318.57.0.351218329459.issue19007@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: GetSystemTimePreciseAsFileTime() is restricted to desktop applications.

The windowstimestamp.com has a warning on this function:

http://www.windowstimestamp.com/description

"""
2.1.4.2.  Desktop Applications: GetSystemTimePreciseAsFileTime()

(...)
The function shall also be used with care when a system time adjustment is active. Current Windows versions treat the performance counter frequency as a constant. The high resolution of GetSystemTimePreciseAsFileTime() is derived from the performance counter value at the time of the call and the performance counter frequency. However, the performance counter frequency should be corrected during system time adjustments to adapt to the modified progress in time. Current Windows versions don't do this. The obtained microsecond part may be severely affected when system time adjustments are active. Seconds may consist of more or less than 1.000.000 microseconds. Microsoft may or not fix this in one of the next updates/versions.
(...)
As of May, 2015 the inaccuracy of GetSystemTimePreciseAsFileTime() during system time adjustments persists for the preview versions of Windows 10.
"""

Is it ok to switch to GetSystemTimePreciseAsFileTime() for Python time.time()?

----------

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

From report at bugs.python.org  Sat Aug  1 00:24:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2015 22:24:15 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1438381455.08.0.204186557673.issue24726@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Aug  1 00:28:24 2015
From: report at bugs.python.org (Eric Snow)
Date: Fri, 31 Jul 2015 22:28:24 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438381704.45.0.727023299873.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've verified that it is definitely the linked list that is getting updated incorrectly at the point that a key is popped off.  The underlying dict is working fine.  The erroneous behavior is happening with either pop, popitem, or __delitem__.  However, it is likely in the common code used to remove a node from the linked list (e.g. _odict_clear_node).

----------

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

From report at bugs.python.org  Sat Aug  1 00:29:22 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2015 22:29:22 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1438381762.87.0.514961479754.issue24726@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Attached revised file that runs to completion on 2.7 and 3.x.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40089/tem2.py

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

From report at bugs.python.org  Sat Aug  1 00:32:04 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2015 22:32:04 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1438381924.87.0.288840401645.issue24726@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Marco, #-prefixed issue numbers like this, #24721, #24667, and #24685, are easier to read.

----------

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

From report at bugs.python.org  Sat Aug  1 00:43:22 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2015 22:43:22 +0000
Subject: [issue24740] make patchcheck doesn't detect changes if commit is done
 first
In-Reply-To: <1438056026.2.0.092826443421.issue24740@psf.upfronthosting.co.za>
Message-ID: <1438382602.41.0.144041431795.issue24740@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Better: a local commit hook that rejects commits that cannot be pushed.  I think this has been discussed, but never done, unless something has been added to the devguide that I missed.

Better still: the hoped-for new workflow where patches are submitted to an automaton that checks, tests, commits, and merges for us.  I believe that this is part of both proposals that Brett Cannon will review.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Aug  1 00:51:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jul 2015 22:51:59 +0000
Subject: [issue24756] doctest run_docstring_examples does have an obvious
 utility
In-Reply-To: <1438262830.97.0.532585638369.issue24756@psf.upfronthosting.co.za>
Message-ID: <1438383119.76.0.693180731403.issue24756@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ditto

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Aug  1 00:55:02 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 31 Jul 2015 22:55:02 +0000
Subject: [issue24768] Bytearray double free or corruption
In-Reply-To: <1438378136.69.0.00968657424449.issue24768@psf.upfronthosting.co.za>
Message-ID: <1438383302.93.0.80992193188.issue24768@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +benjamin.peterson, yselivanov

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

From report at bugs.python.org  Sat Aug  1 01:11:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 31 Jul 2015 23:11:22 +0000
Subject: [issue24724] Element.findall documentation misleading
In-Reply-To: <1437881713.88.0.256447477825.issue24724@psf.upfronthosting.co.za>
Message-ID: <1438384282.48.0.948773180582.issue24724@psf.upfronthosting.co.za>


Martin Panter added the comment:

Eric: Calling findall("country") does _not_ return grandchidren nor further descendants. Also, your pseudocode calling findall() with no arguments does not work, so I am left wondering where you got the wrong impression about grandchildren. The usual way to get a list of direct children is to call list(parent):

>>> root = XML('''<data><country name="Leichtenstein">
...         <country name="Singapore"><country name="Panama"/></country>
...     </country></data>''')
>>> root.findall()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Required argument 'path' (pos 1) not found
>>> list(root)  # List of direct children
[<Element 'country' at 0xb6ebe324>]
>>> root.findall("country")  # List of direct <country> children
[<Element 'country' at 0xb6ebe324>]
>>> root.findall(".//country")  # List of all <country> descendants
[<Element 'country' at 0xb6ebe324>, <Element 'country' at 0xb6ebe284>, <Element 'country' at 0xb6ebe0cc>]

----------

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

From report at bugs.python.org  Sat Aug  1 01:15:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2015 23:15:07 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1438384507.11.0.449674852892.issue24726@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sat Aug  1 01:16:24 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 31 Jul 2015 23:16:24 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438384584.03.0.258494501551.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Sorry to keep you waiting. This sample code runs fine with the attached patch: https://gist.github.com/agronholm/43c71be0028bb866753a

In short, I implemented support for concurrent.futures in the asyncio Task class instead of making concurrent.futures aware of asyncio. The __await__ implementation in concurrent.futures closely mirrors that of asyncio's Future.

----------
Added file: http://bugs.python.org/file40090/asyncio_await.patch

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

From report at bugs.python.org  Sat Aug  1 01:22:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 31 Jul 2015 23:22:01 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1438384921.12.0.287744176049.issue24745@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I've attached defaultfont.patch which will look for the magic value 'TkFixedFont' in the configuration file and do some appropriate magic with it.  Most of the font handling smarts are now in a 'GetFont' call in configHandler, which as a bonus reduces some of the complexity and duplication elsewhere.

----------
keywords: +patch
Added file: http://bugs.python.org/file40091/defaultfont.patch

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

From report at bugs.python.org  Sat Aug  1 01:26:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 31 Jul 2015 23:26:10 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438385170.47.0.515175912412.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> In short, I implemented support for concurrent.futures in the asyncio Task class instead of making concurrent.futures aware of asyncio. The __await__ implementation in concurrent.futures closely mirrors that of asyncio's Future.

I like your approach and the proposed patch. I think we should commit this in 3.6 (the final patch should include docs & tests).

----------

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

From report at bugs.python.org  Sat Aug  1 01:34:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 31 Jul 2015 23:34:33 +0000
Subject: [issue24768] Bytearray double free or corruption
In-Reply-To: <1438378136.69.0.00968657424449.issue24768@psf.upfronthosting.co.za>
Message-ID: <1438385673.66.0.0757240215008.issue24768@psf.upfronthosting.co.za>


Martin Panter added the comment:

Reproduceable on 32 bit x86 Arch Linux.

FTR this is not Issue 23985, since that was fixed in 3.4.3. I have not investigated, but maybe it shares the same cause (Issue 19087). Also, it may be helpful to build with ?./configure --with-pydebug? to pinpoint the problem.

----------
nosy: +pitrou, vadmium

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

From report at bugs.python.org  Sat Aug  1 01:50:44 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Jul 2015 23:50:44 +0000
Subject: [issue24768] Bytearray double free or corruption
In-Reply-To: <1438378136.69.0.00968657424449.issue24768@psf.upfronthosting.co.za>
Message-ID: <1438386644.96.0.887580228078.issue24768@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This was actually fixed in 98c1201d8eea, which didn't make it into 3.4.3.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sat Aug  1 01:50:49 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Jul 2015 23:50:49 +0000
Subject: [issue24768] Bytearray double free or corruption
In-Reply-To: <1438378136.69.0.00968657424449.issue24768@psf.upfronthosting.co.za>
Message-ID: <1438386649.82.0.436031071145.issue24768@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Sat Aug  1 01:51:59 2015
From: report at bugs.python.org (jan parowka)
Date: Fri, 31 Jul 2015 23:51:59 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1438386719.73.0.896658265746.issue24765@psf.upfronthosting.co.za>


jan parowka added the comment:

Mac Developer Library mentions Library/Application Support/<App> as a preferred directory to store configuration files for an application, gotten via a call to NSSearchPathForDirectoriesInDomains or NSFileManager with NSApplicationSupportDirectory path key and either NSLocalDomainMask domain (for all users) or NSUserDomainMask domain (for current user).

https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html

----------

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

From report at bugs.python.org  Sat Aug  1 01:52:43 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jul 2015 23:52:43 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1438386763.61.0.0168813953098.issue24726@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

There is a bug in _PyObject_GenericSetAttrWithDict() Objects/object.c   where a calls are made to PyDict_SetItem() and PyDict_DelItem() without checking first checking for PyDict_CheckExact(). 

* In PEP 372, OrderedDict was consciously specified to be a subclass of regular dicts in order to improve substitutability for dicts in most existing code.  That decision had some negative consequences as well.  It is unavoidable the someone can call the parent class directly and undermine the invariants of the subclass (that is a fact of life for all subclasses that maintain their own state while trying to stay in-sync with state in the parent class -- see http://bugs.python.org/msg247358 for an example).

With pure python code for the subclass, we say, "don't do that". I'll add a note to that effect in the docs for the OD (that said, it is a general rule that applies to all subclasses that have to stay synchronized to state in the parent).

In C version of the OD subclass, we still can't avoid being bypassed (see http://bugs.python.org/issue10977) and having our subclass invariants violated.  Though the C code can't prevent the invariants from being scrambled it does have an obligation to not segfault and to not leak something like "OrderedDict([<NULL>])".  Ideally, if is possible to detect an invalid state (i.e. the linked link being out of sync with the inherited dict), then a RuntimeError or somesuch should be raised.

----------

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

From report at bugs.python.org  Sat Aug  1 02:13:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2015 00:13:24 +0000
Subject: [issue24768] Bytearray double free or corruption
In-Reply-To: <1438378136.69.0.00968657424449.issue24768@psf.upfronthosting.co.za>
Message-ID: <1438388004.17.0.863085338612.issue24768@psf.upfronthosting.co.za>


Martin Panter added the comment:

Ah yes, I was confused. The bug fix isn?t actually in 3.4.3.

----------

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

From report at bugs.python.org  Sat Aug  1 02:28:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2015 00:28:19 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1438388899.16.0.602051227042.issue24765@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 7175, although I think that is more about low-level Python configuration, rather than application-level configuration like Idle.

----------
nosy: +vadmium

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

From report at bugs.python.org  Sat Aug  1 04:36:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Aug 2015 02:36:14 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <20150801023610.110941.57912@psf.io>


Roundup Robot added the comment:

New changeset 20a8e5dccf66 by Terry Jan Reedy in branch '2.7':
Issue #21192: Idle Editor. When a file is run, put its name in the restart bar.
https://hg.python.org/cpython/rev/20a8e5dccf66

New changeset 2ae12789dcb8 by Terry Jan Reedy in branch '3.4':
Issue #21192: Idle Editor. When a file is run, put its name in the restart bar.
https://hg.python.org/cpython/rev/2ae12789dcb8

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  1 04:39:14 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Aug 2015 02:39:14 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <1438396754.23.0.377999154298.issue21192@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is how restarts look now.  Thanks for the initial idea and patch.

>>>
====================== RUN C:\Programs\Python34\tem.py =================
xxxx
>>> 
=============================== RESTART Shell =========================
>>>

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Aug  1 05:17:42 2015
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sat, 01 Aug 2015 03:17:42 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
Message-ID: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

When attempting to build Python without dynamic loading (HAVE_DYNAMIC_LOADING is not defined), the module "_imp" will not have the function "exec_dynamic."  However, Lib/bootstrap.py seems to assume that "_imp.exec_dynamic" exists, causing the error:

----
./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
	echo "generate-posix-vars failed" ; \
	rm -f ./pybuilddir.txt ; \
	exit 1 ; \
fi
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1134, in _install
  File "<frozen importlib._bootstrap>", line 1114, in _setup
  File "<frozen importlib._bootstrap>", line 1082, in _builtin_from_name
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 748, in exec_module
AttributeError: module '_imp' has no attribute 'exec_dynamic'
Fatal Python error: Py_Initialize: importlib install failed

Current thread 0x00000000 (most recent call first):
ABNORMAL TERMINATION
generate-posix-vars failed
----

when trying to build.  This error means that Python 3.5 will not be able to build in a purely static (no dynamic loading whatsoever) form.

This error was encountered in Python 3.5b4.

----------
components: Build
messages: 247797
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Interpreter doesn't start when dynamic loading is disabled
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug  1 06:43:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Sat, 01 Aug 2015 04:43:30 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1438404210.24.0.348045392531.issue22625@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Sat Aug  1 08:08:55 2015
From: report at bugs.python.org (Alex Budovski)
Date: Sat, 01 Aug 2015 06:08:55 +0000
Subject: [issue24770] Py_Finalize not cleaning up all threads
Message-ID: <1438409335.5.0.147877338692.issue24770@psf.upfronthosting.co.za>


New submission from Alex Budovski:

This is a known issue, from the comment, but it is causing AVs for my embedded application when background threads are created, for example, by the _socket builtin module.

/* Undo the effect of Py_Initialize().

   Beware: if multiple interpreter and/or thread states exist, these
   are not wiped out; only the current thread and interpreter state
   are deleted.  But since everything else is deleted, those other
   interpreter and thread states should no longer be used.

   (XXX We should do better, e.g. wipe out all interpreters and
   threads.)

   Locking: as above.

*/

void
Py_Finalize(void)

----------
components: Extension Modules, Interpreter Core
messages: 247798
nosy: Alex Budovski
priority: normal
severity: normal
status: open
title: Py_Finalize not cleaning up all threads
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug  1 08:09:28 2015
From: report at bugs.python.org (Alex Budovski)
Date: Sat, 01 Aug 2015 06:09:28 +0000
Subject: [issue24770] Py_Finalize not cleaning up all threads
In-Reply-To: <1438409335.5.0.147877338692.issue24770@psf.upfronthosting.co.za>
Message-ID: <1438409368.02.0.28497762426.issue24770@psf.upfronthosting.co.za>


Changes by Alex Budovski <abudovski at gmail.com>:


----------
type:  -> crash

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

From report at bugs.python.org  Sat Aug  1 09:37:06 2015
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 01 Aug 2015 07:37:06 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438359228.96.0.678932648745.issue24764@psf.upfronthosting.co.za>
Message-ID: <CA+gUBLSqc+JkOgH+YtFMMF_ZsyQTd+E5mtHSLTu74v3DN2dpig@mail.gmail.com>


Pierre Quentel added the comment:

Yes, I will be able to review the patch next week

2015-07-31 18:13 GMT+02:00 STINNER Victor <report at bugs.python.org>:

>
> STINNER Victor added the comment:
>
> @Pierre Quentel: Hi! Are you still working on CGI? Can you please review
> this patch? Thanks.
>
> --
>
> Previous large change in the cgi module: issue #4953. Pierre helped a lot
> on this one.
>
> ----------
> nosy: +quentel
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24764>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Aug  1 10:14:56 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 01 Aug 2015 08:14:56 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438416896.36.0.951176442512.issue24129@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

I am sorry but I still don't get how things are organized here, so pinging this up. What is the next step? Should I wait for another review?

----------

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

From report at bugs.python.org  Sat Aug  1 10:18:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2015 08:18:52 +0000
Subject: [issue24692] types.coroutines() idempotence documentation
In-Reply-To: <1437650502.32.0.0288592289227.issue24692@psf.upfronthosting.co.za>
Message-ID: <1438417132.9.0.0165772024062.issue24692@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think you are right that it would be typically used as a decorator. Patch v2 changes it to be defined as a decorator.

Not sure what the second part of your comment is referring to. The existing text about lack of __await__() maybe? You still have to have something (such as ?asyncio?) drive the top-level coroutine. So that is a third thing users have to do with them. Passing a coroutine to ?await? does not magically make it go, it just becomes a subordinate of the outer coroutine.

----------
Added file: http://bugs.python.org/file40092/coro-idempotent.v2.patch

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

From report at bugs.python.org  Sat Aug  1 11:01:22 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sat, 01 Aug 2015 09:01:22 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
Message-ID: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>


New submission from Adam Barto?:

I found out that I cannot import tkinter in Python 3.5.0b4 on 64-bit Windows Vista. Trying to import _tkinter results in ImportError: DLL load failed. On the other hand I have no problem importing _ctypes whose .pyd file is at the same location as _tkinter.pyd.

----------
components: Tkinter, Windows
messages: 247802
nosy: Drekin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot import _tkinter in Python 3.5 on Windows
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug  1 11:48:31 2015
From: report at bugs.python.org (karl)
Date: Sat, 01 Aug 2015 09:48:31 +0000
Subject: [issue24772] Smaller viewport shifts the "expand left menu" character
 into the text
Message-ID: <1438422511.74.0.548589592521.issue24772@psf.upfronthosting.co.za>


New submission from karl:

Adding the following to basic.css:

```css
dl {
    margin-bottom: 15px;
    word-wrap: break-word;
}
```

will solve the issue.

See https://github.com/webcompat/web-bugs/issues/1479

----------
assignee: docs at python
components: Documentation
messages: 247803
nosy: docs at python, karlcow
priority: normal
severity: normal
status: open
title: Smaller viewport shifts the "expand left menu" character into the text

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

From report at bugs.python.org  Sat Aug  1 12:10:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Aug 2015 10:10:24 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438384584.03.0.258494501551.issue24383@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZgoTG+5vkY4Tn2ym+TX+4k0KZMLjwXNRKAQ1EZg-Sbaw@mail.gmail.com>


STINNER Victor added the comment:

I'm not sure that it's a good idea to start adding special cases in Task
class which is already very complex.

Instead we may add a way to register custom awaitable objects?

----------

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

From report at bugs.python.org  Sat Aug  1 12:14:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2015 10:14:33 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1438424073.54.0.135201762485.issue7291@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, a while ago I think I made a patch implementing my HTTPConnection.detach() proposal. I can probably dig it up if anyone is interested.

However I gave up on fixing this bug in ?urllib.request?. As far as I understand it, the framework does not distinguish the 407 Proxy Authentication Required error of the initial proxy CONNECT request from any potential 407 response from a tunnelled connection. Perhaps a special case could be made; I think there are already lots of special cases. But the maze of urlopen() handlers is already too complicated and I decided this was too hard to bother working on. Sorry :)

----------
stage:  -> needs patch

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

From report at bugs.python.org  Sat Aug  1 12:15:25 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 01 Aug 2015 10:15:25 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438424125.19.0.879160158112.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

I think concurrent.futures.Future warrants adding support for in Task. It predates asyncio and is generic enough. Can you elaborate on what other types you would want to support as awaitables in Task?

----------

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

From report at bugs.python.org  Sat Aug  1 12:46:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 10:46:41 +0000
Subject: [issue24772] Smaller viewport shifts the "expand left menu" character
 into the text
In-Reply-To: <1438422511.74.0.548589592521.issue24772@psf.upfronthosting.co.za>
Message-ID: <1438426001.21.0.219158889287.issue24772@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Aug  1 12:50:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 10:50:22 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438426222.5.0.923393622081.issue24771@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +larry
priority: normal -> release blocker

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

From report at bugs.python.org  Sat Aug  1 14:24:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Aug 2015 12:24:29 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438424125.19.0.879160158112.issue24383@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ9bJr2=XZ3kdmqPdChyA2n-+a6wQfZi3=DB7UMRPwSsQ@mail.gmail.com>


STINNER Victor added the comment:

There are other implementations of asyncio than the one in CPython.
Pulsar and Tornado define their own Task class. The greenio project
also has a special task object. aioeventlet and aiogevent may also
benefit from a way to register new "awaitable" things.

I'm not opposed to support concurrent.futures.Future object. I don't
like the idea of starting to add a special case for one module. Others
may want to do the same for their library.

----------

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

From report at bugs.python.org  Sat Aug  1 14:46:06 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Aug 2015 12:46:06 +0000
Subject: [issue19007] precise time.time() under Windows 8: use
 GetSystemTimePreciseAsFileTime
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1438433166.22.0.0223701516218.issue19007@psf.upfronthosting.co.za>


Steve Dower added the comment:

What are the expected benefits from changing? Just a higher resolution? I'm not sure that's worth anything if it's inaccurate.

----------

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

From report at bugs.python.org  Sat Aug  1 15:14:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 01 Aug 2015 13:14:14 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
 for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1438434854.74.0.799158238306.issue6164@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The original was never reapplied and wouldn't now apply so I've attached an updated version.

----------
components:  -Distutils2
nosy: +BreamoreBoy, David.Edelsohn, dstufft
versions: +Python 3.4, Python 3.5, Python 3.6 -3rd party, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file40093/issue6164_v2.diff

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

From report at bugs.python.org  Sat Aug  1 16:13:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 14:13:35 +0000
Subject: [issue24766] Subclass of property doesn't preserve instance __doc__
 when using doc= argument
In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za>
Message-ID: <1438438415.35.0.137186801472.issue24766@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat Aug  1 16:23:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 14:23:08 +0000
Subject: [issue24759] Idle: require 8.5 / ttk
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438438988.91.0.615853265802.issue24759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

IMHO Tcl and Tk should be in title case (as Python or Django) or at least all in upper case (as APL or SDL).

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Aug  1 16:26:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 14:26:31 +0000
Subject: [issue24759] Idle: require 8.5 / ttk
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438439191.06.0.864479963411.issue24759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't see any mentions of ttk in IDLE source code except added check. Is ttk really required for IDLE?

----------

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

From report at bugs.python.org  Sat Aug  1 16:33:33 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 01 Aug 2015 14:33:33 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438439613.35.0.71649492895.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> There are other implementations of asyncio than the one in CPython.
> Pulsar and Tornado define their own Task class. The greenio project

I'm not sure if it's possible (or even makes any sense) to integrate 
tasks from other frameworks into asyncio.

greenio simply inherits its task class from asyncio.Task, and will
automatically support concurrent.futures if we support them in
asyncio.

> I'm not opposed to support concurrent.futures.Future object. I don't
> like the idea of starting to add a special case for one module. Others
> may want to do the same for their library.

concurrent.futures is in a unique position -- it's already supported and
integrated in asyncio.  We have executors and they are even used for
DNS lookups.  Supporting concurrent.futures in asyncio.Task seems 
natural to me.

I like Alex's approach -- his idea of '__await__' for concurrent.Future
is very generic, so any other framework can integrate it.  Creating
any kind of registry in asyncio.Task seems a bit unnecessary to me at 
this stage.

----------

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

From report at bugs.python.org  Sat Aug  1 17:00:26 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Aug 2015 15:00:26 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438384584.03.0.258494501551.issue24383@psf.upfronthosting.co.za>
Message-ID: <55BCDF07.3040608@behnel.de>


Stefan Behnel added the comment:

Funny. I just thought about this yesterday and came up with pretty much the
same idea. +1 for the patch.

I don't think there are more classes to support here. Quite the contrary,
other tools should try to integrate via concurrent.futures.Future instead.

----------

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

From report at bugs.python.org  Sat Aug  1 17:16:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 15:16:02 +0000
Subject: [issue24762] Branchless, vectorizable frozen set hash
In-Reply-To: <1438319616.07.0.333748315225.issue24762@psf.upfronthosting.co.za>
Message-ID: <1438442162.63.0.503528677318.issue24762@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The idea looks interesting and the code looks correct. But the patch decreases readability and I'm not sure, that the benefit is worth it. Timings looks good at first glance, but frozenset hash is cached and is calculated only once per instance. I afraid that the benefit of hash calculation optimization is dwarfed by the time of frozenset creation itself.

If other core developer supports this idea I have no strong objections. See my comments on Rietveld.

----------
assignee: serhiy.storchaka -> 

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

From report at bugs.python.org  Sat Aug  1 17:40:05 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2015 15:40:05 +0000
Subject: [issue24762] Branchless, vectorizable frozen set hash
In-Reply-To: <1438319616.07.0.333748315225.issue24762@psf.upfronthosting.co.za>
Message-ID: <1438443605.66.0.994602078543.issue24762@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sat Aug  1 18:53:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Aug 2015 16:53:10 +0000
Subject: [issue24762] Branchless, vectorizable frozen set hash
In-Reply-To: <1438319616.07.0.333748315225.issue24762@psf.upfronthosting.co.za>
Message-ID: <20150801165307.29410.31532@psf.io>


Roundup Robot added the comment:

New changeset cf707dd190a9 by Raymond Hettinger in branch 'default':
Issue #24762:  Speed-up frozenset_hash() and greatly beef-up the comments.
https://hg.python.org/cpython/rev/cf707dd190a9

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  1 18:53:52 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2015 16:53:52 +0000
Subject: [issue24762] Branchless, vectorizable frozen set hash
In-Reply-To: <1438319616.07.0.333748315225.issue24762@psf.upfronthosting.co.za>
Message-ID: <1438448032.75.0.371586715261.issue24762@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  1 20:17:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Aug 2015 18:17:59 +0000
Subject: [issue24759] Idle: require 8.5 / ttk
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438453079.87.0.978275501535.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Re-opened for tweak.

This patch, to exit gracefully if ttk is not available, is the first step before using ttk in Idle.  Mark, a long-time tk/ttk expert and site/book author, has volunteered to help upgrade Idle with ttk. Please see "ttk in idle" on Idle-Sig list for general discussion and #24750 for the first substantive patches. The only reason I have not applied the ttk.Scrollbar patch, on that issue, is because Ned mentioned, on that issue, that the OS 8.5 python requires tcl/tk 8.4.  I strongly feel that this should not stop the use of ttk, but I an first doing a few non-ttk patches, including Mark's patch for #24745, before continuing.

----------
status: closed -> open

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

From report at bugs.python.org  Sat Aug  1 21:04:38 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 01 Aug 2015 19:04:38 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438455878.44.0.262366784161.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

I agree with Stefan and Yury. As for the tests, Yury seemed to have those in his patches -- I'll take a look and see if they're directly applicable.

For Python 3.5 and earlier, there is a workaround to awaiting for concurrent Futures, but it requires the use of the undocumented wrap_future() function. It is the fact that it's undocumented that bothers me.

----------

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

From report at bugs.python.org  Sat Aug  1 21:10:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 19:10:02 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438456202.6.0.500652265075.issue24750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would use optional import to support Tcl/Tk older than 8.5 in Python 3.4 and 2.7.

try:
    from tkinter.ttk import Scrollbar
except ImportError:
    pass

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Aug  1 21:17:28 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 Aug 2015 19:17:28 +0000
Subject: [issue24773] Add local time disambiguation flag to datetime
Message-ID: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Adds a boolean member to the instances of ``datetime.time``
and ``datetime.datetime`` classes that can be used to differentiate
between two moments in time for which local times are the same.

See Datetime-SIG "Local time disambiguation proposal" discussion [1] for more details.

[1]: https://mail.python.org/pipermail/datetime-sig/2015-July/000105.html

----------
assignee: belopolsky
components: Extension Modules, Library (Lib)
files: ltdf.patch
keywords: patch
messages: 247819
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Add local time disambiguation flag to datetime
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40094/ltdf.patch

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

From report at bugs.python.org  Sat Aug  1 21:18:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 01 Aug 2015 19:18:10 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438456690.2.0.799893541583.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I agree with Stefan and Yury. As for the tests, Yury seemed to have those in his patches -- I'll take a look and see if they're directly applicable.

Good idea, the tests are in a fine shape.

> For Python 3.5 and earlier, there is a workaround to awaiting for concurrent Futures, but it requires the use of the undocumented wrap_future() function. It is the fact that it's undocumented that bothers me.

I didn't even know about it :(  Please create an issue.

----------

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

From report at bugs.python.org  Sat Aug  1 21:19:49 2015
From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=)
Date: Sat, 01 Aug 2015 19:19:49 +0000
Subject: [issue24774] inconsistency in http.server.test
Message-ID: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>


New submission from ???:

In http.server.test, it still say "This runs an HTTP server on port 8000 (or the first command line argument).", but it won't read command line argument any more.

since this commit (https://hg.python.org/cpython/rev/935a656359ae)

----------
components: Library (Lib)
files: fix_description.patch
keywords: patch
messages: 247821
nosy: wdv4758h
priority: normal
severity: normal
status: open
title: inconsistency in http.server.test
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40095/fix_description.patch

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

From report at bugs.python.org  Sat Aug  1 21:34:20 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 01 Aug 2015 19:34:20 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438457660.93.0.222653229319.issue24771@psf.upfronthosting.co.za>


eryksun added the comment:

64-bit 3.5.0b4 works for me in Windows 7. Try loading _tkinter.pyd in [Dependency Walker][1]. Or try loading the dependent DLLs directly via ctypes:

    import os
    import _ctypes

    dlls_path = os.path.dirname(_ctypes.__file__)
    for d in ('tcl86t.dll', 'tk86t.dll'):
        path = os.path.join(dlls_path, d)
        try:
            _ctypes.LoadLibrary(path)
        except OSError:
            print('failed:', path)

[1]: http://dependencywalker.com

----------
nosy: +eryksun

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

From report at bugs.python.org  Sat Aug  1 21:35:32 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 01 Aug 2015 19:35:32 +0000
Subject: [issue24773] Add local time disambiguation flag to datetime
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1438457732.31.0.110670959928.issue24773@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Sat Aug  1 21:59:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Aug 2015 19:59:23 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438459163.24.0.4726157084.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

That does not work.  ttk widgets are not drop-in replacements for their predecessors.  The problem is illustrated by these lines from the TextViewer patch

-        self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
-                                       takefocus=FALSE, highlightthickness=0)
+        self.scrollbarView = ttk.Scrollbar(frameText, orient=VERTICAL,
+                                       takefocus=FALSE)

The highlightthickness option, among several others, is not legal for the ttk versions of widgets.  That is why I removed it. This particular instance could be solved by living without the highlightthickness option, but their will be many other instances where we do not want to drop the configuration. The API differences are probably even worse for Treeview and Notebook versus Idle's custom implementations of the same widget.

----------

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

From report at bugs.python.org  Sat Aug  1 22:24:06 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sat, 01 Aug 2015 20:24:06 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438460646.66.0.23761773838.issue24771@psf.upfronthosting.co.za>


Adam Barto? added the comment:

It seems that both tcl86t.dll and tk86t.dll can be found, but their dependency VCRUNTIME140.dll cannot. For some reason, Dependency Walker cannot locate also python35.dll and ieshims.dll (but it tries to find all three libraries in Python 3.5\DLLs and at least python35.dll is located directly in Python 3.5 directory).

----------

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

From report at bugs.python.org  Sat Aug  1 22:32:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Aug 2015 20:32:57 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <20150801203254.1387.6879@psf.io>


Roundup Robot added the comment:

New changeset edf9bfe36ad0 by Terry Jan Reedy in branch '2.7':
Issue #21192: acks for 2.7
https://hg.python.org/cpython/rev/edf9bfe36ad0

----------

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

From report at bugs.python.org  Sat Aug  1 22:47:40 2015
From: report at bugs.python.org (=?utf-8?q?Se=C3=A1n_Kelleher?=)
Date: Sat, 01 Aug 2015 20:47:40 +0000
Subject: [issue24775] Python client failing to connect to server but
 completing as if successful
Message-ID: <1438462060.51.0.501017266126.issue24775@psf.upfronthosting.co.za>


New submission from Se?n Kelleher:

I have a Go server that listens to a port, runs a Python client to connect to the port as a subcommand, and reads from the client. However, the client (as follows) will occasionally run to completion without connecting to the port, but without raising an exception:

    import socket
    import sys

    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    [addr, port] = sys.argv[1].split(':')
    sock.connect((addr, int(port)))
    try:
        sock.send("hello")
    finally:
        sock.close()

    print "done."

`server.go` follows:

	package main

	import (
		"log"
		"net"
		"os"
		"os/exec"
	)

	func main() {
		ln, err := net.ListenTCP("tcp4", &net.TCPAddr{IP: net.IPv4(127, 0, 0, 1)})
		if err != nil {
			log.Fatalf("%v", err)
		}
		defer ln.Close()

		cmd := exec.Command(
			"python",
			"client.py",
			ln.Addr().(*net.TCPAddr).String(),
		)
		cmd.Stdout = os.Stdout
		cmd.Stderr = os.Stderr

		if err := cmd.Start(); err != nil {
			log.Fatalf("%v", err)
		}
		defer cmd.Process.Kill()

		go func() {
			log.Printf("command exited with: %v", cmd.Wait())
			log.Printf("closing listener: %v", ln.Close())
		}()

		conn, err := ln.Accept()
		if err != nil {
			log.Fatalf("%v", err)
		}

		buf := make([]byte, 1024)
		n, err := conn.Read(buf)
		log.Println(string(buf[:n]))
	}

When the connection is successful, the output is as expected:

    done.
    2015/08/01 21:03:50 hello

A failed connection, by contrast, gives no indication from Python that the command failed (`done.` is output), but it is evident that the connection was not established:

    done.
    2015/08/01 20:56:55 command exited with: <nil>
    2015/08/01 20:56:55 closing listener: <nil>
    2015/08/01 20:56:55 accept tcp4 127.0.0.1:42550: use of closed network connection
    exit status 1

>From this, it appears as though the Python client thinks it has established a connection, because neither the `connect` nor the `send` call raise an exception.

This behaviour is corrected in Python 3 (all runs look like the first instance), so it appears to be local to Python 2.7.

----------
components: Library (Lib)
messages: 247826
nosy: Se?n Kelleher
priority: normal
severity: normal
status: open
title: Python client failing to connect to server but completing as if successful
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug  1 23:03:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2015 21:03:18 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438462998.81.0.870144655959.issue24750@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The last version of the patch works well for me and has a nice, elegant look.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Aug  1 23:04:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Aug 2015 21:04:44 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438463084.04.0.702169826283.issue24750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, but setting the highlightthickness option can be optional too.

    self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
                                   takefocus=FALSE)
    try:
        self.scrollbarView['highlightthickness'] = 0
    except TclError:
        pass

or

    self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
                                   takefocus=FALSE)
    if not ttk:
        self.scrollbarView['highlightthickness'] = 0

Otherwise I think it is not worth to apply these changes to maintained releases. 3.4 will switched to security fixes only mode soon, but 2.7 has long support term. Bugfix release should continue to work on platforms that are shipped with Tcl/Tk 8.4.

----------

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

From report at bugs.python.org  Sat Aug  1 23:12:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2015 21:12:47 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
Message-ID: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

A recurring issue with students using IDLE is the user interface for the fonts and tabs preference settings.

* The default setting of 4 space tabs is a good default, but the giant slider cries out to be moved (usually when people are intending to increase their font size).  A slider was not a good choice.  It should use something like what is currently used for font size.

* On the other hand, the font size would benefit from have a slider.

* I don't know if anything can be done to improve the selection of the font face.  The scrolling menu of choices worked great back when we only had a handful of choices but it had grown problematic with a large number of choices.  It is a bit of a struggle to select Menlo on a Mac if you already know what you want.

----------
assignee: terry.reedy
components: IDLE
messages: 247829
nosy: rhettinger, terry.reedy
priority: low
severity: normal
stage: needs patch
status: open
title: Improve Fonts/Tabs UX for IDLE
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug  1 23:25:45 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 01 Aug 2015 21:25:45 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438464345.8.0.824644523323.issue24771@psf.upfronthosting.co.za>


eryksun added the comment:

Not finding python35.dll is normal since there's no activation context from python.exe. The vcruntime140 library is statically linked to avoid having to distribute vcruntime140.dll. See issue 24476. This needs to be changed in the TCL/Tk project files as well.

----------

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

From report at bugs.python.org  Sat Aug  1 23:42:00 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 Aug 2015 21:42:00 +0000
Subject: [issue24773] Add local time disambiguation flag to datetime
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1438465320.5.0.314861013556.issue24773@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Something went wrong in my hg clone and Rietveld did not like my patch.  I moved my development branch to github:

https://github.com/abalkin/cpython/tree/ltdf

Please feel free to leave your comments there.

----------

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

From report at bugs.python.org  Sat Aug  1 23:49:11 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 Aug 2015 21:49:11 +0000
Subject: [issue24773] Add local time disambiguation flag to datetime
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1438465751.88.0.753814817159.issue24773@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


Added file: http://bugs.python.org/file40096/ltdf-2.patch

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

From report at bugs.python.org  Sat Aug  1 23:58:06 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sat, 01 Aug 2015 21:58:06 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438466286.01.0.485400689463.issue24750@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Serhiy, I appreciate what you're saying, but special casing to handle both ttk and non-ttk cases seems not feasible given the amount of resources available to enhance/maintain IDLE. Additionally, part of the rationale for making these changes is to simplify the code by leveraging things in ttk that aren't in 'classic' Tkinter.

Would you suggest:
(a) keep two versions of the IDLE code in the distro (one a snapshot)
(b) require 8.5 Tcl/Tk be installed on a system before IDLE can be used
(c) leave IDLE with its current (embarrassing) UI
(d) drop IDLE from Python altogether

----------

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

From report at bugs.python.org  Sun Aug  2 00:08:44 2015
From: report at bugs.python.org (Eric S)
Date: Sat, 01 Aug 2015 22:08:44 +0000
Subject: [issue24724] Element.findall documentation misleading
In-Reply-To: <1437881713.88.0.256447477825.issue24724@psf.upfronthosting.co.za>
Message-ID: <1438466924.18.0.0157161283778.issue24724@psf.upfronthosting.co.za>


Eric S added the comment:

Code was intended as example, not request for help to correct, but rushed so example was flawed, but still, I tested and you both are right. Must've had other error in code to cause the xml to dict to have every element map to under every node. Debugger also showed findall and list returns with every descendent under every item as well so that influenced my triage.

Issue is closed as far as I'm concerned but it sounds like you all found something else here. 

Sorry for using up your time. Will be more careful and clear if there is a next time.

----------

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

From report at bugs.python.org  Sun Aug  2 00:30:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 01 Aug 2015 22:30:14 +0000
Subject: [issue24774] inconsistency in http.server.test
In-Reply-To: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>
Message-ID: <1438468214.66.0.140430826985.issue24774@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks okay to me, although another option could be to move the argument parsing back into the test() function, where it was originally.

BTW I don?t think the 3.3 branch is open to fixes like this any more.

----------
nosy: +vadmium
stage:  -> patch review
versions:  -Python 3.3

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

From report at bugs.python.org  Sun Aug  2 00:59:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Aug 2015 22:59:06 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <20150801225903.111165.47316@psf.io>


Roundup Robot added the comment:

New changeset 55e5f7766d2c by Terry Jan Reedy in branch '2.7':
Issue 24745: Switch from Courier to platform-sensitive TkFixedFont as default
https://hg.python.org/cpython/rev/55e5f7766d2c

New changeset 5c992189414f by Terry Jan Reedy in branch '3.4':
Issue 24745: Switch from Courier to platform-sensitive TkFixedFont as default
https://hg.python.org/cpython/rev/5c992189414f

New changeset 90c02a0bec08 by Terry Jan Reedy in branch '3.5':
Issue 24745: Merge with 3.4
https://hg.python.org/cpython/rev/90c02a0bec08

New changeset 3a731756f9cc by Terry Jan Reedy in branch 'default':
Issue 24745: Merge with 3.5
https://hg.python.org/cpython/rev/3a731756f9cc

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  2 01:06:38 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Aug 2015 23:06:38 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1438470398.0.0.629552839579.issue24745@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Review published with the changes I made, tested, and committed.

I am not convinced that writing all 3 font attributes is needed, which is good since existing user files do not have all 3.  But safer for future.  Part of my preference to avoid user file when not needed (because only config matches default) is because user files are an occasional point of failure.  But we should fix bugs noted in TODOs and on tracker.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  2 01:16:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Aug 2015 23:16:07 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <20150801231604.1399.83474@psf.io>


Roundup Robot added the comment:

New changeset 82198ae039cd by Terry Jan Reedy in branch '3.4':
Issue 24745: Add ACKS entry.
https://hg.python.org/cpython/rev/82198ae039cd

New changeset bf14b74d6fc0 by Terry Jan Reedy in branch '3.5':
Issue 24745: Add ACKS entry.
https://hg.python.org/cpython/rev/bf14b74d6fc0

New changeset 5744985ad8dc by Terry Jan Reedy in branch '2.7':
Issue 24745: Add ACKS entry.
https://hg.python.org/cpython/rev/5744985ad8dc

----------

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

From report at bugs.python.org  Sun Aug  2 01:36:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Aug 2015 23:36:36 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438472196.71.0.727161117336.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On Idle-sig, in 'ttk appearance' Mark posted before and after screenshots of Preferences Font tab for Windows, Linux, and Mac
http://www.tkdocs.com/images/idle_cfgfont_ttk.png
Glyph, who I never knew read Idle-sig, calls the after shots great (I think he has a Mac, which sees the most improvement).

----------

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

From report at bugs.python.org  Sun Aug  2 01:47:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Aug 2015 23:47:19 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438472839.44.0.752608987995.issue24771@psf.upfronthosting.co.za>


Steve Dower added the comment:

Correct. I'll fix this on Monday or Tuesday this week.

----------
assignee:  -> steve.dower

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

From report at bugs.python.org  Sun Aug  2 01:48:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Aug 2015 23:48:11 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438472891.78.0.405000121402.issue24771@psf.upfronthosting.co.za>


Steve Dower added the comment:

Until then, if you find and install the VC distributable for VS 2015 then you'll have the files you need. On my phone now so I don't have the link handy

----------

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

From report at bugs.python.org  Sun Aug  2 02:41:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 00:41:55 +0000
Subject: [issue1175004] Export more libreadline API functions
Message-ID: <1438476115.37.0.275472398028.issue1175004@psf.upfronthosting.co.za>


Martin Panter added the comment:

Simon: See Issue 24266 about recovering after interrupting the search mode.

Also, I think Issue 1744456 wraps a different part of the Readline API (rl_callback_ for non-blocking interface) to the patch here (rl_add_defun for adding a custom ?key binding? or something). So the two patches could be considered independently.

----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Aug  2 02:47:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 00:47:16 +0000
Subject: [issue1744456] Expose non-blocking callbackAPI in readline module
Message-ID: <1438476436.77.0.376825845526.issue1744456@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think this is a duplicate. The patch here wraps the non-blocking ?alternate interface? <https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC41>: rl_callback_read_char() etc. The patch in Issue 1175004 wraps other APIs, including rl_add_defun() <https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC30>. So if someone was interested in pushing this forward, perhaps it could be reopened.

----------
nosy: +vadmium
resolution: duplicate -> 
stage: resolved -> needs patch
title: Patch for feat. 1713877 Expose callbackAPI in readline module -> Expose non-blocking callbackAPI in readline module

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

From report at bugs.python.org  Sun Aug  2 02:51:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 00:51:33 +0000
Subject: [issue24759] Idle: require ttk (and tcl/tk 8.5)
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438476693.08.0.794150803172.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Re-reading PEP 434, I was mistaken to apply this patch to 2.7 and 3.4 without further discussion.  The PEP says "The PEP would apply to minor ..., but not necessarily to possible major re-writes such as switching to themed widgets ... ." 

Nick, should I post something on python-ideas or pydev, or continue here (moved from #24750) about making the switch also in 2.7 and 3.4?

I believe it would be best overall to at upgrade Idle 2.7, but I will not cry if we stop patching it now. Ditto for 3.4, which will soon get security fixes only anyway.  I am ok with using ttk starting with 3.5.

----------
nosy: +ncoghlan
resolution: fixed -> 
stage: resolved -> 
title: Idle: require 8.5 / ttk -> Idle: require ttk (and tcl/tk 8.5)

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

From report at bugs.python.org  Sun Aug  2 02:53:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 00:53:15 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438476795.55.0.435996167277.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Mark: Serhiy is asking that we not make the change to maintenance releases, 2.7 and 3.4, without further discussion and agreement.  He is correct to do so.  I reread PEP 434 and it specifically says  "The PEP would apply to ..., but not necessarily to possible major re-writes such as switching to themed widgets ... ."  'Not necessarily' means 'only permitted with further discussion.  Further discussion should continue on #24759 which is specifically about this issue.

----------
versions:  -Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Aug  2 03:06:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 01:06:19 +0000
Subject: [issue16346] maximum recursion installing readline package
In-Reply-To: <1351414135.83.0.205698336567.issue16346@psf.upfronthosting.co.za>
Message-ID: <1438477579.63.0.322078233042.issue16346@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
title: readline problem -> maximum recursion installing readline package

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

From report at bugs.python.org  Sun Aug  2 03:11:21 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 01:11:21 +0000
Subject: [issue24759] Idle: require ttk (and tcl/tk 8.5)
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438477881.1.0.0771946275678.issue24759@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Got it re: 2.7/3.4. So the only stumbling block left to 8.5/ttk in 3.5 would be the current Mac build that is ok with Tcl/Tk 8.4...?

----------

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

From report at bugs.python.org  Sun Aug  2 03:11:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 01:11:49 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1438477909.91.0.890871663262.issue24776@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that this tab needs an overhall.
Existing issues would be part of this:
17642 Font resizing hot keys (not sure about this)
14440 Use multiple alphabets in example (definitely)

Other ideas that I remember:
* Enlarge dialog box as needed (it already expands horizontally with big fonts).
* Put indent box across top with unobtrusive spinbox or pulldown box to right.
* For font names, use the same sort of listbox as used with completions, where one can type initial chars of name in entry box and selection bar moves down to first entry that matches. 
* Put example box to right of selection box.

----------
nosy: +markroseman
versions: +Python 3.5

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

From report at bugs.python.org  Sun Aug  2 03:23:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 01:23:39 +0000
Subject: [issue23067] Export readline forced_update_display
In-Reply-To: <1418758154.75.0.0731776033419.issue23067@psf.upfronthosting.co.za>
Message-ID: <1438478619.24.0.306789661041.issue23067@psf.upfronthosting.co.za>


Martin Panter added the comment:

There are actually a few other patches open adding wrappers for rl_forced_update_display():

* Issue 1175004: From 2005, other APIs as well
* Issue 24727: Includes documentation

As well as the documentation, I think it would be good to add a test case for new functionality if possible.

----------
nosy: +vadmium
stage:  -> needs patch
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sun Aug  2 03:26:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 01:26:19 +0000
Subject: [issue1175004] Export more libreadline API functions
Message-ID: <1438478779.92.0.448506575654.issue1175004@psf.upfronthosting.co.za>


Martin Panter added the comment:

rl_forced_update_display() wrappers already proposed in Issue 23067

----------
dependencies: +Export readline forced_update_display

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

From report at bugs.python.org  Sun Aug  2 03:30:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Aug 2015 01:30:30 +0000
Subject: [issue24727] Expand readline module
In-Reply-To: <1437908271.28.0.296512613048.issue24727@psf.upfronthosting.co.za>
Message-ID: <1438479030.28.0.802286705428.issue24727@psf.upfronthosting.co.za>


Martin Panter added the comment:

Suggest you integrate your rl_forced_update_display() wrapper and documentation with the existing patches in Issue 23067.

Regarding the reading_line() flag, your use case seems a bit racy to me. Can?t the other thread start reading a line after reading_line() returns false and before your print() statement happens?

----------
dependencies: +Export readline forced_update_display
nosy: +vadmium

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

From report at bugs.python.org  Sun Aug  2 04:10:03 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 Aug 2015 02:10:03 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1438481403.44.0.84121988773.issue24769@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

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

From report at bugs.python.org  Sun Aug  2 04:39:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Aug 2015 02:39:58 +0000
Subject: [issue23652] ifdef uses of EPOLLxxx macros so we can compile on
 systems that don't have them
In-Reply-To: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>
Message-ID: <20150802023954.41845.45582@psf.io>


Roundup Robot added the comment:

New changeset e38470b49d3c by Zachary Ware in branch '2.7':
Issue #23652: Make the select module compile against LSB headers.
https://hg.python.org/cpython/rev/e38470b49d3c

New changeset c18a18b65a49 by Zachary Ware in branch '3.4':
Issue #23652: Make the select module compile against LSB headers.
https://hg.python.org/cpython/rev/c18a18b65a49

New changeset a99f17c752d8 by Zachary Ware in branch '3.5':
Issue #23652: Merge with 3.4
https://hg.python.org/cpython/rev/a99f17c752d8

New changeset c7273b46980c by Zachary Ware in branch 'default':
Closes #23652: Merge with 3.5
https://hg.python.org/cpython/rev/c7273b46980c

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  2 04:40:31 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 02 Aug 2015 02:40:31 +0000
Subject: [issue23652] ifdef uses of EPOLLxxx macros so we can compile on
 systems that don't have them
In-Reply-To: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>
Message-ID: <1438483231.22.0.561436278427.issue23652@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the patch!

----------

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

From report at bugs.python.org  Sun Aug  2 05:01:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Aug 2015 03:01:28 +0000
Subject: [issue23182] Update grammar tests to use new style for annotated
 function definitions
In-Reply-To: <1420620545.16.0.862545867011.issue23182@psf.upfronthosting.co.za>
Message-ID: <20150802030125.94776.27491@psf.io>


Roundup Robot added the comment:

New changeset c981d9819384 by Zachary Ware in branch '3.4':
Issue #23182: PEP8-ify the annotation grammar tests.  Patch by Ian Lee.
https://hg.python.org/cpython/rev/c981d9819384

New changeset f35bdb6dd242 by Zachary Ware in branch '3.5':
Issue #23182: Merge with 3.4
https://hg.python.org/cpython/rev/f35bdb6dd242

New changeset a0ac94514a30 by Zachary Ware in branch 'default':
Closes #23182: Merge with 3.5
https://hg.python.org/cpython/rev/a0ac94514a30

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  2 05:05:22 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 02 Aug 2015 03:05:22 +0000
Subject: [issue23182] Update grammar tests to use new style for annotated
 function definitions
In-Reply-To: <1420620545.16.0.862545867011.issue23182@psf.upfronthosting.co.za>
Message-ID: <1438484722.39.0.0113220619545.issue23182@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the patch!

----------
nosy: +zach.ware
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Sun Aug  2 06:37:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 04:37:48 +0000
Subject: [issue24759] Idle: require ttk (and tcl/tk 8.5)
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438490268.63.0.802906936424.issue24759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ttk widgets are partially compatible with Tk widgets, so in many cases it is possible to make partial upgrade without major rewriting. Some changes perhaps need major rewriting (using styles, changing layout), and I think this is what the PEP does not allow. However it is possible that all changes can be done without major rewriting, we don't know until try.

----------

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

From report at bugs.python.org  Sun Aug  2 06:39:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 02 Aug 2015 04:39:23 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1438490363.97.0.885842451332.issue24769@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> deferred blocker

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

From report at bugs.python.org  Sun Aug  2 07:17:19 2015
From: report at bugs.python.org (Ankoor Patil)
Date: Sun, 02 Aug 2015 05:17:19 +0000
Subject: [issue24777] sys.getrefcount takes no arguments ??
Message-ID: <1438492639.12.0.0188177121907.issue24777@psf.upfronthosting.co.za>


New submission from Ankoor Patil:

I have just started exploring python in rhino and I think I hit a bug, can you please confirm this or point out where am I going wrong.

Thanks.

----------
components: Cross-Build
files: Capture.PNG
messages: 247855
nosy: Ankoor Patil
priority: normal
severity: normal
status: open
title: sys.getrefcount takes no arguments ??
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40097/Capture.PNG

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

From report at bugs.python.org  Sun Aug  2 09:53:20 2015
From: report at bugs.python.org (sanad)
Date: Sun, 02 Aug 2015 07:53:20 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438502000.37.0.776974080205.issue23672@psf.upfronthosting.co.za>


sanad added the comment:

On the lines of changes proposed by Terry and others in the comments, this is the patch I'm submitting. 

The function _filename_to_unicode() plays the major part in the plot. The function can get two types of filename ,'str' and 'bytes'. When its str, all the astral chars(characters that are outside BMP ) are replaced by the '?'(diamond question mark) character by performing a regex substitution in the return statement.

If the received filename is in the form of b'..' (bytes) or any other encoding ,it is first decoded(as was earlier) into str and before returning, all the out of range Unicode characters are replaced by the '?'(diamond question mark) character .

The effect on behavior is : the 

1.IDLE is able to display correctly,the  filename in the title-bar and in the file open dialog.
2. Any file with name that have astral chars in them are easily imported without any crash.

This is my first patch,please review it ,if any errors found I will correct them and upload again :)

----------
keywords: +patch
nosy: +sanad
Added file: http://bugs.python.org/file40098/issue23672(updated third).patch

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

From report at bugs.python.org  Sun Aug  2 10:25:07 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Sun, 02 Aug 2015 08:25:07 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
Message-ID: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>


New submission from Bernd Dietzel:

if the filename contains Shell Commands they will be executed if they
are passed to os.system() as discribed in the docs.
Filename should be quoted with quote(filename) to fix the bug.

https://docs.python.org/2/library/mailcap.html

"mailcap.findmatch(/caps/, /MIMEtype/[, /key/[, /filename/[, /plist/]]])

    Return a 2-tuple; the first element is a string containing the
    command line to be executed
    (which can be passed to*os.system() *),
......"

Exploid Demo wich runs xterm but should not :
=============================

import mailcap
d=mailcap.getcaps()
commandline,MIMEtype=mailcap.findmatch(d, "text/*", filename="'$(xterm);#.txt")
## commandline = "less ''$(xterm);#.txt'"
import os
os.system(commandline)
## xterm starts

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

By the way ... please do not use os.system() in your code, makes it unsafe.


Best regards
Bernd Dietzel
Germany

----------
components: Library (Lib)
files: screenshot.png
messages: 247857
nosy: TheRegRunner
priority: normal
severity: normal
status: open
title: mailcap.findmatch()   ........ Shell Command Injection in filename
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file40099/screenshot.png

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

From report at bugs.python.org  Sun Aug  2 10:32:03 2015
From: report at bugs.python.org (sanad)
Date: Sun, 02 Aug 2015 08:32:03 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438504323.48.0.202419542876.issue23672@psf.upfronthosting.co.za>


sanad added the comment:

Correction:

This patch fixes the problem of idle not opening when recent file list has filenames outside BMP and the crashing of idle on using filenames with astral characters.

The added benefit is that you can create a file with such chars and save it and access it again from the Recent Files List.

What this patch doesn't fix is :
1. The File Open Dialog displays the filename incorrectly.
2. The File Open Dialog doesn't allows the file with such filename to be opened.
3. When trying the to run the file with such name, it gives an Traceback to Tkinter. The following is the error message :

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/sanad/devpy/pessoc/cpython/Lib/tkinter/__init__.py", line 1549, in __call__
    return self.func(*args)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/ScriptBinding.py", line 124, in run_module_event
    return self._run_module_event(event)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/ScriptBinding.py", line 145, in _run_module_event
    interp.restart_subprocess(with_cwd=False, filename=code.co_filename)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/PyShell.py", line 502, in restart_subprocess
    console.write("\n{0} {1} {0}".format(halfbar, tag))
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/PyShell.py", line 1294, in write
    'Non-BMP character not supported in Tk')
UnicodeEncodeError: 'UCS-2' codec can't encode characters in position 49-49: Non-BMP character not supported in Tk

Which I guess is another related issue.

----------

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

From report at bugs.python.org  Sun Aug  2 11:01:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 09:01:43 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438506103.45.0.209884102446.issue24750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, ttk detection doesn't work this way. ImportError is not raised on import, and TclError is raised instead on widget creation.

Here is a patch for 3.4 that is compatible with 8.4 (tested).

@scroll.diff LGTM for 3.5+.

----------
Added file: http://bugs.python.org/file40100/@scroll34.diff

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

From report at bugs.python.org  Sun Aug  2 11:46:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 09:46:03 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438508763.52.0.165023505009.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If 2.7 and 3.4 are left out of consideration, then, AFAIK, the only people necessarily affected are those with a PowerPC with OS 10.5 who upgrade to python3.5 and also want to run Idle. People with an Intel machine instead might be if there is no python3.5 that will run with the ActiveState 8.5 that Mark says works on Intel 10.5 machines.  I wish I know how many people that is.  I suspect a tiny fraction of Idle users and of people with such machines.  But ...

The compatibility approach will work for Scrollbars, but I am dubious about other widgets.  For instance, tk Buttons have at least 31 options.  ttk Buttons have 9 of the same + style (and class_, which I do not thing we would use), leaving 22 tk-only options. 

To write tk&ttk code *in one file*, I believe
  ...ttk.Button(parent, <options>, style='xyz')
would have to be written (compactly) as something like
  b=...Button(parent, <common options>)
  b.config(**({'style':'xyz'} if ttk else { <tk style options>}))
or (expansively, in 5 lines)
  b=...Button(parent, <common options>)
  if ttk:
    b['style'] = 'xyz'
  else:
    b.config(<tk style options in '=' format>})

I consider this impractical.  I am unwilling to write code that way, in part because it would have to be carefully tested both with and without ttk -- by hand.  I cannot imagine anyone else doing so either. It also does not work for uses of ttk.Treeview, whose API is different from the multiple classes used in Path and Class (Module) browser).  I believe the same is true for ttk.Notebook and the idlelib tab widget.

What I already planned to do instead is copy existing dialog code to new files, possibly refactored, with pep8 filenames and internal names style.  I already planned to leave the existing files in place for now, though as zombies, in case of any external code imports.  With a little more work, it should be possible to optionally use either old or new files. Most of the work would be done with alternate bindings to menu items and accelerator keys, such as Find in Files and Alt-F3.

It might be more acceptible to use ttk in 2.7 and 3.4 as an option rather than as a replacement.  Though I would only commit a ttk version when confident that is works, leaving the option to switch back would add a safety factor.  I changed the title and will revert the patch later.

----------
stage:  -> needs patch
title: Idle: require ttk (and tcl/tk 8.5) -> Idle: add ttk widgets as an option

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

From report at bugs.python.org  Sun Aug  2 12:16:11 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Sun, 02 Aug 2015 10:16:11 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438510571.11.0.177958370711.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

Maybe it would be a good idea to do so as run-mailcap does :

theregrunner at mint17 : ~ ? run-mailcap --debug "';xterm;#'.txt"
 - parsing parameter "';xterm;#'.txt"
 - Reading mime.types file "/etc/mime.types"...
 - extension "txt" maps to mime-type "text/plain"
 - Reading mailcap file "/etc/mailcap"...
Processing file "';xterm;#'.txt" of type "text/plain" (encoding=none)...
 - checking mailcap entry "text/plain; less '%s'; needsterminal"
 - program to execute: less '%s'
 - filename contains shell meta-characters; aliased to '/tmp/fileV7f2MZ'
 - executing: less '/tmp/fileV7f2MZ'
theregrunner at mint17 : ~ ?

----------

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

From report at bugs.python.org  Sun Aug  2 12:27:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 10:27:10 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438511230.5.0.806522799759.issue24759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note also that committed patch doesn't work at all. "from tkinter import ttk" doesn't raise an exception with Tcl/Tk 8.4. See my patch in issue24750 that does working check.

I consider impractical complex code for supporting 8.4 and ttk too. But in simplest cases this can be done easy.

----------

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

From report at bugs.python.org  Sun Aug  2 14:00:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 12:00:15 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1438516815.86.0.126027133415.issue22227@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Martin's comments. Thanks Martin.

----------
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file40101/tarfile_tariter_2.diff

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

From report at bugs.python.org  Sun Aug  2 14:08:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 12:08:23 +0000
Subject: [issue20557] Use specific asserts in io tests
In-Reply-To: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>
Message-ID: <1438517303.85.0.931140324709.issue20557@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually Raymond objected. But under pressure of positive feedbacks and to avoid non-polite discussion I'll commit the patch.

----------

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

From report at bugs.python.org  Sun Aug  2 14:21:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Aug 2015 12:21:22 +0000
Subject: [issue20557] Use specific asserts in io tests
In-Reply-To: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>
Message-ID: <20150802122119.29414.93659@psf.io>


Roundup Robot added the comment:

New changeset ace74c445a3f by Serhiy Storchaka in branch '3.4':
Issue #20557: Use specific asserts in io tests.
https://hg.python.org/cpython/rev/ace74c445a3f

New changeset 2453ac990e5b by Serhiy Storchaka in branch '3.5':
Issue #20557: Use specific asserts in io tests.
https://hg.python.org/cpython/rev/2453ac990e5b

New changeset 859a45ca1e86 by Serhiy Storchaka in branch 'default':
Issue #20557: Use specific asserts in io tests.
https://hg.python.org/cpython/rev/859a45ca1e86

New changeset 68115dd0c7f5 by Serhiy Storchaka in branch '2.7':
Issue #20557: Use specific asserts in io tests.
https://hg.python.org/cpython/rev/68115dd0c7f5

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  2 14:31:29 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 12:31:29 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1438518689.79.0.233594762106.issue22227@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Aug  2 15:04:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 13:04:41 +0000
Subject: [issue20556] Use specific asserts in threading tests
In-Reply-To: <1391808878.85.0.661174932104.issue20556@psf.upfronthosting.co.za>
Message-ID: <1438520681.2.0.360072006348.issue20556@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, I missed to remove one old assertion. Thanks Mark.

----------
versions: +Python 3.5, Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file40102/test_threading_asserts_2.patch

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

From report at bugs.python.org  Sun Aug  2 15:05:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 13:05:20 +0000
Subject: [issue20557] Use specific asserts in io tests
In-Reply-To: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>
Message-ID: <1438520720.36.0.555953369794.issue20557@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  2 15:28:59 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 13:28:59 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438522139.51.0.805760358241.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Yury, your tests complete even without any patches on cpython default (@74fc1af57c72). How is that possible? I verified that they are run.

----------

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

From report at bugs.python.org  Sun Aug  2 15:29:54 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 13:29:54 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438522194.77.0.172340836068.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Nevermind, I was running the wrong Python version.

----------

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

From report at bugs.python.org  Sun Aug  2 15:55:37 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 13:55:37 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438523737.6.0.189789895481.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

I'm having trouble compiling the latest default (@859a45ca1e86). Getting linker errors. I've updated the patch with Yury's tests in it. Would someone mind running them? Apparently they do pass on 3.5b3 at least.

----------

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

From report at bugs.python.org  Sun Aug  2 16:08:25 2015
From: report at bugs.python.org (Chiu-Hsiang Hsu)
Date: Sun, 02 Aug 2015 14:08:25 +0000
Subject: [issue24774] inconsistency in http.server.test
In-Reply-To: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>
Message-ID: <1438524505.48.0.535861436305.issue24774@psf.upfronthosting.co.za>


Chiu-Hsiang Hsu added the comment:

I'm not quite sure we should put argument parsing back into the test() function or just fix docstring. It already expose port and bind through function arguments. It looks wierd to me to have function arguments & CLI arguments modifying the same variable in the same time. If we want to move argument parsing back, I think we should clean the function parameters. In this way, the docstring of test function still need some update, though. (we have much more CLI arguments now)

----------

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

From report at bugs.python.org  Sun Aug  2 16:14:52 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 02 Aug 2015 14:14:52 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438524892.24.0.507249972239.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Alex, the updated patch is attached.

Guido, do you like the new approach? Can I commit this in 3.6?

----------
Added file: http://bugs.python.org/file40103/concurrent.patch

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

From report at bugs.python.org  Sun Aug  2 16:17:13 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 02 Aug 2015 14:17:13 +0000
Subject: [issue23973] PEP 484 implementation
In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za>
Message-ID: <1438525033.16.0.0229004535734.issue23973@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm bumping this up since the CPython repo is several changes behind the typehinting repo (https://github.com/ambv/typehinting/tree/master/prototyping). Those should not miss RC1.

----------
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Aug  2 16:17:55 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 02 Aug 2015 14:17:55 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438525075.29.0.527161329958.issue24272@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This should probably be committed before RC1 -- it's better than nothing!

----------
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Aug  2 16:29:12 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 14:29:12 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438525752.1.0.0645559796188.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Ah hehe, I forgot to actually attach the patch. Thanks Yury.

The asyncio docs need to explicitly mention that concurrent.futures.Futures can be directly awaited from coroutines. Aside from that, I think we're set -- just need Guido to chime in on this.

----------

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

From report at bugs.python.org  Sun Aug  2 16:37:53 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 02 Aug 2015 14:37:53 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438526273.49.0.938294531862.issue24272@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Is anyone working on this right now? If not, I could implement the comments by Guido to the latest patch by Daniel.

----------

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

From report at bugs.python.org  Sun Aug  2 17:00:37 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Sun, 02 Aug 2015 15:00:37 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438527637.76.0.0773478045161.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

I dropped the ball here. The last message from the review system was misclassified by Gmail as spam... Sorry about that.

I can take a look at this tonight but if anyone can address the comments earlier, go for it.

----------

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

From report at bugs.python.org  Sun Aug  2 17:07:44 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 02 Aug 2015 15:07:44 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438524892.24.0.507249972239.issue24383@psf.upfronthosting.co.za>
Message-ID: <55BE321B.2080706@behnel.de>


Stefan Behnel added the comment:

It would be nice to have this applied to 3.5 even. I'm aware that this is a
new feature that shouldn't go in any more at this point, but if it could
get added in 3.5.1 at least, I think it would fill a rather clear and
annoying gap when it comes to tool integration.

If someone explained async/await as a new syntax feature for async
programming to me, and then mentioned that you can't await a Future, I'd be
rather surprised, to put it mildly.

----------

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

From report at bugs.python.org  Sun Aug  2 17:27:27 2015
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 02 Aug 2015 15:27:27 +0000
Subject: [issue24217] O_RDWR undefined in mmapmodule.c
In-Reply-To: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za>
Message-ID: <1438529247.01.0.214210936206.issue24217@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

There is a patch attached to this report for greater than 2 months. Should I mark this as "won't fix?"

----------

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

From report at bugs.python.org  Sun Aug  2 17:56:48 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 15:56:48 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438531008.94.0.694494072871.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

You're right Stefan -- I too was appalled that this was not possible in 3.5 to begin with. It feels completely natural to be able to await for concurrent Futures. But as this is considered a feature, it'll probably have to wait until 3.6. Otherwise you'll end up your app requiring a specific micro-release which is a big no-no in the Python world, as far as features go at least.

But if this is considered a bugfix, it could still go into 3.5.0... *wink wink*. That's what I'm hoping for of course.

----------

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

From report at bugs.python.org  Sun Aug  2 18:32:37 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 02 Aug 2015 16:32:37 +0000
Subject: [issue24779] Python/ast.c: decode_unicode is never called with
 rawmode=True
Message-ID: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

The only call to decode_unicode is this:

if (!*bytesmode && !rawmode) {
    return decode_unicode(c, s, len, rawmode, c->c_encoding);
}

So rawmode will always be 0. Removing this will delete a call to PyUnicode_DecodeRawUnicodeEscape in decode_unicode.

----------
components: Interpreter Core
messages: 247880
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Python/ast.c: decode_unicode is never called with rawmode=True
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Aug  2 18:37:23 2015
From: report at bugs.python.org (Barney Stratford)
Date: Sun, 02 Aug 2015 16:37:23 +0000
Subject: [issue24727] Expand readline module
In-Reply-To: <1437908271.28.0.296512613048.issue24727@psf.upfronthosting.co.za>
Message-ID: <1438533443.6.0.457480320473.issue24727@psf.upfronthosting.co.za>


Barney Stratford added the comment:

You're absolutely right. I had elided the details of the locking from my original use case, but now I look at it again, I see that even what I did have wasn't enough.

I've made a new patch that takes a lock properly. A non-blocking acquisition of the lock will serve the same purpose as looking to see if there is a line being read, and will also prevent the interpreter from starting to read a new line while the text is being printed.

My use case now looks like this.

reading_lock = threading.Lock ()
readline.set_lock (reading_lock)

def describe (indicator):
	if reading_lock.acquire (False):
		print (indicator.description)
		reading_lock.release ()
	else:
		print ()
		print (indicator.description)
		readline.forced_update_display ()

----------
Added file: http://bugs.python.org/file40104/patch.txt

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

From report at bugs.python.org  Sun Aug  2 18:48:10 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 02 Aug 2015 16:48:10 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438534090.83.0.155217234923.issue24383@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

[Repeat from the review]

I still don't think this should be done for 3.5.0, it's definitely a feature, and there are no more betas planned (rc1 is next weekend).

We may be able to do this for 3.5.1 (since PEP 492 was accepted provisionally, see https://mail.python.org/pipermail/python-dev/2015-May/139844.html) although it's still a pretty big new feature.

We should also have more discussion (on python-dev, IMO, not just in the issue) about whether we want this at all -- I find it questionable to mix await and threads, as I have said several times in the discussion about Nick Coghlan's proposal to introduce helper functions with a similar function.

The argument "but they're both Futures" seems pretty bogus to me.

----------

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

From report at bugs.python.org  Sun Aug  2 18:49:29 2015
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 02 Aug 2015 16:49:29 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
Message-ID: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

When newlines are present, the error message displayed by unittest's self.assertEqual() to show where strings differ can be nonsensical.  For example, the caret symbol can show up in a strange location.

The first example below shows a case where things work correctly.  The second shows a newline case with the confusing display.


======================================================================
FAIL: test1
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/chris/***/test.py", line 66, in test1
    self.assertEqual("abc", "abd")
AssertionError: 'abc' != 'abd'
- abc
?   ^
+ abd
?   ^


======================================================================
FAIL: test2
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/chris/***/test.py", line 69, in test2
    self.assertEqual("\nabcx", "\nabdx")
AssertionError: '\nabcx' != '\nabdx'
  
- abcx?   ^
+ abdx?   ^

----------
components: Library (Lib)
messages: 247883
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: unittest assertEqual difference output foiled by newlines
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  2 18:56:51 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 02 Aug 2015 16:56:51 +0000
Subject: [issue24779] Python/ast.c: decode_unicode is never called with
 rawmode=True
In-Reply-To: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za>
Message-ID: <1438534611.49.0.438458244928.issue24779@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

That's poor wording on my part: the call to PyUnicode_DecodeRawUnicodeEscape isn't actually execute if rawmode is false. So it's really just a dead branch that's being deleted.

----------

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

From report at bugs.python.org  Sun Aug  2 19:58:01 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 02 Aug 2015 17:58:01 +0000
Subject: [issue24779] Python/ast.c: decode_unicode is never called with
 rawmode=True
In-Reply-To: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za>
Message-ID: <1438538281.13.0.522563363947.issue24779@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Then I say delete it.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Aug  2 20:07:16 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 02 Aug 2015 18:07:16 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438538836.92.0.934141298452.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> We may be able to do this for 3.5.1 (since PEP 492 was accepted provisionally, see https://mail.python.org/pipermail/python-dev/2015-May/139844.html) although it's still a pretty big new feature.

I agree.  I'm -1 on pushing this to 3.5.0 or to 3.5.1.

----------

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

From report at bugs.python.org  Sun Aug  2 20:50:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 18:50:38 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1438541438.16.0.391782238477.issue24776@psf.upfronthosting.co.za>


Mark Roseman added the comment:

What do you think of the layout in cfg_font_layout.png? (before/after)

----------
Added file: http://bugs.python.org/file40105/cfg_font_layout.png

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

From report at bugs.python.org  Sun Aug  2 21:03:22 2015
From: report at bugs.python.org (Ilia Kurenkov)
Date: Sun, 02 Aug 2015 19:03:22 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1438542202.35.0.519469995391.issue20362@psf.upfronthosting.co.za>


Ilia Kurenkov added the comment:

I notice folks have been subscribing to this. Any chance we could review it and merge? :)

----------

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

From report at bugs.python.org  Sun Aug  2 21:13:41 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Aug 2015 19:13:41 +0000
Subject: [issue24777] sys.getrefcount takes no arguments
In-Reply-To: <1438492639.12.0.0188177121907.issue24777@psf.upfronthosting.co.za>
Message-ID: <1438542821.45.0.276312881551.issue24777@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. Some functions like getrefcount in sys module are specific to CPython. Other Python implementations like IronPython(it doesn't use reference counting for example) may not implement or partially implement those functions.

sys.getrefcount() works fine with CPython:

    >>> import sys
    >>> l = 5
    >>> sys.getrefcount(l)
    35

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: sys.getrefcount takes no arguments ?? -> sys.getrefcount takes no arguments

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

From report at bugs.python.org  Sun Aug  2 21:17:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Aug 2015 19:17:49 +0000
Subject: [issue24217] O_RDWR undefined in mmapmodule.c
In-Reply-To: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za>
Message-ID: <20150802191745.23388.34753@psf.io>


Roundup Robot added the comment:

New changeset 1838f37a8d9e by Benjamin Peterson in branch '3.4':
include fcntl.h on all *nix platforms (closes #24217)
https://hg.python.org/cpython/rev/1838f37a8d9e

New changeset 25ba5e7af08a by Benjamin Peterson in branch '3.5':
Merge 3.4 (#24217)
https://hg.python.org/cpython/rev/25ba5e7af08a

New changeset 4ed9cc2203b3 by Benjamin Peterson in branch 'default':
merge 3.5 (#24217)
https://hg.python.org/cpython/rev/4ed9cc2203b3

New changeset 2e635a0e0207 by Benjamin Peterson in branch '2.7':
include fcntl.h on all *nix platforms (closes #24217)
https://hg.python.org/cpython/rev/2e635a0e0207

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  2 21:30:22 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 02 Aug 2015 19:30:22 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438543822.82.0.336164317131.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Updated patch per review comments.

I also corrected the order of the lines in the new block. If _must_cancel is True, it would have tried to call cancel() on _fut_waiter before it was set. Now the code matches that of the original block.

The docs don't seem to explicitly say anywhere that they only accept asyncio's Futures and not concurrent Futures, so I'm unsure if any changes are needed there at all.

----------
Added file: http://bugs.python.org/file40106/concurrent.patch

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

From report at bugs.python.org  Sun Aug  2 21:38:59 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 02 Aug 2015 19:38:59 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438534090.83.0.155217234923.issue24383@psf.upfronthosting.co.za>
Message-ID: <55BE71CE.2020105@behnel.de>


Stefan Behnel added the comment:

> I find it questionable to mix await and threads, as I have said several
> times in the discussion about Nick Coghlan's proposal to introduce
> helper functions with a similar function.

There are a couple of use cases in the context of asyncio, but definitely
also a major one: blocking database drivers. Normally, applications keep a
pool of connections open to a database and use a bounded size for it in
order to limit the resource usage on server side. Starting a thread pool of
the same size in the application provides a trivial way to make use of
these connections concurrently and efficiently with a blocking database
driver and/or ORM (e.g. SQLAlchemy). "concurrent.futures" makes this really
easy.

> The argument "but they're both Futures" seems pretty bogus to me.

concurrent.futures.Future is not just any Future, it's the one that is in
the standard library, i.e. pretty much the only one that every tool could
agree on (whether or not it knows about or uses asyncio). The fact that
it's thread-safe doesn't really matter to me.

----------

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

From report at bugs.python.org  Sun Aug  2 22:43:00 2015
From: report at bugs.python.org (David Watson)
Date: Sun, 02 Aug 2015 20:43:00 +0000
Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3
 files
In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za>
Message-ID: <1438548180.34.0.828383589227.issue20174@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


----------
nosy: +baikie

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

From report at bugs.python.org  Sun Aug  2 22:43:32 2015
From: report at bugs.python.org (David Watson)
Date: Sun, 02 Aug 2015 20:43:32 +0000
Subject: [issue24725] test_socket testFDPassEmpty fails on OS X 10.11 DP with
 "Cannot allocate memory"
In-Reply-To: <1437896131.77.0.341264720465.issue24725@psf.upfronthosting.co.za>
Message-ID: <1438548212.64.0.807204485977.issue24725@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


----------
nosy: +baikie

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

From report at bugs.python.org  Sun Aug  2 22:46:31 2015
From: report at bugs.python.org (David Watson)
Date: Sun, 02 Aug 2015 20:46:31 +0000
Subject: [issue16263] sendmsg, recvmsg,
 recvmsg_into et al not being detected on Solaris
In-Reply-To: <1350469305.65.0.493434149752.issue16263@psf.upfronthosting.co.za>
Message-ID: <1438548391.3.0.847397567637.issue16263@psf.upfronthosting.co.za>


Changes by David Watson <baikie at users.sourceforge.net>:


----------
nosy: +baikie

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

From report at bugs.python.org  Sun Aug  2 22:57:27 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 20:57:27 +0000
Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs
In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za>
Message-ID: <1438549047.07.0.887630647185.issue23218@psf.upfronthosting.co.za>


Mark Roseman added the comment:

For illustration, attached idle_find_ttk.png, which is a minor layout tweak of the existing one (works on all the various find dialogs, though not shown in screen shot). I agree with Al's other suggestions here.

----------
nosy: +markroseman
Added file: http://bugs.python.org/file40107/idle_find_ttk.png

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

From report at bugs.python.org  Sun Aug  2 22:59:04 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 02 Aug 2015 20:59:04 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438549144.37.0.445317966184.issue24272@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

New version of the patch by Daniel, latest comments by Guido are taken into account.

----------
Added file: http://bugs.python.org/file40108/typing_doc_v3.patch

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

From report at bugs.python.org  Sun Aug  2 22:59:43 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 20:59:43 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438549183.32.0.614941859897.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Minor nit: you import 'ttkcompat' and add 'compat'.

On to the new 'compat': the only doc for .setup_master is the docstring
"If master is not None, itself is returned. If master is None,
    the default master is returned if there is one, otherwise a new
    master is created and returned."
So if master is always passed in, it seems that the call does nothing and could be removed.

._load_tile and ._tile_loaded have no doc. As near as I can tell from
>>> r = tk.Tk()
>>> s = ttk.Scrollbar(r)  # does not set ._tile_loaded on r
>>> ttk._load_tile(r)  # ditto, None returned
with 8.5, ._load_tile does nothing and ._tile_loaded is never set. They are only used for 8.4.  Correct?  If the tile extension is loaded, then use_ttk would be set to True.  Is the tile extension fully compatible with using ttk?

I would like compat.py to consist of an initialization functions that is called exactly once, always with a Tk(), to set globals in the module.

import tkinter as tk
from tkinter import ttk

def initialize(master, ttk_wanted=True): # untested
    globals use_ttk, Scrollbar, ...

    if not ttk_wanted:
        use_ttk = False
    else:
        try:
            ttk._load_tile(master)
        except tkinter.TclError:
            use_ttk = False
        else:
            use_ttk = True

    if use_ttk:
        from ttk import Scrollbar, ...
    else:
        from tk import Scroolbar, ...

Initialize would normally be called when Idle starts up.  ttk.wanted could make use_ttk a user option.  Initialize with ttk_wanted True/False would be used for testing.

----------

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

From report at bugs.python.org  Sun Aug  2 23:00:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 21:00:57 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438549257.88.0.798391324542.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I realize now that tkinter.ttk is (normally) present and will define Python classes even if the tk widgets needed for them to work are not present.  More comments on the added module on #24750

----------

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

From report at bugs.python.org  Sun Aug  2 23:02:15 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 21:02:15 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
Message-ID: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Placeholder for improvements to the syntax highlighting tab in IDLE config dialog.

I've attached cfg_highlight.png which shows a before and after I'm suggesting as a starting point. It would have the same functionality but uses a lot less pieces to implement it. Thoughts?

----------
components: IDLE
files: cfg_highlight.png
messages: 247897
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Improve UX of IDLE Highlighting configuration tab
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40109/cfg_highlight.png

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

From report at bugs.python.org  Sun Aug  2 23:06:57 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 21:06:57 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
Message-ID: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>


New submission from Mark Roseman:

I'm wondering about moving the functionality of the 'configure extensions' dialog into the main configuration dialog.  As I don't know the history here, I'm wondering why it was made separate.

My proposal would be to add an 'Extensions' tab in the main config dialog. Along the left would be a listbox holding the names of each extension. Along the right would be options for the extension selected in the listbox (done pretty much the same as now). Selecting a different extension from the list would swap in the appropriate set of options.

This would have the additional advantage of doing away with the stacked tabs.

----------
components: IDLE
messages: 247898
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Merge 'configure extensions' into main IDLE config dialog
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Aug  2 23:17:09 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 21:17:09 +0000
Subject: [issue24760] IDLE settings dialog shouldn't be modal
In-Reply-To: <1438297628.71.0.179622085434.issue24760@psf.upfronthosting.co.za>
Message-ID: <1438550229.06.0.807679400425.issue24760@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Incidentally (and this I would say is a definite bug) because the modal doesn't fully work on the Mac, you can actually create multiple copies of the config dialog!

----------

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

From report at bugs.python.org  Sun Aug  2 23:30:07 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 21:30:07 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438551007.52.0.999506115803.issue24750@psf.upfronthosting.co.za>


Mark Roseman added the comment:

While I think this approach would largely be a bad idea for an IDLE-sized application, where I think it definitely would be useful is in something very restricted like the tkSimpleDialog code. 

To improve the various little 'askstring', 'askinteger' etc. sprinkled throughout IDLE I had to do a copy/paste to change that code to use ttk widgets. Because that is an example of something very simple and self-contained, it could easily provide an option to do ttk or non-ttk widgets. 

Apologies if this is too off-topic.

----------

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

From report at bugs.python.org  Sun Aug  2 23:42:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Aug 2015 21:42:07 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1438551727.61.0.578452277412.issue22227@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good and passes tests.  Go ahead and apply.

----------
assignee: lars.gustaebel -> serhiy.storchaka
nosy: +rhettinger

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

From report at bugs.python.org  Sun Aug  2 23:57:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 21:57:45 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438552665.3.0.74997192347.issue24781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I find the new arrangement more confusing.

----------

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

From report at bugs.python.org  Mon Aug  3 00:11:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Aug 2015 22:11:08 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438553468.44.0.759368363285.issue24781@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would make theme element chooser a list box and move the sample to the right.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Mon Aug  3 00:24:00 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 22:24:00 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1438554240.23.0.149603594144.issue23524@psf.upfronthosting.co.za>


Robert Collins added the comment:

Looks committed a way back to me.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Aug  3 00:27:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 22:27:44 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment, ?query,
 //netloc
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1438554464.17.0.738554470268.issue22852@psf.upfronthosting.co.za>


Robert Collins added the comment:

See also issue 6631

----------
nosy: +rbcollins

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

From report at bugs.python.org  Mon Aug  3 00:31:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Aug 2015 22:31:07 +0000
Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs
In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za>
Message-ID: <1438554667.58.0.635538033991.issue23218@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

These changes all seem reasonable and have a nice look.
I have misgivings about shortening "regular expression" to "regex".
Otherwise, +1 for everything else.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Mon Aug  3 00:31:36 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 22:31:36 +0000
Subject: [issue6631] Disallow relative files paths in urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1438554696.01.0.976882488168.issue6631@psf.upfronthosting.co.za>


Robert Collins added the comment:

test_relativelocalfile is still in place in the urllib tests, so its affecting urlopen to this point.

So I think the bug is fixed at least to the extent of the original report. I'm going to close this.

----------
nosy: +rbcollins
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Aug  3 00:39:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Aug 2015 22:39:30 +0000
Subject: [issue22397] test_socket failure on AIX
In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za>
Message-ID: <20150802223927.53971.8283@psf.io>


Roundup Robot added the comment:

New changeset e48826904e63 by Robert Collins in branch '3.4':
Issue #22397: Skip failing tests on AIX
https://hg.python.org/cpython/rev/e48826904e63

New changeset a12d29f87e4c by Robert Collins in branch '3.5':
Issue #22397: Skip failing tests on AIX
https://hg.python.org/cpython/rev/a12d29f87e4c

New changeset 62235755609f by Robert Collins in branch 'default':
Issue #22397: Skip failing tests on AIX
https://hg.python.org/cpython/rev/62235755609f

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  3 00:41:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 22:41:42 +0000
Subject: [issue22397] test_socket failure on AIX
In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za>
Message-ID: <1438555302.59.0.14904025644.issue22397@psf.upfronthosting.co.za>


Robert Collins added the comment:

I've updated the ref in the patch to this bug per Victor's comments, and applied.

I'm not sure of protocol here. Do we close this ticket, or keep it open to analyze the actual cause?

----------
nosy: +rbcollins

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

From report at bugs.python.org  Mon Aug  3 00:46:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 02 Aug 2015 22:46:30 +0000
Subject: [issue22397] test_socket not running all tests on AIX
In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za>
Message-ID: <1438555590.53.0.528745021388.issue22397@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: commit review -> needs patch
title: test_socket failure on AIX -> test_socket not running all tests on AIX

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

From report at bugs.python.org  Mon Aug  3 00:52:08 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 22:52:08 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438555928.12.0.111929556159.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

One of the other options I was playing with previously was a listbox for choosing the theme (what I'd suspect is the main user activity here).

----------
Added file: http://bugs.python.org/file40110/cfg_highlight_alt.png

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

From report at bugs.python.org  Mon Aug  3 01:16:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 23:16:01 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438557361.48.0.832403992555.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

cfg_highlight_alt.png shows with the listbox for choosing a theme

Also added highlight3.png... same kind of thing, but by renaming the tab as 'Themes' you no longer even need the row of labels at the top. And it parallels the fonts/tabs design suggestion somewhat too.

----------
Added file: http://bugs.python.org/file40111/highlight3.png

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

From report at bugs.python.org  Mon Aug  3 01:19:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 23:19:25 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1438557565.91.0.726150073459.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In general, Idle-sig is a better place to ask question ;-).  I applied the extension dialog patch just a year ago (#3068), It still needs improvements (#22704, #22705, #22706, #22707 #22726). Before that, people had to hand-edit either the idlelib or user version. So I applied the patch when clearly usable, and did not worry about making it 'perfect' first. 

Part of the answer to why separate dialogs is related to there being a) a separate config file (but the other dialog handles the other three) and probably more importantly, b) the set of extension being extensible, both by us and by users.

This all said, I dislike the jumbled stacked tabs. Also, the entry space is wider than needed for any of our extensions. So whether the dialogs are consolidated or not, I like the idea of three columns: alphabetical list of extensions (all visible unless a user adds a large number), option names, and value entry. I would like to see a patch for this first.  I would not mind patches for some of the issue above right after. I would like to improve this box before using ttk.

The Idle dialog has room for an Extensions tab without stacking.  I would like to see a separate, later patch for consolidation.

----------
nosy: +taleinat
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Aug  3 01:54:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Aug 2015 23:54:21 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438559661.42.0.657808019679.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Keep in mind that most option substitution would be at the file rather than widget level.  The scrollbar switching would be for something like editor windows, which are basically generic.  For the option dialog, we would copy ConfigDialog.py to, say, configuration.py, adjust the imports, and convert to ttk (and pep8, as we wish).  Then use_ttk would be used for choosing which file's ConfigDialog to bind to the Configure IDLE menu item.

----------

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

From report at bugs.python.org  Mon Aug  3 02:30:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Aug 2015 00:30:33 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438561833.37.0.345225785775.issue24781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

After I added a custom Terry theme, my main activity has been tweaking it. Version 3 is an clear improvement over the existing tab.  With the example box on top, I think the comment should be
# Click here or dropbox
# below to change item.

0 Foregound 0 Background are supposed to be radio buttons.  The black and white squares look like anything but.

'Theme' is ambiguous as to Idle's text highlighting themes versus ttk's widget style themes. I think the current grouping should be labeled 'Text Highlighting'.  This will pave the way to add, to the ttk version, a 'Widget Style' listbox allowing users to choose among those available.

With these items resolved, I would be inclined to apply a tk patch to all versions.

----------

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

From report at bugs.python.org  Mon Aug  3 02:31:57 2015
From: report at bugs.python.org (David E. Narvaez)
Date: Mon, 03 Aug 2015 00:31:57 +0000
Subject: [issue24783] Import Error (undefined symbol: PyFloat_Type) when
 Importing math Module on Shared Build
Message-ID: <1438561917.37.0.601266500098.issue24783@psf.upfronthosting.co.za>


New submission from David E. Narvaez:

The original bug report can be found at https://bugs.kde.org/show_bug.cgi?id=335965. I was not able to reproduce this on Gentoo until the Fedora maintainer commented they build their Python with --enable-shared. At that point, I built two copies of Python 2.7 from git, one with defaults and one with --enable-shared. When I run the application with PYTHONHOME=/path/to/defualt/install it runs correctly, and when I run the application with PYTHONHOME=/path/to/shared/install I can reproduce the bug.

Is there something missing in the linking of this application in order for it to use a Python installation built with --enable-shared?

----------
components: Installation
messages: 247915
nosy: david-narvaez
priority: normal
severity: normal
status: open
title: Import Error (undefined symbol: PyFloat_Type) when Importing math Module on Shared Build
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  3 02:41:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 03 Aug 2015 00:41:45 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1438562505.77.0.971798295306.issue6500@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a patch for 2.7. I don't think backporting 9eceb618274a to 2.7  is worth the effort for this, so I just fixed the __getattr__ method and added a test.

----------
keywords: +patch
nosy: +berker.peksag
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40112/issue6500.diff

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

From report at bugs.python.org  Mon Aug  3 05:28:19 2015
From: report at bugs.python.org (Ashley Anderson)
Date: Mon, 03 Aug 2015 03:28:19 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1438572499.88.0.544611504748.issue12006@psf.upfronthosting.co.za>


Ashley Anderson added the comment:

Thanks for the review and the good suggestions. Hopefully this new patch is an improvement.

I didn't know about the context manager for assertRaises - I was just following the format for another ValueError test a few lines above.

The frozenset and re-wrapped comment were left from playing around with another way to do the checks, and I've corrected them.

I think the conditionals around calculating the julian and year are clearer now as well.

Please (obviously) let me know if there are further changes. Also please let me know if this is not the proper way to respond to the code review!

----------
Added file: http://bugs.python.org/file40113/issue12006_8_complete.patch

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

From report at bugs.python.org  Mon Aug  3 06:16:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Aug 2015 04:16:54 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438575414.72.0.625620486835.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The problem with astral chars and open/save dialogs is the subject of #21084. The problem with printing astral chars generated by programs is #22742 and maybe #21084.  I added a fix for the very new display of filenames on the run separator bar, which is the problem discovered above.

----------

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

From report at bugs.python.org  Mon Aug  3 09:05:13 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 03 Aug 2015 07:05:13 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za>
Message-ID: <1438585513.63.0.68090674101.issue23996@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The fix wasn't applied yet, so the current code in 3.4 and later branches is still incorrect. Any of the last two patches ("*_value") will fix it, with my preference on the last one.

----------
versions: +Python 3.6

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

From report at bugs.python.org  Mon Aug  3 10:13:11 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Aug 2015 08:13:11 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za>
Message-ID: <1438589591.77.0.279262150719.issue23996@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola, gvanrossum, haypo

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

From report at bugs.python.org  Mon Aug  3 10:30:03 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Mon, 03 Aug 2015 08:30:03 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1438590603.76.0.903553143287.issue20362@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

* The removal of the 'kot' test is ok. That's what the fix is about. With longMessage set to False, we should only see the custom message, 'Message', and not the message about the regex that contains 'kot'.
* Please update the patch for 3.5 to use assertRegex and assertNotRegex in the assertMessages call. These are the new names. With the current patch, the tests throw deprecation warnings.

Other than that the patch looks good (I am not a committer, though, so I can't help further).

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Mon Aug  3 11:06:58 2015
From: report at bugs.python.org (Louis Dassy)
Date: Mon, 03 Aug 2015 09:06:58 +0000
Subject: [issue24784] Build fails --without-threads
Message-ID: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>


New submission from Louis Dassy:

Build of default branch fails using --without-threads. I added the WITH_THREAD check around PyGILState_Check

----------
components: Build
files: without-threads.patch
keywords: patch
messages: 247921
nosy: berker.peksag, louis.dassy, python-dev
priority: normal
severity: normal
status: open
title: Build fails --without-threads
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file40114/without-threads.patch

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

From report at bugs.python.org  Mon Aug  3 11:35:52 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 03 Aug 2015 09:35:52 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1438594552.12.0.268569407462.issue20362@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Sorry for my late response, Ilia. Your reply to my first question looks correct to me. Please send your updated patch and I'll apply.

----------
assignee:  -> berker.peksag
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Mon Aug  3 11:44:49 2015
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 03 Aug 2015 09:44:49 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438595089.22.0.509107620677.issue24272@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Mon Aug  3 13:36:02 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 03 Aug 2015 11:36:02 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438601762.18.0.625688689972.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

+1. It was specifically SQLAlchemy (but not limited to it -- there are many other blocking APIs) that made me look for a way to easily use threads with native coroutines.

The best workaround I've come up with:

from asyncio import wrap_future

async def foo():
    await wrap_future(executor.submit(...))

But as I mentioned before, wrap_future() is nowhere to be found in the asyncio docs.

----------

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

From report at bugs.python.org  Mon Aug  3 13:44:43 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 03 Aug 2015 11:44:43 +0000
Subject: [issue24785] Document asyncio.futures.wrap_future()
Message-ID: <1438602283.27.0.137322848878.issue24785@psf.upfronthosting.co.za>


New submission from Alex Gr?nholm:

Since Python 3.5 will not support awaiting for concurrent.futures.Futures natively, one has to use the asyncio.futures.wrap_future() function in coroutines like this:

async def foo():
    await wrap_future(executor.submit(...))

The wrap_future() function is, however, not mentioned in the asyncio documentation. It should be, in order for the standard library to provide the above crutch until proper support arrives in 3.6.

----------
assignee: docs at python
components: Documentation
messages: 247924
nosy: alex.gronholm, docs at python
priority: normal
severity: normal
status: open
title: Document asyncio.futures.wrap_future()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug  3 13:45:37 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 03 Aug 2015 11:45:37 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438602337.29.0.407279237301.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Created issue 24785 for the documentation of wrap_future().

----------

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

From report at bugs.python.org  Mon Aug  3 14:04:02 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 03 Aug 2015 12:04:02 +0000
Subject: [issue24785] Document asyncio.futures.wrap_future()
In-Reply-To: <1438602283.27.0.137322848878.issue24785@psf.upfronthosting.co.za>
Message-ID: <1438603442.88.0.235969192647.issue24785@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 24755.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> asyncio.wrap_future undocumented

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

From report at bugs.python.org  Mon Aug  3 14:31:27 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 03 Aug 2015 12:31:27 +0000
Subject: [issue24785] Document asyncio.futures.wrap_future()
In-Reply-To: <1438602283.27.0.137322848878.issue24785@psf.upfronthosting.co.za>
Message-ID: <1438605087.55.0.523858555366.issue24785@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Mon Aug  3 14:31:39 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 03 Aug 2015 12:31:39 +0000
Subject: [issue24755] asyncio.wrap_future undocumented
In-Reply-To: <1438250618.09.0.00442439827356.issue24755@psf.upfronthosting.co.za>
Message-ID: <1438605099.97.0.624241325435.issue24755@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Mon Aug  3 15:14:59 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 03 Aug 2015 13:14:59 +0000
Subject: [issue24755] asyncio.wrap_future undocumented
In-Reply-To: <1438250618.09.0.00442439827356.issue24755@psf.upfronthosting.co.za>
Message-ID: <1438607699.36.0.725380231623.issue24755@psf.upfronthosting.co.za>


Changes by Alex Gr?nholm <alex.gronholm+python at nextday.fi>:


----------
nosy: +alex.gronholm

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

From report at bugs.python.org  Mon Aug  3 16:52:16 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Aug 2015 14:52:16 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1438589591.81.0.0337244274043.issue23996@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLG1jHrgqMYnwjeZ8C0DdAXsEqYR1O=iz-2GhnNFfGVLQ@mail.gmail.com>


Guido van Rossum added the comment:

Please try to make sure this is fixed before 3.5 rc 1.

----------

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

From report at bugs.python.org  Mon Aug  3 17:03:11 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Aug 2015 15:03:11 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438602337.29.0.407279237301.issue24383@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKpiMB9f6H4uWJPGKtkMzRyjiqXH_1HS_9KKZKztXSxAg@mail.gmail.com>


Guido van Rossum added the comment:

Every individual use case can be dealt with easily by adding simple helper
functions. I really want to keep async and threads separate. And it's no
coincidence that concurrent.futures is threadsafe; that's part of its spec.

----------

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

From report at bugs.python.org  Mon Aug  3 17:07:04 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 03 Aug 2015 15:07:04 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za>
Message-ID: <1438614424.92.0.467892055404.issue23996@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Any of the last two patches ("*_value") will fix it, with my preference on the last one.

Stefan, the last patch looks good to me.  Do you think we can have a unittest for this?

----------

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

From report at bugs.python.org  Mon Aug  3 18:06:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Aug 2015 16:06:57 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za>
Message-ID: <1438618017.57.0.812827497469.issue23996@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide tests covering all branches (normalized exception, unnormalized exception, absent value, non-tuple value, empty tuple value, non-empty tuple value...) Stefan?

----------
nosy: +serhiy.storchaka
stage: patch review -> test needed

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

From report at bugs.python.org  Mon Aug  3 18:11:56 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Mon, 03 Aug 2015 16:11:56 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438618316.47.0.992301652464.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Why do you want to keep threads separate from asyncio? What's the downside here?
The use of helper functions is justifiable when integrating a third party framework or similar with asyncio, but standard library components should just integrate well with each other. Requiring boilerplate wrappers for such use seems unreasonable to me.

----------

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

From report at bugs.python.org  Mon Aug  3 18:13:45 2015
From: report at bugs.python.org (Ilia Kurenkov)
Date: Mon, 03 Aug 2015 16:13:45 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1438618425.62.0.439908087166.issue20362@psf.upfronthosting.co.za>


Ilia Kurenkov added the comment:

Thanks for the feedback, folks. Adding the updated patch.

----------
Added file: http://bugs.python.org/file40115/20362_py35.patch

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

From report at bugs.python.org  Mon Aug  3 18:19:14 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 03 Aug 2015 16:19:14 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1438618754.53.0.274679480049.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

The squares next to foreground/background are placeholders for those controls I can't remember what they're called (colour wells?) where it shows the current colour, and clicking it brings up a colour picker allowing you to change. So separate ones for foreground/background rather than a radio button to say what you'll set and then a button to set it. Sorry for the confusion.

Any reason that you'd want to actually include a choice of ttk themes? Not sure that would really add anything positive to the overall UX (especially on Mac and Windows).

Worth discussing more about the name 'theme' (which seems to be common in other code editors) vs. 'text highlighting' vs. other alternatives.

Btw, is there a way to change the background colour and/or has that topic come up before?

----------

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

From report at bugs.python.org  Mon Aug  3 18:28:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 16:28:01 +0000
Subject: [issue24740] make patchcheck doesn't detect changes if commit is done
 first
In-Reply-To: <1438056026.2.0.092826443421.issue24740@psf.upfronthosting.co.za>
Message-ID: <1438619281.02.0.335190391037.issue24740@psf.upfronthosting.co.za>


R. David Murray added the comment:

You can install the same (patchcheck-equivalent) hooks the repo uses in your local repo.  If this is not documented in the devguide it should be.  The hooks are publicly available (hg.python.org/hooks).  (It has been so long since I set this up for myself that I don't remember the steps precisely, but I'm sure I could figure it out by looking at my setup if someone needs the info.)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Aug  3 18:28:09 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Aug 2015 16:28:09 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1438618316.47.0.992301652464.issue24383@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLeS3hWXLuZqim4XVSennHQMsGno1cDA+wFW8u00FPkRQ@mail.gmail.com>


Guido van Rossum added the comment:

Sorry, there's no space in this issue for an answer.

----------

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

From report at bugs.python.org  Mon Aug  3 18:40:32 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 03 Aug 2015 16:40:32 +0000
Subject: [issue24754] argparse add_argument with action="store_true",
 type=bool should not crash
In-Reply-To: <1438250218.94.0.699008040775.issue24754@psf.upfronthosting.co.za>
Message-ID: <1438620032.07.0.389469232733.issue24754@psf.upfronthosting.co.za>


paul j3 added the comment:

Right, the only arguments that a `store_true` Action class accepts are:

     option_strings, dest, default=False,required=False, help=None

parser.add_argument() massages its parameters a bit, and then uses the 'action' parameter to construct an Action subclass object with the other parameters.  Depending on their needs the subclasses may set various defaults or omit certain parameters. And without a catchall '**kwargs', the result of providing an omitted parameter is this error message.

For 'store_true', a 'type' parameter is superfluous.  It doesn't take any arguments (it sets 'nargs=0'), so there aren't any arguments to convert with the 'type' function.  It's the Action's own 'default' and 'const' that provide the required False and True values.

Also 'bool' is not a meaningful 'type' - for any Action class.  There isn't a function in Python converts a string to a boolean.  'bool()' does not do this.  Or rather, `bool(astr)' converts every string to True except the empty one.

I've seen this mistake before, assuming that 'type=bool' means 'I want the result to be a boolean'.  But the docs do say 

    type= can take any callable that takes a single string argument and returns the converted value:

'type=float' means 'use float(astr) to convert astr', not 'the argument should be a float'.

The documentation is not clear about what parameters are valid for each Action type.  It indicates, in bits and pieces, that some parameters are meaningful for certain actions, and not useful for others.  One (version) even takes a parameter that others don't.  But I haven't seen many bugs - here or on StackOverflow - where this is an issue.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Mon Aug  3 18:48:27 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 03 Aug 2015 16:48:27 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1438618017.57.0.812827497469.issue23996@psf.upfronthosting.co.za>
Message-ID: <55BF9B55.4090405@behnel.de>


Stefan Behnel added the comment:

Regarding tests, it looks like iteration isn't currently tested at the C
level at all. At least, the xx test modules don't have any types that use
it. I can write one up next week, or add it to one of the existing types
(Xxo_Type?). Unlikely that I'll make the deadline for rc1 next weekend, though.

----------

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

From report at bugs.python.org  Mon Aug  3 19:03:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 17:03:08 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438621388.49.0.129090972248.issue24129@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your ping after a month is very appropriate.  It looks like yes, this is waiting for another review.  Based on the fact that the previous patches were reviewed by core devs and you have responded, I'm moving it to 'commit review', but I haven't looked at the patch myself.

----------
stage:  -> commit review
versions: +Python 3.6

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

From report at bugs.python.org  Mon Aug  3 19:03:35 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 03 Aug 2015 17:03:35 +0000
Subject: [issue24739] allow argparse.FileType to accept newline argument
In-Reply-To: <1438049324.32.0.674993969885.issue24739@psf.upfronthosting.co.za>
Message-ID: <1438621415.27.0.556448044451.issue24739@psf.upfronthosting.co.za>


paul j3 added the comment:

argparse.FileType serves 2 purposes

- handling filenames for simple quick shell-like scripts

- as a model for custom 'types', specifically one that uses a class to generate the desired type callable.

Other bug-issues show that it hasn't aged well.  It doesn't work nicely with the newer open/close context paradigm.  It needs changes to handle 'rb' and 'wb' modes.

I suppose it could be modified to accept the full range of parameters that the modern 'open' takes:

    open(file, mode='r', buffering=-1, encoding=None,
        errors=None, newline=None, closefd=True, opener=None) 

either explicitly, or as a pass through **kwargs.

But it is also something that you could easily subclass or modify for your own purposes.

Or just accept the filenames as strings, and do your own open/close after parsing.  This gives you more control over when and how the files are opened.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Mon Aug  3 19:12:44 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 03 Aug 2015 17:12:44 +0000
Subject: [issue24736] argparse add_mutually_exclusive_group do not print help
In-Reply-To: <1438001526.73.0.776043102355.issue24736@psf.upfronthosting.co.za>
Message-ID: <1438621964.23.0.618114096744.issue24736@psf.upfronthosting.co.za>


paul j3 added the comment:

These two types of groups serve different purposes and aren't designed to nest or interact.

An argument group groups arguments in the help lines.  It does not affect parsing at all.  It can't be used to add a 'group' of arguments to another group.

A mutually exclusive group produces an error message during parsing, and modifies the usage line.  There isn't a way, in the current code, to nest groups of arguments (in some sort of 'any' or 'and' sense) within a mutually exclusive group.  It's 'xor' for all arguments.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Mon Aug  3 19:13:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Aug 2015 17:13:48 +0000
Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised
 exceptions
In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za>
Message-ID: <1438622028.6.0.764214300426.issue23996@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is it possible to test from Python level?

----------

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

From report at bugs.python.org  Mon Aug  3 19:31:42 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 03 Aug 2015 17:31:42 +0000
Subject: [issue24647] Document argparse.REMAINDER as being equal to "..."
In-Reply-To: <1437079645.1.0.921184801927.issue24647@psf.upfronthosting.co.za>
Message-ID: <1438623102.25.0.1987081501.issue24647@psf.upfronthosting.co.za>


paul j3 added the comment:

Also, argparse.PARSER  is '+...'

'? * +' have closely matched analogs in regex patterns.  '...' and '+...' do not.  So Python users will have an intuitive idea of what "nargs='*'" means.  "nargs='...'" is not so obvious.

As a general rule, the document does not expose the values of module constants.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Mon Aug  3 20:18:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 18:18:48 +0000
Subject: [issue24775] Python client failing to connect to server but
 completing as if successful
In-Reply-To: <1438462060.51.0.501017266126.issue24775@psf.upfronthosting.co.za>
Message-ID: <1438625928.39.0.0683288038567.issue24775@psf.upfronthosting.co.za>


R. David Murray added the comment:

If whatever change fixed this has not already been backported to 2.7, it is likely that whatever it was was deemed to complex for backport.  If someone can figure out what the fix was and propose a reasonable way to back port it, we would most likely do so.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Aug  3 20:44:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 18:44:10 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438627450.99.0.873703919599.issue24778@psf.upfronthosting.co.za>


R. David Murray added the comment:

In this case os.system is an appropriate API, because it mirrors the API of mailcap itself (that is, mailcap entries are shell commands).  

I'm not convinced there is a security bug here.  It seems to me that there are two cases: either the filename is determined by the program, in which case there is no security issue, or the filename comes from an external source, and the program will have had to *write it to the file system* before the mailcap command will do anything.  So the security hole, if any, will have happened earlier in the process.

Now, one can argue that the quoting should be done in order to preserve the meaning of an arbitrary filename.  Which would allay your concern even if I disagree that it is a real security bug :)

(I don't understand why run-mailcap uses an alias rather than correctly quoting the meta-characters.)

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Aug  3 21:06:39 2015
From: report at bugs.python.org (Paul Anton Letnes)
Date: Mon, 03 Aug 2015 19:06:39 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1438628799.81.0.729149716787.issue10708@psf.upfronthosting.co.za>


Paul Anton Letnes added the comment:

I believe someone should also commit the following command:
hg rm Misc/porting
in the main python repository, since the contents of this file are now found in the devguide.

----------

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

From report at bugs.python.org  Mon Aug  3 21:27:35 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Mon, 03 Aug 2015 19:27:35 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438630055.26.0.630995114057.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

@David
Thanks for the comment :-)

I think if you read the Documentation 
https://docs.python.org/2/library/mailcap.html
this may lead new programmers, wich may never heard of Shell Injections before, step by step directly to write insecure webbbrowsers and/or mail readers. At least there should be a warning in the docs !
   
You ask why run-mailcap do not use quotig, i believe because quoting is not an easy thing to do, i attached a demo ;-)

Thank you.

----------
Added file: http://bugs.python.org/file40116/The Quote Problem.py

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

From report at bugs.python.org  Mon Aug  3 21:44:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 19:44:13 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1438631053.89.0.532793586452.issue24780@psf.upfronthosting.co.za>


R. David Murray added the comment:

In this particular case the problem is the lack of a trailing newline on the input string.  It might be possible to improve the extended display algorithm by making sure there is a new line before the carrot line, but care must be taken to account for the cases where one string ends with newline and the other doesn't.  I think this problem only applies to strings that have no trailing newline.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Aug  3 21:46:13 2015
From: report at bugs.python.org (Alessandro Cucci)
Date: Mon, 03 Aug 2015 19:46:13 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1438631173.72.0.727435897632.issue19475@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

uploaded a new patch!

----------
Added file: http://bugs.python.org/file40117/issue19475_v3.patch

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

From report at bugs.python.org  Mon Aug  3 22:05:37 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 03 Aug 2015 20:05:37 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1438632337.89.0.0904849769086.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I've attached extdlg.patch, which changes the UI for the configure extensions dialog. 

In particular, it replaces the stacked tabs with a listbox on the left, with the details of each extension appearing in a labelframe on the right. The inside of the labelframe gets swapped in with pretty much the same thing that was in the dialog before.

This should be compatible with Tk 8.4, as ttk was not used.

----------
keywords: +patch
Added file: http://bugs.python.org/file40118/extdlg.patch

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

From report at bugs.python.org  Mon Aug  3 22:08:22 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 03 Aug 2015 20:08:22 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1438632502.89.0.105891646957.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Screenshot extdlg.png shows result

----------
Added file: http://bugs.python.org/file40119/extdlg.png

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

From report at bugs.python.org  Mon Aug  3 22:31:07 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Mon, 03 Aug 2015 20:31:07 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438633867.89.0.079701256005.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

Exploid Demo wich works with quote() : 

>>> commandline,MIMETYPE=mailcap.findmatch(d, 'text/*', filename=quote(';xterm;#.txt'))
>>> commandline
"less '';xterm;#.txt''"
>>> os.system(commandline)
### xterm starts

----------

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

From report at bugs.python.org  Mon Aug  3 22:31:26 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Aug 2015 20:31:26 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438633886.64.0.162160610591.issue24272@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thank you Ivan! I am going to commit this, it's much better than the two lines we had before. :-) There's still a lot of work left to do -- towards the end there are many classes without description. Maybe you and Daniel can divide up the work for those? We can always iterate (even during the release candidates and even after the 3.5.0 release).

----------

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

From report at bugs.python.org  Mon Aug  3 22:57:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Aug 2015 20:57:38 +0000
Subject: [issue22397] test_socket failure on AIX
In-Reply-To: <1438555302.59.0.14904025644.issue22397@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZeOqzRsJD72EFb-0konzQcAZ+PK86zCBtwGt7BAYGjFw@mail.gmail.com>


STINNER Victor added the comment:

I'm not interested to investigate the issue on AIX. IMHO the feature is
just not supported by the kernel so there is nothing to investigate except
if you want to hack AIX kernel.

----------
title: test_socket not running all tests on AIX -> test_socket failure on AIX

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

From report at bugs.python.org  Mon Aug  3 23:00:31 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 21:00:31 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438635631.25.0.959248768071.issue23725@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
versions: +Python 3.6

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

From report at bugs.python.org  Mon Aug  3 23:11:07 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 21:11:07 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438636267.34.0.976267685185.issue23725@psf.upfronthosting.co.za>


Robert Collins added the comment:

I'm not 100% sure that tempfile.tempdir should be deprecated. Its much less convenient to control global behaviour with that. I agree that mktemp should be.

I've updated the patch though.

----------
nosy: +rbcollins
Added file: http://bugs.python.org/file40120/issue-23725.patch

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

From report at bugs.python.org  Mon Aug  3 23:12:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 21:12:30 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1438636350.39.0.936922927357.issue20180@psf.upfronthosting.co.za>


Robert Collins added the comment:

So I'm confused. Is this applicable or not? Its in commit review, but there's discussion of politics here :(.

----------
nosy: +rbcollins
status: open -> pending

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

From report at bugs.python.org  Mon Aug  3 23:16:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 21:16:56 +0000
Subject: [issue22397] test_socket failure on AIX
In-Reply-To: <1410547453.79.0.287492326275.issue22397@psf.upfronthosting.co.za>
Message-ID: <1438636616.95.0.616107269139.issue22397@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 00:02:08 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 22:02:08 +0000
Subject: [issue23888] Fixing fractional expiry time bug in cookiejar
In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za>
Message-ID: <1438639328.29.0.762780420172.issue23888@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Tue Aug  4 00:07:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 03 Aug 2015 22:07:58 +0000
Subject: [issue23888] Fixing fractional expiry time bug in cookiejar
In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za>
Message-ID: <20150803220755.53977.88685@psf.io>


Roundup Robot added the comment:

New changeset 1c1c508d1b98 by Robert Collins in branch '3.4':
Issue #23888: Handle fractional time in cookie expiry. Patch by ssh.
https://hg.python.org/cpython/rev/1c1c508d1b98

New changeset 06406205ae99 by Robert Collins in branch '3.5':
Issue #23888: Handle fractional time in cookie expiry. Patch by ssh.
https://hg.python.org/cpython/rev/06406205ae99

New changeset 73902903d397 by Robert Collins in branch 'default':
Issue #23888: Handle fractional time in cookie expiry. Patch by ssh.
https://hg.python.org/cpython/rev/73902903d397

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  4 00:11:50 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 22:11:50 +0000
Subject: [issue23888] Fixing fractional expiry time bug in cookiejar
In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za>
Message-ID: <1438639910.33.0.366698141912.issue23888@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 00:11:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Aug 2015 22:11:54 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438639914.48.0.63156180462.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, something is wrong, because if we are deprecating :data:`tmpdir` we shouldn't be cross referencing it from the non-deprecated docs.  The explanation of how the default value is calculated should be moved up to gettmpdir.

My understanding is that now that all functions accept a 'dir' parameter, the tmpdir global was deprecated because global state is bad, and if an application really wants to affect the global state it can use the one of the environment variables that are checked, which is more flexible.

----------

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

From report at bugs.python.org  Tue Aug  4 00:17:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Aug 2015 22:17:44 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438640264.33.0.463421670436.issue23725@psf.upfronthosting.co.za>


Robert Collins added the comment:

I can't find any reference to a discussion to deprecate tempdir outside of this issue. Nothing on python-dev/python-ideas/peps.

I can see that there's an argument that it should be deprecated, but AFAICT the idea to do so originated here. I'd like to see wider discussion though (because I don't think it makes sense to deprecate it) - its no more or less global than environment variables, its already here as a feature, and its not going to save us code maintenance or bugs if we do deprecate it - and if we are deprecating it, we should be issueing a PendingDeprecation warning at minimum.

How about we change the patch to not deprecate it, and either open a new ticket, or let folk that want to deprecate it raise that on the list?

----------

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

From report at bugs.python.org  Tue Aug  4 00:21:27 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 03 Aug 2015 22:21:27 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438640487.85.0.631400300695.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

It's looking like the problem is in _odict_add_new_node.  If that's the case then I should be able to resolve this issue soon.

----------

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

From report at bugs.python.org  Tue Aug  4 00:28:07 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 03 Aug 2015 22:28:07 +0000
Subject: [issue24786] Changes in the devguide repository are not published
 online in HTML
Message-ID: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

I change content and configuration in the devguide repository and I don't see the changes available in HTML in <https://docs.python.org/devguide/> even after some days.

----------
assignee: docs at python
components: Documentation
messages: 247961
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: Changes in the devguide repository are not published online in HTML

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

From report at bugs.python.org  Tue Aug  4 00:35:22 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Mon, 03 Aug 2015 22:35:22 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438641322.94.0.598719265133.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

I don't think tempdir should be removed. I just think it should not be used. So what about moving the description of tempdir to the end, as it was in the last patch, but calling the section "Other functions and variables".

----------

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

From report at bugs.python.org  Tue Aug  4 00:45:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 03 Aug 2015 22:45:36 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <20150803224534.41839.14940@psf.io>


Roundup Robot added the comment:

New changeset 0511b1165bb6 by Terry Jan Reedy in branch '2.7':
Issue #24759: Revert 8203fc75b3d2.
https://hg.python.org/cpython/rev/0511b1165bb6

New changeset 06852194f541 by Terry Jan Reedy in branch '3.4':
Issue #24759: Revert 13a8782a775e.
https://hg.python.org/cpython/rev/06852194f541

New changeset 863e3cdbbabe by Terry Jan Reedy in branch '3.5':
Issue #24759: Merge with 3.4
https://hg.python.org/cpython/rev/863e3cdbbabe

New changeset 3bcb184b62f8 by Terry Jan Reedy in branch 'default':
Issue #24759: Merge with 3.5
https://hg.python.org/cpython/rev/3bcb184b62f8

----------

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

From report at bugs.python.org  Tue Aug  4 01:06:50 2015
From: report at bugs.python.org (Douglas Bagnall)
Date: Mon, 03 Aug 2015 23:06:50 +0000
Subject: [issue24754] argparse add_argument with action="store_true",
 type=bool should not crash
In-Reply-To: <1438250218.94.0.699008040775.issue24754@psf.upfronthosting.co.za>
Message-ID: <1438643210.38.0.734201537877.issue24754@psf.upfronthosting.co.za>


Douglas Bagnall added the comment:

Thanks paul.j3 and r.david.murray,

I see your points.

What led me to this was automatically generating command line options from a Gstreamer element, mapping
the Gstreamer property types to Python types. Then I special-cased the action="store_true" for the boolean ones and was surprised by the somewhat unclear error message.

As you suggest, paul.j3, "type" is in some ways an unfortunate choice of keyword for this, but it too late to change that.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 01:22:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 03 Aug 2015 23:22:44 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <20150803232241.111049.28594@psf.io>


Roundup Robot added the comment:

New changeset e9f91d47c8ab by Steve Dower in branch '3.5':
Issue #24771: Adds vcruntime DLL to tcltk package
https://hg.python.org/cpython/rev/e9f91d47c8ab

New changeset 14dee84ab900 by Steve Dower in branch 'default':
Issue #24771: Adds vcruntime DLL to tcltk package
https://hg.python.org/cpython/rev/14dee84ab900

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  4 01:25:49 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 03 Aug 2015 23:25:49 +0000
Subject: [issue24771] Cannot import _tkinter in Python 3.5 on Windows
In-Reply-To: <1438419682.41.0.973559633469.issue24771@psf.upfronthosting.co.za>
Message-ID: <1438644349.69.0.256628220784.issue24771@psf.upfronthosting.co.za>


Steve Dower added the comment:

Rather than change the tcl and tk project files (which is not as easy as updating the Python projects - I spent an hour trying), I've added the vcruntime DLL to the MSI with tkinter.

Distutils has already been updated to not include it any more, and I really want to avoid having people depend on it since it could break the nice compatibility we have going now, but there's no easy way around it right now.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 02:05:57 2015
From: report at bugs.python.org (Tiago Wright)
Date: Tue, 04 Aug 2015 00:05:57 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
Message-ID: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>


New submission from Tiago Wright:

csv.Sniffer().sniff() guesses "M" for the delimiter of the first dataset below. The same error occurs when the "," is replaced by "\t". However, it correctly guesses "," for the second dataset.

---Dataset 1----
Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
Sscanner ac15072911220.pdf,CM_15203,28714.32,MX Jan Feb,948198,,
Sscanner ac15072911221.pdf,CM 16148,15600,MX Unkwon,948199,,
Sscanner ac15072911230.pdf,CM 16148,33488,MX Cavalier,948200,Photos don't match the invoice
Sscanner ac15072911261.pdf,CM_14464,1713.6,MX Dutiful,948203,,
Sscanner ac15072911262.pdf,CM 16148,3114,MX Apr,948202,,
Sscanner ac15072911250.pdf,CM_14464,1232.28,MX Jan Feb,948208,,
Sscanner ac15072911251.pdf,CM_17491,15232,MX Unkwon,948207,,
Sscanner ac15072911253.pdf,CM_14464,11250,MX Cavalier,,,
Sscanner ac15072911253.pdf,CM_14464,11250,MX Dutiful,,,
Sscanner ac15072911253.pdf,CM_14464,11250,MX Apr,,,

--- Dataset 2---
Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
Sscanner ac15072911220.pdf,CM_15203,82.07,MX Jan Feb,948198,,
Sscanner ac15072911221.pdf,CM 16148,23.29,MX Unkwon,948199,,
Sscanner ac15072911230.pdf,CM 16148,88.55,MX Cavalier,948200,Photos don't match the invoice,
Sscanner ac15072911261.pdf,CM_14464,58.78,MX Dutiful,948203,,
Sscanner ac15072911262.pdf,CM 16148,52,MX Apr,948202,,
Sscanner ac15072911250.pdf,CM_14464,40.40,MX Jan Feb,948208,,
Sscanner ac15072911251.pdf,CM_17491,54.97,MX Unkwon,948207,,
Sscanner ac15072911253.pdf,CM_14464,4.08,MX Cavalier,,,
Sscanner ac15072911253.pdf,CM_14464,49.11,MX Dutiful,,,
Sscanner ac15072911253.pdf,CM_14464,18.28,MX Apr,,,

----------
components: Extension Modules
messages: 247967
nosy: Tiago Wright
priority: normal
severity: normal
status: open
title: csv.Sniffer guesses "M" instead of \t or , as the delimiter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  4 02:20:26 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Aug 2015 00:20:26 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438647626.1.0.753782839054.issue23725@psf.upfronthosting.co.za>


Robert Collins added the comment:

mktemp is clearly insecure. I'd just move the tmpdir up above the Deprecation section start

----------

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

From report at bugs.python.org  Tue Aug  4 02:25:52 2015
From: report at bugs.python.org (Peter Lovett)
Date: Tue, 04 Aug 2015 00:25:52 +0000
Subject: [issue24021] Add docstring to urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1438647951.99.0.314830431793.issue24021@psf.upfronthosting.co.za>


Peter Lovett added the comment:

Updated patch to 3.6
urlretrieve now has a decent docstring; this patch just adds a docstring to urlcleanup.

----------
nosy: +PeterLovett
versions: +Python 3.6 -Python 2.7
Added file: http://bugs.python.org/file40121/issue-24021.patch

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

From report at bugs.python.org  Tue Aug  4 02:48:21 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Tue, 04 Aug 2015 00:48:21 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438649301.54.0.0593042714252.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Updated version (based on issue-23725.patch from rbcollins):
- move tempdir description at the end of the main section, before Examples
- do not add my name second time in ACKS

----------
Added file: http://bugs.python.org/file40122/issue-23725.patch

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

From report at bugs.python.org  Tue Aug  4 02:53:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Aug 2015 00:53:41 +0000
Subject: [issue24021] Add docstring to urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <20150804005338.17717.45829@psf.io>


Roundup Robot added the comment:

New changeset 659f5adc2354 by Robert Collins in branch '3.4':
Issue #24021: docstring for urllib.urlcleanup.
https://hg.python.org/cpython/rev/659f5adc2354

New changeset 6fd69aeb8a3b by Robert Collins in branch '3.5':
Issue #24021: docstring for urllib.urlcleanup.
https://hg.python.org/cpython/rev/6fd69aeb8a3b

New changeset 43ed41cdd3c2 by Robert Collins in branch 'default':
Issue #24021: docstring for urllib.urlcleanup.
https://hg.python.org/cpython/rev/43ed41cdd3c2

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  4 02:54:21 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Aug 2015 00:54:21 +0000
Subject: [issue24021] Add docstring to urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1438649661.85.0.826430015198.issue24021@psf.upfronthosting.co.za>


Robert Collins added the comment:

Applied to 3.4 and up. Thanks for the patch.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 03:48:34 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 04 Aug 2015 01:48:34 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438652914.93.0.863275290208.issue24787@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

How are you calling the sniff() method? Note that it takes a sample of the CSV file. For example, this works for me:

>>> f = open("sniff1.csv")
>>> dialect = csv.Sniffer().sniff(next(open("sniff1.csv")))
>>> dialect.delimiter 
','
>>> dialect.lineterminator
'\r\n'

where sniff1.csv is your Dataset 1. (I think for reliable operation you really want your sample to be a multiple of whole lines.)

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Tue Aug  4 04:30:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 02:30:10 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1438655410.03.0.914103996718.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  This was really bugging me.  I remembered it clearly, but I couldn't find an issue.  Thought maybe it was a comment in the code, but nope.  Google led me to this line in the docs: "It is no longer necessary to use the global tempdir variable."  Checking when that was last changed, it turns out it was by me in issue 10354, which is the issue containing the discussion that I was remembering, but that was about template.  

Nevertheless, I think the sentence in the docs itself could be considered a documentation deprecation.

Since you are arguing that it shouldn't be considered deprecated, I think we should get some more participants in the discussion.  I'm +.5 on explicitly documenting it as deprecated.  I'm adding a couple folks from issue 10354 who might have an opinion.

Note that if we do keep it in the main section, that sentence should still be deleted, since it looks like "it is no longer necessary" has been true now for longer than it *was* necessary.

----------
nosy: +eric.smith, gregory.p.smith, rhettinger

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

From report at bugs.python.org  Tue Aug  4 04:38:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 02:38:40 +0000
Subject: [issue24786] Changes in the devguide repository are not published
 online in HTML
In-Reply-To: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za>
Message-ID: <1438655920.29.0.174597297609.issue24786@psf.upfronthosting.co.za>


R. David Murray added the comment:

I see your change made on the 30th on the web.  I don't see where the copyright is displayed, so I can't confirm that one, but Brett's change on the second is there.

So, I don't see a bug here.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Aug  4 04:40:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 02:40:03 +0000
Subject: [issue24754] argparse add_argument with action="store_true",
 type=bool should not crash
In-Reply-To: <1438250218.94.0.699008040775.issue24754@psf.upfronthosting.co.za>
Message-ID: <1438656003.02.0.981955987497.issue24754@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Tue Aug  4 04:40:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 04 Aug 2015 02:40:42 +0000
Subject: [issue24595] InteractiveInterpreter always prints to stdout
In-Reply-To: <1436446812.02.0.787958220284.issue24595@psf.upfronthosting.co.za>
Message-ID: <1438656042.22.0.819296118852.issue24595@psf.upfronthosting.co.za>


Martin Panter added the comment:

Terry: perhaps you?re thinking of <https://docs.python.org/dev/library/contextlib.html#contextlib.redirect_stdout> :)

----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Aug  4 05:08:21 2015
From: report at bugs.python.org (Ankoor Patil)
Date: Tue, 04 Aug 2015 03:08:21 +0000
Subject: [issue24777] sys.getrefcount takes no arguments
In-Reply-To: <1438492639.12.0.0188177121907.issue24777@psf.upfronthosting.co.za>
Message-ID: <1438657701.98.0.803262339443.issue24777@psf.upfronthosting.co.za>


Ankoor Patil added the comment:

Thanks Berker Peksag.

----------

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

From report at bugs.python.org  Tue Aug  4 05:08:46 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 04 Aug 2015 03:08:46 +0000
Subject: [issue24786] Changes in the devguide repository are not published
 online in HTML
In-Reply-To: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za>
Message-ID: <1438657726.88.0.791041325058.issue24786@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The copyright is right at the bottom of the page.  From the link given by Jes?s on the very first page it now reads 2011-2015.  I clicked next but still 2011-2014, next again 2011-2014, then gave up.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Tue Aug  4 05:08:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 03:08:56 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438657736.83.0.639738272334.issue24778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  I see.  The problem is that our desire to quote conflicts with mailcap's attempts to quote.

I now agree with you that run-mailcap's approach is correct, but creating a temporary alias is out of scope for findmatch.  That would need to be done by findmatch's caller.

I think we should add a documentation note about the problem and the solution.  I don't see any reliable way to detect the problem and raise an error for the same reason that quoting doesn't work. (The aliasing can tolerate false positives; but, for backward compatibility reasons, an error detection function here cannot.)

It would be possible to add a helper for the aliasing to 3.6, but if someone wants to propose that they should open an new issue for the enhancement.

I'm

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

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

From report at bugs.python.org  Tue Aug  4 05:14:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 03:14:01 +0000
Subject: [issue24786] Changes in the devguide repository are not published
 online in HTML
In-Reply-To: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za>
Message-ID: <1438658041.53.0.412311198517.issue24786@psf.upfronthosting.co.za>


R. David Murray added the comment:

Huh.  I don't see a copyright, but I do see it if I do view source.  The fact that not all pages are updated is probably due to those pages not having any internal changes and therefore not being regenerated.  Someone would have to clear the build cache on the server to get all the pages to regenerate with the new copyright.

----------

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

From report at bugs.python.org  Tue Aug  4 05:31:57 2015
From: report at bugs.python.org (Peter Lovett)
Date: Tue, 04 Aug 2015 03:31:57 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1438659117.97.0.963121259391.issue17570@psf.upfronthosting.co.za>


Peter Lovett added the comment:

Tiny change on case of Windows file 'mercurial.ini'
Although Windows is case-insensitive on filenames, the file itself is named in lowercase (I'm using TortoiseHg v3.4.2; I'm assuming older versions of TortoiseHg also name it in this way.)

----------
nosy: +PeterLovett
Added file: http://bugs.python.org/file40123/issue17570.patch

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

From report at bugs.python.org  Tue Aug  4 06:30:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 04 Aug 2015 04:30:06 +0000
Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr
In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za>
Message-ID: <1438662606.35.0.0514898317749.issue12869@psf.upfronthosting.co.za>


Martin Panter added the comment:

Results of experimenting on 3.6:

* The startup messages are written to standard error.
* The interactive interpreter prompts to the original standard error if Readline not used. But with Gnu Readline, prompts do go to the original standard output, as does other interactive Readline output (echoed input etc). This is what Albert reported.
* The interactive interpreter always reads from the original standard input, whether Readline is used or not.
* The displayhook() function always writes to the current sys.stdout, as documented.
* The excepthook() function always writes to the current sys.stderr, also as documented.
* The input() function is documented to prompt to sys.stdout, however see Issue 1927 for some quirks with that.
* The input() function always reads from the current sys.stdin. The Readline library is only used if sys.stdin and sys.stdout are the original file descriptors.

I agree it would probably be more consistent for the interpreter prompt to go to standard output. It looks like stdout is inspected to determine whether Readline will be used, while stderr is not inspected. So it makes sense for the prompt to go to stdout.

However I disagree that it should go to a redirected stream, sys.stderr or sys.stdout, since sys.stdin does not affect input. But see Issue 17620, about redirecting sys.stdin.

----------
nosy: +vadmium
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug  4 07:12:22 2015
From: report at bugs.python.org (Peter Lovett)
Date: Tue, 04 Aug 2015 05:12:22 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1438665142.39.0.426135344492.issue17570@psf.upfronthosting.co.za>


Peter Lovett added the comment:

Also a similar change to patch.rst

./python.exe
should be:
PCbuild\<target>\python.exe

----------
Added file: http://bugs.python.org/file40124/issue17570-2.patch

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

From report at bugs.python.org  Tue Aug  4 07:34:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Aug 2015 05:34:53 +0000
Subject: [issue24595] InteractiveInterpreter always prints to stdout
In-Reply-To: <1436446812.02.0.787958220284.issue24595@psf.upfronthosting.co.za>
Message-ID: <1438666493.21.0.979917583161.issue24595@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There is also redirect_stderr, but not for stdin.  I am not sure what specific issue is left here, of if this should be closed.

----------

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

From report at bugs.python.org  Tue Aug  4 08:46:19 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Aug 2015 06:46:19 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
 and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1438670779.85.0.415396171951.issue9517@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Berker committed the original patch to move the helper module, so adjusting the stage back to reflect the ongoing review on related issues.

----------
keywords:  -easy
stage: commit review -> patch review

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

From report at bugs.python.org  Tue Aug  4 09:20:02 2015
From: report at bugs.python.org (Peter Otten)
Date: Tue, 04 Aug 2015 07:20:02 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438672802.49.0.763512453128.issue24787@psf.upfronthosting.co.za>


Peter Otten added the comment:

The sniffer actually changes its "mind" in the fourth line:

Python 3.4.0 (default, Jun 19 2015, 14:20:21) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> csv.Sniffer().sniff("""\
... Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
... Sscanner ac15072911220.pdf,CM_15203,28714.32,MX Jan Feb,948198,,
... Sscanner ac15072911221.pdf,CM 16148,15600,MX Unkwon,948199,,
... """).delimiter
','
>>> csv.Sniffer().sniff("""\
... Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
... Sscanner ac15072911220.pdf,CM_15203,28714.32,MX Jan Feb,948198,,
... Sscanner ac15072911221.pdf,CM 16148,15600,MX Unkwon,948199,,
... Sscanner ac15072911230.pdf,CM 16148,33488,MX Cavalier,948200,Photos don't match the invoice
... """).delimiter
'M'

That line has only 5 commas while all others have 6. Unfortunately all lines contain exactly two "M"...

----------
nosy: +peter.otten

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

From report at bugs.python.org  Tue Aug  4 09:49:03 2015
From: report at bugs.python.org (Christopher Meng)
Date: Tue, 04 Aug 2015 07:49:03 +0000
Subject: [issue24747] ctypes silently truncates ints larger than C int
In-Reply-To: <1438171886.06.0.632497745661.issue24747@psf.upfronthosting.co.za>
Message-ID: <1438674543.73.0.982097470496.issue24747@psf.upfronthosting.co.za>


Changes by Christopher Meng <cickumqt at gmail.com>:


----------
nosy: +Christopher Meng

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

From report at bugs.python.org  Tue Aug  4 10:44:46 2015
From: report at bugs.python.org (Tal Einat)
Date: Tue, 04 Aug 2015 08:44:46 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1438677886.93.0.594445998035.issue20180@psf.upfronthosting.co.za>


Tal Einat added the comment:

Summary of the current state of this AC conversion derby group:

1) The collections, itertools and random modules should not be converted (at least for now).

2) The three example modules should not be converted (Modules/xxlimited.c, Modules/xxmodule.c and Modules/xxsubtype.c).

3) The latest unicodeobject.c patch has a LGTM from Serhiy after several rounds of review and improvement. This should probably go in at some point.

4) The single PyArg_ParseTuple in find.h should not be converted, since that is actually used for more than a single find() method via some precompiler macro "magic".

5) transmogrify.h can be converted and has a conversion patch, but the patch likely needs updating since it is from Jan. 2014.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Aug  4 14:20:07 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 04 Aug 2015 12:20:07 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1438690807.88.0.130669510777.issue19518@psf.upfronthosting.co.za>


Adam Barto? added the comment:

I'm not sure this is the right issue. The support for Unicode filenames is not (at least on Windows) ideal.

Let ?.py be a Python script with invalid syntax.

> py ?.py
  File "<encoding error>", line 2
    as as compile error
     ^
SyntaxError: invalid syntax

On the other hand, if run.py is does something like

path = sys.argv[1]
with tokenize.open(path) as f:
    source = f.read()
code = compile(source, path, "exec")
exec(code, __main__.__dict__)

we get 
> py run.py ?.py
  File "Python Unicode\\u03b1.py", line 2
    as as compile error
     ^
SyntaxError: invalid syntax

(or 'File "Python Unicode\?.py", line 2' depending on whether sys.stdout can encode the string).

So the "<encoding error>" in the first example is unfortunate as it is easy to get better result even by a simple pure Python approach.

----------
nosy: +Drekin

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

From report at bugs.python.org  Tue Aug  4 17:27:33 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 04 Aug 2015 15:27:33 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1438702053.48.0.914814657063.issue17570@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like the patchcheck section also has a "PCBuild/python.exe" that should be fixed.

Are the previous commenters satisfied with the fixes?

----------

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

From report at bugs.python.org  Tue Aug  4 17:29:13 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 04 Aug 2015 15:29:13 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438702153.35.0.974172705699.issue24787@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

I should have probably pointed out that the Sniffer class is the unloved stepchild of the csv module. In my experience it is rarely necessary. You either:

* Are reading CSV files which are about what Excel would produce with its default settings

or

* Know just what your format is, and can define the various parameters easily

It's pretty rare, I think, to get a delimited file in some format which is completely unknown and which thus has to be deduced.

As Peter showed, the Sniffer class is also kind of unreliable. I didn't write it, and there are precious few test cases for it. One of your datasets should probably be added to the mix and bugs fixed.

----------

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

From report at bugs.python.org  Tue Aug  4 17:40:08 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Aug 2015 15:40:08 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1438702808.8.0.410281557701.issue17570@psf.upfronthosting.co.za>


Zachary Ware added the comment:

In the patch:

-add configuration settings to ``~/.hgrc`` for the relevant repo(s) (remember
+add configuration settings to ``~/.hgrc`` (``mercurial.ini`` on Windows)
+for the relevant repo(s) (remember

This is nonsensical, `~/.hgrc` (`%USERPROFILE%\Mercurial.ini`) is the user-level Mercurial configuration; the settings "for the relevant repo(s)" are in `.hg/hgrc` in the repository (same on all platforms).

Btw, for me, the user-level config file on Windows has always been title-cased (`Mercurial.ini`) unless I preemptively created it myself.  Really doesn't matter, though :)

----------

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

From report at bugs.python.org  Tue Aug  4 20:42:11 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Tue, 04 Aug 2015 18:42:11 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438713731.53.0.957849371382.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

Yes changing the docs is a good idea.

I was thinking about a patch :

import os
####### patch
import random
try:
  from shlex import quote
except ImportError:
  from pipes import quote
#######

....... and so on ....


# Part 3: using the database.

def findmatch(caps, MIMEtype, key='view', filename="/dev/null", plist=[]):
    """Find a match for a mailcap entry.

    Return a tuple containing the command line, and the mailcap entry
    used; (None, None) if no match is found.  This may invoke the
    'test' command of several matching entries before deciding which
    entry to use.

    """

    entries = lookup(caps, MIMEtype, key)
    # XXX This code should somehow check for the needsterminal flag.
    for e in entries:
        if 'test' in e:
            test = subst(e['test'], filename, plist)
            if test and os.system(test) != 0:
                continue
####### patch
        ps=''.join(random.choice('python') for i in range(100))
        x=e[key]
        while '%s' in x:
            x=x.replace('%s',ps)  
        command=subst(x, MIMEtype, filename, plist)
        while "'"+ps+"'" in command:
            command=command.replace("'"+ps+"'",quote(filename))
        while ps in command:
            command=command.replace(ps,quote(filename))          
######  command = subst(e[key], MIMEtype, filename, plist)
        return command, e
    return None, None

----------

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

From report at bugs.python.org  Tue Aug  4 21:43:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Aug 2015 19:43:36 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438717416.47.0.40830317366.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A second specific reason to make ttk optional is either they or the accompanying re-writing may (and probably will) break some extension that goes beyond the narrowly defined extension interface.  For the present, a user using such an extension would be able to continue to do so, by turning use_ttk off. (I plan to add some DeprecationWarnings, either at startup or old tk module import, when use_ttk is possible but turned off.)

The normal bugfix-only policy, and the Idle exemption, starts with each x.y.0b1 release. The point of excluding 'major re-writes such as switching to themed widgets' was to exclude changes in bugfix releases that prevent idle from running in the 'current' environment.  In private email, Nick agreed with me that with ttk and any possible disablement made optional, it can be added to all current releases. He also suggested being on by default when possible.

I decided not to put anything into 3.5.0.  I intend to start pushing ttk patches perhaps next week after the release branch is split off and the main 3.5 branch is 3.5.1.

----------

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

From report at bugs.python.org  Tue Aug  4 22:07:55 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Aug 2015 20:07:55 +0000
Subject: [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1438718875.75.0.16651099925.issue20769@psf.upfronthosting.co.za>


Robert Collins added the comment:

24081 invalidates half the patch, but the other half still applies.

----------
nosy: +rbcollins
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Tue Aug  4 22:10:42 2015
From: report at bugs.python.org (Pastafarianist)
Date: Tue, 04 Aug 2015 20:10:42 +0000
Subject: [issue24788] HTTPException is derived from Exception instead of
 IOError
Message-ID: <1438719042.84.0.137488437732.issue24788@psf.upfronthosting.co.za>


New submission from Pastafarianist:

In both Python 2 and Python 3, HTTPException is derived from Exception. This is not quite convenient, since catching all connection-related errors while performing an HTTP query requires catching both IOError (which is subclassed by socket.error) and HTTPException. It might be better to change the parent class to IOError instead.

----------
components: Library (Lib)
messages: 247995
nosy: Pastafarianist
priority: normal
severity: normal
status: open
title: HTTPException is derived from Exception instead of IOError
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug  4 22:16:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Aug 2015 20:16:57 +0000
Subject: [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <20150804201654.29398.51199@psf.io>


Roundup Robot added the comment:

New changeset cfd768814ca3 by Robert Collins in branch '2.7':
Issue #20769: Improve reload() docs. Patch by Dorian Pula.
https://hg.python.org/cpython/rev/cfd768814ca3

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  4 22:17:31 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Aug 2015 20:17:31 +0000
Subject: [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1438719451.44.0.321973894986.issue20769@psf.upfronthosting.co.za>


Robert Collins added the comment:

2.7 side applied.

----------

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

From report at bugs.python.org  Tue Aug  4 22:22:18 2015
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 04 Aug 2015 20:22:18 +0000
Subject: [issue24789] ctypes doc string
Message-ID: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za>


New submission from David W. Lambert:

doc string suggests str is a valid init argument.  The code strongly discourages this.

ctypes.create_string_buffer

def create_string_buffer(init, size=None):
    """create_string_buffer(aBytes) -> character array
    create_string_buffer(anInteger) -> character array
    create_string_buffer(aString, anInteger) -> character array
    """
    if isinstance(init, bytes):
        if size is None:
            size = len(init)+1
        buftype = c_char * size
        buf = buftype()
        buf.value = init
        return buf
    elif isinstance(init, int):
        buftype = c_char * init
        buf = buftype()
        return buf
    raise TypeError(init)

----------
components: ctypes
messages: 247998
nosy: LambertDW
priority: normal
severity: normal
status: open
title: ctypes doc string
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  4 22:32:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Aug 2015 20:32:40 +0000
Subject: [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <20150804203236.53963.11279@psf.io>


Roundup Robot added the comment:

New changeset 33dfbb293892 by Robert Collins in branch '3.4':
Issue #20769: Improve reload() docs. Patch by Dorian Pula.
https://hg.python.org/cpython/rev/33dfbb293892

New changeset 9fe1a440e4b8 by Robert Collins in branch '3.5':
Issue #20769: Improve reload() docs. Patch by Dorian Pula.
https://hg.python.org/cpython/rev/9fe1a440e4b8

New changeset 6778332f687a by Robert Collins in branch 'default':
Issue #20769: Improve reload() docs. Patch by Dorian Pula.
https://hg.python.org/cpython/rev/6778332f687a

----------

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

From report at bugs.python.org  Tue Aug  4 22:33:15 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Aug 2015 20:33:15 +0000
Subject: [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1438720395.27.0.434928237024.issue20769@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch. Applied to 3.4/3.5/3.6 as well.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug  4 22:36:43 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 04 Aug 2015 20:36:43 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438720603.1.0.934623975725.issue24272@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

I could add the docs for the first half of the remaining classes by the end of this week.

----------

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

From report at bugs.python.org  Tue Aug  4 22:37:44 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Aug 2015 20:37:44 +0000
Subject: [issue24789] ctypes doc string
In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za>
Message-ID: <1438720664.39.0.679566664111.issue24789@psf.upfronthosting.co.za>


eryksun added the comment:

That's a vestige of the 2.x docs. For 3.x it should be "create_string_buffer(aBytes, anInteger)".

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eryksun
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug  4 22:55:27 2015
From: report at bugs.python.org (Evan Hubinger)
Date: Tue, 04 Aug 2015 20:55:27 +0000
Subject: [issue24649] python -mtrace --help is wrong
In-Reply-To: <1437086585.22.0.878051480873.issue24649@psf.upfronthosting.co.za>
Message-ID: <1438721727.6.0.091342540998.issue24649@psf.upfronthosting.co.za>


Evan Hubinger added the comment:

Added a patch that clears up the incorrect help. It now accurately reflects the only constraints that the code actually puts on the arguments:

    if listfuncs and (count or trace):
        _err_exit("cannot specify both --listfuncs and (--trace or --count)")

    if not (count or trace or report or listfuncs or countcallers):
        _err_exit("must specify one of --trace, --count, --report, "
                  "--listfuncs, or --trackcalls")

To reflect both of those constraints, and only those constraints, the part of the help message in question now reads:

Otherwise, at least one of the following options must be given:
-t, --trace           Print each line to sys.stdout before it is executed.
-c, --count           Count the number of times each line is executed
                      and write the counts to <module>.cover for each
                      module executed, in the module's directory.
                      See also `--coverdir', `--file', `--no-report' below.
-l, --listfuncs       Keep track of which functions are executed at least
                      once and write the results to sys.stdout after the
                      program exits. Cannot be specified alongside `--trace`
                      or `--count`.
-T, --trackcalls      Keep track of caller/called pairs and write the
                      results to sys.stdout after the program exits.
-r, --report          Generate a report from a counts file; do not execute
                      any code.  `--file' must specify the results file to
                      read, which must have been created in a previous run
                      with `--count --file=FILE'.

----------
keywords: +patch
nosy: +Evan Hubinger
Added file: http://bugs.python.org/file40125/issue24649.patch

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

From report at bugs.python.org  Tue Aug  4 22:58:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Aug 2015 20:58:41 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438721921.77.0.966461629288.issue24750@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Back to Editor Windows: I have a new idea for the status bar

First: move ln, col to the left, replace the label with a label + entry box.  If someone edits the line number and hits return (or just leaves the box?), jump to the line.  Treat negative numbers as from the end.  Do the same with col.  Have AltG jump to the box.

Second: use the remaining space to add a Find [         ] label and box for simple search, with default settings.  This should cover about half of use cases.  Add a button for advanced usages.  The advanced box could combine the existig boxed to cover, find, replace, and multiple files.

----------

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

From report at bugs.python.org  Tue Aug  4 23:49:12 2015
From: report at bugs.python.org (Tiago Wright)
Date: Tue, 04 Aug 2015 21:49:12 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438702153.35.0.974172705699.issue24787@psf.upfronthosting.co.za>
Message-ID: <CAFxr9VpCq6PqwT94XJEY4_H4JbfuWg=8BJm4fL87PcLkwN_BxA@mail.gmail.com>


Tiago Wright added the comment:

I agree that the parameters are easily deduced for any one csv file after a
quick inspection. The reason I went searching for a good sniffer was that I
have ~2100 csv files of slightly different formats coming from different
sources. In some cases, a csv file is sent directly to me, other times it
is first opened in excel and saved, and other times it is copy-pasted from
excel into another location, yielding 3 variations on the formatting from a
single source. Multiply that by 8 different sources of data.

For hacking disparate data sources together, it is more interesting to have
a sniffer that works really well to distinguish among the most common
dialects of csv, than one that tries to deduce the parameters of a rare or
unknown format. I agree with you that it would be a rare case that the
format is completely unknown -- more likely, you know it is one of two or
three possible options and don't want to have to inspect each file to find
out which.

Unfortunately, trying to limit delimiters to some of the most common ones
using the delimiters parameter just raises an error:

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> csv.Sniffer().sniff("""\
... Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
... Sscanner ac15072911220.pdf,CM_15203,41.56,MX Jan Feb,948198,,
... Sscanner ac15072911221.pdf,CM 16148,41.50,MX Unkwon,948199,,
... Sscanner ac15072911230.pdf,CM 16148,6.42,MX Cavalier,948200,Photos
don't match the invoice
... Sscanner ac15072911261.pdf,CM_14464,0.06,MX Dutiful,948203,,
... Sscanner ac15072911262.pdf,CM 16148,88,MX Apr,948202,,
... Sscanner ac15072911250.pdf,CM_14464,94.08,MX Jan Feb,948208,,
... Sscanner ac15072911251.pdf,CM_17491,39.84,MX Unkwon,948207,,
... Sscanner ac15072911253.pdf,CM_14464,42.07,MX Cavalier,,,
... Sscanner ac15072911253.pdf,CM_14464,2.23,MX Dutiful,,,
... Sscanner ac15072911253.pdf,CM_14464,12.84,MX Apr,,,
... """).delimiter
'M'
>>> csv.Sniffer().sniff("""\
... Invoice File,Credit Memo,Amount Claimed,Description,Invoice,Message,
... Sscanner ac15072911220.pdf,CM_15203,41.56,MX Jan Feb,948198,,
... Sscanner ac15072911221.pdf,CM 16148,41.50,MX Unkwon,948199,,
... Sscanner ac15072911230.pdf,CM 16148,6.42,MX Cavalier,948200,Photos
don't match the invoice
... Sscanner ac15072911261.pdf,CM_14464,0.06,MX Dutiful,948203,,
... Sscanner ac15072911262.pdf,CM 16148,88,MX Apr,948202,,
... Sscanner ac15072911250.pdf,CM_14464,94.08,MX Jan Feb,948208,,
... Sscanner ac15072911251.pdf,CM_17491,39.84,MX Unkwon,948207,,
... Sscanner ac15072911253.pdf,CM_14464,42.07,MX Cavalier,,,
... Sscanner ac15072911253.pdf,CM_14464,2.23,MX Dutiful,,,
... Sscanner ac15072911253.pdf,CM_14464,12.84,MX Apr,,,
... """, delimiters=",\t|^").delimiter
Traceback (most recent call last):
  File "<stdin>", line 13, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/csv.py",
line 189, in sniff
    raise Error("Could not determine delimiter")
_csv.Error: Could not determine delimiter

On Tue, Aug 4, 2015 at 8:29 AM Skip Montanaro <report at bugs.python.org>
wrote:

>
> Skip Montanaro added the comment:
>
> I should have probably pointed out that the Sniffer class is the unloved
> stepchild of the csv module. In my experience it is rarely necessary. You
> either:
>
> * Are reading CSV files which are about what Excel would produce with its
> default settings
>
> or
>
> * Know just what your format is, and can define the various parameters
> easily
>
> It's pretty rare, I think, to get a delimited file in some format which is
> completely unknown and which thus has to be deduced.
>
> As Peter showed, the Sniffer class is also kind of unreliable. I didn't
> write it, and there are precious few test cases for it. One of your
> datasets should probably be added to the mix and bugs fixed.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24787>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Aug  5 00:48:49 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Aug 2015 22:48:49 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438728529.62.0.883851011167.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

It turns out the problem was that the odict resize mechanism was not getting triggered in all the cases that it should have been.  dict resizes after a certain number of insertions, whether or not previous deletions have cleared out space.  odict only resizes its fast lookup table when it needs to do a fast node lookup and only when the current dict keys size does not match the current size of the odict fast lookup table.

This bug is the consequence of a corner case which odict did not handle correctly.  When you delete an item and then insert another, the resulting size of the dict keys is the same as the it was before the deletion.  However, the insertion may have triggered a resize.  This matters because when a resize happens the keys are re-inserted into the hash table.  If it so happens that they key you just removed was in a slot that would have otherwise been occupied by another key (i.e. there was an earlier collision) then upon resizing that other key will be moved to its preferred slot.

Here's a patch that changes odict to rely on the pointer value of dict's ma_keys (rather than on ma_keys.dk_size) to indicate the need for a resize.  This works because dict creates a new keys struct every time it resizes.

I'll point out that one alternative would be to track a "state" counter on dict that increments each time there's a resize.  Then odict could check that rather than the ma_keys pointer value.

----------
keywords: +patch
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file40126/odict-correct-resize.diff

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

From report at bugs.python.org  Wed Aug  5 00:49:29 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Aug 2015 22:49:29 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438728569.88.0.978431081249.issue24667@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
priority: normal -> release blocker

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

From report at bugs.python.org  Wed Aug  5 00:51:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Aug 2015 22:51:58 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438728718.4.0.834365575859.issue24787@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you look at the algorithm it is doing some fancy things with metrics, but does have a 'preferred delimiters' list that it checks.  It is possible things could be improved either by tweaking the threshold or by somehow giving added weight to the metrics when the candidate character is in the preferred delimiter list.

We might have to do this with a feature flag to turn it on, though, since it could change the results for programs that happen to work with the current algorithm.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Aug  5 01:04:45 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Aug 2015 23:04:45 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438729485.66.0.138898640627.issue24667@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Added file: http://bugs.python.org/file40127/odict-correct-resize.diff

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

From report at bugs.python.org  Wed Aug  5 01:13:28 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Aug 2015 23:13:28 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438730008.63.0.31719150106.issue24667@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file40126/odict-correct-resize.diff

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

From report at bugs.python.org  Wed Aug  5 01:26:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Aug 2015 23:26:51 +0000
Subject: [issue17776] IDLE Internationalization
In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za>
Message-ID: <1438730811.81.0.588644261292.issue17776@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I presume setting builtins._ is part of imitating the shell. It could be replace with setattr.

----------

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

From report at bugs.python.org  Wed Aug  5 01:51:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 04 Aug 2015 23:51:30 +0000
Subject: [issue24788] HTTPException is derived from Exception instead of
 IOError
In-Reply-To: <1438719042.84.0.137488437732.issue24788@psf.upfronthosting.co.za>
Message-ID: <1438732290.47.0.306669685886.issue24788@psf.upfronthosting.co.za>


Martin Panter added the comment:

Did you have any specific exceptions in mind, or specific subclasses of IOError? In 3.5 we now have the RemoteDisconnected exception, which derives ConnectionResetError. Some of the other exceptions are only local programmer errors. Currently documented exceptions:

Exception:
  http.client.HTTPException:
  * NotConnected
  * InvalidURL
  * UnknownProtocol
  * UnknownTransferEncoding
  * UnimplementedFileMode
  * IncompleteRead
  * ImproperConnectionState:
    + CannotSendRequest
    + CannotSendHeader
    + ResponseNotReady
  * BadStatusLine
    + RemoteDisconnected
  * LineTooLong

NotConnected is a programmer error, and it is only raised if the undocumented and untested ?auto_open? flag is cleared.

InvalidURL is triggered by the input URL, not the network or remote server.

UnknownTransferEncoding was once triggered by the remote response, but is no longer invoked; see Issue 600488. Maybe it should be deprecated?

UnimplementedFileMode looks like it was once either an internal consistency error, or a programmer error, raised by passing the wrong mode to FakeSocket.makefile(). Unused since r57680; probably should also be deprecated.

The ImproperConnectionState hierarchy exceptions are also programmer errors, raised when the wrong method is called according to the local object state.

I would perhaps support UnknownProtocol, IncompleteRead, BadStatusLine, LineTooLong (and maybe UnknownTransferEncoding) being derived from some more specific exception. Maybe ValueError would be more appropriate for protocol errors, EOFError for IncompleteRead. I?m not sure.

OSError is specifically designed for errors related to C?s ?errno?, and none of these errors are related to ?errno?. Though I acknowledge there are other subclasses that ignore this fact, such as URLError.

----------
nosy: +vadmium

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

From report at bugs.python.org  Wed Aug  5 02:29:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Aug 2015 00:29:23 +0000
Subject: [issue24790] Idle: improve stack viewer
Message-ID: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Debug => Stack Viewer (no hot key) could become more useful, aside from #23544, freezing Idle when Debugger active.

1. Don't include idlelib.run.runcode.
2. Don't duplicate globals under each function. Once for the module is enough.
3. Remove +Locals under each function and instead display locals when expanding Clicking a function should display locals without having to click anything else.
4. Add a button to expand all locals?

----------
components: IDLE
messages: 248010
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: improve stack viewer
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 02:45:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Aug 2015 00:45:27 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1438735527.11.0.939136484104.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

5. Change title to something better than 'Idle'.  Perhaps 'Idle Shell Traceback'?

----------

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

From report at bugs.python.org  Wed Aug  5 02:54:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Aug 2015 00:54:36 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1438736076.67.0.395124298329.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

5b. Add Python version to end of , as with Shell window.

This will be more than one patch. Some should be easy.

----------
keywords: +easy

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

From report at bugs.python.org  Wed Aug  5 05:00:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 03:00:20 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <20150805030015.111049.38706@psf.io>


Roundup Robot added the comment:

New changeset 6987a9c7dde9 by Zachary Ware in branch '2.7':
Issue #24751: When running regrtest with '-w', don't fail if re-run succeeds.
https://hg.python.org/cpython/rev/6987a9c7dde9

New changeset 9964edf2fd1e by Zachary Ware in branch '3.4':
Issue #24751: When running regrtest with '-w', don't fail if re-run succeeds.
https://hg.python.org/cpython/rev/9964edf2fd1e

New changeset 9d1f6022261d by Zachary Ware in branch '3.5':
Issue #24751: Merge with 3.4
https://hg.python.org/cpython/rev/9d1f6022261d

New changeset 6f67c74608b6 by Zachary Ware in branch 'default':
Closes #24751: Merge with 3.5
https://hg.python.org/cpython/rev/6f67c74608b6

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Aug  5 05:42:24 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 05 Aug 2015 03:42:24 +0000
Subject: [issue24791] *args regression
Message-ID: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>


New submission from Ben Longbons:

The following code is allowed by the grammar of Python 3.4, but not Python 3.5:

`def f(): g(*a or b)`

where unary `*` has the lowest precedence, i.e. it is equivalent to:

`def f(): g(*(a or b))`

The cause of the regression that the 3.4 grammar for `arglist` uses `'*' test` but the 3.5 grammar uses `'*' expr`. This is likely an oversight due to the PEP 448 changes; the fix should most likely be applied to the new `display`s as well as fixing the regression.


***

Thanks to zware on IRC for actually testing this for me, since I don't have a runnable python3.5, just docs.

----------
components: Interpreter Core
messages: 248014
nosy: o11c
priority: normal
severity: normal
status: open
title: *args regression
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug  5 05:44:47 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 05 Aug 2015 03:44:47 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438746287.41.0.514391409166.issue24791@psf.upfronthosting.co.za>


Ben Longbons added the comment:

Related: bug 24176 fixed this for the `**` case.

----------

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

From report at bugs.python.org  Wed Aug  5 05:52:36 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Aug 2015 03:52:36 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438746756.42.0.899383378658.issue24791@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +3.4regression
nosy: +benjamin.peterson, yselivanov, zach.ware
priority: normal -> release blocker
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6

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

From report at bugs.python.org  Wed Aug  5 05:53:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 03:53:26 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <20150805035324.1393.51120@psf.io>


Roundup Robot added the comment:

New changeset 3c170f68407f by Zachary Ware in branch '3.4':
Issue #24791: Add tests for things that regressed with PEP 448
https://hg.python.org/cpython/rev/3c170f68407f

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug  5 05:55:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Aug 2015 03:55:48 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438746948.41.0.59366659881.issue24791@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Test committed on 3.4; I'm not comfortable enough with the grammar to actually fix the issue (the obvious change of `star_expr` => `'*' test` isn't enough, I tried :)).

----------

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

From report at bugs.python.org  Wed Aug  5 06:37:25 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 04:37:25 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438749445.08.0.281090174977.issue24791@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The attached patch should fix that. Please review.

----------
keywords: +patch
Added file: http://bugs.python.org/file40128/issue24791.patch

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

From report at bugs.python.org  Wed Aug  5 06:48:33 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 04:48:33 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438750113.65.0.720684478936.issue24791@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +larry, ncoghlan

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

From report at bugs.python.org  Wed Aug  5 06:51:27 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 04:51:27 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1438750287.92.0.820027012451.issue2292@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Do we need to make lib2to3 compatible with the new grammar?

----------
nosy: +yselivanov

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

From report at bugs.python.org  Wed Aug  5 07:06:50 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 05 Aug 2015 05:06:50 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438751210.47.0.0490912930534.issue24791@psf.upfronthosting.co.za>


Ben Longbons added the comment:

Also consider:

*() or (), *() or ()
[*() or (), *() or ()]
{*() or (), *() or ()}
{**{} or {}, **{} or {}}

Note that the second-or-later argument is a separate part of the grammar so that's why I wrote it twice.

Actually, I think `star_expr` will probably go away entirely.

----------

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

From report at bugs.python.org  Wed Aug  5 08:12:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Aug 2015 06:12:49 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1438755169.27.0.707273320148.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I presume sorting the list is a trivial matter.

----------

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

From report at bugs.python.org  Wed Aug  5 10:51:02 2015
From: report at bugs.python.org (Amund Hov)
Date: Wed, 05 Aug 2015 08:51:02 +0000
Subject: [issue24792] zipimporter masks import errors
Message-ID: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>


New submission from Amund Hov:

Due to mixed version .pyc files in my zipped python application I was getting inconsistent loading of certain packages.

E.g.

n [4]: zf.find_module('kitconsole')
Out[4]: <zipimporter object "test_controller_test.zip">

In [5]: zf.load_module('kitconsole')
---------------------------------------------------------------------------
ZipImportError                            Traceback (most recent call last)
<ipython-input-5-8e75885cc952> in <module>()
----> 1 zf.load_module('kitconsole')

ZipImportError: can't find module 'kitconsole'


Unpacking the archive and doing the import from the file system revealed the  real issue, ImportError: Bad Magic Number.

As an end user it was confusing that zipimporter reported being able to find the module in find_module(), but not in load_module(). Is it possible to have load_module provide a better error message when import fails? The wording now does not give any hints when searching the bug-tracker / Google.

----------
messages: 248022
nosy: Amund Hov
priority: normal
severity: normal
status: open
title: zipimporter masks import errors
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug  5 10:53:59 2015
From: report at bugs.python.org (Amund Hov)
Date: Wed, 05 Aug 2015 08:53:59 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1438764839.02.0.503040440473.issue24792@psf.upfronthosting.co.za>


Changes by Amund Hov <amund.hov at gmail.com>:


----------
type: behavior -> enhancement

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

From report at bugs.python.org  Wed Aug  5 11:07:24 2015
From: report at bugs.python.org (Gregor)
Date: Wed, 05 Aug 2015 09:07:24 +0000
Subject: [issue24793] Calling 'python' via subprocess.call ignoring passed
 %PATH%
Message-ID: <1438765644.91.0.822925834311.issue24793@psf.upfronthosting.co.za>


New submission from Gregor:

I just noticed that there is a litte inconvenience when I try to invoke 'python' via subprocess.call passing an environment (%PATH%) from a script. I pass an environment where %PATH% only contains one directory where a python2.7.3-exe is present (I checked with "subprocess.call(['where','python'],env=environment)" that python is found there). However when calling "subprocess.call(['python'],env=environment)" python 2.7.9 is opened, which is the python version I called the script with. Seems inconvenient to me.

Greetings

----------
components: Windows
messages: 248023
nosy: paul.moore, phbarnacle, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Calling 'python' via subprocess.call ignoring passed %PATH%
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  5 11:43:32 2015
From: report at bugs.python.org (Amund Hov)
Date: Wed, 05 Aug 2015 09:43:32 +0000
Subject: [issue24794] PyZipFile mixes compiled files from different python
 versions.
Message-ID: <1438767812.67.0.706553781663.issue24794@psf.upfronthosting.co.za>


New submission from Amund Hov:

In my project I have a mixture of scripts using Python 2.7 and 3.4.
Some of the scripts using python 3.4 are packaged into archives using
PyZipFile.

Through some combination I ended up with 2.7 compiled packages in my archive when packaging using python 3.4. In combination with issue 24792 "zipimporter masks import errors" this led to many grey hairs figuring out why my packaging scripts suddenly broke.

Are there sufficient provisions in PyZipFile to prevent this? It seems it will happily mix compiled files with differing magic bytes.

----------
messages: 248024
nosy: Amund Hov
priority: normal
severity: normal
status: open
title: PyZipFile mixes compiled files from different python versions.
type: behavior

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

From report at bugs.python.org  Wed Aug  5 12:03:39 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2015 10:03:39 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1438769019.02.0.206971241952.issue2292@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yes we should. I'd consider it a bug if it wasn't supported in 3.5.0 and we could fix that bug in 3.5.1.

----------

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

From report at bugs.python.org  Wed Aug  5 12:27:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 10:27:42 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <20150805102737.110941.28350@psf.io>


Roundup Robot added the comment:

New changeset a8dcbd2711d6 by Guido van Rossum in branch '3.5':
Issue #24272: Initial docs for typing.py (PEP 484).
https://hg.python.org/cpython/rev/a8dcbd2711d6

New changeset 0c74fd4219aa by Guido van Rossum in branch 'default':
Issue #24272: Initial docs for typing.py (PEP 484). (Merge from 3.5.)
https://hg.python.org/cpython/rev/0c74fd4219aa

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug  5 12:27:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 10:27:42 +0000
Subject: [issue23973] PEP 484 implementation
In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za>
Message-ID: <20150805102737.110941.85216@psf.io>


Roundup Robot added the comment:

New changeset f142b7c7a8e3 by Guido van Rossum in branch '3.5':
Issue #23973: Update typing.py from GitHub repo.
https://hg.python.org/cpython/rev/f142b7c7a8e3

New changeset c9a6ce666ff2 by Guido van Rossum in branch 'default':
Issue #23973: Update typing.py from GitHub repo. (Merge from 3.5.)
https://hg.python.org/cpython/rev/c9a6ce666ff2

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug  5 12:28:40 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2015 10:28:40 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438770520.9.0.866718815154.issue24272@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I've landed this now (for real). Next time please strip all trailing whitespace from typing.rst, else the hg push fails!

----------

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

From report at bugs.python.org  Wed Aug  5 12:52:01 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 05 Aug 2015 10:52:01 +0000
Subject: [issue24793] Calling 'python' via subprocess.call ignoring passed
 %PATH%
In-Reply-To: <1438765644.91.0.822925834311.issue24793@psf.upfronthosting.co.za>
Message-ID: <1438771921.13.0.916314416605.issue24793@psf.upfronthosting.co.za>


Paul Moore added the comment:

This is standard Windows behaviour. Executables are always located first in the directory where your program (in this case the Python executable) is running from - even before searching PATH.

If you want to use a different Python, you should specify the full path  to the executable - "subprocess.call(["C:\\Python34\\python.exe"])".

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Aug  5 13:55:12 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 05 Aug 2015 11:55:12 +0000
Subject: [issue24793] Calling 'python' via subprocess.call ignoring passed
 %PATH%
In-Reply-To: <1438765644.91.0.822925834311.issue24793@psf.upfronthosting.co.za>
Message-ID: <1438775712.8.0.874737364394.issue24793@psf.upfronthosting.co.za>


eryksun added the comment:

Popen calls Windows [CreateProcess][1]. If the Popen "executable" argument isn't used or if the file from the command line doesn't include a directory path, then CreateProcess searches for it in the following directories:

    1. The directory from which the application loaded.
    2. The current directory for the parent process.
       * This step is skipped if the parent defines
         %NoDefaultCurrentDirectoryInExePath%.
    3. The 32-bit Windows system directory.
    4. The 16-bit Windows system directory. 
    5. The Windows directory. 
    6. The directories that are listed in the PATH 
       environment variable. 

Also note that the PATH searched is that of the *parent* process; the "env" parameter doesn't affect this. 

Call the SearchPath function if you need a custom search for the fully qualified path. 

    import ctypes
    from ctypes import wintypes

    kernel32 = ctypes.WinDLL('kernel32')

    kernel32.SearchPathW.argtypes = (
        wintypes.LPCWSTR,                   # _In_opt_  lpPath
        wintypes.LPCWSTR,                   # _In_      lpFileName
        wintypes.LPCWSTR,                   # _In_opt_  lpExtension
        wintypes.DWORD,                     # _In_      nBufferLength
        wintypes.LPWSTR,                    # _Out_     lpBuffer
        ctypes.POINTER(wintypes.LPWSTR))    # _Out_opt_ lpFilePart
                                            
    def search_path(filename, path=None, ext='.exe'):
        length, new_length = 0, 260
        while new_length > length:
            length = new_length
            filepath = (ctypes.c_wchar * length)()
            new_length = kernel32.SearchPathW(path, filename, ext,
                                              length, filepath, None)
        return filepath.value

For example:

    >>> search_path('python')
    u'C:\\Program Files\\Python27\\python.exe'
    >>> import os            
    >>> search_path('python', os.environ['PATH'])
    u''

    >>> search_path('more.com', os.environ['PATH'])
    u'C:\\Windows\\System32\\more.com'
    >>> search_path('more', ext='.com')            
    u'C:\\Windows\\system32\\more.com'

[1]: https://msdn.microsoft.com/en-us/library/ms682425

----------
nosy: +eryksun

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

From report at bugs.python.org  Wed Aug  5 14:29:03 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 12:29:03 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438777743.47.0.929901785678.issue24759@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

IDLE's in an "interesting" place right now - it isn't showing people Tcl/Tk in its best light, so folks are likely to assume all Tcl/Tk apps necessarily look that way, and it's also using GUI idioms like separate shell and editor windows that don't reflect the conventions of modern IDEs.

For 3.5.1+, I think there's no question that we want to show IDLE in the best possible light, and we want to try to do that by default. That means modernising it to use the best cross-platform features that Tcl/Tk has to offer (including ttk).

However, Ned pointed out that the last PPC-supporting Mac OS X (10.5) has a Tcl/Tk version older than 8.5, and there's the general compatibility risk for breaking extensions with large refactorings, so retaining a "non-ttk mode" will be a valuable approach to the modernisation effort.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Aug  5 14:38:33 2015
From: report at bugs.python.org (=?utf-8?q?Mathias_Fr=C3=B6jdman?=)
Date: Wed, 05 Aug 2015 12:38:33 +0000
Subject: [issue24795] Make event loops with statement context managers
Message-ID: <1438778311.28.0.548352526709.issue24795@psf.upfronthosting.co.za>


New submission from Mathias Fr?jdman:

Since asyncio event loops have to be closed nowadays, it would be pretty convenient and pythonic to make BaseEventLoop a context manager that calls self.close() in __exit__ the same way as contextlib.closing() does it. Example:

import asyncio

with asyncio.get_event_loop() as loop:
    loop.run_until_complete(func())

instead of

import asyncio
from contextlib import closing

with closing(asyncio.get_event_loop()) as loop:
    loop.run_until_complete(func())

or event the bulkier

import asyncio

loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(func())
finally:
    loop.close()

The attached patch applies to Python 3.5b4's asyncio/base_events.py

----------
components: asyncio
files: patch
messages: 248032
nosy: Mathias Fr?jdman, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Make event loops with statement context managers
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file40129/patch

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

From report at bugs.python.org  Wed Aug  5 14:45:36 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 12:45:36 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1438778736.48.0.670819968208.issue24769@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This is an interesting find - thanks.

Adding Larry as 3.5 release manager to the cc here, as I think the right fix actually involves an API adjustment inside _imp.

One of the consequences of PEP 489 (multi-phase initialisation) was that builtin imports and extension module imports now share a lot more code, and that includes the fact that while we have both _imp.create_builtin and _imp.create_dynamic, they currently share a module level exec implementation in _imp.exec_dynamic.

However, the definition and implementation of _imp.exec_dynamic is still behind the same preprocessor guard as _imp.create_dynamic, hence the error reported here.

As far as a fix goes, rather than defining _imp.exec_dynamic unconditionally, my inclination is to say that merging the Python level APIs in addition to the underyling C level implementation represents a design mistake when we implemented the PEP, and there should be a separate _imp.exec_builtin function.

The fact that _imp.exec_dynamic just called _imp.exec_builtin internally would then be a pure CPython implementation detail, rather than something importlib specifically depended on.

----------
nosy: +encukou

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

From report at bugs.python.org  Wed Aug  5 14:47:21 2015
From: report at bugs.python.org (=?utf-8?q?Mathias_Fr=C3=B6jdman?=)
Date: Wed, 05 Aug 2015 12:47:21 +0000
Subject: [issue24795] Make event loops with statement context managers
In-Reply-To: <1438778311.28.0.548352526709.issue24795@psf.upfronthosting.co.za>
Message-ID: <1438778841.72.0.87591025758.issue24795@psf.upfronthosting.co.za>


Mathias Fr?jdman added the comment:

(Just noticed http://bugs.python.org/issue19860, which I originally failed to notice when just searching for "asyncio loop" and not context manager)

Anyway, in recent Python/asyncio versions, failing to close the event loop before exiting whole the process can cause problems, so I think the case is valid now.

----------

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

From report at bugs.python.org  Wed Aug  5 15:02:49 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2015 13:02:49 +0000
Subject: [issue24795] Make event loops with statement context managers
In-Reply-To: <1438778841.72.0.87591025758.issue24795@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLpXvaOeah3b+MKRMawc60CfHBj81hCf8k8KdwKG5Dsqg@mail.gmail.com>


Guido van Rossum added the comment:

This seems the wrong idea to me. Event loops should be long-lived, so the
context manager would ideally see very little use.

----------

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

From report at bugs.python.org  Wed Aug  5 15:05:17 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 13:05:17 +0000
Subject: [issue24796] Deleting names referencing from enclosed and enclosing
 scopes
Message-ID: <1438779917.48.0.0299421063838.issue24796@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While committing issue #24129, I noticed the following in the execution model documentation:

==================
If a variable is referenced in an enclosing scope, it is illegal to delete the name. An error will be reported at compile time.
==================

I'm not sure what that means, as both of the following compiled fine for me under 3.4.2:

>>> def f():
...     x = 1
...     def g():
...         nonlocal x
...         del x
... 
>>> def f():
...     x = 1
...     del x
...     def g():
...         print(x)
...

----------
assignee: docs at python
components: Documentation
messages: 248036
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Deleting names referencing from enclosed and enclosing scopes

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

From report at bugs.python.org  Wed Aug  5 15:19:39 2015
From: report at bugs.python.org (Yuriy Syrovetskiy)
Date: Wed, 05 Aug 2015 13:19:39 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438780779.4.0.735929779581.issue15944@psf.upfronthosting.co.za>


Yuriy Syrovetskiy added the comment:

You don't need `raw=True`, `.cast('b')` already must do this. But unfortunately, is is not implemented yet.

----------
nosy: +cblp

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

From report at bugs.python.org  Wed Aug  5 15:26:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 13:26:37 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <20150805132528.111049.74583@psf.io>


Roundup Robot added the comment:

New changeset 94e215a5e24b by Nick Coghlan in branch '3.4':
Issue #24129: Clarify reference docs for name resolution.
https://hg.python.org/cpython/rev/94e215a5e24b

New changeset 5e4d21311772 by Nick Coghlan in branch '3.5':
Merge issue #24129 from 3.4
https://hg.python.org/cpython/rev/5e4d21311772

New changeset e75881393cf2 by Nick Coghlan in branch 'default':
Merge issue #24129 from 3.5
https://hg.python.org/cpython/rev/e75881393cf2

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug  5 16:47:19 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 14:47:19 +0000
Subject: [issue24796] Deleting names referencing from enclosed and enclosing
 scopes
In-Reply-To: <1438779917.48.0.0299421063838.issue24796@psf.upfronthosting.co.za>
Message-ID: <1438786038.85.0.682453418562.issue24796@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that I haven't attempted to resolve this myself, as I'm not sure if we should just delete the paragraph, or if we accidentally dropped a compile time error check that didn't have any tests somewhere along the line.

Probably a good one to raise on python-dev...

----------

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

From report at bugs.python.org  Wed Aug  5 16:47:19 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 14:47:19 +0000
Subject: [issue24794] PyZipFile mixes compiled files from different python
 versions.
In-Reply-To: <1438767812.67.0.706553781663.issue24794@psf.upfronthosting.co.za>
Message-ID: <1438786039.4.0.064678475799.issue24794@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, that used to be a general problem with .pyc files before we introduced __pycache__.  PyZipFile still supports the "legacy mode" by using whatever .pyc file is there, if there is one.  Perhaps it is time to deprecate the legacy mode in 3.6?

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Aug  5 16:47:23 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 14:47:23 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438786043.41.0.464551161042.issue24129@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able to make these docs completely intuitive (as name resolution is genuinely complex), but Ivan's revisions at least mean we're no longer assuming readers know how the name resolution worked prior to the introduction of lexical scoping, and a couple of tricky cases now have inline examples.

I also noticed an existing paragraph in the docs that *I* didn't understand, and filed issue #24796 to cover that. I'm not sure if we should just delete the paragraph, or if we accidentally dropped a compile time error check that didn't have any tests to ensure we were detecting the problem.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type: behavior -> enhancement

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

From report at bugs.python.org  Wed Aug  5 16:48:55 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 05 Aug 2015 14:48:55 +0000
Subject: [issue24796] Deleting names referencing from enclosed and enclosing
 scopes
In-Reply-To: <1438779917.48.0.0299421063838.issue24796@psf.upfronthosting.co.za>
Message-ID: <1438786135.13.0.789014098533.issue24796@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I wonder if it is a left-over from the behaviour prior to 3.2? In 3.1, I
get this syntax error:

py> def outer():
...     spam = 1
...     def inner():
...             nonlocal spam
...             del spam
...     inner()
...
SyntaxError: can not delete variable 'spam' referenced in nested scope

See also the "Changed in 3.2" comment here:

https://docs.python.org/3/reference/simple_stmts.html#the-del-statement

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Wed Aug  5 16:51:51 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 14:51:51 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438786311.16.0.572674033564.issue24129@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able to make these docs completely intuitive (as name resolution is genuinely complex), but Ivan's revisions at least mean we're no longer assuming readers know how the name resolution worked prior to the introduction of lexical scoping, and a couple of tricky cases now have inline examples.

I also noticed an existing paragraph in the docs that *I* didn't understand, and filed issue #24796 to cover that. I'm not sure if we should just delete the paragraph, or if we accidentally dropped a compile time error check that didn't have any tests to ensure we were detecting the problem.

----------

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

From report at bugs.python.org  Wed Aug  5 16:53:17 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 14:53:17 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438786397.05.0.233099533648.issue24129@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
Removed message: http://bugs.python.org/msg248043

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

From report at bugs.python.org  Wed Aug  5 16:55:23 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 14:55:23 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438786523.22.0.0787859814139.issue24791@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Actually, I think `star_expr` will probably go away entirely.

I'm not so concerned with supporting [*[] or []] stuff, but rather fixing the immediate regression in 3.5.0.  I'd keep the patch size to the minimum.

----------

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

From report at bugs.python.org  Wed Aug  5 16:55:27 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 14:55:27 +0000
Subject: [issue24129] Incorrect (misleading) statement in the execution model
 documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1438786527.79.0.714181884339.issue24129@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The issue tracker was having issues and didn't automatically register the commits. Links:

3.4: https://hg.python.org/cpython/rev/94e215a5e24b
3.5: https://hg.python.org/cpython/rev/5e4d21311772
default: https://hg.python.org/cpython/rev/e75881393cf2

----------

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

From report at bugs.python.org  Wed Aug  5 17:00:37 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Wed, 05 Aug 2015 15:00:37 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438786837.67.0.60201255023.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

@Ivan, I'll work on the remaining half.

----------

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

From report at bugs.python.org  Wed Aug  5 17:08:10 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 05 Aug 2015 15:08:10 +0000
Subject: [issue24796] Deleting names referencing from enclosed and enclosing
 scopes
In-Reply-To: <1438779917.48.0.0299421063838.issue24796@psf.upfronthosting.co.za>
Message-ID: <1438787290.56.0.86322269092.issue24796@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

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

From report at bugs.python.org  Wed Aug  5 17:18:45 2015
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 05 Aug 2015 15:18:45 +0000
Subject: [issue24797] email.header.decode_header return type is not consistent
Message-ID: <1438787925.35.0.0505694721939.issue24797@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

The return type of email.header.decode_header is not consistent. When there are encoded parts the return type is a list of (bytes, charset or None) (Note that the documentation says it is a list of (str, charset)). However, when there are no encoded parts the return type is [(str, None)]. Note that, at the end of the function, there is a routine that converts everything to bytes.

Compare:
In [01]: email.header.decode_header('=?UTF-8?Q?foo?=bar')
Out[01]: [(b'foo', 'utf-8'), (b'bar', None)]

In [02]: email.header.decode_header('foobar')
Out[02]: [('foobar', None)]

----------
messages: 248047
nosy: Sebastian Kreft
priority: normal
severity: normal
status: open
title: email.header.decode_header return type is not consistent
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 17:31:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Aug 2015 15:31:06 +0000
Subject: [issue24797] email.header.decode_header return type is not consistent
In-Reply-To: <1438787925.35.0.0505694721939.issue24797@psf.upfronthosting.co.za>
Message-ID: <1438788666.01.0.00872927721095.issue24797@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +email
nosy: +barry, r.david.murray
type:  -> behavior

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

From report at bugs.python.org  Wed Aug  5 17:45:48 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 15:45:48 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1438789548.81.0.0754309553455.issue23749@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I'm working on porting pypostgresql (pure python postgresql driver) library to use asyncio as its underlying IO machinery.  And it appears that PQ3 protocol starts as clear text, and then upgrades to use TLS (if server or connection configured so).

I've been experimenting with various approaches to how we can design an API for this, and below are some of my thoughts:

1. The API cannot be implemented on event loop. Loops generally know nothing about the internal structure of transports, i.e. what loop or protocol the transport is attached to.

2. The API cannot be implemented on protocols. Protocols are decoupled from transports (they only receive a reference to the corresponding transport in their connection_made method). Access to the transport is requires to create an SSL proxy transport/protocol pair.

3. Therefore, the most convenient place to add the new API are *transports*. I propose to add a 'start_ssl' method to transports with the following signature:

        def start_ssl(self, sslcontext=None,
                      server_side=False, server_hostname=None) -> Transport:

It will only be implemented on Python 3.5 (because of SSL MemoryBIO requirement).

Protocols can call 'start_ssl' any time after 'connection_made' is called. 'start_ssl' returns a new Transport (ssl proxy) that has to be used from that moment on.  In case the SSL handshake fails, protocol's 'connection_lost' method will be called.

----------

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

From report at bugs.python.org  Wed Aug  5 17:49:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 15:49:44 +0000
Subject: [issue24797] email.header.decode_header return type is not consistent
In-Reply-To: <1438787925.35.0.0505694721939.issue24797@psf.upfronthosting.co.za>
Message-ID: <1438789784.59.0.489043442254.issue24797@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, don't use that, use the new APIs.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> email.header.decode_header sometimes returns bytes, sometimes str

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

From report at bugs.python.org  Wed Aug  5 17:50:55 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:50:55 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1438789855.07.0.552740110345.issue24792@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, gregory.p.smith, ncoghlan, superluser, twouters

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

From report at bugs.python.org  Wed Aug  5 17:51:29 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:51:29 +0000
Subject: [issue19699] Update zipimport for PEP 451
In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za>
Message-ID: <1438789889.13.0.673967865913.issue19699@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +gregory.p.smith, superluser, twouters

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

From report at bugs.python.org  Wed Aug  5 17:52:03 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:52:03 +0000
Subject: [issue23734] zipimport should not check pyc timestamps against zipped
 py files
In-Reply-To: <1426964347.09.0.21067648462.issue23734@psf.upfronthosting.co.za>
Message-ID: <1438789923.52.0.843334261562.issue23734@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan, superluser
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Wed Aug  5 17:52:10 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:52:10 +0000
Subject: [issue19699] Update zipimport for PEP 451
In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za>
Message-ID: <1438789930.38.0.608409881493.issue19699@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Wed Aug  5 17:52:21 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:52:21 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1438789941.46.0.112050999633.issue24792@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 17:52:43 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:52:43 +0000
Subject: [issue23327] zipimport to import from non-ascii pathname on Windows
In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za>
Message-ID: <1438789963.62.0.63290907798.issue23327@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow, superluser

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

From report at bugs.python.org  Wed Aug  5 17:53:08 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:53:08 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1438789988.49.0.501574166371.issue19883@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow, superluser

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

From report at bugs.python.org  Wed Aug  5 17:53:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:53:32 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1438790012.97.0.866782546384.issue5950@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Wed Aug  5 17:53:39 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:53:39 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1438790019.67.0.391198405883.issue19883@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.6

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

From report at bugs.python.org  Wed Aug  5 17:54:28 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:54:28 +0000
Subject: [issue23327] zipimport to import from non-ascii pathname on Windows
In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za>
Message-ID: <1438790068.19.0.208059806484.issue23327@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
type: crash -> behavior
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 17:55:39 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:55:39 +0000
Subject: [issue21062] Evalute all import-related modules for best practices
In-Reply-To: <1395763138.25.0.943943141564.issue21062@psf.upfronthosting.co.za>
Message-ID: <1438790139.34.0.12503644196.issue21062@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser

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

From report at bugs.python.org  Wed Aug  5 17:58:01 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:58:01 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1438790281.36.0.236950559023.issue1116520@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Wed Aug  5 17:58:39 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:58:39 +0000
Subject: [issue17004] Expand zipimport to include other compression methods
In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za>
Message-ID: <1438790319.29.0.963423560621.issue17004@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Wed Aug  5 17:59:18 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:59:18 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1438790358.5.0.536006716253.issue19081@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser
versions: +Python 3.6 -Python 3.3

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

From report at bugs.python.org  Wed Aug  5 17:59:43 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 15:59:43 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1438790383.05.0.59448713993.issue14678@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser
versions: +Python 3.6 -Python 3.3

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

From report at bugs.python.org  Wed Aug  5 18:00:31 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:00:31 +0000
Subject: [issue16651] Find out what stdlib modules lack a pure Python
 implementation
In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za>
Message-ID: <1438790431.16.0.286190791221.issue16651@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Wed Aug  5 18:01:20 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:01:20 +0000
Subject: [issue8400] zipimporter find_module fullname mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1438790480.84.0.987835620286.issue8400@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +brett.cannon, gregory.p.smith, superluser

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

From report at bugs.python.org  Wed Aug  5 18:01:37 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:01:37 +0000
Subject: [issue8400] zipimporter find_module fullname mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1438790497.62.0.354619154397.issue8400@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2

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

From report at bugs.python.org  Wed Aug  5 18:02:12 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:02:12 +0000
Subject: [issue15713] PEP 3121, 384 Refactoring applied to zipimport module
In-Reply-To: <1345154035.4.0.564693100383.issue15713@psf.upfronthosting.co.za>
Message-ID: <1438790532.92.0.06943977008.issue15713@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +brett.cannon, gregory.p.smith, superluser
stage:  -> patch review
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Wed Aug  5 18:06:15 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:06:15 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1438790775.61.0.52354599534.issue14905@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +superluser
versions: +Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug  5 18:06:49 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:06:49 +0000
Subject: [issue17633] zipimport's handling of namespace packages is incorrect
In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za>
Message-ID: <1438790809.16.0.822834396689.issue17633@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Wed Aug  5 18:07:07 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:07:07 +0000
Subject: [issue17633] zipimport's handling of namespace packages is incorrect
In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za>
Message-ID: <1438790827.81.0.847503153252.issue17633@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Wed Aug  5 18:07:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 16:07:32 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1438790852.14.0.0736842734454.issue14905@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Wed Aug  5 18:25:34 2015
From: report at bugs.python.org (gladman)
Date: Wed, 05 Aug 2015 16:25:34 +0000
Subject: [issue24798] Issue in the MSVC compiler class in distutils on Python
 3.5
Message-ID: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>


New submission from gladman:

I have been using _msvcompiler.py from Python 3.5 to build some executables but I have been unable to get it to generate and embed a  manifest.  

When I looked into this I found that the subroutine that sets up the parameters for generating a manifest ('manifest_get_embed_info'  at around line 471) has the line:

        ld_args.append('/MANIFESTFILE:' + temp_manifest)

to set the manifest's name but doesn't actually ask for a manifest to be generated.  Here is what is said about /MANIFESTFILE on MSDN:

"/MANIFESTFILE will have no effect if you do not also link with /MANIFEST."

After adding:

        ld_args.append('/MANIFEST')

before the above line, I then succeed in obtaining the manifest.

----------
components: Distutils
messages: 248050
nosy: dstufft, eric.araujo, gladman
priority: normal
severity: normal
status: open
title: Issue in the MSVC compiler class in distutils on Python 3.5
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug  5 18:47:55 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Aug 2015 16:47:55 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1438793275.12.0.719642237054.issue24798@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> steve.dower
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
title: Issue in the MSVC compiler class in distutils on Python 3.5 -> _msvccompiler.py doesn't properly support manifests
versions: +Python 3.6

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

From report at bugs.python.org  Wed Aug  5 19:15:53 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2015 17:15:53 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1438794953.86.0.594772950538.issue23749@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Why does the start_tls() function need to know the internal structure of the Transport? I'm hesitant to add this API to Transport; it somehow feels wrong to put such an implementation-specific thing there. E.g. I presume you can't do this for an UDP transport. Or perhaps it could be an API on a subclass of Transport -- then only members of that subclass will support this API.

----------

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

From report at bugs.python.org  Wed Aug  5 19:21:44 2015
From: report at bugs.python.org (Al Sweigart)
Date: Wed, 05 Aug 2015 17:21:44 +0000
Subject: [issue24759] Idle: add ttk widgets as an option
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1438795304.59.0.473136901185.issue24759@psf.upfronthosting.co.za>


Changes by Al Sweigart <asweigart at gmail.com>:


----------
nosy: +Al.Sweigart

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

From report at bugs.python.org  Wed Aug  5 19:28:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 17:28:07 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1438795687.01.0.0896900112625.issue24798@psf.upfronthosting.co.za>


Steve Dower added the comment:

It looks like manifests aren't generated with CRT version info anymore either, so I'll take this opportunity to clean up the build process some more too.

----------

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

From report at bugs.python.org  Wed Aug  5 19:38:37 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 17:38:37 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1438796317.75.0.0751067768318.issue23749@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Why does the start_tls() function need to know the internal structure of the Transport? 

If start_tls() is added to the loop, it will (likely) have the following signature:

    loop.start_tls(transport)

then I'd want it to check if the `transport` is on the same event loop, and after that we'll need to patch 'transport._protocol' with an `SSLProtocol` wrapper.  This requires adding 'get_loop()', 'get_protocol()' and 'set_protocol()' methods to transports (the latter one is kind of useless for anything but 'start_tls').

We can't implement 'loop.start_tls(protocol)', because protocols don't store a reference to their transports.

> I'm hesitant to add this API to Transport; it somehow feels wrong to put such an implementation-specific thing there. E.g. I presume you can't do this for an UDP transport. Or perhaps it could be an API on a subclass of Transport -- then only members of that subclass will support this API.

We can add a special subclass of Transport -- TLSTransport (that's how it's done in Twisted, btw: http://goo.gl/iAziWY) with 'start_tls' method raising 'NotImplementedError'.  We can later inherit _SelectorSocketTransport and _ProactorSocketTransport classes from it, implementing the method in Python 3.5.

----------

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

From report at bugs.python.org  Wed Aug  5 19:49:56 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2015 17:49:56 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1438796317.75.0.0751067768318.issue23749@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKnJBGq8OVhiLY4Q72Buhew_xPd_5aXhbupdSTaJCeYBw@mail.gmail.com>


Guido van Rossum added the comment:

OK, got it. SGTM.

----------

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

From report at bugs.python.org  Wed Aug  5 19:59:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 17:59:05 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <20150805175901.41825.76345@psf.io>


Roundup Robot added the comment:

New changeset 7aa2d3e1c885 by Yury Selivanov in branch '3.4':
Issue #23812: Fix asyncio.Queue.get() to avoid loosing items on cancellation.
https://hg.python.org/cpython/rev/7aa2d3e1c885

New changeset d5644d7e222d by Yury Selivanov in branch '3.5':
Issue #23812: Fix asyncio.Queue.get() to avoid loosing items on cancellation.
https://hg.python.org/cpython/rev/d5644d7e222d

New changeset 8f581da70ccd by Yury Selivanov in branch 'default':
Issue #23812: Fix asyncio.Queue.get() to avoid loosing items on cancellation.
https://hg.python.org/cpython/rev/8f581da70ccd

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug  5 19:59:43 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 17:59:43 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438797583.63.0.401498519719.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The fix is committed. Closing the issue. Thanks a lot, Gustavo!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Aug  5 20:47:23 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 18:47:23 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1438800443.15.0.322896434305.issue24798@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've simplified the manifest handling:

* embed by default, since we no longer need to filter CRT SxS info
* omit UAC info from DLLs
* use full PATH when running tools
* some other tidying

Not necessarily going to wait for lots of reviews, as I know very few people are interested in distutils, but feel free to chime in if you like. I'll give it a day or so.

----------
keywords: +patch
Added file: http://bugs.python.org/file40130/24798_1.patch

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

From report at bugs.python.org  Wed Aug  5 20:58:52 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Wed, 05 Aug 2015 18:58:52 +0000
Subject: [issue24778] mailcap.findmatch() ........ Shell Command Injection in
 filename
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438801132.83.0.00982960038434.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

# for the docs ... quoting of the filename when you call mailcap.findmatch()

f=";xterm;#.txt" # Shell Command Demo ... xterm will run if quote() fails

import mailcap
import random
try:
  from shlex import quote
except ImportError:
  from pipes import quote
d=mailcap.getcaps()
PY=''.join(random.choice('PYTHON') for i in range(100))
cmd,MIMEtype=mailcap.findmatch(d, 'text/plain', filename=PY)
while "'"+PY+"'" in cmd:
   cmd=cmd.replace("'"+PY+"'",quote(f))
while PY in cmd:
   cmd=cmd.replace(PY,quote(f))
print(cmd)  
# less ';xterm;#.txt'

----------

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

From report at bugs.python.org  Wed Aug  5 21:05:39 2015
From: report at bugs.python.org (Al Sweigart)
Date: Wed, 05 Aug 2015 19:05:39 +0000
Subject: [issue24799] IDLE should detect changes to open files by other
 processes
Message-ID: <1438801539.3.0.903562604709.issue24799@psf.upfronthosting.co.za>


New submission from Al Sweigart:

Many IDEs will check for changes to their opened files made by other programs. This is usually done with a quick check when the IDE's window gets focus.

A dialog will tell the user the file has changed on disk and ask if they want to reload it. This dialog is only shown when the file has changed AND there are unsaved changes made in the editor. Otherwise, the file changes are just silently reloaded. (This is the behavior of Sublime Text.)

----------
components: IDLE
messages: 248059
nosy: Al.Sweigart
priority: normal
severity: normal
status: open
title: IDLE should detect changes to open files by other processes
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 21:17:56 2015
From: report at bugs.python.org (Ethan Henderson)
Date: Wed, 05 Aug 2015 19:17:56 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438802276.16.0.64362510257.issue22329@psf.upfronthosting.co.za>


Ethan Henderson added the comment:

I have the same issue on 3.4.3 x64 on Windows 10 x64.

I set PYTHONHOME and PYTHONPATH (Just to C:/Python34), but that didn't fix the problem.

----------
nosy: +Zbee

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

From report at bugs.python.org  Wed Aug  5 21:18:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 19:18:59 +0000
Subject: [issue24778] mailcap.findmatch: document shell command Injection
 danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438802339.34.0.855174392427.issue24778@psf.upfronthosting.co.za>


R. David Murray added the comment:

I have no idea what your code samples are trying to accomplish, I'm afraid, but that's not the kind of documentation I'm advocating anyway.

----------
title: mailcap.findmatch()   ........ Shell Command Injection in filename -> mailcap.findmatch: document shell command Injection danger in filename parameter

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

From report at bugs.python.org  Wed Aug  5 21:32:42 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Wed, 05 Aug 2015 19:32:42 +0000
Subject: [issue24778] mailcap.findmatch: document shell command Injection
 danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438803162.34.0.530396020897.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

What i do is the last doc is like this :

1) Replace the filename with a random name
2) Run mailcap.findmatch() with the random name
3) If exists, replace the quote characters ' before and behind the random name with nothing.
4) Now the random name has no quoting from mailcap itself
5) So now we can use our own quote() savely

----------

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

From report at bugs.python.org  Wed Aug  5 21:37:06 2015
From: report at bugs.python.org (Fabian)
Date: Wed, 05 Aug 2015 19:37:06 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438803426.46.0.363531015279.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Thank you for figuring it out and providing a patch after I couldn't really give good information. I haven't been able to test it for myself but your explanation makes sense :)

----------

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

From report at bugs.python.org  Wed Aug  5 21:44:41 2015
From: report at bugs.python.org (Peter Eastman)
Date: Wed, 05 Aug 2015 19:44:41 +0000
Subject: [issue24800] Incorrect handling of local variables in comprehensions
 with exec()
Message-ID: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>


New submission from Peter Eastman:

The following script demonstrates a bug in the exec() function in Python 3.4.  (It works correctly in 2.7).

script = """
print(a)
print([a for i in range(5)])
"""
exec(script, globals(), {"a":5})

It produces the following output:

5
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    exec(script, globals(), {"a":5})
  File "<string>", line 3, in <module>
  File "<string>", line 3, in <listcomp>
NameError: name 'a' is not defined

The variable "a" is getting passed to the script, as expected: printing it out works correctly.  But if you use it in a comprehension, the interpreter claims it does not exist.

----------
messages: 248064
nosy: Peter Eastman
priority: normal
severity: normal
status: open
title: Incorrect handling of local variables in comprehensions with exec()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug  5 21:48:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 19:48:24 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438804104.54.0.858706203082.issue22329@psf.upfronthosting.co.za>


Steve Dower added the comment:

+Martin, who apparently never made it onto nosy.

You should clear those variables, run a Repair, and then uninstall. This error typically is because pip has become corrupted and cannot be removed.

This does not affect Python 3.5 or later.

----------
nosy: +loewis
versions:  -Python 3.5

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

From report at bugs.python.org  Wed Aug  5 21:51:37 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 05 Aug 2015 19:51:37 +0000
Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete
 statement parsing for detection
In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za>
Message-ID: <1438804297.74.0.659269090281.issue21718@psf.upfronthosting.co.za>


Robert Collins added the comment:

@Gerhard would you like that ported to cPython for you?

@Tom - I think that if the patch applies to 2.7.x we should apply it there since its very unlikely to break non-buggy code.

----------
nosy: +rbcollins
versions: +Python 3.6

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

From report at bugs.python.org  Wed Aug  5 21:55:54 2015
From: report at bugs.python.org (Ethan Henderson)
Date: Wed, 05 Aug 2015 19:55:54 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438804554.74.0.89629774713.issue22329@psf.upfronthosting.co.za>


Ethan Henderson added the comment:

I deleted those variables and tried running a repair but still got the "specified account already exists" schpeel.
I then tried running an uninstall and got the same error as last time there too.

There's presently no pip at all; there is no python folder on C:/.

----------

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

From report at bugs.python.org  Wed Aug  5 21:57:15 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 05 Aug 2015 19:57:15 +0000
Subject: [issue13224] Change str(x) to return only the qualname for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1438804635.22.0.142167366382.issue13224@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Wed Aug  5 21:58:18 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 19:58:18 +0000
Subject: [issue24800] Incorrect handling of local variables in comprehensions
 with exec()
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438804698.33.0.705160061364.issue24800@psf.upfronthosting.co.za>


R. David Murray added the comment:

exec is subtle.  See the explanation linked from issue 23087, which while not *exactly* on point explains the underlying problem (a comprehension is a new scope, and exec can't reach an intermediate scope the way a compiled function can).

As far as the difference from 2.7 goes, the scoping rules for comprehensions changed in python3: the variable you are concerned with is now part of the local scope.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> Exec variable not found error

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

From report at bugs.python.org  Wed Aug  5 22:00:29 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 05 Aug 2015 20:00:29 +0000
Subject: [issue13224] Change str(x) to return only the qualname for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1438804829.16.0.175262636626.issue13224@psf.upfronthosting.co.za>


Robert Collins added the comment:

The patch is a little stale but it seems easy enough to fix up. I'll commit it tomorrowish in the absence of other discussion.

----------

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

From report at bugs.python.org  Wed Aug  5 22:06:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 20:06:33 +0000
Subject: [issue24778] mailcap.findmatch: document shell command Injection
 danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438805193.33.0.592750187523.issue24778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, that's a clever idea.

----------

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

From report at bugs.python.org  Wed Aug  5 22:09:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 05 Aug 2015 20:09:28 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1438805368.08.0.508315387581.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Yup. Revised extdlg-sorted.patch attached.  Thanks for noticing that!

----------
Added file: http://bugs.python.org/file40131/extdlg-sorted.patch

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

From report at bugs.python.org  Wed Aug  5 22:16:44 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 05 Aug 2015 20:16:44 +0000
Subject: [issue24370] OrderedDict behavior is unclear with misbehaving keys.
In-Reply-To: <1433300480.06.0.538096094872.issue24370@psf.upfronthosting.co.za>
Message-ID: <1438805804.94.0.617997202627.issue24370@psf.upfronthosting.co.za>


Eric Snow added the comment:

Fair enough.

----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Aug  5 22:22:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 20:22:42 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438806162.81.0.243098895731.issue22329@psf.upfronthosting.co.za>


Steve Dower added the comment:

I need to see the detailed log to be any more helpful. Can you try running this command and post the log here:

msiexec /l*vx log.txt /x {9529565F-E693-3F11-B3BF-8CD545F5F9A0}

(Note that the UUID is different from earlier because it matches 3.4.3.amd64 and the previous was for another version)

----------

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

From report at bugs.python.org  Wed Aug  5 22:26:43 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Wed, 05 Aug 2015 20:26:43 +0000
Subject: [issue24778] mailcap.findmatch: document shell command Injection
 danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1438806403.81.0.345083543282.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

Thanks :-)

As you may noticed i now choosed to use a random name made of the chars of "PYTHON" in BIG letters instead of small letters i used before.

Thats because i do not want to get in trouble with the little "t" in %t wich is replaced by the subst function too.

----------

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

From report at bugs.python.org  Wed Aug  5 22:33:59 2015
From: report at bugs.python.org (Peter Eastman)
Date: Wed, 05 Aug 2015 20:33:59 +0000
Subject: [issue24800] Incorrect handling of local variables in comprehensions
 with exec()
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438806839.14.0.828241700546.issue24800@psf.upfronthosting.co.za>


Peter Eastman added the comment:

I don't believe that explanation is correct.  You can just as easily get the same problem without explicitly passing a map to exec().  For example:

def f():
    script = """
print(a)
print([a for i in range(5)])
    """
    a = 5
    exec(script)
    
f()

The documentation for exec() states, "In all cases, if the optional parts are omitted, the code is executed in the current scope."  Therefore the code above should be exactly equivalent to the following:

def f():
    a = 5
    print(a)
    print([a for i in range(5)])
    
f()

But the latter works and the former doesn't.  Contrary to the documentation, the code is clearly not being executed in the same scope.

----------
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Wed Aug  5 22:42:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 20:42:01 +0000
Subject: [issue24800] Incorrect handling of local variables in comprehensions
 with exec()
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438807321.07.0.365606208139.issue24800@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes it is.  The comprehension is a *new* scope, within the outer scope of the exec, and it *cannot see* the variables in the outer scope of the exec.  You have the same problem if you try to use a comprehension in that way in a class statement at the class level.  An exec is explicitly *not* equivalent to a function body.  It is equivalent to operating in a class body, if you give it two namespaces, and in a global context if you give it one.  This is documented.

Please don't reopen the issue.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Aug  5 22:48:22 2015
From: report at bugs.python.org (Peter Eastman)
Date: Wed, 05 Aug 2015 20:48:22 +0000
Subject: [issue24800] Incorrect handling of local variables in comprehensions
 with exec()
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438807702.34.0.656039705623.issue24800@psf.upfronthosting.co.za>


Peter Eastman added the comment:

Then fix the documentation.  This behavior directly contradicts the documentation of the exec() function.  The question is not what scope the comprehension runs in, it's what scope the script runs in.  See my third example.  A comprehension in the f() function has no problem seeing local variables defined in that function.  If the script were running into the same scope as that function, then comprehensions inside the script would also see those variables.  They don't, clearly demonstrating that the script does *not* run in the same scope, and contradicting the documentation.

----------
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Wed Aug  5 22:52:28 2015
From: report at bugs.python.org (Ethan Henderson)
Date: Wed, 05 Aug 2015 20:52:28 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438807948.63.0.599932030934.issue22329@psf.upfronthosting.co.za>


Ethan Henderson added the comment:

Running that in my command prompt outputs "Access is denied," even after disabling UAC.
Running that in bash just gives me a popup for Windows Installer.

Is the UUID going to be different for 3.4.3 intel x64 (I have intel, not amd)?

----------

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

From report at bugs.python.org  Wed Aug  5 23:06:35 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 21:06:35 +0000
Subject: [issue24800] exec docs should note that the no argument form in a
 local scope is really the two argument form
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438808795.56.0.415703460865.issue24800@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, it looks like what the documentation of exec is missing is the fact that calling exec with no arguments in a non-global is equivalent to calling it with *two* arguments.  That is, your "exec(script)" statement is equivalent to "exec(script, globals(), locals())".  This is implicit but very much *not* explicit in the current documentation, and should be made explicit.

To be sure I'm explaining this fully: the documentation of exec says  "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition".

>>> class Foo:
...   a = 10
...   [a for x in range(5)]
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in Foo
  File "<stdin>", line 3, in <listcomp>
NameError: name 'a' is not defined

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: resolved -> needs patch
title: Incorrect handling of local variables in comprehensions with exec() -> exec docs should note that the no argument form in a local scope is really the two argument form

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

From report at bugs.python.org  Wed Aug  5 23:06:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Aug 2015 21:06:48 +0000
Subject: [issue24800] exec docs should note that the no argument form in a
 local scope is really the two argument form
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438808808.54.0.352249027072.issue24800@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug  5 23:39:03 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 21:39:03 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438810743.33.0.639290784384.issue24667@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Wed Aug  5 23:43:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 21:43:34 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438811014.34.0.379205382206.issue22329@psf.upfronthosting.co.za>


Steve Dower added the comment:

Start from an elevated command prompt. There's only one 64-bit build, so that'll be it. Our name for it is amd64, even though it applies to both Intel and AMD.

----------

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

From report at bugs.python.org  Wed Aug  5 23:49:25 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 05 Aug 2015 21:49:25 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1438811365.96.0.483133559588.issue15663@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I'd like to revisit this, particularly in the context of some of the discussions regarding future improvements of IDLE.

Assume we have a barebones Tcl/Tk framework build of e.g. 8.6.4 as part of the installer (core Tcl/Tk, not like e.g. ActiveTcl).

Would something like this work?

1. if just system Tcl/Tk already installed (/System/Library/Frameworks), install new /Library/Frameworks/Tcl.framework and /Library/Frameworks/Tk.framework

2. if /Library/Frameworks/Tcl.framework is installed, but doesn't have 8.6.x (e.g. may have Versions/8.4), add the new version into the existing framework, so we'd then have a 8.4.x and a 8.6.4 installed

3. if there's already /Library/Frameworks/Tcl.framework/Versions/8.6 and it's a lower version (e.g. 8.6.1) we could simply nag them in the installer to consider upgrading on their own (the theory being that if they've installed it once somehow they can most likely do it again with a newer version of whatever they have)

This way if there's any existing Tcl/Tk there that other things are linking against, it shouldn't get disturbed. Possible, or just wishful thinking?

----------
nosy: +markroseman, terry.reedy

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

From report at bugs.python.org  Wed Aug  5 23:55:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 21:55:33 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <20150805215527.29392.11641@psf.io>


Roundup Robot added the comment:

New changeset e4cb64628673 by Yury Selivanov in branch '3.5':
Issue #24791: Fix grammar regression for call syntax: 'g(*a or b)'.
https://hg.python.org/cpython/rev/e4cb64628673

New changeset 4c89dd5199e5 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24791)
https://hg.python.org/cpython/rev/4c89dd5199e5

----------

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

From report at bugs.python.org  Thu Aug  6 00:00:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Aug 2015 22:00:39 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <20150805220036.5517.34189@psf.io>


Roundup Robot added the comment:

New changeset 40c391d12741 by Yury Selivanov in branch '3.5':
Issue #24791: More tests in test_parser
https://hg.python.org/cpython/rev/40c391d12741

New changeset a572137b4f05 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24791; more tests in test_parser)
https://hg.python.org/cpython/rev/a572137b4f05

----------

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

From report at bugs.python.org  Thu Aug  6 00:01:00 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 05 Aug 2015 22:01:00 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <1438812060.78.0.0695904570326.issue24791@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Aug  6 00:02:38 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 05 Aug 2015 22:02:38 +0000
Subject: [issue24391] Better repr for threading objects
In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za>
Message-ID: <1438812158.1.0.788075693029.issue24391@psf.upfronthosting.co.za>


Robert Collins added the comment:

So, I think the majority opinion seems to be:
<module.type at address value1, value2, ...>

AIUI the patch doesn't quite do that, so I'm going to pop this back to patch review.

That said, Serhiy, if you fix it up, just commit it please :)

----------
nosy: +rbcollins
stage: commit review -> patch review

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

From report at bugs.python.org  Thu Aug  6 00:06:23 2015
From: report at bugs.python.org (Ethan Henderson)
Date: Wed, 05 Aug 2015 22:06:23 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438812383.75.0.336382085562.issue22329@psf.upfronthosting.co.za>


Ethan Henderson added the comment:

My log.txt: http://puu.sh/jqLWR.txt

Turns out that my antivirus was blocking that command from running before.

----------

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

From report at bugs.python.org  Thu Aug  6 00:42:09 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Aug 2015 22:42:09 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438814529.39.0.498717476813.issue22329@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks. Unfortunately I can't get anything helpful from that log because it's failing too early. It seems like you have some corruption in your Windows installer database, since it isn't even getting far enough into the Python installer. I'd track down a troubleshooter or reputable system cleaner and see if you can clean up your system.

----------

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

From report at bugs.python.org  Thu Aug  6 01:17:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Aug 2015 23:17:50 +0000
Subject: [issue24795] Make event loops with statement context managers
In-Reply-To: <CAP7+vJLpXvaOeah3b+MKRMawc60CfHBj81hCf8k8KdwKG5Dsqg@mail.gmail.com>
Message-ID: <CAMpsgwZfB8eDU0UTKODEon-HtqdQkh6-x8BUA=uR5=mzg1D2yg@mail.gmail.com>


STINNER Victor added the comment:

+1 for me. Asyncio examples already have this try/finally pattern. I
already proposed to support context manager some months ago.

Guido, I don't understand your point. Usually the main function id
loop.run_until_complete/.run_forever. That's all. It doesn't mean that the
loop only runs a few milliseconds.

----------

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

From report at bugs.python.org  Thu Aug  6 02:15:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Aug 2015 00:15:52 +0000
Subject: [issue13224] Change str(x) to return only the qualname for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1438820152.5.0.7399726334.issue13224@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m a bit confused. In the current patch, the new type_str() function appears to use the ?qualname? (which I support), but some of the test changes seem to contradict this, e.g.:

 >>> C.foo(1)
-classmethod <class 'test.test_descrtut.C'> 1
+classmethod C 1

Also, I think this new feature should be documented.

----------

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

From report at bugs.python.org  Thu Aug  6 02:44:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Aug 2015 00:44:05 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438821845.38.0.0232146751723.issue15944@psf.upfronthosting.co.za>


Martin Panter added the comment:

In my experience, I tend to only use memoryview() for ?bytes-like? buffers (but see Issue 23756 about clarifying what this means). Example from /Lib/_compression.py:67:

def readinto(self, b):
    with memoryview(b) as view, view.cast("B") as byte_view:
        data = self.read(len(byte_view))
        byte_view[:len(data)] = data
    return len(data)

Fixing cast("B") or adding a memoryview(raw=True) mode could probably help when all you want is a byte buffer.

----------

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

From report at bugs.python.org  Thu Aug  6 02:57:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Aug 2015 00:57:53 +0000
Subject: [issue24795] Make event loops with statement context managers
In-Reply-To: <1438778311.28.0.548352526709.issue24795@psf.upfronthosting.co.za>
Message-ID: <1438822673.0.0.0953982247495.issue24795@psf.upfronthosting.co.za>


Martin Panter added the comment:

>From what I can see, the examples in the current documentation tend to diectly call loop.close() without an exception handler. Only two examples have the bare-bones try / finally handler (which is important for the example that uses Ctrl+C).

----------
nosy: +vadmium

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

From report at bugs.python.org  Thu Aug  6 03:08:48 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 06 Aug 2015 01:08:48 +0000
Subject: [issue24800] exec docs should note that the no argument form in a
 local scope is really the two argument form
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438823328.42.0.375857493154.issue24800@psf.upfronthosting.co.za>


eryksun added the comment:

> If exec gets two separate objects as globals and locals, 
> the code will be executed as if it were embedded in a 
> class definition.

Probably there needs to be more clarification of the compilation context. Class definitions support lexical closures, whereas source code passed to exec is compiled at the time of the call, independent of the lexical context. 

In the following example, the code objects for both the class body and the comprehension can access the free variable "a". In CPython, the class body references the free variable via the LOAD_CLASSDEREF op, and the comprehension uses the LOAD_DEREF op.

    def f():
       a = 5
       class C:
           print(a)
           print([a for i in range(5)])

    
    >>> f()
    5
    [5, 5, 5, 5, 5]
 
    >>> dis.dis(f.__code__.co_consts[2])
      3           0 LOAD_NAME                0 (__name__)
                  3 STORE_NAME               1 (__module__)
                  6 LOAD_CONST               0 ('f.<locals>.C')
                  9 STORE_NAME               2 (__qualname__)

      4          12 LOAD_NAME                3 (print)
                 15 LOAD_CLASSDEREF          0 (a)
                 18 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
                 21 POP_TOP

      5          22 LOAD_NAME                3 (print)
                 25 LOAD_CLOSURE             0 (a)
                 28 BUILD_TUPLE              1
                 31 LOAD_CONST               1 (<code object <listcomp> ...>)
                 34 LOAD_CONST               2 ('f.<locals>.C.<listcomp>')
                 37 MAKE_CLOSURE             0
                 40 LOAD_NAME                4 (range)
                 43 LOAD_CONST               3 (5)
                 46 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
                 49 GET_ITER
                 50 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
                 53 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
                 56 POP_TOP
                 57 LOAD_CONST               4 (None)
                 60 RETURN_VALUE

    >>> dis.dis(f.__code__.co_consts[2].co_consts[1])
      5           0 BUILD_LIST               0
                  3 LOAD_FAST                0 (.0)
            >>    6 FOR_ITER                12 (to 21)
                  9 STORE_FAST               1 (i)
                 12 LOAD_DEREF               0 (a)
                 15 LIST_APPEND              2
                 18 JUMP_ABSOLUTE            6
            >>   21 RETURN_VALUE

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Aug  6 03:36:03 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 01:36:03 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
Message-ID: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>


New submission from Mark Roseman:

For popup menus, control-click works, but right-click on mouse buttons that support it, doesn't work.

This is a followup to #10404, last addressed in 2010.

As noted there, right click behaviour should be supported.

The right click Tk text bindings on Mac (which is B2) seem to bind both to the virtual 'PasteSelection' event, and also to fast-scroll through a large file is you click and drag with the right mouse button. Both of these are blatant problems with Tk's text.tcl.

The issue when trying to fix this before was when a B2 (context menu) binding was added to the text widget, both that and the bogus B2 bindings fired. This is because Tk can fire multiple bindings for a widget (default is bindings for the widget itself, the widget's toplevel, the widget's class, and 'all'). 

There is a way to short-circuit this in Tcl (basically the widget-specific binding calls 'break', which prevents the others from firing). The simpler alternative is probably just redefining the alternative class-level (Text) bindings.

In other words, yeah, this should be pretty easily fixable.

----------
messages: 248092
nosy: markroseman, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: right-mouse click in IDLE on Mac doesn't work
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug  6 03:40:26 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 01:40:26 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1438825226.19.0.464318219348.issue24801@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
components: +IDLE

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

From report at bugs.python.org  Thu Aug  6 03:40:48 2015
From: report at bugs.python.org (Tiago Wright)
Date: Thu, 06 Aug 2015 01:40:48 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438728718.4.0.834365575859.issue24787@psf.upfronthosting.co.za>
Message-ID: <CAFxr9VppN__LfF5nKY-hkpK9m_N+rLh4n=A4X3wVuFCdic9dKg@mail.gmail.com>


Tiago Wright added the comment:

I've run the Sniffer against 1614 csv files on my computer and compared the
delimiter it detects to what I have set manually. Here are the results:

 Sniffer            Human,;\t\(blank)Error:)ceMpGrand TotalError rate,498  2
110  1   5122.7%; 1          10.0%\t3 922 69121  227105412.5%|   33
330.0%space    91   4  1435.7%Grand Total5011922351610221142271614
-Tiago

On Tue, Aug 4, 2015 at 3:51 PM R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> If you look at the algorithm it is doing some fancy things with metrics,
> but does have a 'preferred delimiters' list that it checks.  It is possible
> things could be improved either by tweaking the threshold or by somehow
> giving added weight to the metrics when the candidate character is in the
> preferred delimiter list.
>
> We might have to do this with a feature flag to turn it on, though, since
> it could change the results for programs that happen to work with the
> current algorithm.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24787>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Aug  6 04:42:46 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 06 Aug 2015 02:42:46 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438828966.31.0.360122507236.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

@Fabian, hey, thanks for bringing it to our attention!

----------

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

From report at bugs.python.org  Thu Aug  6 04:42:54 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 06 Aug 2015 02:42:54 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438828974.96.0.469229025102.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

If I don't get any feedback before then, I'll commit the patch on Friday.

----------

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

From report at bugs.python.org  Thu Aug  6 05:07:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Aug 2015 03:07:00 +0000
Subject: [issue18082] Inconsistent behavior of IOBase methods on closed files
In-Reply-To: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za>
Message-ID: <1438830420.89.0.488430810445.issue18082@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation <https://docs.python.org/dev/library/io.html#io.IOBase> says ?. . . calling any method (even inquiries) on a closed stream is undefined. Implementations may raise ValueError?. So IMO you shouldn?t rely on any particular success or failure behaviour of these methods when a stream is closed.

Having the stream methods waste time calling out to Python methods and descriptors like readable() and ?closed? all the time can make things unnecessarily slow and inefficient (see my work at the end of Issue 18003 for example). On the other hand, removing the existing checks could potentially break someone?s code. I suggest closing this, unless someone has a specific proposal or reason to change.

----------
nosy: +vadmium

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

From report at bugs.python.org  Thu Aug  6 05:14:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Aug 2015 03:14:22 +0000
Subject: [issue24800] exec docs should note that the no argument form in a
 local scope is really the two argument form
In-Reply-To: <1438803881.09.0.804532346481.issue24800@psf.upfronthosting.co.za>
Message-ID: <1438830862.58.0.606969445393.issue24800@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, yes, so "a class body at global scope" or something like that :)

LOAD_CLASSDEREF is another whole level of complication to the scoping weirdness for classes; see issue 19979 and issue 24129.

----------

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

From report at bugs.python.org  Thu Aug  6 05:14:47 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 06 Aug 2015 03:14:47 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438830887.32.0.58828832324.issue24787@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

Tiago, sorry, but your last post with results is completely unintelligible. Can you toss the table in a file and attach it instead?

----------

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

From report at bugs.python.org  Thu Aug  6 05:15:21 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:15:21 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
Message-ID: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>


New submission from John Leitch:

Python suffers from a buffer over-read in PyFloat_FromString() that is caused by the incorrect assumption that buffers returned by PyObject_GetBuffer() are null-terminated. This could potentially result in the disclosure of adjacent memory.

PyObject *
PyFloat_FromString(PyObject *v)
{
    const char *s, *last, *end;
    double x;
    PyObject *s_buffer = NULL;
    Py_ssize_t len;
    Py_buffer view = {NULL, NULL};
    PyObject *result = NULL;

    if (PyUnicode_Check(v)) {
        s_buffer = _PyUnicode_TransformDecimalAndSpaceToASCII(v);
        if (s_buffer == NULL)
            return NULL;
        s = PyUnicode_AsUTF8AndSize(s_buffer, &len);
        if (s == NULL) {
            Py_DECREF(s_buffer);
            return NULL;
        }
    }
    else if (PyObject_GetBuffer(v, &view, PyBUF_SIMPLE) == 0) {
        s = (const char *)view.buf; <<<< The unterminated buffer is retrieved here.
        len = view.len;
    }
    else {
        PyErr_Format(PyExc_TypeError,
            "float() argument must be a string or a number, not '%.200s'",
            Py_TYPE(v)->tp_name);
        return NULL;
    }
    last = s + len;
    /* strip space */
    while (s < last && Py_ISSPACE(*s))
        s++;
    while (s < last - 1 && Py_ISSPACE(last[-1]))
        last--;
    /* We don't care about overflow or underflow.  If the platform
     * supports them, infinities and signed zeroes (on underflow) are
     * fine. */
    x = PyOS_string_to_double(s, (char **)&end, NULL); <<<< The buffer is then passed
                                                            along here.
    if (end != last) {
        PyErr_Format(PyExc_ValueError,
                     "could not convert string to float: "
                     "%R", v);
        result = NULL;
    }
    else if (x == -1.0 && PyErr_Occurred())
        result = NULL;
    else
        result = PyFloat_FromDouble(x);

    PyBuffer_Release(&view);
    Py_XDECREF(s_buffer);
    return result;
}

double
PyOS_string_to_double(const char *s,
                      char **endptr,
                      PyObject *overflow_exception)
{
    double x, result=-1.0;
    char *fail_pos;

    errno = 0;
    PyFPE_START_PROTECT("PyOS_string_to_double", return -1.0)
    x = _PyOS_ascii_strtod(s, &fail_pos);
    PyFPE_END_PROTECT(x)

    if (errno == ENOMEM) {
        PyErr_NoMemory();
        fail_pos = (char *)s;
    }
    else if (!endptr && (fail_pos == s || *fail_pos != '\0'))
        PyErr_Format(PyExc_ValueError, <<<< If any of these error paths are taken, the
                                            unterminated buffer is passed along without
                                            its length, ultimately resulting in a call
                                            to unicode_fromformat_write_cstr().
                      "could not convert string to float: "
                      "%.200s", s);
    else if (fail_pos == s)
        PyErr_Format(PyExc_ValueError,
                      "could not convert string to float: "
                      "%.200s", s);
    else if (errno == ERANGE && fabs(x) >= 1.0 && overflow_exception)
        PyErr_Format(overflow_exception,
                      "value too large to convert to float: "
                      "%.200s", s);
    else
        result = x;

    if (endptr != NULL)
        *endptr = fail_pos;
    return result;
}

static int
unicode_fromformat_write_cstr(_PyUnicodeWriter *writer, const char *str,
                              Py_ssize_t width, Py_ssize_t precision)
{
    /* UTF-8 */
    Py_ssize_t length;
    PyObject *unicode;
    int res;

    length = strlen(str); <<<< str points to the unterminated buffer, which means 
                               strlen() my read off the end, depending on the contents
                               of adjacent memory.
    if (precision != -1)
        length = Py_MIN(length, precision);
    unicode = PyUnicode_DecodeUTF8Stateful(str, length, "replace", NULL); <<<< The new,
                                                                    incorrect length is
                                                                    passed along.
																		 
    if (unicode == NULL)
        return -1;

    res = unicode_fromformat_write_str(writer, unicode, width, -1);
    Py_DECREF(unicode);
    return res;
}

A script that reproduces the issue is as follows:

import array
float(array.array("B",b"A"*0x10))

And it produces the following exception:

0:000> gu
eax=00000000 ebx=06116b00 ecx=00000000 edx=00000000 esi=06116b00 edi=00000000
eip=6516be1b esp=0080f440 ebp=0080f4f4 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
python35!PyFloat_FromString+0xab:
6516be1b 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:0080f494=090a2fe8
0:000> db @@(view.buf)
090a2fe8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
090a2ff8  c0 c0 c0 c0 d0 d0 d0 d0-?? ?? ?? ?? ?? ?? ?? ??  ........????????
090a3008  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3018  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3028  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3038  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3048  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3058  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> g
(828.bec): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0080f4d0 ebx=0080f3a0 ecx=0080f3a0 edx=090a2fe8 esi=090a3000 edi=090a2fe9
eip=651ac280 esp=0080f31c ebp=0080f328 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
python35!unicode_fromformat_write_cstr+0x10:
651ac280 8a06            mov     al,byte ptr [esi]          ds:002b:090a3000=??
0:000> db esi-0x10
090a2ff0  41 41 41 41 41 41 41 41-c0 c0 c0 c0 d0 d0 d0 d0  AAAAAAAA........
090a3000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
090a3060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
python35!unicode_fromformat_write_cstr+10 [c:\build\cpython\objects\unicodeobject.c @ 2368]
651ac280 8a06            mov     al,byte ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 651ac280 (python35!unicode_fromformat_write_cstr+0x00000010)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 090a3000
Attempt to read from address 090a3000

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=0080f4d0 ebx=0080f3a0 ecx=0080f3a0 edx=090a2fe8 esi=090a3000 edi=090a2fe9
eip=651ac280 esp=0080f31c ebp=0080f328 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
python35!unicode_fromformat_write_cstr+0x10:
651ac280 8a06            mov     al,byte ptr [esi]          ds:002b:090a3000=??

FAULTING_THREAD:  00000bec

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  python.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  090a3000

READ_ADDRESS:  090a3000 

FOLLOWUP_IP: 
python35!unicode_fromformat_write_cstr+10 [c:\build\cpython\objects\unicodeobject.c @ 2368]
651ac280 8a06            mov     al,byte ptr [esi]

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

FAULTING_LOCAL_VARIABLE_NAME:  length

APP:  python.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 651ac6e9 to 651ac280

STACK_TEXT:  
0080f328 651ac6e9 ffffffff 000000c8 00000000 python35!unicode_fromformat_write_cstr+0x10
0080f384 651ac955 0080f39c 090a2fe8 65321778 python35!unicode_fromformat_arg+0x409
0080f3d8 651f1a1a 65321778 0080f404 090a2fe8 python35!PyUnicode_FromFormatV+0x65
0080f3f4 652070a9 6536bd38 65321778 090a2fe8 python35!PyErr_Format+0x1a
0080f42c 6516be70 090a2fe8 0080f484 00000000 python35!PyOS_string_to_double+0xa9
0080f4f4 6514808b 06116b00 6536d658 6536d658 python35!PyFloat_FromString+0x100
0080f554 6516e6e2 06116b00 06116b00 06116b00 python35!PyNumber_Float+0xcb
0080f568 65194e08 6536d658 0610e630 00000000 python35!float_new+0x72
0080f588 6514947d 6536d658 0610e630 00000000 python35!type_call+0x38
0080f5a4 651e49cc 6536d658 0610e630 00000000 python35!PyObject_Call+0x6d
0080f5d0 651e449c 00000001 0610e630 00000083 python35!do_call+0x11c
0080f600 651e18d8 060ceab0 00000000 00000040 python35!call_function+0x36c
0080f678 651e339f 060ceab0 00000000 08c73ff0 python35!PyEval_EvalFrameEx+0x2318
0080f6c4 6521a142 060eff58 00000000 00000000 python35!_PyEval_EvalCodeWithName+0x82f
0080f700 65219fd5 060eff58 060eff58 0080f7cc python35!run_mod+0x42
0080f72c 6521904a 06d40fc8 061571d0 00000101 python35!PyRun_FileExFlags+0x85
0080f770 650ef037 06d40fc8 061571d0 00000001 python35!PyRun_SimpleFileExFlags+0x20a
0080f79c 650ef973 0080f7cc 65492100 65492108 python35!run_file+0xe7
0080f840 1c4b143f 00000002 05e06f10 05e0cf48 python35!Py_Main+0x913
0080f88c 76323744 7ee8e000 76323720 ddf3f75b python!__scrt_common_main_seh+0xff
0080f8a0 7789a064 7ee8e000 16227053 00000000 KERNEL32!BaseThreadInitThunk+0x24
0080f8e8 7789a02f ffffffff 778bd7c3 00000000 ntdll!__RtlUserThreadStart+0x2f
0080f8f8 00000000 1c4b14f7 7ee8e000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  c:\build\cpython\objects\unicodeobject.c

FAULTING_SOURCE_FILE:  c:\build\cpython\objects\unicodeobject.c

FAULTING_SOURCE_LINE_NUMBER:  2368

FAULTING_SOURCE_CODE:  
  2364:     Py_ssize_t length;
  2365:     PyObject *unicode;
  2366:     int res;
  2367: 
> 2368:     length = strlen(str);
  2369:     if (precision != -1)
  2370:         length = Py_MIN(length, precision);
  2371:     unicode = PyUnicode_DecodeUTF8Stateful(str, length, "replace", NULL);
  2372:     if (unicode == NULL)
  2373:         return -1;


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python35!unicode_fromformat_write_cstr+10

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python35

IMAGE_NAME:  python35.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5598ccc2

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_python35.dll!unicode_fromformat_write_cstr

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_python35!unicode_fromformat_write_cstr+10

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_python35.dll!unicode_fromformat_write_cstr

FAILURE_ID_HASH:  {1d85cbc9-3259-9a7e-3da2-8540573292b2}

Followup: MachineOwner
---------

To fix the issue, it is recommended that PyFloat_FromString() check the type of argument v after a successful PyObject_GetBuffer() call to determine if the buffer is null-terminated or otherwise. A proposed patch is attached.

----------
files: PyFloat_FromString_Buffer_Over-read.patch
keywords: patch
messages: 248099
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: PyFloat_FromString Buffer Over-read
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file40132/PyFloat_FromString_Buffer_Over-read.patch

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

From report at bugs.python.org  Thu Aug  6 05:16:26 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:16:26 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>
Message-ID: <1438830986.23.0.260255434168.issue24802@psf.upfronthosting.co.za>


John Leitch added the comment:

Attaching repro

----------
Added file: http://bugs.python.org/file40133/PyFloat_FromString_Buffer_Over-read.py

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

From report at bugs.python.org  Thu Aug  6 05:18:43 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:18:43 +0000
Subject: [issue24803] PyNumber_Long Buffer Over-read.patch
Message-ID: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za>


New submission from John Leitch:

Python suffers from a buffer over-read in PyNumber_Long() that is caused by the incorrect assumption that buffers returned by PyObject_GetBuffer() are null-terminated. This could potentially result in the disclosure of adjacent memory.

PyObject *
PyNumber_Long(PyObject *o)
{
    [...]

    if (PyObject_GetBuffer(o, &view, PyBUF_SIMPLE) == 0) { <<<< The unterminated buffer 
                                                                is retreived here.
        /* need to do extra error checking that PyLong_FromString()
         * doesn't do.  In particular int('9\x005') must raise an
         * exception, not truncate at the null.
         */
        PyObject *result = _PyLong_FromBytes(view.buf, view.len, 10); <<<< The buffer
                                                is then passed to _PyLong_FromBytes(),
                                                which ultimately passes it to
                                                PyLong_FromString().
        PyBuffer_Release(&view);
        return result;
    }

    return type_error("int() argument must be a string, a bytes-like object "
                      "or a number, not '%.200s'", o);
}

PyObject *
PyLong_FromString(const char *str, char **pend, int base)
{
    int sign = 1, error_if_nonzero = 0;
    const char *start, *orig_str = str;
    PyLongObject *z = NULL;
    PyObject *strobj;
    Py_ssize_t slen;

    [...]

  onError:
    if (pend != NULL)
        *pend = (char *)str;
    Py_XDECREF(z);
    slen = strlen(orig_str) < 200 ? strlen(orig_str) : 200; <<<< If this path is taken,
                                                        orig_str is pointing to the
                                                        unterminated string, resulting in
														strlen reading off the end of the
                                                        buffer.
    strobj = PyUnicode_FromStringAndSize(orig_str, slen); <<<< The incorrect length is
	                                                      then used to create a Python
                                                          string.
    if (strobj == NULL)
        return NULL;
    PyErr_Format(PyExc_ValueError,
                 "invalid literal for int() with base %d: %.200R",
                 base, strobj);
    Py_DECREF(strobj);
    return NULL;
}

A script that reproduces the issue is as follows:

import array
int(array.array("B",b"A"*0x10))

And it produces the following exception:

0:000> p
eax=00000000 ebx=5dbc4699 ecx=00000000 edx=00000000 esi=07ad6b00 edi=00000000
eip=5da07f7e esp=00e4f8f8 ebp=00e4f934 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
python35!PyNumber_Long+0x20e:
5da07f7e 6a0a            push    0Ah
0:000> db @@(view.buf)
096fefe8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
096feff8  c0 c0 c0 c0 d0 d0 d0 d0-?? ?? ?? ?? ?? ?? ?? ??  ........????????
096ff008  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff018  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff028  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff038  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff048  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff058  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> g
Breakpoint 3 hit
eax=07aed7b0 ebx=0000000a ecx=07aed7a0 edx=07aed000 esi=096fefe8 edi=096fefe8
eip=5da3a55e esp=00e4f870 ebp=00e4f8c4 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
python35!PyLong_FromString+0x4ce:
5da3a55e 8b74244c        mov     esi,dword ptr [esp+4Ch] ss:002b:00e4f8bc=096fefe8
0:000> g
(648.e5c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=07aed7d0 ebx=0000000a ecx=096ff000 edx=096fefe9 esi=096fefe8 edi=096fefe8
eip=5da3a567 esp=00e4f870 ebp=00e4f8c4 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
python35!PyLong_FromString+0x4d7:
5da3a567 8a01            mov     al,byte ptr [ecx]          ds:002b:096ff000=??
0:000> db ecx-0x10
096feff0  41 41 41 41 41 41 41 41-c0 c0 c0 c0 d0 d0 d0 d0  AAAAAAAA........
096ff000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
096ff060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
python35!PyLong_FromString+4d7 [c:\build\cpython\objects\longobject.c @ 2293]
5da3a567 8a01            mov     al,byte ptr [ecx]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 5da3a567 (python35!PyLong_FromString+0x000004d7)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 096ff000
Attempt to read from address 096ff000

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=07aed7d0 ebx=0000000a ecx=096ff000 edx=096fefe9 esi=096fefe8 edi=096fefe8
eip=5da3a567 esp=00e4f870 ebp=00e4f8c4 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
python35!PyLong_FromString+0x4d7:
5da3a567 8a01            mov     al,byte ptr [ecx]          ds:002b:096ff000=??

FAULTING_THREAD:  00000e5c

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  python.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  096ff000

READ_ADDRESS:  096ff000 

FOLLOWUP_IP: 
python35!PyLong_FromString+4d7 [c:\build\cpython\objects\longobject.c @ 2293]
5da3a567 8a01            mov     al,byte ptr [ecx]

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  python.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 5da3a60d to 5da3a567

STACK_TEXT:  
00e4f8c4 5da3a60d 096fefe8 00e4f8e0 0000000a python35!PyLong_FromString+0x4d7
00e4f8e4 5da07f8b 096fefe8 00000010 0000000a python35!_PyLong_FromBytes+0x1d
00e4f934 5da3e2cb 07ad6b00 5dc30b98 5dc30b98 python35!PyNumber_Long+0x21b
00e4f958 5da54e08 5dc30b98 07ace630 00000000 python35!long_new+0xab
00e4f978 5da0947d 5dc30b98 07ace630 00000000 python35!type_call+0x38
00e4f994 5daa49cc 5dc30b98 07ace630 00000000 python35!PyObject_Call+0x6d
00e4f9c0 5daa449c 00000001 07ace630 00000083 python35!do_call+0x11c
00e4f9f0 5daa18d8 0662eab0 00000000 00000040 python35!call_function+0x36c
00e4fa68 5daa339f 0662eab0 00000000 092cfff0 python35!PyEval_EvalFrameEx+0x2318
00e4fab4 5dada142 0664ff58 00000000 00000000 python35!_PyEval_EvalCodeWithName+0x82f
00e4faf0 5dad9fd5 0664ff58 0664ff58 00e4fbbc python35!run_mod+0x42
00e4fb1c 5dad904a 07320fc8 07ae7cf0 00000101 python35!PyRun_FileExFlags+0x85
00e4fb60 5d9af037 07320fc8 07ae7cf0 00000001 python35!PyRun_SimpleFileExFlags+0x20a
00e4fb8c 5d9af973 00e4fbbc 65492100 65492108 python35!run_file+0xe7
00e4fc2c 653e72e5 00e4fc80 1c4b143f 00000002 python35!Py_Main+0x913
00e4fc80 76323744 7f444000 76323720 dbcbc723 ucrtbase!_initterm+0x85
00e4fc94 7789a064 7f444000 24309cee 00000000 KERNEL32!BaseThreadInitThunk+0x24
00e4fcdc 7789a02f ffffffff 778bd7e4 00000000 ntdll!__RtlUserThreadStart+0x2f
00e4fcec 00000000 1c4b14f7 7f444000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  c:\build\cpython\objects\longobject.c

FAULTING_SOURCE_FILE:  c:\build\cpython\objects\longobject.c

FAULTING_SOURCE_LINE_NUMBER:  2293

FAULTING_SOURCE_CODE:  
  2289:   onError:
  2290:     if (pend != NULL)
  2291:         *pend = (char *)str;
  2292:     Py_XDECREF(z);
> 2293:     slen = strlen(orig_str) < 200 ? strlen(orig_str) : 200;
  2294:     strobj = PyUnicode_FromStringAndSize(orig_str, slen);
  2295:     if (strobj == NULL)
  2296:         return NULL;
  2297:     PyErr_Format(PyExc_ValueError,
  2298:                  "invalid literal for int() with base %d: %.200R",


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python35!PyLong_FromString+4d7

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python35

IMAGE_NAME:  python35.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5598ccc2

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_python35.dll!PyLong_FromString

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_python35!PyLong_FromString+4d7

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_python35.dll!pylong_fromstring

FAILURE_ID_HASH:  {e857bdce-f7a2-f3d9-b507-e98e25bcd084}

Followup: MachineOwner
---------

To fix the issue, it is recommended that PyNumber_Long() check the type of argument o after a successful PyObject_GetBuffer() call to determine if the buffer is null-terminated or otherwise. A proposed patch is attached.

----------
files: PyNumber_Long_Buffer_Over-read.patch
keywords: patch
messages: 248101
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: PyNumber_Long Buffer Over-read.patch
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file40134/PyNumber_Long_Buffer_Over-read.patch

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

From report at bugs.python.org  Thu Aug  6 05:19:49 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:19:49 +0000
Subject: [issue24803] PyNumber_Long Buffer Over-read.patch
In-Reply-To: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za>
Message-ID: <1438831189.02.0.447775479482.issue24803@psf.upfronthosting.co.za>


John Leitch added the comment:

Attaching repro.

----------
Added file: http://bugs.python.org/file40135/PyNumber_Long_Buffer_Over-read.py

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

From report at bugs.python.org  Thu Aug  6 06:17:40 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 06 Aug 2015 04:17:40 +0000
Subject: [issue24804] https://www.python.org/ftp/python/2.7.4/python-2.7.4.msi
 actually installs 2.7.7
Message-ID: <1438834660.08.0.482520111464.issue24804@psf.upfronthosting.co.za>


New submission from Laura Creighton:

Mail to webmaster

The Link to?[1]https://www.python.org/ftp/python/2.7.4/python-2.7.4.msi
actually installs 2.7.7

Best,
Jean Doig

All prompts in the install dialog indicate 2.7.4 but the final install is
2.7.7?

----------
components: Installation
messages: 248103
nosy: lac
priority: normal
severity: normal
status: open
title: https://www.python.org/ftp/python/2.7.4/python-2.7.4.msi actually installs 2.7.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  6 06:24:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Aug 2015 04:24:40 +0000
Subject: [issue24803] PyNumber_Long Buffer Over-read.patch
In-Reply-To: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za>
Message-ID: <1438835080.14.0.843550423161.issue24803@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core
nosy: +serhiy.storchaka
stage:  -> patch review
type: security -> crash

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

From report at bugs.python.org  Thu Aug  6 06:25:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Aug 2015 04:25:30 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>
Message-ID: <1438835130.65.0.745599002067.issue24802@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core
nosy: +serhiy.storchaka
stage:  -> patch review
type: security -> behavior
versions: +Python 2.7, Python 3.4, Python 3.6

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

From report at bugs.python.org  Thu Aug  6 06:25:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Aug 2015 04:25:50 +0000
Subject: [issue24803] PyNumber_Long Buffer Over-read.patch
In-Reply-To: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za>
Message-ID: <1438835150.64.0.279894472632.issue24803@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 2.7, Python 3.4, Python 3.6

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

From report at bugs.python.org  Thu Aug  6 06:26:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Aug 2015 04:26:08 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>
Message-ID: <1438835168.15.0.040368800532.issue24802@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
type: behavior -> crash

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

From report at bugs.python.org  Thu Aug  6 06:45:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Aug 2015 04:45:15 +0000
Subject: [issue24804] https://www.python.org/ftp/python/2.7.4/python-2.7.4.msi
 actually installs 2.7.7
In-Reply-To: <1438834660.08.0.482520111464.issue24804@psf.upfronthosting.co.za>
Message-ID: <1438836315.64.0.889109861157.issue24804@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The report is almost certainly not accurate and is probably a result of trying to install 2.7.4 on top of 2.7.7, which will not work (the 2.7.7 python27.dll is newer and not overwritten).  Either way, neither version is supported anymore.

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Aug  6 06:55:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 04:55:45 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <20150806045539.5521.30189@psf.io>


Roundup Robot added the comment:

New changeset dda625798111 by Terry Jan Reedy in branch '3.4':
Issue #23672: Allow Idle to edit and run files with astral chars in name.
https://hg.python.org/cpython/rev/dda625798111

New changeset 97d50e6247e1 by Terry Jan Reedy in branch '3.5':
Issue #23672:Merge with 3.4
https://hg.python.org/cpython/rev/97d50e6247e1

New changeset 180bfaa7cdf8 by Terry Jan Reedy in branch 'default':
Issue #23672:Merge with 3.5
https://hg.python.org/cpython/rev/180bfaa7cdf8

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  6 06:59:40 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 04:59:40 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438837180.42.0.613580838706.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I made a different fix for avoid the error posted when running.  Sanad, PLEASE test running a file with astral char, the same way you did before, to see is there are any other problems.  I cannot get such a file into an Idle editor on Windows. I *think* this patch is enough, but cannot be sure.

I am leaving this open both for your test and a possible 2.7 backport.

----------
stage: test needed -> commit review

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

From report at bugs.python.org  Thu Aug  6 07:06:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 05:06:10 +0000
Subject: [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <20150806050607.29412.3775@psf.io>


Roundup Robot added the comment:

New changeset ae53bd5decae by Zachary Ware in branch '3.4':
Issue #21279: Flesh out str.translate docs
https://hg.python.org/cpython/rev/ae53bd5decae

New changeset 064b569e38fe by Zachary Ware in branch '3.5':
Issue #21279: Merge with 3.4
https://hg.python.org/cpython/rev/064b569e38fe

New changeset 967c9a9fe724 by Zachary Ware in branch 'default':
Closes #21279: Merge with 3.5
https://hg.python.org/cpython/rev/967c9a9fe724

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Aug  6 07:09:41 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Aug 2015 05:09:41 +0000
Subject: [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <1438837781.03.0.0412520604578.issue21279@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Very minor grammatical fixes, reflowed the .rst docs, and re-added the codecs module mention in a less obtrusive manner, but the patch is committed.  Thank you Kinga, Martin, and John!

----------
nosy: +zach.ware

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

From report at bugs.python.org  Thu Aug  6 07:15:40 2015
From: report at bugs.python.org (Debarshi Goswami)
Date: Thu, 06 Aug 2015 05:15:40 +0000
Subject: [issue24805] Python installer having problem in installing Python for
 all users in Windows
Message-ID: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za>


New submission from Debarshi Goswami:

Python installer (msi) having problem in installing Python for all users in Windows. It gets installed for installing user only. 

I was able to log the python output and found the below in the log. 
MSI (s) (8C:D0) [07:13:00:212]: Determined that existing product (either this product or the product being upgraded with a patch) is installed per-user.

I tried the below command combinations  to install python per machine, but it seems this a default product behavior. It should be fixed.

1. msiexec /i %setup_loc% TARGETDIR="C:\apps\Python34" ADDLOCAL="ALL" ALLUSERS="1" MSIINSTALLPERUSER="" /qb

2. msiexec /i %setup_loc% TARGETDIR="C:\apps\Python34" ADDLOCAL="ALL" WHICHUSERS="ALL" /qb 
  
3. msiexec /a %setup_loc% /passive /norestart TARGETDIR="c:\apps\Python34" ADDLOCAL="ALL" ALLUSERS="1"


Setup_loc=python msi file location
ADDLOCAL="ALL" -  Install all the features of the product .
ALLUSERS="1" - ALLUSERS property value of 1 specifies the per-machine installation .
MSIINSTALLPERUSER="" - MSIINSTALLPERUSER property to an empty string ("") for a per-machine installation.

Please let me know if I am missing anything. It seems a bug to me.

----------
components: Installation
messages: 248109
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Python installer having problem in installing Python for all users in Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  6 07:20:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Aug 2015 05:20:53 +0000
Subject: [issue24805] Python installer having problem in installing Python for
 all users in Windows
In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za>
Message-ID: <1438838453.16.0.544910022553.issue24805@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The default for the 3.4 installer is to install for all users, so it's strange that you can't get it to install for all users.  The log message you quote suggests that there's already a Python 3.4 installed per-user, is that the case?  What results do you get with no 3.4 installed at all?

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> test needed

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

From report at bugs.python.org  Thu Aug  6 08:28:48 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 06 Aug 2015 06:28:48 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438842528.33.0.308578249763.issue15944@psf.upfronthosting.co.za>


eryksun added the comment:

A functional memoryview for ctypes objects would avoid having to use workarounds, such as the following:

    >>> d = ctypes.c_double()
    >>> b = (ctypes.c_char * ctypes.sizeof(d)).from_buffer(d)
    >>> b[:] = b'abcdefgh'
    >>> d.value
    8.540883223036124e+194

or using numpy.frombuffer as a bridge:

    >>> d = ctypes.c_double()
    >>> m = memoryview(numpy.frombuffer(d, 'B'))
    >>> m[:] = b'abcdefgh'
    >>> d.value
    8.540883223036124e+194

David's request that cast('B') should be made to work for all contiguous buffers seems reasonable. That said, the ctypes format strings also need fixing. Let's see what happens when "@d" is used instead of "<d":

    >>> double_stgdict = stgdict(ctypes.c_double)
    >>> double_stgdict
    dict: 
        ob_base: 
            ob_refcnt: 1
            ob_type: py_object(<class 'StgDict'>)
        ma_used: 7
        ma_keys: LP_PyDictKeysObject(0x1aa5750)
        ma_values: LP_LP_PyObject(<NULL>)
    size: 8
    align: 8
    length: 0
    ffi_type_pointer: 
        size: 8
        alignment: 8
        type: 3
        elements: <NULL>
    proto: py_object('d')
    setfunc: SETFUNC(0x7f9f9b6e3e60)
    getfunc: GETFUNC(0x7f9f9b6e3d90)
    paramfunc: PARAMFUNC(0x7f9f9b6e31d0)
    argtypes: py_object(<NULL>)
    converters: py_object(<NULL>)
    restype: py_object(<NULL>)
    checker: py_object(<NULL>)
    flags: 4096
    format: b'<d'
    ndim: 0
    shape: LP_c_long(<NULL>)

    >>> double_stgdict.format = b'@d'

    >>> d = ctypes.c_double(3.14)
    >>> m = memoryview(d)
    >>> m[()]
    3.14
    >>> m[()] = 6.28
    >>> d.value
    6.28

    >>> m = m.cast('B')
    >>> m[:] = b'abcdefgh'
    >>> d.value
    8.540883223036124e+194

This shows that changing the format string (set by PyCSimpleType_new in _ctypes.c) to use "@" makes the memoryview work normally. OTOH, the swapped type (e.g. c_double.__ctype_be__) would need to continue to use a standard little-endian ("<") or big-endian (">") format.

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Aug  6 09:00:11 2015
From: report at bugs.python.org (Brecht Machiels)
Date: Thu, 06 Aug 2015 07:00:11 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
Message-ID: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>


New submission from Brecht Machiels:

These both raise an exception:

    class Null(type(None)): pass

    class Null(object, type(None)): pass

The following does not:

    class Object(object): pass
    class Null(Object, type(None)): pass

This should also raise a TypeError.
Also, the result is not what I expected, as "bool(Null())" yields True.

----------
components: Interpreter Core
messages: 248112
nosy: brechtm
priority: normal
severity: normal
status: open
title: Inheriting from NoneType does not fail consistently
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Aug  6 09:42:28 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2015 07:42:28 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>
Message-ID: <1438846948.73.0.57572853553.issue24802@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Aug  6 10:28:03 2015
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 06 Aug 2015 08:28:03 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438849683.46.0.0971934721507.issue24806@psf.upfronthosting.co.za>


Armin Rigo added the comment:

FWIW ``bool(Null())`` gives "correctly" the result False in CPython 3.5.

The problem in my opinion is that "!Py_TPFLAGS_BASETYPE" is checked only on the best base instead of on all bases.  It lets this kind of nonsense pass through.

In CPython 2.7 (but not 3.5) the following example also works (and is equally nonsense):

    class A(int): pass
    class Bogus(A, bool): pass

Although we're subclassing NoneType or bool, I did not manage to get a CPython crash from any of these examples.

----------
nosy: +arigo

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

From report at bugs.python.org  Thu Aug  6 10:58:49 2015
From: report at bugs.python.org (Brecht Machiels)
Date: Thu, 06 Aug 2015 08:58:49 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438851529.55.0.595655666775.issue24806@psf.upfronthosting.co.za>


Brecht Machiels added the comment:

Similar inconsistent behavior for:

    class Object(object): pass
    class Integer(Object, int): pass

versus

    class Integer(object, int): pass

However, I'm successfully using the first version, which saves some boilerplate code for emulating ints. Instances of Integer seem to behave exactly like ints. Personally, I wouldn't like to loose this ability. (May I shouldn't have created this ticket :).

----------

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

From report at bugs.python.org  Thu Aug  6 11:03:17 2015
From: report at bugs.python.org (Brecht Machiels)
Date: Thu, 06 Aug 2015 09:03:17 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438851797.63.0.509500735998.issue24806@psf.upfronthosting.co.za>


Brecht Machiels added the comment:

This is a real-world example where this type of inheritance is used: https://github.com/brechtm/rinohtype/blob/8bd961243c1059aa7cb738493e4687f7a5930d5b/rinoh/backend/pdf/cos.py#L121

I don't think there is any inherent reason not to subclass from (indirectly) object and int at the same time. I understand this is only a limitation of CPython? Please correct me if I'm wrong.

----------

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

From report at bugs.python.org  Thu Aug  6 11:10:42 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Aug 2015 09:10:42 +0000
Subject: [issue24795] Make event loops with statement context managers
In-Reply-To: <1438822673.0.0.0953982247495.issue24795@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK1Jf3j=4VnwBtuws3z7-rF=vE9XUD2Ph+c8_EyUNw8dw@mail.gmail.com>


Guido van Rossum added the comment:

My worry is that the context manager will make people believe it's a good
pattern to create an event loop just to make one call. If tests violate
this pattern, add a context manager helper function to test_utils.py.

On Thu, Aug 6, 2015 at 2:57 AM, Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> >From what I can see, the examples in the current documentation tend to
> diectly call loop.close() without an exception handler. Only two examples
> have the bare-bones try / finally handler (which is important for the
> example that uses Ctrl+C).
>
> ----------
> nosy: +vadmium
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24795>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Aug  6 11:15:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 09:15:17 +0000
Subject: [issue24531] please document that no code preceding encoding
 declaration is allowed
In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>
Message-ID: <20150806091513.53975.45750@psf.io>


Roundup Robot added the comment:

New changeset 08e03dfb7dab by Robert Collins in branch '2.7':
Issue #24531: Document that encoding lines cannot follow non-comment lines.
https://hg.python.org/cpython/rev/08e03dfb7dab

New changeset ab75b7ff4dfe by Robert Collins in branch '3.4':
Issue #24531: Document that encoding lines cannot follow non-comment lines.
https://hg.python.org/cpython/rev/ab75b7ff4dfe

New changeset caecc1869921 by Robert Collins in branch '3.5':
Issue #24531: Document that encoding lines cannot follow non-comment lines.
https://hg.python.org/cpython/rev/caecc1869921

New changeset 82c9ce30c0a0 by Robert Collins in branch 'default':
Issue #24531: Document that encoding lines cannot follow non-comment lines.
https://hg.python.org/cpython/rev/82c9ce30c0a0

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  6 11:15:54 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 06 Aug 2015 09:15:54 +0000
Subject: [issue24531] please document that no code preceding encoding
 declaration is allowed
In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>
Message-ID: <1438852554.48.0.169323151216.issue24531@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks, applied across the board; I had to tweak it a little on 2.7.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Aug  6 11:18:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 06 Aug 2015 09:18:50 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1438852730.68.0.794875886343.issue23004@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> berker.peksag

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

From report at bugs.python.org  Thu Aug  6 12:17:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 10:17:42 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <20150806101739.1391.69108@psf.io>


Roundup Robot added the comment:

New changeset 3d7adf5b3fb3 by Berker Peksag in branch '3.4':
Issue #23004: mock_open() now reads binary data correctly when the type of read_data is bytes.
https://hg.python.org/cpython/rev/3d7adf5b3fb3

New changeset 526a186de32d by Berker Peksag in branch '3.5':
Issue #23004: mock_open() now reads binary data correctly when the type of read_data is bytes.
https://hg.python.org/cpython/rev/526a186de32d

New changeset ed15f399a292 by Berker Peksag in branch 'default':
Issue #23004: mock_open() now reads binary data correctly when the type of read_data is bytes.
https://hg.python.org/cpython/rev/ed15f399a292

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  6 12:21:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 06 Aug 2015 10:21:50 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1438856510.54.0.112114126957.issue23004@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Aaron(also thanks to Demian for reviews). I've fixed the merge conflict and added more tests.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Aug  6 12:28:21 2015
From: report at bugs.python.org (Jon Ribbens)
Date: Thu, 06 Aug 2015 10:28:21 +0000
Subject: [issue24807] compileall can cause Python installation to fail
Message-ID: <1438856901.35.0.951815503778.issue24807@psf.upfronthosting.co.za>


New submission from Jon Ribbens:

If you are installing Python 2.7.10 and a previous version of 2.7 was already installed, the installation processs can fail when compileall.py finds badly-written third-party modules in the site-packages or dist-packages directories.

The installation process should either ignore errors from compileall.py, or compileall.py should be told to ignore the site-packages and dist-packages directories.

----------
components: Installation
messages: 248121
nosy: Jon Ribbens
priority: normal
severity: normal
status: open
title: compileall can cause Python installation to fail
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  6 12:30:40 2015
From: report at bugs.python.org (=?utf-8?b?SsO2cmcgTcO8bGxlcg==?=)
Date: Thu, 06 Aug 2015 10:30:40 +0000
Subject: [issue9023] distutils relative path errors
In-Reply-To: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>
Message-ID: <1438857040.75.0.85750168172.issue9023@psf.upfronthosting.co.za>


J?rg M?ller added the comment:

This bug still exists. I am having a similar use case as ghazel. I have to use absolute paths for the setup.py to work, but the problem is that those paths then end up in the egg-info/SOURCES.txt file which is something that package maintainers of linux distributions don't like!

----------
nosy: +neXyon
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  6 12:35:59 2015
From: report at bugs.python.org (Joseph Weston)
Date: Thu, 06 Aug 2015 10:35:59 +0000
Subject: [issue24808] PyTypeObject fields have incorrectly documented types
Message-ID: <1438857358.96.0.0472075361686.issue24808@psf.upfronthosting.co.za>


New submission from Joseph Weston:

Several fields in the Python 3.x documentation for the PyTypeObject API
have incorrectly documented types. This was probably due to a wholesale
shift of documentation from Python 2.x.

----------
assignee: docs at python
components: Documentation
files: PyTypeObject_documentation.patch
keywords: patch
messages: 248123
nosy: Joseph Weston, docs at python
priority: normal
severity: normal
status: open
title: PyTypeObject fields have incorrectly documented types
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40136/PyTypeObject_documentation.patch

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

From report at bugs.python.org  Thu Aug  6 13:22:40 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Aug 2015 11:22:40 +0000
Subject: [issue24802] PyFloat_FromString Buffer Over-read
In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za>
Message-ID: <1438860160.37.0.442063740108.issue24802@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Aug  6 13:28:58 2015
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 06 Aug 2015 11:28:58 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438860538.4.0.518652998736.issue24806@psf.upfronthosting.co.za>


Armin Rigo added the comment:

@brechtm No, the example you give is wrong.  It is correct that this refuses to work (and unrelated to this bug):

    class Integer(object, int): pass

for reasons explained in the docs.

----------

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

From report at bugs.python.org  Thu Aug  6 13:30:36 2015
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 06 Aug 2015 11:30:36 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438860636.29.0.752142369086.issue24806@psf.upfronthosting.co.za>


Armin Rigo added the comment:

To be clearer, this bug report is, more precisely, about subclassing built-in classes that are not meant to be subclassable.  This includes type(None) and bool.

----------

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

From report at bugs.python.org  Thu Aug  6 13:30:59 2015
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 06 Aug 2015 11:30:59 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438860659.31.0.457548038297.issue24806@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

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

From report at bugs.python.org  Thu Aug  6 13:47:38 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Aug 2015 11:47:38 +0000
Subject: [issue24803] PyNumber_Long Buffer Over-read.patch
In-Reply-To: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za>
Message-ID: <1438861658.71.0.734721361773.issue24803@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Aug  6 14:56:06 2015
From: report at bugs.python.org (Brecht Machiels)
Date: Thu, 06 Aug 2015 12:56:06 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438865766.6.0.96417418132.issue24806@psf.upfronthosting.co.za>


Brecht Machiels added the comment:

Ok. I was afraid a fix for this might affect "class Integer(Object, int)". Good to hear it shouldn't.

----------

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

From report at bugs.python.org  Thu Aug  6 15:45:34 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Aug 2015 13:45:34 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438868734.36.0.335408992643.issue15944@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yuriy: cast() does not do this.  What's requested is that e.g. a
single float is represented as a bytes object instead of a float.

Thus, you'd be able to do:

  m[0] = b'\x00\x00\x00\x01'

This has other implications, for example, two NaNs would compare
equal.  Hence the suggestion memoryview(raw=True).

----------

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

From report at bugs.python.org  Thu Aug  6 16:08:40 2015
From: report at bugs.python.org (Will Booth)
Date: Thu, 06 Aug 2015 14:08:40 +0000
Subject: [issue24809] Add getprotobynumber to socket module
Message-ID: <1438870120.05.0.712162767088.issue24809@psf.upfronthosting.co.za>


New submission from Will Booth:

Add an old method from netdb to python for a best-effort, centerized look up. For the function to work, /etc/protocols would also need to be present. If the protocol doesn't exist OSError is raised. 

Patch attached.

----------
components: Extension Modules
files: proto.diff
keywords: patch
messages: 248128
nosy: wbooth
priority: normal
severity: normal
status: open
title: Add getprotobynumber to socket module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40137/proto.diff

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

From report at bugs.python.org  Thu Aug  6 16:09:41 2015
From: report at bugs.python.org (Ethan Henderson)
Date: Thu, 06 Aug 2015 14:09:41 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1438870181.73.0.356487381913.issue22329@psf.upfronthosting.co.za>


Ethan Henderson added the comment:

I managed to resolve the issue following these steps:
1. Installing Python 3.4.3 on another computer (not even the same architecture)
2. Copying the Python34 folder from that other computer to the computer I broke
3. Running the uninstaller for Python 3.4.3
4. Reinstalling Python 3.4.3 normally as it is now removed correctly

I also replicated this error in 2.7.10 and fixed it with only slightly different steps:
1. Installing Python 2.7.10 on another computer (again, not even the same architecture as the broken computer)
2. Copying the Python27 folder from that other computer to the computer I broke
3. Running the repair tool for Python 2.7.10
4. Running the uninstaller for Python 2.7.10
5. Reinstalling Python 2.7.10 normally as it is now removed correctly

I replicated the issue in 2.7.10 again afterwards, and it does appear that step 3 is required.

----------

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

From report at bugs.python.org  Thu Aug  6 16:42:48 2015
From: report at bugs.python.org (Will Booth)
Date: Thu, 06 Aug 2015 14:42:48 +0000
Subject: [issue24809] Add getprotobynumber to socket module
In-Reply-To: <1438870120.05.0.712162767088.issue24809@psf.upfronthosting.co.za>
Message-ID: <1438872168.85.0.251006853292.issue24809@psf.upfronthosting.co.za>


Changes by Will Booth <m3rz3rk3r at gmail.com>:


----------
versions: +Python 3.5 -Python 3.6

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

From report at bugs.python.org  Thu Aug  6 17:19:29 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:19:29 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
Message-ID: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>


New submission from Mark Roseman:

To facilitate using IDLE to learn Python, and perhaps as a first experience with programming altogether, and taking advantage of the fact that IDLE comes with Python out of the box, I propose the following:

1. A new "learning" mode be introduced to Python. We can characterize IDLE's current behaviour as the "advanced" mode.

2. The goal of this learning mode is to make decisions for users that best help them concentrate on the task at hand, and minimize the time needed to focus on IDLE as an application.

3. In learning mode:
  3a.  The existing configuration dialog should not be present.
  3b.  The existing Options menu should not be present.
  3c.  The concept of 'extensions' should not be part of the UX.

4. The list of requirements in #3 is a starting point only.

5. At some point in time, the learning mode will become IDLE's default.

6. Switching from learning mode to advanced mode should be "protected" in some form (warnings, a quiz regarding one's favourite colour, etc.).

7. The expected path for most who continue beyond the learning phase is to switch to another IDE (Sublime, TextMate, Atom, etc.). Therefore an explicit non-goal of the learning mode is transitioning to advanced mode.

----------
components: IDLE
messages: 248130
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: UX mode for IDLE targeted to 'new learners'
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Aug  6 17:30:44 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:30:44 +0000
Subject: [issue17535] IDLE: Add an option to show line numbers along the left
 side of the editor window, and have it enabled by default.
In-Reply-To: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za>
Message-ID: <1438875044.97.0.997763577359.issue17535@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Thu Aug  6 17:37:36 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:37:36 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1438875456.83.0.540008483423.issue24225@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Thu Aug  6 17:40:12 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:40:12 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1438875612.47.0.293797332486.issue13504@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Thu Aug  6 17:42:08 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:42:08 +0000
Subject: [issue17942] IDLE Debugger: Improve GUI
In-Reply-To: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za>
Message-ID: <1438875728.46.0.409198565101.issue17942@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Thu Aug  6 17:48:22 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:48:22 +0000
Subject: [issue17535] IDLE: Add an option to show line numbers along the left
 side of the editor window, and have it enabled by default.
In-Reply-To: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za>
Message-ID: <1438876102.6.0.182260277566.issue17535@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Just as a point of information and possible future reference, there is a 'tklib' (collection of Tk-related modules written in Tcl) module called 'ctext' which does syntax highlighting as well as implements the line numbering thing (also using a text widget beside the main text). There may be some tricks in there to steal.

----------

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

From report at bugs.python.org  Thu Aug  6 17:51:34 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 15:51:34 +0000
Subject: [issue24809] Add getprotobynumber to socket module
In-Reply-To: <1438870120.05.0.712162767088.issue24809@psf.upfronthosting.co.za>
Message-ID: <1438876294.21.0.743945856587.issue24809@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

What are the use cases?

If it's "(Rarely used.)" (as docstring indicates), then, perhaps, a package on PyPI is a better solution.

----------
nosy: +haypo, yselivanov
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Thu Aug  6 17:52:08 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 15:52:08 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438876328.57.0.530109341365.issue24810@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
versions:  -Python 3.5

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

From report at bugs.python.org  Thu Aug  6 17:54:09 2015
From: report at bugs.python.org (Tiago Wright)
Date: Thu, 06 Aug 2015 15:54:09 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438830887.32.0.58828832324.issue24787@psf.upfronthosting.co.za>
Message-ID: <CAFxr9VpzeEUfG6xd44+suXS9nLUyT+K74LaO=c6uHsLEc5A3eQ@mail.gmail.com>


Tiago Wright added the comment:

Table attached.

-Tiago

On Wed, Aug 5, 2015 at 8:14 PM Skip Montanaro <report at bugs.python.org>
wrote:

>
> Skip Montanaro added the comment:
>
> Tiago, sorry, but your last post with results is completely
> unintelligible. Can you toss the table in a file and attach it instead?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24787>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file40138/csvsniffertest3.htm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24787>
_______________________________________
-------------- next part --------------
<html xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta name="Excel Workbook Frameset">
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 14">
<![if !supportTabStrip]>
<link id="shLink" href="manual_files/sheet001.htm">
<link id="shLink" href="manual_files/sheet002.htm">
<link id="shLink" href="manual_files/sheet003.htm">

<link id="shLink">

<script language="JavaScript">
<!--
 var g_iIEVer=0;
 
 var c_lTabs=3;

 var c_rgszSh=new Array(c_lTabs);
 c_rgszSh[0] = "Sheet2";
 c_rgszSh[1] = "Sheet1";
 c_rgszSh[2] = "Sheet1??????(2)";


 var c_rgszClr=new Array(8);
 c_rgszClr[0]="window";
 c_rgszClr[1]="buttonface";
 c_rgszClr[2]="windowframe";
 c_rgszClr[3]="windowtext";
 c_rgszClr[4]="threedlightshadow";
 c_rgszClr[5]="threedhighlight";
 c_rgszClr[6]="threeddarkshadow";
 c_rgszClr[7]="threedshadow";

 var g_iShCur;
 var g_rglTabX=new Array(c_lTabs);

function fnBuildFrameset()
{
 var szHTML="<frameset rows=\"*,18\" border=0 width=0 frameborder=no framespacing=0>"+
  "<frame src=\""+document.all.item("shLink")[2].href+"\" name=\"frSheet\" noresize>"+
  "<frameset cols=\"54,*\" border=0 width=0 frameborder=no framespacing=0>"+
  "<frame src=\"\" name=\"frScroll\" marginwidth=0 marginheight=0 scrolling=no>"+
  "<frame src=\"\" name=\"frTabs\" marginwidth=0 marginheight=0 scrolling=no>"+
  "</frameset></frameset><plaintext>";

document.open("text/html","replace");
document.write(szHTML);
document.close();

 fnBuildTabStrip();
}

function fnBuildTabStrip()
{
 var szHTML=
  "<html><head><style>.clScroll {font:8pt Courier New;color:"+c_rgszClr[2]+";cursor:default;line-height:10pt;}"+
  ".clScroll2 {font:10pt Arial;color:"+c_rgszClr[2]+";cursor:default;line-height:11pt;}</style></head>"+
  "<body onclick=\"event.returnValue=false;\" ondragstart=\"event.returnValue=false;\" onselectstart=\"event.returnValue=false;\" bgcolor="+c_rgszClr[4]+" topmargin=0 leftmargin=0><table cellpadding=0 cellspacing=0 width=100%>"+
  "<tr><td colspan=6 height=1 bgcolor="+c_rgszClr[2]+"></td></tr>"+
  "<tr><td style=\"font:1pt\">&nbsp;<td>"+
  "<td valign=top id=tdScroll class=\"clScroll\" onclick=\"parent.fnFastScrollTabs(0);\" onmouseover=\"parent.fnMouseOverScroll(0);\" onmouseout=\"parent.fnMouseOutScroll(0);\"><a>&#171;</a></td>"+
  "<td valign=top id=tdScroll class=\"clScroll2\" onclick=\"parent.fnScrollTabs(0);\" ondblclick=\"parent.fnScrollTabs(0);\" onmouseover=\"parent.fnMouseOverScroll(1);\" onmouseout=\"parent.fnMouseOutScroll(1);\"><a>&lt</a></td>"+
  "<td valign=top id=tdScroll class=\"clScroll2\" onclick=\"parent.fnScrollTabs(1);\" ondblclick=\"parent.fnScrollTabs(1);\" onmouseover=\"parent.fnMouseOverScroll(2);\" onmouseout=\"parent.fnMouseOutScroll(2);\"><a>&gt</a></td>"+
  "<td valign=top id=tdScroll class=\"clScroll\" onclick=\"parent.fnFastScrollTabs(1);\" onmouseover=\"parent.fnMouseOverScroll(3);\" onmouseout=\"parent.fnMouseOutScroll(3);\"><a>&#187;</a></td>"+
  "<td style=\"font:1pt\">&nbsp;<td></tr></table></body></html>";

frames['frScroll'].document.open("text/html","replace");
frames['frScroll'].document.write(szHTML);
frames['frScroll'].document.close();

 szHTML =
  "<html><head>"+
  "<style>A:link,A:visited,A:active {text-decoration:none;"+"color:"+c_rgszClr[3]+";}"+
  ".clTab {cursor:hand;background:"+c_rgszClr[1]+";font:8pt Arial;padding-left:3px;padding-right:3px;text-align:center;}"+
  ".clBorder {background:"+c_rgszClr[2]+";font:1pt;}"+
  "</style></head><body onload=\"parent.fnInit();\" onselectstart=\"event.returnValue=false;\" ondragstart=\"event.returnValue=false;\" bgcolor="+c_rgszClr[4]+
  " topmargin=0 leftmargin=0><table id=tbTabs cellpadding=0 cellspacing=0>";

 var iCellCount=(c_lTabs+1)*2;

 var i;
 for (i=0;i<iCellCount;i+=2)
  szHTML+="<col width=1><col>";

 var iRow;
 for (iRow=0;iRow<6;iRow++) {

  szHTML+="<tr>";

  if (iRow==5)
   szHTML+="<td colspan="+iCellCount+"></td>";
  else {
   if (iRow==0) {
    for(i=0;i<iCellCount;i++)
     szHTML+="<td height=1 class=\"clBorder\"></td>";
   } else if (iRow==1) {
    for(i=0;i<c_lTabs;i++) {
     szHTML+="<td height=1 nowrap class=\"clBorder\">&nbsp;</td>";
     szHTML+=
      "<td id=tdTab height=1 nowrap class=\"clTab\" onmouseover=\"parent.fnMouseOverTab("+i+");\" onmouseout=\"parent.fnMouseOutTab("+i+");\">"+
      "<a href=\""+document.all.item("shLink")[i].href+"\" target=\"frSheet\" id=aTab>&nbsp;"+c_rgszSh[i]+"&nbsp;</a></td>";
    }
    szHTML+="<td id=tdTab height=1 nowrap class=\"clBorder\"><a id=aTab>&nbsp;</a></td><td width=100%></td>";
   } else if (iRow==2) {
    for (i=0;i<c_lTabs;i++)
     szHTML+="<td height=1></td><td height=1 class=\"clBorder\"></td>";
    szHTML+="<td height=1></td><td height=1></td>";
   } else if (iRow==3) {
    for (i=0;i<iCellCount;i++)
     szHTML+="<td height=1></td>";
   } else if (iRow==4) {
    for (i=0;i<c_lTabs;i++)
     szHTML+="<td height=1 width=1></td><td height=1></td>";
    szHTML+="<td height=1 width=1></td><td></td>";
   }
  }
  szHTML+="</tr>";
 }

 szHTML+="</table></body></html>";

frames['frTabs'].document.open("text/html","replace");
frames['frTabs'].document.charset=document.charset;
frames['frTabs'].document. write(szHTML);
frames['frTabs'].document.close();

}

function fnInit()
{
 if (parent.window.g_iIEVer>=4) {
  if (document.readyState=="complete"
   && frames['frTabs'].document.readyState=="complete")
    {
     g_rglTabX[0]=0;
     var i;
     for (i=1;i<=c_lTabs;i++)
      with (frames['frTabs'].document.all.tbTabs.rows[1].cells[fnTabToCol(i-1)])
       g_rglTabX[i]=offsetLeft+offsetWidth-6;
    }
    else
     window.setTimeout("fnInit()",150);
   }
}

function fnGetIEVer()
{
 var stzAgent=navigator.userAgent;
 var iVer=parseInt(navigator.appVersion);
 if (stzAgent.indexOf("MSIE")!=-1 && iVer<4)
  g_iIEVer=3;
 else if (stzAgent.indexOf("MSIE 4")!=-1)
  g_iIEVer=4;
 else
  g_iIEVer=5;
}

function fnTabToCol(iTab)
{
 return 2*iTab+1;
}

function fnNextTab(fDir)
{
 var iNextTab=-1;
 var i;

 with (frames['frTabs'].document.body) {
  if (fDir==0) {
   if (scrollLeft>0) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i-1;
   }
  } else {
   if (g_rglTabX[c_lTabs]+6>offsetWidth+scrollLeft) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<=scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i;
   }
  }
 }
 return iNextTab;
}

function fnScrollTabs(fDir)
{
 var iNextTab=fnNextTab(fDir);

 if (iNextTab>=0) {
  frames['frTabs'].scroll(g_rglTabX[iNextTab],0);
  return true;
 } else
  return false;
}

function fnFastScrollTabs(fDir)
{
 if (c_lTabs>16)
  frames['frTabs'].scroll(g_rglTabX[fDir?c_lTabs-1:0],0);
 else
  if (fnScrollTabs(fDir)>0) window.setTimeout("fnFastScrollTabs("+fDir+");",5);
}

function fnSetTabProps(iTab,fActive)
{
 var iCol=fnTabToCol(iTab);
 var i;

 if (iTab>=0) {
  with (frames['frTabs'].document.all) {
   with (tbTabs) {
    for (i=0;i<=4;i++) {
     with (rows[i]) {
      if (i==0)
       cells[iCol].style.background=c_rgszClr[fActive?0:2];
      else if (i>0 && i<4) {
       if (fActive) {
        cells[iCol-1].style.background=c_rgszClr[2];
        cells[iCol].style.background=c_rgszClr[0];
        cells[iCol+1].style.background=c_rgszClr[2];
       } else {
        if (i==1) {
         cells[iCol-1].style.background=c_rgszClr[2];
         cells[iCol].style.background=c_rgszClr[1];
         cells[iCol+1].style.background=c_rgszClr[2];
        } else {
         cells[iCol-1].style.background=c_rgszClr[4];
         cells[iCol].style.background=c_rgszClr[(i==2)?2:4];
         cells[iCol+1].style.background=c_rgszClr[4];
        }
       }
      } else
       cells[iCol].style.background=c_rgszClr[fActive?2:4];
     }
    }
   }
   with (aTab[iTab].style) {
    cursor=(fActive?"default":"hand");
    color=c_rgszClr[3];
   }
  }
 }
}

function fnMouseOverScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[5];
}

function fnMouseOutScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[2];
}

function fnMouseOverTab(iTab)
{
 if (iTab!=g_iShCur) {
  var iCol=fnTabToCol(iTab);
  with (frames['frTabs'].document.all) {
   tdTab[iTab].style.background=c_rgszClr[5];
  }
 }
}

function fnMouseOutTab(iTab)
{
 if (iTab>=0) {
  var elFrom=frames['frTabs'].event.srcElement;
  var elTo=frames['frTabs'].event.toElement;

  if ((!elTo) ||
   (elFrom.tagName==elTo.tagName) ||
   (elTo.tagName=="A" && elTo.parentElement!=elFrom) ||
   (elFrom.tagName=="A" && elFrom.parentElement!=elTo)) {

   if (iTab!=g_iShCur) {
    with (frames['frTabs'].document.all) {
     tdTab[iTab].style.background=c_rgszClr[1];
    }
   }
  }
 }
}

function fnSetActiveSheet(iSh)
{
 if (iSh!=g_iShCur) {
  fnSetTabProps(g_iShCur,false);
  fnSetTabProps(iSh,true);
  g_iShCur=iSh;
 }
}
 fnGetIEVer();
 fnBuildFrameset();
//-->
</script>
function fnInit()
{
 if (parent.window.g_iIEVer>=4) {
  if (document.readyState=="complete"
   && frames['frTabs'].document.readyState=="complete")
    {
     g_rglTabX[0]=0;
     var i;
     for (i=1;i<=c_lTabs;i++)
      with (frames['frTabs'].document.all.tbTabs.rows[1].cells[fnTabToCol(i-1)])
       g_rglTabX[i]=offsetLeft+offsetWidth-6;
    }
    else
     window.setTimeout("fnInit()",150);
   }
}

function fnGetIEVer()
{
 var stzAgent=navigator.userAgent;
 var iVer=parseInt(navigator.appVersion);
 if (stzAgent.indexOf("MSIE")!=-1 && iVer<4)
  g_iIEVer=3;
 else if (stzAgent.indexOf("MSIE 4")!=-1)
  g_iIEVer=4;
 else
  g_iIEVer=5;
}

function fnTabToCol(iTab)
{
 return 2*iTab+1;
}

function fnNextTab(fDir)
{
 var iNextTab=-1;
 var i;

 with (frames['frTabs'].document.body) {
  if (fDir==0) {
   if (scrollLeft>0) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i-1;
   }
  } else {
   if (g_rglTabX[c_lTabs]+6>offsetWidth+scrollLeft) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<=scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i;
   }
  }
 }
 return iNextTab;
}

function fnScrollTabs(fDir)
{
 var iNextTab=fnNextTab(fDir);

 if (iNextTab>=0) {
  frames['frTabs'].scroll(g_rglTabX[iNextTab],0);
  return true;
 } else
  return false;
}

function fnFastScrollTabs(fDir)
{
 if (c_lTabs>16)
  frames['frTabs'].scroll(g_rglTabX[fDir?c_lTabs-1:0],0);
 else
  if (fnScrollTabs(fDir)>0) window.setTimeout("fnFastScrollTabs("+fDir+");",5);
}

function fnSetTabProps(iTab,fActive)
{
 var iCol=fnTabToCol(iTab);
 var i;

 if (iTab>=0) {
  with (frames['frTabs'].document.all) {
   with (tbTabs) {
    for (i=0;i<=4;i++) {
     with (rows[i]) {
      if (i==0)
       cells[iCol].style.background=c_rgszClr[fActive?0:2];
      else if (i>0 && i<4) {
       if (fActive) {
        cells[iCol-1].style.background=c_rgszClr[2];
        cells[iCol].style.background=c_rgszClr[0];
        cells[iCol+1].style.background=c_rgszClr[2];
       } else {
        if (i==1) {
         cells[iCol-1].style.background=c_rgszClr[2];
         cells[iCol].style.background=c_rgszClr[1];
         cells[iCol+1].style.background=c_rgszClr[2];
        } else {
         cells[iCol-1].style.background=c_rgszClr[4];
         cells[iCol].style.background=c_rgszClr[(i==2)?2:4];
         cells[iCol+1].style.background=c_rgszClr[4];
        }
       }
      } else
       cells[iCol].style.background=c_rgszClr[fActive?2:4];
     }
    }
   }
   with (aTab[iTab].style) {
    cursor=(fActive?"default":"hand");
    color=c_rgszClr[3];
   }
  }
 }
}

function fnMouseOverScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[5];
}

function fnMouseOutScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[2];
}

function fnMouseOverTab(iTab)
{
 if (iTab!=g_iShCur) {
  var iCol=fnTabToCol(iTab);
  with (frames['frTabs'].document.all) {
   tdTab[iTab].style.background=c_rgszClr[5];
  }
 }
}

function fnMouseOutTab(iTab)
{
 if (iTab>=0) {
  var elFrom=frames['frTabs'].event.srcElement;
  var elTo=frames['frTabs'].event.toElement;

  if ((!elTo) ||
   (elFrom.tagName==elTo.tagName) ||
   (elTo.tagName=="A" && elTo.parentElement!=elFrom) ||
   (elFrom.tagName=="A" && elFrom.parentElement!=elTo)) {

   if (iTab!=g_iShCur) {
    with (frames['frTabs'].document.all) {
     tdTab[iTab].style.background=c_rgszClr[1];
    }
   }
  }
 }
}

function fnSetActiveSheet(iSh)
{
 if (iSh!=g_iShCur) {
  fnSetTabProps(g_iShCur,false);
  fnSetTabProps(iSh,true);
  g_iShCur=iSh;
 }
}
 fnGetIEVer();
 fnBuildFrameset();
//-->
</script>
function fnInit()
{
 if (parent.window.g_iIEVer>=4) {
  if (document.readyState=="complete"
   && frames['frTabs'].document.readyState=="complete")
    {
     g_rglTabX[0]=0;
     var i;
     for (i=1;i<=c_lTabs;i++)
      with (frames['frTabs'].document.all.tbTabs.rows[1].cells[fnTabToCol(i-1)])
       g_rglTabX[i]=offsetLeft+offsetWidth-6;
    }
    else
     window.setTimeout("fnInit()",150);
   }
}

function fnGetIEVer()
{
 var stzAgent=navigator.userAgent;
 var iVer=parseInt(navigator.appVersion);
 if (stzAgent.indexOf("MSIE")!=-1 && iVer<4)
  g_iIEVer=3;
 else if (stzAgent.indexOf("MSIE 4")!=-1)
  g_iIEVer=4;
 else
  g_iIEVer=5;
}

function fnTabToCol(iTab)
{
 return 2*iTab+1;
}

function fnNextTab(fDir)
{
 var iNextTab=-1;
 var i;

 with (frames['frTabs'].document.body) {
  if (fDir==0) {
   if (scrollLeft>0) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i-1;
   }
  } else {
   if (g_rglTabX[c_lTabs]+6>offsetWidth+scrollLeft) {
    for (i=0;i<c_lTabs&&g_rglTabX[i]<=scrollLeft;i++);
    if (i<c_lTabs)
     iNextTab=i;
   }
  }
 }
 return iNextTab;
}

function fnScrollTabs(fDir)
{
 var iNextTab=fnNextTab(fDir);

 if (iNextTab>=0) {
  frames['frTabs'].scroll(g_rglTabX[iNextTab],0);
  return true;
 } else
  return false;
}

function fnFastScrollTabs(fDir)
{
 if (c_lTabs>16)
  frames['frTabs'].scroll(g_rglTabX[fDir?c_lTabs-1:0],0);
 else
  if (fnScrollTabs(fDir)>0) window.setTimeout("fnFastScrollTabs("+fDir+");",5);
}

function fnSetTabProps(iTab,fActive)
{
 var iCol=fnTabToCol(iTab);
 var i;

 if (iTab>=0) {
  with (frames['frTabs'].document.all) {
   with (tbTabs) {
    for (i=0;i<=4;i++) {
     with (rows[i]) {
      if (i==0)
       cells[iCol].style.background=c_rgszClr[fActive?0:2];
      else if (i>0 && i<4) {
       if (fActive) {
        cells[iCol-1].style.background=c_rgszClr[2];
        cells[iCol].style.background=c_rgszClr[0];
        cells[iCol+1].style.background=c_rgszClr[2];
       } else {
        if (i==1) {
         cells[iCol-1].style.background=c_rgszClr[2];
         cells[iCol].style.background=c_rgszClr[1];
         cells[iCol+1].style.background=c_rgszClr[2];
        } else {
         cells[iCol-1].style.background=c_rgszClr[4];
         cells[iCol].style.background=c_rgszClr[(i==2)?2:4];
         cells[iCol+1].style.background=c_rgszClr[4];
        }
       }
      } else
       cells[iCol].style.background=c_rgszClr[fActive?2:4];
     }
    }
   }
   with (aTab[iTab].style) {
    cursor=(fActive?"default":"hand");
    color=c_rgszClr[3];
   }
  }
 }
}

function fnMouseOverScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[5];
}

function fnMouseOutScroll(iCtl)
{
 frames['frScroll'].document.all.tdScroll[iCtl].style.color=c_rgszClr[2];
}

function fnMouseOverTab(iTab)
{
 if (iTab!=g_iShCur) {
  var iCol=fnTabToCol(iTab);
  with (frames['frTabs'].document.all) {
   tdTab[iTab].style.background=c_rgszClr[5];
  }
 }
}

function fnMouseOutTab(iTab)
{
 if (iTab>=0) {
  var elFrom=frames['frTabs'].event.srcElement;
  var elTo=frames['frTabs'].event.toElement;

  if ((!elTo) ||
   (elFrom.tagName==elTo.tagName) ||
   (elTo.tagName=="A" && elTo.parentElement!=elFrom) ||
   (elFrom.tagName=="A" && elFrom.parentElement!=elTo)) {

   if (iTab!=g_iShCur) {
    with (frames['frTabs'].document.all) {
     tdTab[iTab].style.background=c_rgszClr[1];
    }
   }
  }
 }
}

function fnSetActiveSheet(iSh)
{
 if (iSh!=g_iShCur) {
  fnSetTabProps(g_iShCur,false);
  fnSetTabProps(iSh,true);
  g_iShCur=iSh;
 }
}
 fnGetIEVer();
 fnBuildFrameset();
//-->
</script>
<![endif]><!--[if gte mso 9]><xml>
 <x:ExcelWorkbook>
  <x:ExcelWorksheets>
   <x:ExcelWorksheet>
    <x:Name>Sheet2</x:Name>
    <x:WorksheetSource HRef=":manual_files:sheet001.htm"/>
   </x:ExcelWorksheet>
   <x:ExcelWorksheet>
    <x:Name>Sheet1</x:Name>
    <x:WorksheetSource HRef=":manual_files:sheet002.htm"/>
   </x:ExcelWorksheet>
   <x:ExcelWorksheet>
    <x:Name>Sheet1 (2)</x:Name>
    <x:WorksheetSource HRef=":manual_files:sheet003.htm"/>
   </x:ExcelWorksheet>
  </x:ExcelWorksheets>
  <x:Stylesheet HRef=":manual_files:stylesheet.css"/>
  <x:WindowHeight>11780</x:WindowHeight>
  <x:WindowWidth>24740</x:WindowWidth>
  <x:WindowTopX>0</x:WindowTopX>
  <x:WindowTopY>0</x:WindowTopY>
  <x:ActiveSheet>2</x:ActiveSheet>
  <x:ProtectStructure>False</x:ProtectStructure>
  <x:ProtectWindows>False</x:ProtectWindows>
 </x:ExcelWorkbook>
</xml><![endif]-->
</head>

<frameset rows="*,39" border=0 width=0 frameborder=no framespacing=0>
 <frame src="manual_files/sheet003.htm" name="frSheet">
 <frame src="manual_files/tabstrip.htm" name="frTabs" marginwidth=0 marginheight=0>
 <noframes>
  <body>
   <p>This page uses frames, but your browser doesn't support them.</p>
  </body>
 </noframes>
</frameset>
</html>

From report at bugs.python.org  Thu Aug  6 17:54:26 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 15:54:26 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <1438876466.04.0.625482594491.issue24806@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +benjamin.peterson, yselivanov
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug  6 18:50:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Aug 2015 16:50:23 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438879823.21.0.904801548367.issue15944@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that allows any ?C-contiguous? memoryview() to be cast to a byte view. Apart from the test that was explicitly checking that this wasn?t supported, the rest of the test suite still passes. I basically removed the check that was generating the ?source format must be a native single character? error.

If two NANs are represented by the same byte sequence, I would expect their byte views to compare equal, which is the case with my patch.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file40139/cast-bytes.patch

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

From report at bugs.python.org  Thu Aug  6 19:04:45 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Aug 2015 17:04:45 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438880685.04.0.137069294291.issue15944@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The question is whether we want this behavior.

----------
assignee:  -> skrah

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

From report at bugs.python.org  Thu Aug  6 19:12:49 2015
From: report at bugs.python.org (Will Booth)
Date: Thu, 06 Aug 2015 17:12:49 +0000
Subject: [issue24809] Add getprotobynumber to socket module
In-Reply-To: <1438870120.05.0.712162767088.issue24809@psf.upfronthosting.co.za>
Message-ID: <1438881169.05.0.727058736134.issue24809@psf.upfronthosting.co.za>


Will Booth added the comment:

Allow users to translate protocol numbers from IPv4/IPv6 headers to a friendly human readable string.

Just filling a gap in the API. There might be a PyPI package out there similar to socket. However, it's complementary function,'getprotobyname', already exist here. getprotobynumber just flips getprotobyname around.

----------

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

From report at bugs.python.org  Thu Aug  6 20:04:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 18:04:58 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <20150806180445.29394.18721@psf.io>


Roundup Robot added the comment:

New changeset 024d4f4011c9 by Yury Selivanov in branch '3.4':
Issue #23812: Fix getter-cancellation with many pending getters code path
https://hg.python.org/cpython/rev/024d4f4011c9

New changeset 2752fe734bfb by Yury Selivanov in branch '3.5':
Merge 3.4 (issue #23812)
https://hg.python.org/cpython/rev/2752fe734bfb

New changeset e54c684e6788 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #23812)
https://hg.python.org/cpython/rev/e54c684e6788

----------

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

From report at bugs.python.org  Thu Aug  6 20:19:40 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 18:19:40 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438885180.97.0.925634446693.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Guido, Victor,

I've just pushed a commit to fix a misspelled method call in queues.py (related to the previous commit in this issue).

Along with fixing the bug and writing a unittest for it, I discovered an issue with the current queues design.

Here's an outline of the new unittest:

1. we have a queue with three queue.get() coroutines waiting for its items: `g1`, `g2`, `g3`

2. we do `push_nowait(i1)` and `push_nowait(i2)`; we cancel `g1`

3. the loop gets the chance to run

4. `g1` detects that it was cancelled and pushes the item `i1` in front of the queue (otherwise we just lose it).

Now, the problem is that `g2` has already received `i2` (by `push_nowait`); and `i1` will end up consumed by `g3`!

This all means that with getter coroutines being cancelled, it's possible that getters might receive queue items out of order.

So the question is: is this a matter of documenting this behaviour, or we should consider some other design for queues implementation?

----------

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

From report at bugs.python.org  Thu Aug  6 21:22:47 2015
From: report at bugs.python.org (Tiago Wright)
Date: Thu, 06 Aug 2015 19:22:47 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <CAFxr9VpzeEUfG6xd44+suXS9nLUyT+K74LaO=c6uHsLEc5A3eQ@mail.gmail.com>
Message-ID: <CAFxr9VqStwJ8nFnfpRNZi3WaEX3mdUE9ubZhiC4w1m0nOWmFMQ@mail.gmail.com>


Tiago Wright added the comment:

It seems the HTML file did not come through correctly. Trying a text
version, please view this in a monospace font:

        |   Sniffer
                                    |
Human   |   ,   |   ;   |   \t  |   \   |  space|Except |   :   |   )   |
c   |   e   |   M   |   p   |Total  |   %Error
---------------------------------------------------------------------------------------------------------------------------
    ,   |   498 |       |       |   2   |   1   |   10  |       |       |
1   |       |       |       |   512 |   2.7%
    ;   |       |   1   |       |       |       |       |       |       |
    |       |       |       |   1   |   0.0%
    \t  |   3   |       |   922 |       |   6   |   91  |   2   |   1   |
    |       |   2   |   27  |   1054|   12.5%
    |   |       |       |       |   33  |       |       |       |       |
    |       |       |       |   33  |   0.0%
space   |       |       |       |       |   9   |   1   |       |       |
    |   4   |       |       |   14  |   35.7%
---------------------------------------------------------------------------------------------------------------------------
Total   |   501 |   1   |   922 |   35  |   16  |   102 |   2   |   1   |
1   |   4   |   2   |   27  |   1614

On Thu, Aug 6, 2015 at 8:54 AM Tiago Wright <report at bugs.python.org> wrote:

>
> Tiago Wright added the comment:
>
> Table attached.
>
> -Tiago
>
> On Wed, Aug 5, 2015 at 8:14 PM Skip Montanaro <report at bugs.python.org>
> wrote:
>
> >
> > Skip Montanaro added the comment:
> >
> > Tiago, sorry, but your last post with results is completely
> > unintelligible. Can you toss the table in a file and attach it instead?
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue24787>
> > _______________________________________
> >
>
> ----------
> Added file: http://bugs.python.org/file40138/csvsniffertest3.htm
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24787>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Aug  6 21:24:56 2015
From: report at bugs.python.org (Fabian)
Date: Thu, 06 Aug 2015 19:24:56 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438889096.39.0.965539625691.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Okay I think I've run the test suite on 3.6 although it only works with https://gerrit.wikimedia.org/r/#/c/229683/ now as inspect.getargspec has been removed (when I initially posted this, it was just deprecated).

Well writing this I just thought I could've tested that on 3.5? well anyway I don't get any KeyErrors.

----------

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

From report at bugs.python.org  Thu Aug  6 21:29:13 2015
From: report at bugs.python.org (Tiago Wright)
Date: Thu, 06 Aug 2015 19:29:13 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <CAFxr9VqStwJ8nFnfpRNZi3WaEX3mdUE9ubZhiC4w1m0nOWmFMQ@mail.gmail.com>
Message-ID: <CAFxr9VrSctx4zu6-fK=hOJm7mDMwWDde8s9ZES+-jE4hQsdxEQ@mail.gmail.com>


Tiago Wright added the comment:

I apologize, it seems the text table got line wrapped. This time as a TXT
attachment.

-Tiago

On Thu, Aug 6, 2015 at 12:22 PM Tiago Wright <report at bugs.python.org> wrote:

>
> Tiago Wright added the comment:
>
>
>

----------
Added file: http://bugs.python.org/file40140/csvsniffertest3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24787>
_______________________________________
-------------- next part --------------
        |   Sniffer                                                                                             |
Human   |   ,   |   ;   |   \t  |   \   |  space|Except |   :   |   )   |   c   |   e   |   M   |   p   |Total  |   %Error
---------------------------------------------------------------------------------------------------------------------------
    ,   |   498 |       |       |   2   |   1   |   10  |       |       |   1   |       |       |       |   512 |   2.7%
    ;   |       |   1   |       |       |       |       |       |       |       |       |       |       |   1   |   0.0%
    \t  |   3   |       |   922 |       |   6   |   91  |   2   |   1   |       |       |   2   |   27  |   1054|   12.5%
    |   |       |       |       |   33  |       |       |       |       |       |       |       |       |   33  |   0.0%
space   |       |       |       |       |   9   |   1   |       |       |       |   4   |       |       |   14  |   35.7%
---------------------------------------------------------------------------------------------------------------------------
Total   |   501 |   1   |   922 |   35  |   16  |   102 |   2   |   1   |   1   |   4   |   2   |   27  |   1614

From report at bugs.python.org  Thu Aug  6 21:29:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Aug 2015 19:29:23 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438889363.03.0.849909842117.issue24787@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your best bet is to attach an ascii text file as an uploaded file.

----------

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

From report at bugs.python.org  Thu Aug  6 21:29:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Aug 2015 19:29:58 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1438889398.02.0.682124444366.issue24787@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, much better :)

----------

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

From report at bugs.python.org  Thu Aug  6 22:00:23 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Aug 2015 20:00:23 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1438885180.97.0.925634446693.issue23812@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJnupqnf8d_3NAz5QsZGYZftgybPSqc71nuB7VFwaG3FA@mail.gmail.com>


Guido van Rossum added the comment:

Honestly, I've lost track of the queue design. Maybe the push-back on
cancellation is just wrong? After all, if a coroutine has received an item,
it's out of the queue, even if it gets cancelled before it can do anything
with the item.

On Thu, Aug 6, 2015 at 8:19 PM, Yury Selivanov <report at bugs.python.org>
wrote:

>
> Yury Selivanov added the comment:
>
> Guido, Victor,
>
> I've just pushed a commit to fix a misspelled method call in queues.py
> (related to the previous commit in this issue).
>
> Along with fixing the bug and writing a unittest for it, I discovered an
> issue with the current queues design.
>
> Here's an outline of the new unittest:
>
> 1. we have a queue with three queue.get() coroutines waiting for its
> items: `g1`, `g2`, `g3`
>
> 2. we do `push_nowait(i1)` and `push_nowait(i2)`; we cancel `g1`
>
> 3. the loop gets the chance to run
>
> 4. `g1` detects that it was cancelled and pushes the item `i1` in front of
> the queue (otherwise we just lose it).
>
> Now, the problem is that `g2` has already received `i2` (by
> `push_nowait`); and `i1` will end up consumed by `g3`!
>
> This all means that with getter coroutines being cancelled, it's possible
> that getters might receive queue items out of order.
>
> So the question is: is this a matter of documenting this behaviour, or we
> should consider some other design for queues implementation?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23812>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Aug  6 22:00:42 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Aug 2015 20:00:42 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438891242.18.0.303597459693.issue23812@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Honestly, I've lost track of the queue design. Maybe the push-back on cancellation is just wrong? After all, if a coroutine has received an item, it's out of the queue, even if it gets cancelled before it can do anything with the item.

----------

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

From report at bugs.python.org  Thu Aug  6 22:08:22 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 20:08:22 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438891701.98.0.552195323792.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Honestly, I've lost track of the queue design. Maybe the push-back on cancellation is just wrong? After all, if a coroutine has received an item, it's out of the queue, even if it gets cancelled before it can do anything with the item.

I think the push-back is a right thing.  At least, I wouldn't expect ``wait_for(queue.get(), 0.1)`` code to lose queue items *sometimes* in big codebases.

----------

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

From report at bugs.python.org  Thu Aug  6 22:23:06 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 06 Aug 2015 20:23:06 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438892586.82.0.797774379785.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

That's good to know.  Thanks.

----------

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

From report at bugs.python.org  Thu Aug  6 22:42:32 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Thu, 06 Aug 2015 20:42:32 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438893752.02.0.945657055924.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

I don't think the order for multiple concurrent getters matters that much.  With analogy with the threading case, if multiple threads are blocked get()ing an item from the same queue, I would not presume to expect anything about the ordering which thread receives which item.

That being said, I'm sorry patch caused this problem, but losing items is an infinitely worse problem.

That being said, I think the problem stems from the way queue get is designed.  Currently it is something like:

1. get(): in case the queue is empty, create a Future, add it to "_getters", then begin waiting for this future;
2. When an item is being put(), take the first getter and set its result to the item being put;
3. the get() coroutine resumes and the item is found in the futures's result.

A better design is to make it so the future that get() is waiting for doesn't actually receive the item, it is only used to "wake up" the get() coroutine.  I would be something like:

1. get(): in case the queue is empty, create a Future, add it to "_getters", then begin waiting for this future;
2. When an item is being put():
   2.1. add the item to the internal queue
   2.2. take the first getter and set its result to None
3. the get() coroutine resumes, and then takes an item from the internal queue, returning it.

Clearly, in this design, handling cancellation in get is much simpler: you don't need to do anything, just let it cancel, no cleanup action needed.

----------

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

From report at bugs.python.org  Thu Aug  6 23:25:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 21:25:09 +0000
Subject: [issue23978] ttk.Style.element_create using incorrect tk.call syntax
In-Reply-To: <1429224578.03.0.989768410298.issue23978@psf.upfronthosting.co.za>
Message-ID: <1438896309.41.0.726077376196.issue23978@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This looks like it should be an easy for for someone who understands tcl.call syntax.  When we add ttk to Idle, I do not expect to use element_create, but maybe someone will want to to create a custom theme.

----------
nosy: +markroseman -gpolo
versions: +Python 3.6

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

From report at bugs.python.org  Thu Aug  6 23:38:24 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 06 Aug 2015 21:38:24 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438897104.96.0.825347660496.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> A better design is to make it so the future that get() is waiting for doesn't actually receive the item, it is only used to "wake up" the get() coroutine.  I would be something like:
>
> 1. get(): in case the queue is empty, create a Future, add it to "_getters", then begin waiting for this future;
> 2. When an item is being put():
>    2.1. add the item to the internal queue
>    2.2. take the first getter and set its result to None
> 3. the get() coroutine resumes, and then takes an item from the internal queue, returning it.
> 
> Clearly, in this design, handling cancellation in get is much simpler: you don't need to do anything, just let it cancel, no cleanup action needed.

I like this a lot.  Do you want to draft a patch?  :)

----------

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

From report at bugs.python.org  Thu Aug  6 23:50:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 21:50:16 +0000
Subject: [issue14799] Tkinter ttk tests hang on linux
In-Reply-To: <1336935343.12.0.855604727116.issue14799@psf.upfronthosting.co.za>
Message-ID: <1438897816.69.0.623495945028.issue14799@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Andrew, is this still a problem with current Unity? Or with updated version of tk 8.5, or any version of 8.6?

Should we downgrade this from 'critical'?  After 3 years, it seems not to be ;-).

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Thu Aug  6 23:53:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 21:53:09 +0000
Subject: [issue4343] tkinter: add _get_master() and use it consistently
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1438897989.61.0.844665194573.issue4343@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, have your patches on other issues make this one obsolete, or partially so?

----------

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

From report at bugs.python.org  Thu Aug  6 23:57:48 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 06 Aug 2015 21:57:48 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1438898268.28.0.0447995110364.issue23004@psf.upfronthosting.co.za>


Robert Collins added the comment:

Post merge review:

looks like

data_as_list = read_data.splitlines(True)

would be a little cleaner.

----------

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

From report at bugs.python.org  Thu Aug  6 23:59:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 21:59:49 +0000
Subject: [issue17397] ttk::themes missing from ttk.py
In-Reply-To: <1363005797.61.0.988966555267.issue17397@psf.upfronthosting.co.za>
Message-ID: <1438898389.97.0.692209694949.issue17397@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Mark, do you have any opinion of this?  It apparently impinges on what themes we use or can offer as an option.

----------
nosy: +markroseman
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Fri Aug  7 00:34:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Aug 2015 22:34:53 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <20150806223449.17725.76597@psf.io>


Roundup Robot added the comment:

New changeset f5069e6e4229 by Robert Collins in branch '3.4':
Issue #4395: Better testing and documentation of binary operators.
https://hg.python.org/cpython/rev/f5069e6e4229

New changeset b9a0165a3de8 by Robert Collins in branch '3.5':
Issue #4395: Better testing and documentation of binary operators.
https://hg.python.org/cpython/rev/b9a0165a3de8

New changeset e56893df8e76 by Robert Collins in branch 'default':
Issue #4395: Better testing and documentation of binary operators.
https://hg.python.org/cpython/rev/e56893df8e76

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  7 00:43:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 06 Aug 2015 22:43:02 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1438900982.24.0.174965017291.issue4395@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch; applied to 3.4 and up.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Aug  7 00:47:28 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Thu, 06 Aug 2015 22:47:28 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438901248.89.0.210626820479.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

Sure, just give me a couple of days.

----------

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

From report at bugs.python.org  Fri Aug  7 00:58:03 2015
From: report at bugs.python.org (zsero)
Date: Thu, 06 Aug 2015 22:58:03 +0000
Subject: [issue24811] Unicode character in history breaks history under Windows
Message-ID: <1438901883.57.0.996284173311.issue24811@psf.upfronthosting.co.za>


New submission from zsero:

Python 3.3+ works really well when using codepage 65001 under Windows/ConEmu. Simply starting it with `chcp 65001` allows both printing and inputting of unicode characters.

However, if any such character is ever entered into the history, the history functionality breaks from there on.

Error is the following:
```
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "C:\Python34\lib\site.py", line 426, in register_readline
    readline.read_history_file(history)
  File "C:\Python34\lib\site-packages\pyreadline\rlmain.py", line 165, in read_history_file
    self.mode._history.read_history_file(filename)
  File "C:\Python34\lib\site-packages\pyreadline\lineeditor\history.py", line 82, in read_history_file
    for line in open(filename, 'r'):
  File "C:\Python34\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 86: character maps to <undefined>
```

ipython shell is not affected.

----------
components: Unicode, Windows
messages: 248158
nosy: ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware, zsero
priority: normal
severity: normal
status: open
title: Unicode character in history breaks history under Windows
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug  7 00:59:04 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Aug 2015 22:59:04 +0000
Subject: [issue21937] IDLE interactive window doesn't display unsaved-indicator
In-Reply-To: <1404794523.71.0.976776826141.issue21937@psf.upfronthosting.co.za>
Message-ID: <1438901944.69.0.41162431906.issue21937@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A follow-on issue would be to have an option to prompt to save (as with editor windows) or autosave when closing the shell.  A default path might be .idlerc/shellsave.txt.

----------
versions: +Python 3.6

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

From report at bugs.python.org  Fri Aug  7 01:50:30 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 06 Aug 2015 23:50:30 +0000
Subject: [issue24811] Unicode character in history breaks history under Windows
In-Reply-To: <1438901883.57.0.996284173311.issue24811@psf.upfronthosting.co.za>
Message-ID: <1438905030.77.0.205512928835.issue24811@psf.upfronthosting.co.za>


eryksun added the comment:

This is a 3rd party issue with the pyreadline module, which already has an open ticket for this problem:

https://github.com/pyreadline/pyreadline/issues/30

----------
nosy: +eryksun

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

From report at bugs.python.org  Fri Aug  7 02:04:48 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Aug 2015 00:04:48 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438905888.72.0.429634518987.issue24810@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Sounds patronizing.

Whether used for beginners to programming or experts, IDLE (or any other application) should start with sensible defaults. As much as possible, it should usefully start without requiring extra configuration. But beyond that, actively prohibiting users from changing settings if they choose to do so is not helpful. Beginners can just ignore the Options menu if it is too much for them, and changing settings and seeing what happens is a great way to learn an application.

As for the idea of interrogating users before they are permitted to make their own choices for settings, that is outrageous. It isn't like the settings are dangerous: there's a choice of font, tab size, size of the window, etc. All things which even beginners may have legitimate reasons to change. For example, if the default font size is too small, or not enough contrast.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Fri Aug  7 02:31:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 00:31:59 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438907519.52.0.464661768991.issue24810@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Aug  7 02:35:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Aug 2015 00:35:11 +0000
Subject: [issue24811] Unicode character in history breaks history under Windows
In-Reply-To: <1438901883.57.0.996284173311.issue24811@psf.upfronthosting.co.za>
Message-ID: <1438907711.99.0.709305068711.issue24811@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Aug  7 02:45:50 2015
From: report at bugs.python.org (Tiago Wright)
Date: Fri, 07 Aug 2015 00:45:50 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438889398.02.0.682124444366.issue24787@psf.upfronthosting.co.za>
Message-ID: <CAFxr9VpV5qxZ7H1Gzn_a5u63F1WVJsaXmse0EFv78sV4G_9jHA@mail.gmail.com>


Tiago Wright added the comment:

I've run the Sniffer against the same data set, but varied the size of the
sample given to the code. It seems that feeding it more data actually seems
to make the results less accurate. Table attached.
On Thu, Aug 6, 2015 at 12:29 PM R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Yes, much better :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24787>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file40141/csvsniffertest5.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24787>
_______________________________________
-------------- next part --------------
                 lines3  lines7  lines70  lines700
human Sniff                                   
,     ,          490     487     424      393     
      A          1       0       0        0       
      Exception  6       8       4        4       
      c          1       1       1        1       
      g          1       0       0        0       
      h          1       0       0        0       
      space      0       0       9        7       
      y          0       0       1        1       
;     ;          1       1       1        1       
\t    \t         918     917     929      706     
      *          0       0       6        7       
      ,          6       3       2        1       
      -          0       0       0        5       
      :          0       2       2        2       
      D          5       0       0        0       
      E          0       0       10       10      
      Exception  52      91      18       18      
      M          1       1       0        0       
      c          2       0       0        0       
      m          2       0       0        0       
      p          61      27      22       22      
      s          0       0       2        2       
      space      1       6       51       125     
bar   bar        33      33      20       9       
space Exception  0       1       1        1       
      e          4       4       4        4       
      space      10      9       9        9       

From report at bugs.python.org  Fri Aug  7 02:57:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 07 Aug 2015 00:57:22 +0000
Subject: [issue22052] Comparison operators called in reverse order for
 subclasses with no override.
In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
Message-ID: <1438909042.27.0.813650103336.issue22052@psf.upfronthosting.co.za>


Martin Panter added the comment:

My patch was committed for Python 3.4+. The priority of the comparator methods is now documented at the end of <https://docs.python.org/dev/reference/datamodel.html#richcmpfuncs>. Perhaps all that is left to do here is to apply similar changes to the Python 2 documentation.

----------

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

From report at bugs.python.org  Fri Aug  7 03:55:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 07 Aug 2015 01:55:16 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438912516.17.0.807883745497.issue15944@psf.upfronthosting.co.za>


Martin Panter added the comment:

Assuming Issue 23756 is resolved and various standard library functions are meant to work with any C-contiguous buffer, then it makes sense to me for memoryview.cast("B") to work for any C-contiguous buffer. I also got the impression that David, Yuriy, and Eryksun all support this.

I don?t understand why you wouldn?t want this behaviour. It seems pointless just to maintain symmetry with being unable to cast back to ?<d?. And casting from e.g. floating point to bytes to integers already disregards the original data type, so casting from unsupported types to bytes should be no worse.

----------

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

From report at bugs.python.org  Fri Aug  7 03:59:30 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 01:59:30 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438912770.62.0.970692537995.issue24810@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In general, users and instructors are demanding more options, not less.

'extensions' could be renamed 'plug-ins'.  The current system could use some rethinking, since the choice between a feature being 'built-in' versus a 'built-in extension' is at least partly historical accident.  I think having Run-module be optional should go. Having that named 'ScriptBinding' in the extension config is mystifying to anyone who does not know the reason. With Run_module disabled, the debugger than only operates when a module is run makes no sense. etc.

Other than that, I am inclined to close this issue.

This proposal strikes me a similar to defining 'Beginner Python'.  Instructors may do that for didactic purposes (sometime infuriating more advanced students), but Python itself does not support subsetting.

----------

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

From report at bugs.python.org  Fri Aug  7 04:05:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 02:05:16 +0000
Subject: [issue1207613] Idle Editor: Bottom Scroll Bar
Message-ID: <1438913116.87.0.801275608799.issue1207613@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Bottom Scroll Bar in IDLE -> Idle Editor: Bottom Scroll Bar
versions: +Python 3.6

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

From report at bugs.python.org  Fri Aug  7 05:10:31 2015
From: report at bugs.python.org (Cameron Simpson)
Date: Fri, 07 Aug 2015 03:10:31 +0000
Subject: [issue19702] Update pickle to take advantage of PEP 451
In-Reply-To: <1385624711.1.0.561130815884.issue19702@psf.upfronthosting.co.za>
Message-ID: <1438917031.95.0.317716521526.issue19702@psf.upfronthosting.co.za>


Changes by Cameron Simpson <cs at zip.com.au>:


----------
nosy: +cameron

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

From report at bugs.python.org  Fri Aug  7 06:15:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:15:38 +0000
Subject: [issue24812] All standard keystrokes not recognized in IDLE dialogs
 on Mac
Message-ID: <1438920938.34.0.296980992753.issue24812@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Most of the dialogs in IDLE on OS X do respond to 'Return' key as equivalent to hitting OK, and Escape to hitting Cancel.

Guidelines also suggest that the Enter key (on numeric keypad) should work like 'Return', and Cmd-. (period) should work like Cancel. Doesn't happen now in any of the places I looked.

----------
components: IDLE
messages: 248166
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: All standard keystrokes not recognized in IDLE dialogs on Mac
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:18:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 04:18:25 +0000
Subject: [issue24799] IDLE should detect changes to open files by other
 processes
In-Reply-To: <1438801539.3.0.903562604709.issue24799@psf.upfronthosting.co.za>
Message-ID: <1438921105.09.0.765690697664.issue24799@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy
stage:  -> test needed
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug  7 06:19:42 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:19:42 +0000
Subject: [issue24813] About IDLE dialog shouldn't be modal
Message-ID: <1438921182.01.0.453311500566.issue24813@psf.upfronthosting.co.za>


New submission from Mark Roseman:

No reason for it to be modal. Especially on OS X (where it really isn't...)

----------
components: IDLE
messages: 248167
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: About IDLE dialog shouldn't be modal
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:21:13 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:21:13 +0000
Subject: [issue24814] Disable Undo/Redo menu items when not applicable
Message-ID: <1438921273.62.0.917598140136.issue24814@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Undo/Redo in Edit menu should be disabled when there is nothing to Undo or Redo

----------
components: IDLE
messages: 248168
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Disable Undo/Redo menu items when not applicable
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:25:24 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:25:24 +0000
Subject: [issue24815] IDLE can lose menubar on OS X
Message-ID: <1438921524.87.0.36411577411.issue24815@psf.upfronthosting.co.za>


New submission from Mark Roseman:

It's fairly easy to get IDLE to revert back to an empty menubar, i.e. just a Python menu.

For example, open a shell, debugger, and editor window. Click on debugger window, then editor window, then close editor window. Focus goes back to debugger, but doesn't have a proper menubar.

----------
components: IDLE
messages: 248169
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE can lose menubar on OS X
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:34:10 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:34:10 +0000
Subject: [issue24816] don't allow selecting IDLE debugger menu item when
 running
Message-ID: <1438922050.39.0.00616155269251.issue24816@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Right now when you're running a program you can still select the 'debugger' item in the menu... you just get an error dialog "you can only toggle the debugger when idle" (with a title "don't debug now").

While I got a kick out of the title and using the word "idle" in the error message, the menu item should just be disabled when it's not relevant

----------
components: IDLE
messages: 248170
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: don't allow selecting IDLE debugger menu item when running
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:36:56 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:36:56 +0000
Subject: [issue24817] disable format menu items when not applicable
Message-ID: <1438922216.82.0.623288828961.issue24817@psf.upfronthosting.co.za>


New submission from Mark Roseman:

In an editor window, with no selection, most of the items in the format menu (indent, tabify, etc.) aren't applicable, so the corresponding menu items should be disabled.

----------
components: IDLE
messages: 248171
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: disable format menu items when not applicable
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:37:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 04:37:27 +0000
Subject: [issue24799] IDLE should detect changes to open files by other
 processes
In-Reply-To: <1438801539.3.0.903562604709.issue24799@psf.upfronthosting.co.za>
Message-ID: <1438922247.69.0.0111356095346.issue24799@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Notepad++ always asks, even when the edit buffer is not dirty. Actual use case: edit file with tkinter import and run in 3.4.  Works.  Open file in 2.7, changet tkinter to Tkinter, and run it.  If I click on the 3.4 wndow, I do not want it silently changed.

Here is my expert use (with changed edit buffers).  Hg nearly always screws up merges of Idle entries in misc/NEWS (skip the whys).  So I open the two or three required versions in Notepad++, edit all to how they should be, save the earliest (currently 3.4), go to TortoiseHg, commit, and merge forward (currently to 3.5).  If there is a conflict, revert to local, activate the 3.5 Notepad++ window, click NO, save, go back to TortoiseHg, mark resolved, and commit.

I am curious when beginners would need this feature.

----------

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

From report at bugs.python.org  Fri Aug  7 06:40:56 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 07 Aug 2015 04:40:56 +0000
Subject: [issue5305] imaplib should support international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1438922456.99.0.379034887233.issue5305@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Ping.

----------

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

From report at bugs.python.org  Fri Aug  7 06:41:42 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 07 Aug 2015 04:41:42 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1438922502.5.0.602915973856.issue22598@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

ping.

----------

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

From report at bugs.python.org  Fri Aug  7 06:41:52 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 07 Aug 2015 04:41:52 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1438922512.65.0.0268145939997.issue22598@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: jcea -> 

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

From report at bugs.python.org  Fri Aug  7 06:44:11 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:44:11 +0000
Subject: [issue24818] no way to run program in debugger from edit window
Message-ID: <1438922651.24.0.0742005388558.issue24818@psf.upfronthosting.co.za>


New submission from Mark Roseman:

If I have just an edit window open with my program, there's no way to run the program with the debugger visible. Should be a way to do so without going through the extra steps of opening up a shell window first

----------
components: IDLE
messages: 248175
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: no way to run program in debugger from edit window
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:48:29 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:48:29 +0000
Subject: [issue24819] replace window size preference with just use last window
 size
Message-ID: <1438922909.15.0.485758801191.issue24819@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Rather than including the window width/height in the config dialog, just remember the last window size and use that next time

----------
components: IDLE
messages: 248176
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: replace window size preference with just use last window size
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:51:23 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:51:23 +0000
Subject: [issue17642] IDLE add font resizing hot keys
In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>
Message-ID: <1438923083.69.0.652571444954.issue17642@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Fri Aug  7 06:54:17 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:54:17 +0000
Subject: [issue24820] IDLE themes for light on dark
Message-ID: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>


New submission from Mark Roseman:

If there are going to be highlighting themes in IDLE, and the ability to customize them, why not the background color of the window? Light on dark is easier for some people to read - adding one that did that would be a good candidate for another built-in theme. Also many people (myself included) tend to use a light color other than white for editors, terminals, etc.

----------
components: IDLE
messages: 248177
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE themes for light on dark
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 06:55:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:55:28 +0000
Subject: [issue1528593] Printing: No print dialog or page setup
Message-ID: <1438923328.49.0.666244272117.issue1528593@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Fri Aug  7 07:42:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 05:42:12 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1438926132.03.0.817213112385.issue22598@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Fri Aug  7 07:43:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 05:43:29 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1438926209.54.0.133804604345.issue22598@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I take this.

----------

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

From report at bugs.python.org  Fri Aug  7 08:11:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 06:11:26 +0000
Subject: [issue24821] The optimization of string search can cause pessimization
Message-ID: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Search in strings is highly optimized for common case. However for some input data the search in non-ascii string becomes unexpectedly slow. Compare:

$ ./python -m timeit -s 's = "?????"*10**4' -- '"?" in s'
100000 loops, best of 3: 11.7 usec per loop
$ ./python -m timeit -s 's = "?????"*10**4' -- '"?" in s'
1000 loops, best of 3: 769 usec per loop

It's because the lowest byte of the code of Ukrainian capital letter ? (U+0404) matches the highest byte of codes of most Cyrillic letters (U+04xx). There are similar issues with some other scripts.

I think we should use more robust optimization.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 248179
nosy: haypo, pitrou, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: The optimization of string search can cause pessimization
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Fri Aug  7 08:16:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 06:16:21 +0000
Subject: [issue24822] IDLE: Accelerator key doesn't work for Options
Message-ID: <1438928181.3.0.0815993516884.issue24822@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Accelerator key (Alt+O) for the Options menu works in IDLE Shell window, but doesn't work in IDLE Editor windows due to conflict with the accelerator key for the Format menu.

----------
components: IDLE
messages: 248180
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Accelerator key doesn't work for Options
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 09:29:57 2015
From: report at bugs.python.org (=?utf-8?b?VG9taSBLecO2c3RpbMOk?=)
Date: Fri, 07 Aug 2015 07:29:57 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1438932597.37.0.347163885671.issue15443@psf.upfronthosting.co.za>


Changes by Tomi Ky?stil? <tomi.kyostila at gmail.com>:


----------
nosy: +tomikyos

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

From report at bugs.python.org  Fri Aug  7 10:53:52 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 07 Aug 2015 08:53:52 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1438901248.89.0.210626820479.issue23812@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK939hK7frm4bFyYuaZWmRtYQY9NZ9pYQO2mohqpd23Gg@mail.gmail.com>


Guido van Rossum added the comment:

So this looks like it will miss 3.5.0rc1. How confident are we that the new
patch won't introduce new bugs? This late in the release process that would
be awkward.

On Fri, Aug 7, 2015 at 12:47 AM, Gustavo J. A. M. Carneiro <
report at bugs.python.org> wrote:

>
> Gustavo J. A. M. Carneiro added the comment:
>
> Sure, just give me a couple of days.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23812>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Aug  7 11:00:24 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Aug 2015 09:00:24 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438938024.67.0.6059373382.issue15944@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The proposal sounds reasonable to me.

----------

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

From report at bugs.python.org  Fri Aug  7 12:18:08 2015
From: report at bugs.python.org (Tom Pohl)
Date: Fri, 07 Aug 2015 10:18:08 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
Message-ID: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>


New submission from Tom Pohl:

>From the ctypes.create_string_buffer docs:
"""If a bytes object is specified as first argument, the buffer is made one item larger than its length so that the last element in the array is a NUL termination character. An integer can be passed as second argument which allows to specify the size of the array if the length of the bytes should not be used."""

Based on this documentation I would expect a NUL-terminated byte array in any case. However, when I do this

>>> for size in range(5, 2, -1): print(size, ctypes.create_string_buffer(b'123', size).raw)
5 b'123\x00\x00'
4 b'123\x00'
3 b'123'

I get b'123' for size=3 without a NUL. My expectation would be the same exception as I get for create_string_buffer(b'123', 2).

----------
components: ctypes
messages: 248183
nosy: tom.pohl
priority: normal
severity: normal
status: open
title: ctypes.create_string_buffer does not add NUL if len(init) == size
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  7 12:30:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 10:30:32 +0000
Subject: [issue24824] Pydoc fails with codecs
Message-ID: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Pydoc fails with the codecs module in 3.5+. All works in 3.4.

$ ./python -m pydoc codecs
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.5/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython-3.5/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 2648, in <module>
    cli()
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 2613, in cli
    help.help(arg)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 1895, in help
    elif request: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 1632, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 1625, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 370, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 1160, in docmodule
    contents.append(self.document(value, key, name))
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 372, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/home/serhiy/py/cpython-3.5/Lib/pydoc.py", line 1345, in docroutine
    signature = inspect.signature(object)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 2988, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 2738, in from_callable
    follow_wrapper_chains=follow_wrapped)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 2229, in _signature_from_callable
    skip_bound_arg=skip_bound_arg)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 2061, in _signature_from_builtin
    return _signature_fromstr(cls, func, s, skip_bound_arg)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 2009, in _signature_fromstr
    p(name, default)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 1991, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/home/serhiy/py/cpython-3.5/Lib/ast.py", line 245, in visit
    return visitor(node)
  File "/home/serhiy/py/cpython-3.5/Lib/ast.py", line 310, in generic_visit
    new_node = self.visit(old_value)
  File "/home/serhiy/py/cpython-3.5/Lib/ast.py", line 245, in visit
    return visitor(node)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 1978, in visit_Attribute
    return wrap_value(value)
  File "/home/serhiy/py/cpython-3.5/Lib/inspect.py", line 1965, in wrap_value
    raise RuntimeError()
RuntimeError

----------
components: Library (Lib)
messages: 248184
nosy: doerwalter, lemburg, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Pydoc fails with codecs
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 12:48:00 2015
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 07 Aug 2015 10:48:00 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <CA+gUBLSqc+JkOgH+YtFMMF_ZsyQTd+E5mtHSLTu74v3DN2dpig@mail.gmail.com>
Message-ID: <CA+gUBLS98EWV0evudQEdKcZ4jysV+Dk+sfSeLsCVL_cv=d3PYA@mail.gmail.com>


Pierre Quentel added the comment:

I don't really see why there is a Content-Length in the headers of a
multipart form data. The specification at
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2 doesn't
mention it, and it is absent in the example that looks like the one tested
by Peter :

Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--

In case a user agent would insert it, I think the best would be to
ignore it. That is, inside read_multi(), after

            headers = parser.close()

add these lines :

            if 'content-length' in headers:
                del headers['content-length']

It's hard to see the potential side effects but I think it's cleaner
than the proposed patch, which is not correct anyway for another
reason : the attribute value is set to a bytes objects, instead of a
string.

Peter, does this make sense ? If so, can you submit another patch ?

----------

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

From report at bugs.python.org  Fri Aug  7 12:51:36 2015
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Aug 2015 10:51:36 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1438944696.51.0.340302712373.issue678264@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Aug  7 12:51:43 2015
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Aug 2015 10:51:43 +0000
Subject: [issue9917] resource max value represented as signed when should be
 unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1438944703.64.0.4644212245.issue9917@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Aug  7 14:57:56 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Aug 2015 12:57:56 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438952276.6.0.535400082139.issue15944@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If people are content with writing m[124:128] = b'abcd' and accept
that tolist() etc. won't represent the original structure of the
object, then let's do it.

On the bright side, it is less work. -- I'll review the patch.

----------

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

From report at bugs.python.org  Fri Aug  7 15:06:25 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Fri, 07 Aug 2015 13:06:25 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438952785.0.0.080570077057.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

I was wrong, there still needs to be some cleanup in cancellation, even with the new approach.  But it does solve the out-of-order problem.

I don't know if it should be applied to rc1.  I wish I had more time to test.  Up to you guys.

----------
Added file: http://bugs.python.org/file40142/p.diff

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

From report at bugs.python.org  Fri Aug  7 15:08:02 2015
From: report at bugs.python.org (sanad)
Date: Fri, 07 Aug 2015 13:08:02 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438952882.15.0.697054277983.issue23672@psf.upfronthosting.co.za>


sanad added the comment:

Hey Terry, after testing the committed patch on my Linux Mint, I have found the following behaviour:

1. The issue of IDLE not starting when Recent File list has name outside BMP has been fixed.

2. The File Name is correctly formatted and displayed in the file editor window title and in the recent file list.(astral chars replaced by diamond question mark symbol)

3. Files with astral char names now RUN perfectly.

4. You can create a file with astral char in its name and run it effectively and re run it from the recent file list.

PS : since you are unable to test it own windows and many other developers might face the same I'm uploading the screenshot of the IDLE windows after the patch is applied.
In the given test , I had kept my file name as "??hello?My?Name?.py"
and it was displayed as "??hello?My?Name?.py"

----------
Added file: http://bugs.python.org/file40143/idlerun.png

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

From report at bugs.python.org  Fri Aug  7 15:09:27 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Aug 2015 13:09:27 +0000
Subject: [issue15944] memoryview: allow all casts to bytes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438952967.51.0.36152079302.issue15944@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
title: memoryviews and ctypes -> memoryview: allow all casts to bytes

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

From report at bugs.python.org  Fri Aug  7 15:12:37 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Aug 2015 13:12:37 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1438952276.6.0.535400082139.issue15944@psf.upfronthosting.co.za>
Message-ID: <55C4AEC2.4040901@free.fr>


Antoine Pitrou added the comment:

Le 07/08/2015 14:57, Stefan Krah a ?crit :
> 
> If people are content with writing m[124:128] = b'abcd' and accept
> that tolist() etc. won't represent the original structure of the
> object, then let's do it.

As long as the casting has to be explicit, this sounds ok to me.

----------
title: memoryview: allow all casts to bytes -> memoryviews and ctypes

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

From report at bugs.python.org  Fri Aug  7 15:15:49 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Aug 2015 13:15:49 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438953349.17.0.242331257563.issue15944@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Ok, shall we sneak this past Larry for 3.5?

----------

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

From report at bugs.python.org  Fri Aug  7 15:22:12 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Aug 2015 13:22:12 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1438953732.16.0.754558379653.issue15944@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Why not :)

----------

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

From report at bugs.python.org  Fri Aug  7 15:53:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 13:53:24 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1438955604.22.0.720064446028.issue23672@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Interesting, this doesn't work with non-UTF-8 locale.

$ touch astral?.py
$ LC_ALL=en_US.iso88591 ./python -m idlelib.idle -e astral?.py
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "/home/serhiy/py/cpython/Lib/idlelib/PyShell.py", line 1553, in main
    if flist.open(filename) is None:
  File "/home/serhiy/py/cpython/Lib/idlelib/FileList.py", line 36, in open
    edit = self.EditorWindow(self, filename, key)
  File "/home/serhiy/py/cpython/Lib/idlelib/PyShell.py", line 123, in __init__
    EditorWindow.__init__(self, *args)
  File "/home/serhiy/py/cpython/Lib/idlelib/EditorWindow.py", line 288, in __init__
    if io.loadfile(filename):
  File "/home/serhiy/py/cpython/Lib/idlelib/IOBinding.py", line 244, in loadfile
    self.updaterecentfileslist(filename)
  File "/home/serhiy/py/cpython/Lib/idlelib/IOBinding.py", line 525, in updaterecentfileslist
    self.editwin.update_recent_files_list(filename)
  File "/home/serhiy/py/cpython/Lib/idlelib/EditorWindow.py", line 899, in update_recent_files_list
    if '\0' in path or not os.path.exists(path[0:-1]):
  File "/home/serhiy/py/cpython/Lib/genericpath.py", line 19, in exists
    os.stat(path)
UnicodeEncodeError: 'latin-1' codec can't encode character '\U0001d53c' in position 22: ordinal not in range(256)

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Aug  7 16:06:09 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 07 Aug 2015 14:06:09 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1438956369.4.0.0683274528616.issue19771@psf.upfronthosting.co.za>


Laura Creighton added the comment:

I tried to run some tests from  the python3.4 test suite and got:
python3 -m test -ugui test_tk test_ttk_guionly test_idle
/usr/bin/python3: Error while finding spec for 'test.__main__' (<class 'ImportError'>: bad magic number in 'test': b'\x03\xf3\r\n'); 'test' is a package and cannot be directly executed

The actual problem has nothing to do with test being a package.  It
had to do with finding a python2 pyc and trying to run that.  It would be nice if the patch checked for this problem as well before concluding that somebody just tried to execute a package.

----------
nosy: +lac

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

From report at bugs.python.org  Fri Aug  7 16:16:34 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 14:16:34 +0000
Subject: [issue24825] visual margin indicator for breakpoints in IDLE
Message-ID: <1438956994.9.0.955708326842.issue24825@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Right now breakpoints can only be set/cleared by using a context menu on a line in the editor. I discovered this entirely by reading through the bug database, as right-click doesn't work on OS X (#24801).

Some other tools use an indicator (e.g. stop sign) in the left margin, which can be toggled on and off by a simple click. This could exist in conjunction with line numbering (#17535)

----------
components: IDLE
messages: 248194
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: visual margin indicator for breakpoints in IDLE
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 16:29:08 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 14:29:08 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
Message-ID: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>


New submission from Mark Roseman:

This builds on things like the tabbed editor suggestion, but essentially I'm talking about a scenario where you'd have your one (editor) window open working on your program, you click 'run...' or 'debug...' from the menu, and a shell and debugger area open up at the bottom of that one window, and you can resize that area.

This is analogous to what happens if you click 'inspect element' in most web browsers nowadays.

Getting rid of the *need* for multiple windows would help simplify a lot of things.

----------
components: IDLE
messages: 248195
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: ability to integrate editor, shell, debugger in one window
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 16:40:20 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 07 Aug 2015 14:40:20 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1438958420.95.0.117191339579.issue24272@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Here is a new patch for the first part of classes at the end of docs.
I also did some minor changes (in particular added more info on generics and removed the section about ellipsis for default arguments, we could return it if we decide to write something about stub files here).

----------
Added file: http://bugs.python.org/file40144/typedoc_new.patch

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

From report at bugs.python.org  Fri Aug  7 16:52:39 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Aug 2015 14:52:39 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1438959159.15.0.0213877937953.issue23004@psf.upfronthosting.co.za>


Berker Peksag added the comment:

data_as_list = read_data.splitlines(True)

is not actually the equivalent of

    data_as_list = [l + sep for l in read_data.split(sep)]

It will change the behavior of the _iterate_read_data helper. See the comment at https://github.com/python/cpython/blob/78d05eb847c6b8fede08ca74bb59210c00e4c599/Lib/unittest/mock.py#L2278

However, in default branch, we can simplify it to

    yield from read_data.splitlines(keepends=True)

----------

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

From report at bugs.python.org  Fri Aug  7 17:06:48 2015
From: report at bugs.python.org (Peter Landry)
Date: Fri, 07 Aug 2015 15:06:48 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1438960008.12.0.887121398339.issue24764@psf.upfronthosting.co.za>


Peter Landry added the comment:

Yeah, I think that makes the most sense to me as well. I tried to make a minimum-impact patch, but this feels cleaner.

If we remove the Content-Length header, the `limit` kwarg might occur at an odd place in the part itself, but that feels unavoidable if someone submits an incorrect Content-Length for the request itself.

I'll re-work the patch and make sure the tests I added still add value. Thanks!

----------

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

From report at bugs.python.org  Fri Aug  7 17:12:11 2015
From: report at bugs.python.org (Peter Landry)
Date: Fri, 07 Aug 2015 15:12:11 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1438960331.89.0.990932142548.issue24764@psf.upfronthosting.co.za>


Peter Landry added the comment:

A new patch that simply removes Content-Length from part headers when present.

----------
Added file: http://bugs.python.org/file40145/cgi_multipart.patch

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

From report at bugs.python.org  Fri Aug  7 17:45:05 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 07 Aug 2015 15:45:05 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438962305.95.0.281109719995.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Where do we stand with this then? Should I start a thread on python-dev to get the ball rolling?

----------

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

From report at bugs.python.org  Fri Aug  7 17:50:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Aug 2015 15:50:43 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1438962642.99.0.554230738208.issue23004@psf.upfronthosting.co.za>


R. David Murray added the comment:

splitlines(keepends=True) is not ever equivalent to splitting by just '\n'.  I don't know the details here, but switching to that would certainly be a behavior change.  (Especially if the code path also applies to non-binary data!):

>>> b'abc\nde\r\nf\x1dg'.splitlines(True)
[b'abc\n', b'de\r\n', b'f\x1dg']
>>> 'abc\nde\r\nf\x1dg'.splitlines(True)
['abc\n', 'de\r\n', 'f\x1d', 'g']

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Aug  7 18:10:12 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Aug 2015 16:10:12 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1438963812.46.0.00329601955727.issue24824@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

This is related to Arguments Clinic and Larry's implementation of signature parsing for built-in functions.

This particular bug is caused by 'codecs.encode' & 'codecs.decode' functions with the AC signatures defined as follows:

  _codecs.encode
      obj: object
      encoding: str(c_default="NULL") = sys.getdefaultencoding()
      errors: str(c_default="NULL") = "strict"

"encoding" argument's default is a method call, and _signature_fromstr fails to recognize method calls appropriately.

The attached patch fixes the problem by rendering such default values as "<method_name()>".  I don't think we should evaluate the method call anyways, because it can cause strange side effects and can be just plain wrong -- like in this issue -- we shouldn't render 'encoding="utf-8"' just because that's how docs.python.org server is configured.

Anyways, the patch isn't pretty, but does fix the problem with minimal code.  Another option would be to fix codecs.encode and codecs.decode signatures to "encoding: None" and edit documentation accordingly.

Assigning this issue to Larry for his review.

----------
assignee:  -> larry
keywords: +patch
nosy: +larry
priority: normal -> release blocker
stage:  -> patch review
Added file: http://bugs.python.org/file40146/inspect.patch

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

From report at bugs.python.org  Fri Aug  7 18:14:11 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Aug 2015 16:14:11 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438964051.63.0.486678842794.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Guido, I agree, let's not push the updated implementation in 3.5.0.

Gustavo, could you please generate the patch with "hg diff", so that code review here works?  And I think we need a new issue to track the new patch.

----------
nosy: +larry
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Fri Aug  7 18:14:36 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Aug 2015 16:14:36 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438964076.23.0.819449163531.issue23812@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy:  -larry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Fri Aug  7 18:17:46 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Aug 2015 16:17:46 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438964265.98.0.910231591113.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Alex, sure, go ahead.  Although I think python-ideas would be a better choice.

----------

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

From report at bugs.python.org  Fri Aug  7 18:22:37 2015
From: report at bugs.python.org (Chris Brennan)
Date: Fri, 07 Aug 2015 16:22:37 +0000
Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi)
In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za>
Message-ID: <1438964557.02.0.398790565565.issue22028@psf.upfronthosting.co.za>


Chris Brennan added the comment:

This bug appears (for me) when I use longer install paths, both in the GUI installer and doing a silent install via msiexec. The paths I've used so far are these:

E:\langs\Python\x32\27
E:\langs\Python\x32\34
E:\langs\Python\x64\27
E:\langs\Python\x64\34

E:\Python\x32\27
E:\Python\x32\34
E:\Python\x64\27
E:\Python\x64\34

Both of these paths fail to install when pip is called. If I install to a single-level directory, the install works fine (doesn't matter what drive I use either....)

----------
nosy: +Chris Brennan
versions: +Python 2.7

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

From report at bugs.python.org  Fri Aug  7 18:36:15 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Fri, 07 Aug 2015 16:36:15 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438965375.44.0.945966772382.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

I am not using hg anymore, since asyncio migrated to git.

Here's a github PR, does that help? 
https://github.com/python/asyncio/pull/260

----------

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

From report at bugs.python.org  Fri Aug  7 18:37:54 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Aug 2015 16:37:54 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1438965474.67.0.719625350054.issue23812@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Yep, GH works. Thanks!

----------

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

From report at bugs.python.org  Fri Aug  7 19:00:22 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 17:00:22 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438966822.17.0.408323888182.issue24810@psf.upfronthosting.co.za>


Mark Roseman added the comment:

While the thing about asking for a favourite colour before switching to advanced mode was a joke, I do sincerely believe that extensive progressive disclosure techniques should be used to keep much of IDLE's features and options hidden out of the box.

If the response to the question "how can we make IDLE easier to use for X" is always "add feature Y", we're screwed.

----------

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

From report at bugs.python.org  Fri Aug  7 19:01:41 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 07 Aug 2015 17:01:41 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438966901.39.0.371941293902.issue24383@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You could also withdraw. The more I think about it the more I dislike it. I just don't think we should do *anything* that encourages confusion between threads and tasks. They are fundamentally different concepts and should remain so.

----------

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

From report at bugs.python.org  Fri Aug  7 19:04:27 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 07 Aug 2015 17:04:27 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1438967067.39.0.940877473772.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

I've already made my case on python-ideas, so let's talk it over there.

----------

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

From report at bugs.python.org  Fri Aug  7 19:54:04 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 07 Aug 2015 17:54:04 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1438970044.55.0.268168461939.issue24823@psf.upfronthosting.co.za>


eryksun added the comment:

Not every buffer is null-terminated. That's just the assumption used if the size isn't specified. The documentation can possibly be reworded to make this clearer, but the function itself shouldn't be changed.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, eryksun
priority: normal -> low
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 20:41:26 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 18:41:26 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1438972886.57.0.0673641830208.issue24765@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Two negative factors.

1. Users may edit the user config files 'by hand'. They occasionally must edit them to fix problems. Burying them in a *hidden* directory (invisible in Explorer) will make editing much harder, *especially for beginners*.  Even as a long-time Windows user, I only recently learned how to access %APPDATA% in Win 7, by fiddling with the entry bar the right way and adding exactly 'AppDate\' to the existing path, displayed as a path.  I am pretty sure this is different than with XP.  I imagine this has changed again in Win 8 and Win 10.  I really do not want to have to explain the Win version specific details when someone asks how to fix a problem here, python-list, or stackoverflow.  I doubt either of you want to either.

2. The one .idlerc directory is used for all currently installed python versions.  When one installs a new version, such as the upcoming 3.5.0, the custom font and size, custom keybindings, and anything else, are just there.  We cannot magically go back and change all existing installations.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Aug  7 20:54:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 18:54:29 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1438973669.46.0.854981554397.issue24801@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From your description, I an not sure what it is that does not work.

----------

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

From report at bugs.python.org  Fri Aug  7 20:59:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 18:59:29 +0000
Subject: [issue24813] Idle Help dialogs shouldn't be modal
In-Reply-To: <1438921182.01.0.453311500566.issue24813@psf.upfronthosting.co.za>
Message-ID: <1438973969.32.0.403023571143.issue24813@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am broadening this to include re-evaluation of everything under Help.  There are other issues for search on config.

----------
title: About IDLE dialog shouldn't be modal -> Idle Help dialogs shouldn't be modal

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

From report at bugs.python.org  Fri Aug  7 21:08:06 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 19:08:06 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1438974486.88.0.320897886199.issue24801@psf.upfronthosting.co.za>


Mark Roseman added the comment:

If you have your mouse set up to have two buttons, right-clicking in the editor window doesn't bring up the context menu it's supposed to.

----------

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

From report at bugs.python.org  Fri Aug  7 21:18:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Aug 2015 19:18:18 +0000
Subject: [issue24810] UX mode for IDLE targeted to 'new learners'
In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za>
Message-ID: <1438975098.51.0.818226842082.issue24810@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> In general, users and instructors are demanding more
> options, not less.

This is correct.  I teach Python classes using IDLE.  It does NOT need to be dumbed down (people has notepad for that).   The API can be made more usable but I am against this feature request.

----------

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

From report at bugs.python.org  Fri Aug  7 21:23:05 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:23:05 +0000
Subject: [issue24814] Idle: Disable menu items when not applicable
In-Reply-To: <1438921273.62.0.917598140136.issue24814@psf.upfronthosting.co.za>
Message-ID: <1438975385.03.0.323666038465.issue24814@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I want to make this the cover issue for the general topic.  We should make an overall list here.  A patch can cover whatever subset of items that someone wants to tackle.  Specific issues should only be opened when there is a specific patch, or if there are specific problems to discuss for a particular item or set of items. Such separate issues become dependencies of this one.

24817 Format menu

----------
dependencies: +disable format menu items when not applicable
stage:  -> test needed
title: Disable Undo/Redo menu items when not applicable -> Idle: Disable menu items when not applicable

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

From report at bugs.python.org  Fri Aug  7 21:39:37 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:39:37 +0000
Subject: [issue24818] no way to run program in debugger from edit window
In-Reply-To: <1438922651.24.0.0742005388558.issue24818@psf.upfronthosting.co.za>
Message-ID: <1438976377.78.0.0672462786693.issue24818@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Agreed.  I believe Al's menu revision suggested moving Debugger to Run. Debugger has to hook into Shell because it has to see packets moving between Shell and the execution process. Opening the debugger window currently requires that Shell already be open. Running a file opens Shell.  So we need to rewrite Debugger to delay hooking into Shell unless Shell is present .. or until it is activated (by running a file).  I believe this could be done by having a .connect_to_shell method that can be called either from .__init__ or the activate method.

There are several worse problems with Debugger.  I think they need some consideration together, lest a patch for one issue interfere with a patch for another.

----------

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

From report at bugs.python.org  Fri Aug  7 21:41:54 2015
From: report at bugs.python.org (Tom Pohl)
Date: Fri, 07 Aug 2015 19:41:54 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1438976514.93.0.0624641056926.issue24823@psf.upfronthosting.co.za>


Tom Pohl added the comment:

I agree: not every buffer is null-terminated.

But the function name suggests that it creates a _string_ buffer which will most likely be used as an input to a C function. There, it can easily trigger a buffer overflow without a null termination which can be considered a severe security risk.

----------
components:  -Documentation
versions:  -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug  7 21:43:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:43:09 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1438976589.92.0.60473175793.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This looks like mostly a duplicate of #7949.  Can you differentiate?

----------

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

From report at bugs.python.org  Fri Aug  7 21:50:17 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:50:17 +0000
Subject: [issue24816] don't allow selecting IDLE debugger menu item when
 running
In-Reply-To: <1438922050.39.0.00616155269251.issue24816@psf.upfronthosting.co.za>
Message-ID: <1438977017.74.0.643135522173.issue24816@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Stackviewer should also be disabled when not applicable, which I believe included while debugger is running (unless it is modified, or including in debugger).

----------

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

From report at bugs.python.org  Fri Aug  7 21:53:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:53:53 +0000
Subject: [issue23937] IDLE: revise window size, placement startup options
In-Reply-To: <1428955532.11.0.740629698052.issue23937@psf.upfronthosting.co.za>
Message-ID: <1438977233.81.0.63556555265.issue23937@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE start maximized -> IDLE: revise window size, placement startup options

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

From report at bugs.python.org  Fri Aug  7 21:54:02 2015
From: report at bugs.python.org (Tom Pohl)
Date: Fri, 07 Aug 2015 19:54:02 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1438977242.35.0.671003388474.issue24823@psf.upfronthosting.co.za>


Tom Pohl added the comment:

If one needs to set a general buffer (i.e. not a null-terminated string buffer) one could always use:

>>> string = (ctypes.c_char*4)()
>>> string.raw = b'abcd'

----------

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

From report at bugs.python.org  Fri Aug  7 21:54:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 19:54:23 +0000
Subject: [issue24819] replace window size preference with just use last window
 size
In-Reply-To: <1438922909.15.0.485758801191.issue24819@psf.upfronthosting.co.za>
Message-ID: <1438977263.03.0.0901205041574.issue24819@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: revise window size, placement startup options

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

From report at bugs.python.org  Fri Aug  7 22:07:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 20:07:46 +0000
Subject: [issue24825] visual margin indicator for breakpoints in IDLE
In-Reply-To: <1438956994.9.0.955708326842.issue24825@psf.upfronthosting.co.za>
Message-ID: <1438978066.41.0.24623192288.issue24825@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#24801 needs to be fixed so we can depend on right clicking. I think SET and CLEAR should be replace by TOGGLE (#22083). The patch for #17535 already includes marking breakpoints in the margin.  I am opposed to a putting a symbol on every line.  Too noisy and too confusing to beginners for an advanced feature.  There are other things that could be added to a line-number context menu, such as cutting or copying a line without having to drag select it (which is too easy to mess up).

----------

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

From report at bugs.python.org  Fri Aug  7 22:09:47 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 20:09:47 +0000
Subject: [issue17397] ttk::themes missing from ttk.py
In-Reply-To: <1363005797.61.0.988966555267.issue17397@psf.upfronthosting.co.za>
Message-ID: <1438978187.16.0.37604805835.issue17397@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I believe the ttk::themes call is older, part of when it was still Tile. There are a bunch of those kind of API's that were kept around (for compatibility I presume) when the official API (style theme names) was created and documented.

As explained on the original mailing list thread, the difference has to do with Tcl's lazy loading of packages (i.e. it knows what package to load when you need a particular command, but will not necessarily load it until the command is used)
    http://code.activestate.com/lists/python-tkinter-discuss/3371/

To summarize, even now you can install themes and use them, they just won't appear in the list until they're used.

Because calls like ttk::themes are *not* part of the official, documented API, I would strongly suggest not adding a separate API in tkinter; instead, stay with Style.theme_names

I would suggest that the default behaviour of theme_names be changed to call ttk::themes (falling back on theme use if it generates an error). I would also suggest adding a tkinter-only optional keyword parameter to this call (e.g. loaded, defaulting to False; if True is would call 'ttk::style theme names'). Then document that loaded=True is not guaranteed to be only loaded ones in future, because I wouldn't be surprised if Tk changes this at some point.

----------

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

From report at bugs.python.org  Fri Aug  7 22:14:25 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 20:14:25 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1438978465.66.0.301734437746.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I read #7949 as saying the text widget picks up the background color from the system-wide GTk theme. 

This one is saying that the background color of the text widget should be changeable as part of an IDLE highlighting theme.

----------

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

From report at bugs.python.org  Fri Aug  7 22:17:54 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 20:17:54 +0000
Subject: [issue24825] visual margin indicator for breakpoints in IDLE
In-Reply-To: <1438956994.9.0.955708326842.issue24825@psf.upfronthosting.co.za>
Message-ID: <1438978674.5.0.997563838513.issue24825@psf.upfronthosting.co.za>


Mark Roseman added the comment:

oh agree, definitely don't want a symbol on every line. i was already thinking implementation where you'd probably have an object matching the background for hit detection! :-)

but yes, visually nothing there but empty space when there isn't a breakpoint, and a symbol there when the breakpoint is set

----------

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

From report at bugs.python.org  Fri Aug  7 23:03:50 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 21:03:50 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1438981430.73.0.501975255207.issue24750@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I'm attaching mainwin3.patch, which is a subset of the previous patches, modified to not use ttk. It gets rid of the highlightthickness, the sunken line/column effect, and adds a thin separator below the text widget.

----------
Added file: http://bugs.python.org/file40147/mainwin3.patch

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

From report at bugs.python.org  Fri Aug  7 23:34:12 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 21:34:12 +0000
Subject: [issue24812] All standard keystrokes not recognized in IDLE dialogs
 on Mac
In-Reply-To: <1438920938.34.0.296980992753.issue24812@psf.upfronthosting.co.za>
Message-ID: <1438983252.47.0.469159423038.issue24812@psf.upfronthosting.co.za>


Mark Roseman added the comment:

note that many of these are using 'simpledialog' which has that limitation

----------

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

From report at bugs.python.org  Fri Aug  7 23:37:15 2015
From: report at bugs.python.org (jan parowka)
Date: Fri, 07 Aug 2015 21:37:15 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1438983435.64.0.0633100963809.issue24765@psf.upfronthosting.co.za>


jan parowka added the comment:

> fiddling with the entry bar the right way and adding exactly 'AppDate\' to the existing path

You can type in '%APPDATA%' in the path bar, run dialog, or even start menu, and it will take you to the current user's Application Data folder. It works from XP upwards.

> The one .idlerc directory is used for all currently installed python versions

Yes, I imagine that's a bigger issue. The installer could, however, check whether there is currently an .idle directory in user folder and copy the settings over.

----------

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

From report at bugs.python.org  Fri Aug  7 23:39:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Aug 2015 21:39:41 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <20150807213936.23398.93003@psf.io>


Roundup Robot added the comment:

New changeset 8e966eba2b5e by Steve Dower in branch '3.5':
Issue #24798: _msvccompiler.py doesn't properly support manifests
https://hg.python.org/cpython/rev/8e966eba2b5e

New changeset f61a083b843f by Steve Dower in branch 'default':
Issue #24798: _msvccompiler.py doesn't properly support manifests
https://hg.python.org/cpython/rev/f61a083b843f

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  7 23:43:20 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 07 Aug 2015 21:43:20 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1438983800.26.0.995844387086.issue24798@psf.upfronthosting.co.za>


Steve Dower added the comment:

Made a couple more changes (including a fix for vcruntime140.dll embedding) after testing numpy's build, but that worked fine with the final fixes.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Aug  7 23:57:32 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 21:57:32 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1438984652.37.0.767454661979.issue24801@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached macpopup.patch which removes the incorrect Tk behaviour and makes it so that right click on Mac will bring up the context menu as appropriate.

----------
keywords: +patch
Added file: http://bugs.python.org/file40148/macpopup.patch

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

From report at bugs.python.org  Sat Aug  8 00:28:39 2015
From: report at bugs.python.org (Tiago Wright)
Date: Fri, 07 Aug 2015 22:28:39 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <CAFxr9VpV5qxZ7H1Gzn_a5u63F1WVJsaXmse0EFv78sV4G_9jHA@mail.gmail.com>
Message-ID: <CAFxr9VpDak7E6rhZjER9rFoyGNsxcTQi5FiMBd13+RqA43oKMg@mail.gmail.com>


Tiago Wright added the comment:

Attached is a .py file with 32 test cases for the Sniff class, 18 that
fail, 14 that pass.

My hope is that these samples can be used to improve the delimiter
detection code.

-Tiago

----------
Added file: http://bugs.python.org/file40149/testround8.py

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

def test_delimiters():

	delimiter_samples = [
	
		{ 'delimiter' :"\t", 'sample' :   # error:"Exception"
'''Field Name				Definition
RefID				        Unique (sequential) number assigned to vehicles
IsBadBuy				Identifies if the kicked vehicle was an avoidable purchase 
PurchDate				The Date the vehicle was Purchased at Auction
Auction					Auction provider at which the  vehicle was purchased
VehYear					The manufacturer's year of the vehicle
VehicleAge				The Years elapsed since the manufacturer's year
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"Exception"
'''rules	support	confidence	lift
1	{Brushes} => {Nail.Polish}	0.149	1	3.57142857142857
2	{Brushes} => {Bronzer}	0.097	0.651006711409396	2.33335738856414
3	{Brushes} => {Concealer}	0.092	0.61744966442953	1.39694494214826
4	{Lip.liner} => {Concealer}	0.179	0.764957264957265	1.73067254515218
5	{Bronzer} => {Concealer}	0.175	0.627240143369176	1.41909534698909
6	{Blush} => {Concealer}	0.22	0.606060606060606	1.37117784176608
''' },

		{ 'delimiter' :",", 'sample' :   # error:"Exception"
'''A,B,C,D,E
2000-01-03 00:00:00,0.980268513777,3.68573087906,-0.364216805298,-1.15973806169,foo
2000-01-04 00:00:00,1.04791624281,-0.0412318367011,-0.16181208307,0.212549316967,bar
2000-01-05 00:00:00,0.498580885705,0.731167677815,-0.537677223318,1.34627041952,baz
2000-01-06 00:00:00,1.12020151869,1.56762092543,0.00364077397681,0.67525259227,qux
2000-01-07 00:00:00,-0.487094399463,0.571454623474,-1.6116394093,0.103468562917,foo2
''' },

		{ 'delimiter' :",", 'sample' :   # error:"Exception"
'''1,699,4751,4158
8,1856
12,4059,5716,4299,4967,2128
16,1928,1176
19,1928,2775,4646,1720,3148,2552,5978,3736,3090
22,4059,1856,4103,4739,4865,4769,621,2874,1637,252
28,5321,4059,4952,1856,4103,699,1976
''' },

		{ 'delimiter' :",", 'sample' :   # error:"Exception"
'''?????????Date,From,To,Flight_Number,Airline,Distance,Duration,Seat,Seat_Type,Class,Reason,Plane,Registration,Trip,Note,From_OID,To_OID,Airline_OID,Plane_OID
2004-08-27,YHZ,YYZ,,Air Canada,801,01:56,,A,Y,L,,,,,73,193,330
2004-08-01,YYZ,YHZ,,Air Canada,801,01:56,,A,Y,L,,,,,193,73,330
2004-07-30,YHZ,YYZ,,Air Canada,801,01:56,,A,Y,L,,,,,73,193,330
2004-05-30,ZRH,MUC,,Lufthansa,162,00:47,,,Y,L,,,,,1678,346,3320
2004-05-30,MUC,YYZ,,Air Canada,4131,07:53,,,Y,L,,,,,346,193,330
2004-05-30,YYZ,YOW,,Unknown,226,00:54,,,Y,L,,,,,193,100,-1
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"Exception"
'''Format version	Start date	End date	Sender	Recipient	Aggregator
5	2010-05-01	2010-05-31	Spotify	Udsvxd	Udsvxd
Country	Label	Product	Currency	Total tracks	Rightholder's tracks	Pro rata share	Revenue share	Number of users	Net revenue	Payable	USD Rate	USD Payable
XV	Ipstqx Gjivgmn	C	JFG	33126406	7	0.00	20.00	87845	851092.49	0.04	5.6647	0.09
JN	Mvcqxv Gjivgmqxd Iv	P	JFG	368037889	635611	0.01	40.00	472355	639147.36	506.62	5.6647	562.82
IL	Mvcqxv Gjivgmn	C	JFG	3501	6	0.04	20.00	8	31.61	0.05	5.6647	0.05
DW	Mvcqxv	C	DWO	62836541	58448	0.04	20.00	84344	330574.21	557.63	5.8230	513.62
''' },

		{ 'delimiter' :",", 'sample' :   # error:"Exception"
'''age,workclass,education,education-num,marital-status,occupation,relationship,race,sex,capital-gain,capital-loss,hours-per-week,native-country,1iclass
39, State-gov, 77516, Bachelors, 13, Never-married, Adm-clerical, Not-in-family, White, Male, 2174, 0, 40, United-States, <=50K
50, Self-emp-not-inc, 83311, Bachelors, 13, Married-civ-spouse, Exec-managerial, Husband, White, Male, 0, 0, 13, United-States, <=50K
38, Private, 215646, HS-grad, 9, Divorced, Handlers-cleaners, Not-in-family, White, Male, 0, 0, 40, United-States, <=50K
53, Private, 234721, 11th, 7, Married-civ-spouse, Handlers-cleaners, Husband, Black, Male, 0, 0, 40, United-States, <=50K
28, Private, 338409, Bachelors, 13, Married-civ-spouse, Prof-specialty, Wife, Black, Female, 0, 0, 40, Cuba, <=50K
37, Private, 284582, Masters, 14, Married-civ-spouse, Exec-managerial, Wife, White, Female, 0, 0, 40, United-States, <=50K
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"M"
'''Invoice File	Credit Memo	Amount Claimed	Description	Invoice	Message	
Sscanner ac15024711440.pdf	CM_15406	49213.64	MX 607293 607822 (feb)	739179	
Sscanner ac15024711441.pdf	CM 18139	15800	MX Husband	739177	
Sscanner ac15024711460.pdf	CM 18139	66399	MX Prof-specialty	739400	Photos don't match the invoice
Sscanner ac15024711481.pdf	CM_13383	1216.8	MX Exec-managerial	739406	
Sscanner ac15024711484.pdf	CM 18139	6113	MX Married-civ-spouse	739404	
Sscanner ac15024711450.pdf	CM_13383	1464.49	MX Adm-clerical	739409	
''' },

		{ 'delimiter' :",", 'sample' :   # error:"c"
'''?????????Date,From,To,Flight_Number,Airline,Distance,Duration,Seat,Seat_Type,Class,Reason,Plane,Registration,Trip,Note,From_OID,To_OID,Airline_OID,Plane_OID
2009-11-22,FRA,ORD,83,American Airlines,4336,08:15,,,Y,L,,,,,340,3830,24
2009-11-21,DFW,LAX,2407,American Airlines,1233,02:42,,,Y,L,,,,,3670,3484,24
2009-11-21,ORD,FRA,84,American Airlines,4336,08:15,,,Y,L,,,,,3830,340,24
2009-11-21,LAX,ORD,1972,American Airlines,1744,03:37,,,Y,L,,,,,3484,3830,24
2009-11-04,SEA,DFW,428,American Airlines,1660,03:28,,,F,B,,,,,3577,3670,24
2009-11-02,ORD,SEA,509,American Airlines,1718,03:34,,,Y,B,,,,,3830,3577,24
''' },

		{ 'delimiter' :" ", 'sample' :   # error:"e"
'''  -7.7947021e-01   8.3822138e-01   1.0000000e+00
   1.5563491e-01   8.9537743e-01   1.0000000e+00
  -5.9907703e-02  -7.1777995e-01   1.0000000e+00
   2.0759636e-01   7.5893338e-01   1.0000000e+00
  -1.9598312e-01  -3.7548716e-01  -1.0000000e+00
   5.8848947e-01  -8.4255381e-01   1.0000000e+00
   7.1985874e-03  -5.4831650e-01  -1.0000000e+00
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"p"
'''Format version	Start date	End date	Sender	Recipient	Aggregator
8	2010-08-01	2010-08-31	Spotify	Udsvxd	Udsvxd
Country	Label	Product	URI	UPC	ISRC	Track name	Artist name	Composer name	Album name	Quantity	USD Payable
BI	Krgzur Epfrekzub Fr	Y	spotify:track:5LcJHnfHaOgzqgEdBm5SYR		BIFPH5000567	Ixev	Msp Cyhh		Ixev	582	0.57940800
UH	Krgzur Epfrekzub Fr	Y	spotify:track:5LcJHnfHaOgzqgEdBm5SYR		BIFPH5000567	Ixev	Msp Cyhh		Ixev	4	0.00464677
PT	Krgzur Epfrekzub Fr	Y	spotify:track:5LcJHnfHaOgzqgEdBm5SYR		BIFPH5000567	Ixev	Msp Cyhh		Ixev	54	0.00470712
TP	Krgzur Epfrekzub Fr	Y	spotify:track:5LcJHnfHaOgzqgEdBm5SYR		BIFPH5000567	Ixev	Msp Cyhh		Ixev	50	0.00385357
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"space"
'''Start Date	End Date	UPC	ISRC/ISBN	Vendor Identifier	Quantity	Partner Share	Extended Partner Share	Partner Share Currency	Sales or Return	Apple Identifier	Artist/Show/Developer/Author	Title	Label/Studio/Network/Developer/Publisher	Grid	Product Type Identifier	ISAN/Other Identifier	Country Of Sale	Pre-order Flag	Promo Code	Customer Price	Customer Currency
08/05/2012	09/01/2012		DXSLM1100784	DXSLM1100784	7			SHP		954411600	Cbsvas Wgrzlif	A.U.F.V.	Ugwarg Blsgbuard Sg		H5		SH				
08/05/2012	09/01/2012		DXSLM0800165	DXSLM0800165	9			SHP		188943559	Okragb Xgif	Vhl Lqkcmaylb	Ugwarg Blsgbuard Sg Mvu		H5		SH				
08/05/2012	09/01/2012		DXSLM0200696	DXSLM0200696	1			SHP		906524385	Tamu Xlcfvf	Vtg Ucrslbf (aa) [Ogr Hgjzarf Blwae]	Ugwarg Blsgbuard Sg		H5		SH				
08/05/2012	09/01/2012		DXSLM1100588	DXSLM1100588	4			SHP		989512521	Blcm Lfvcvl	Av'f Blcm	Ugwarg Blsgbuard Sg Mvu		H5		SH				
08/05/2012	09/01/2012		DXSLM0200734	DXSLM0200734_4059707501641	1			SHP		510770760	Ogzlb'f Uckdhvlb	Vhl Mcfv Mckdh	Ugwarg Blsgbuf		H5		SH				
08/05/2012	09/01/2012		DXSLM0600760	DXSLM0600760	4			SHP		767159752	Xgrral "Jbarsl" Xammi	Fg Lnlbigrl	Ugwarg Blsgbuf		H5		SH				
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"space"
'''ym	Stock Code	Artist	Title	Total)	AA)	Other)	YV)	VR)	ZF/Y2)	HB/QN)	VX/FS/MM/AN)	QB)	PR)	GX)	TN/GO)	HQ)	QG RN IK YZ)	YS)	BNW
201207	07MDI957	MXGJC BGIPTAJIGE	Leatdmxdn Utzimc	2.18	2.18	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
201207	07MDI826	ALEE UAAIUOE	Oglmztc Ulddxdn	24.40	24.40	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
201207	07MDI423	ALEE UAAIUOE	Jyt Elut Jyxdn	85.39	85.39	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
201207	OIDDXT-OIIQ-BLBTG	JE006472	Sxzz Izmylu Id Oiddxt 'Bgxdat' Oxzzc Blbtgolaq Oiiq	281.18	281.18	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
201207	MIUOLN2OZLAQ	JE006432	MIUXDI OLNNH - OZLAQ	26.67	26.67	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
201207	MIUOQ02	PLUTE CIGQEJID	PLUTE CIGQEJID OIIQ	97.70	97.70	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"space"
'''Name	Artist	Composer	Album	Grouping	Genre	Size	Time	Disc Number	Disc Count	Track Number	Track Count	Year	Date Modified	Date Added	Bit Rate	Sample Rate	Volume Adjustment	Kind	Equalizer	Comments	Plays	Last Played	Skips	Last Skipped	My Rating	Location
Csxk Sj I Biel	AQLMMLA	AQLMMLA	Zyjb Rdasb Aqxsje 2015 Btmmlbostj	Btjoibo ZYJB RDASB Msbljasje at zyjbrdasb.btr 686-669-2255	ZYJB	9887402	846			6		2015	6/87/84, 2:26 QR	6/63/84, 7:09 QR	360	22800		RQLE idkst hsml		dqolrqt qlxbdaasul kxdra oxscim hlr utn sjksl qtq xtbf ijoglrsb ijoglr labiql hxllktr alo hxll jtj-myxsb-utn ceu kixfjlaa msego bttm kxsusje alny gijk bmiqa hmy xgyogrsb admoxy bgijel qtplxhdm aoxtje sjklqljkljo lrqtplxrljo atqgsaosbiolk lkey psmk glixo b	8	4/80/84, 9:37 QR	8	3/89/84, 2:60 IR		Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:AQLMMLA:Zyjb Rdasb Aqxsje 2015 Btmmlbostj:06 Csxk Sj I Biel.rq3
Bixlmlaa	Imln Psjaotj	Imln Psjaotj	Zyjb Rdasb Aqxsje 2015 Btmmlbostj	Btjoibo ZYJB RDASB Msbljasje at zyjbrdasb.btr 686-669-2255	ZYJB	80317562	641			4		2015	6/87/84, 2:26 QR	6/63/84, 7:09 QR	360	22800		RQLE idkst hsml		rskolrqt qtq xtbf kijbl hlr utn eije qixoy lrtostjim atixsje lqsb sjaqsxsje kxsusje biobgy ikuljodxtda cdsmk Afy Hlxxlsxi ijoglrsb rtosuiostjim qlxbdaasul ayjog qsijt cxsego xgyogrsb giqqy ytdoghdm qmiyhdm ljlxelosb bdol dqmshosje tqosrsaosb lnbsolk msego						Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:Imln Psjaotj:Zyjb Rdasb Aqxsje 2015 Btmmlbostj:04 Bixlmlaa.rq3
Kt So Ieisj	X??????yfatqq & Xtcyj				Adrrlx Wira 2014; Csmmctixk Bgixolk - DF; Ieisj	86647541	309			3		2014	4/61/82, 5:65 QR	9/9/84, 7:29 QR	360	22800		RQLE idkst hsml								Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:X??????yfatqq & Xtcyj:Djfjtpj Imcdr:03 Kt So Ieisj.rq3
Hsjk Ry Piy Msrsolx	Gdobg Gixxsa		Oicml 45			64370600	838						86/4/82, 9:07 QR	86/4/82, 9:07 QR	8439	25000		PIU idkst hsml			6	9/9/84, 7:61 QR				Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:Gdobg Gixxsa:Oicml 45:Hsjk Ry Piy Msrsolx.piu
Esul So 6 Rl	Riktjji		Gixk Bijky		Qtq	9505711	657			3	86	2008	2/6/84, 80:06 IR	2/6/84, 80:09 IR	851	22800		RQLE idkst hsml								Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:Riktjji:Gixk Bijky:03 Esul So 6 Rl.rq3
S Wdao Pijji Mtul D (Esul So 6 Rl)	Wiy-Z	Bgxsaotqglx Pimmibl/Fsoo Pimflx/Rsfl Hmtplxa/Alij Btrca/Klxsb Rsbgilm "KTQ" Ijelmloosl/Otkk Agip/Qgixxlmm Psmmsira/Bgik Gdet/Wirla Wtgjatj/Agipj Bixolx	Ogl Kyjiaoy Xtb Mi Hirsmsi 2000		Xiq	9120192	667	8	8	3	89	2000	2/6/84, 80:06 IR	2/6/84, 80:09 IR	360	22800		RQLE idkst hsml								Ribsjotag GK:Dalxa:xap:Rdasb:sOdjla:sOdjla Rdasb:Btrqsmiostja:Ogl Kyjiaoy Xtb Mi Hirsmsi 2000:03 S Wdao Pijji Mtul D (Esul So 6 Rl).rq3
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:","
'''01-12-2010	31-12-2010	BPRDO0508860	Slrekr Mqftdwn	Ejd Zkdc Vlqm Ejd Svedlfqqf	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	4	0.0418
01-12-2010	31-12-2010	BPRDO0508868	Slrekr Mqftdwn	K Pde Wqy Oqqt Bqqh Qf Ejd Hsfrdvoqql	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	1	0.0162
01-12-2010	31-12-2010	BPRDO0508864	Slrekr Mqftdwn	Vstd Esodn Qv Nsf Vlsfrknrq	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	8	0.0848
01-12-2010	31-12-2010	BPRDO0508862	Slrekr Mqftdwn	Hsfrkfb Njqdn	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	8	0.0848
01-12-2010	31-12-2010	BPRDO0508867	Slrekr Mqftdwn	Lkqe Zsf	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	4	0.0418
01-12-2010	31-12-2010	BPRDO0508869	Slrekr Mqftdwn	Ldh Okbje Kfhkrsedn Hqqln Sld Ndryldh	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	4	0.0418
01-12-2010	31-12-2010	BPRDO0508866	Slrekr Mqftdwn	Mslhw Pym	Cjsedzdl Adqaod Nsw K Sm, Ejse'n Cjse K'm Fqe	5034202016250	VL	8	0.0848
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:":"
'''Format version	Start date	End date	Sender	Recipient	Aggregator
1	09/01/11	09/30/11	Spotify	Udsvxd	Udsvxd
Country	Label	Product	URI	UPC	EAN	ISRC	Track name	Artist name	Composer name	Album name	Quantity	USD Payable
VR	Jthrxt Psftpjrxk Ft	H	spotify:track:02xTp9FM6wiKSFB0B55vze		5036202029354	{'isrc': 'KDFSL1000399'}	Hqpoqx	Woqcc, Qcahtx, Bcseusx		Vtp Cus Kutbcb Wrcurx	1	0.0113
BS	Jthrxt Psftpjrxk Ft	H	spotify:track:02xTp9FM6wiKSFB0B55vze		5036202029354	{'isrc': 'KDFSL1000399'}	Hqpoqx	Woqcc, Qcahtx, Bcseusx		Vtp Cus Kutbcb Wrcurx	4	0.0715
XL	Jthrxt Psftpjrxk Ft	Q	spotify:track:02xTp9FM6wiKSFB0B55vze		5036202029354	{'isrc': 'KDFSL1000399'}	Hqpoqx	Woqcc, Qcahtx, Bcseusx		Vtp Cus Kutbcb Wrcurx	1	0.0038
SB	Jthrxt Psftpjrxk Ft	H	spotify:track:02xTp9FM6wiKSFB0B55vze		5036202029354	{'isrc': 'KDFSL1000399'}	Hqpoqx	Woqcc, Qcahtx, Bcseusx		Vtp Cus Kutbcb Wrcurx	1	0.0060
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"Exception"
'''Format version	Start date	End date	Recipient	Aggregator
2	11/01/11	11/30/11	Udsvxd	Udsvxd
Country	Label	Product	Currency	Total tracks	Rightholder's tracks	Pro rata share	Revenue share	Subscriber number	Net revenue	Payable	EUR Payable	USD Payable
QG	Spnxlp Hgyphsi	M	JIS	959	3	0.93	90	3	37.9397	0.0451	0.0517	0.0451
QG	Spjafg Ixk Hgyphsi	M	JIS	959	3	0.93	90	3	37.9397	0.0451	0.0517	0.0451
QZ	Spnxlp	J	GJH	10702	77	0.09	90	11	294.4235	0.0550	0.0550	0.0444
QZ	Spnxlp Hgyphsxld Yp	J	GJH	10702	43	0.72	90	11	294.4235	0.7180	0.7180	0.3392
''' },

		{ 'delimiter' :"\t", 'sample' :   # error:"Exception"
'''Format version	Start date	End date	Sender	Recipient	Aggregator
5	11/01/11	11/30/11	Spotify	Udsvxd	Udsvxd
Country	Label	Product	URI	UPC	EAN	ISRC	Track name	Artist name	Composer name	Album name	Quantity	USD Payable
CW	Lsmwts Onysolz	500	spotify:track:1EpGeaPY1xl7AKDwTA5ICI	6081303033068	6081303033068	UDYNP0900112	Hsvwst Qhhosqyjwtu	Qoyvwy Mstfnkz		Jemdeu	5	0.1913
ZN	Lsmwts Onysolz	10	spotify:track:1EpGeaPY1xl7AKDwTA5ICI	6081303033068	6081303033068	UDYNP0900112	Hsvwst Qhhosqyjwtu	Qoyvwy Mstfnkz		Jemdeu	5	0.2430
UD	Lsmwts Onysolz	50	spotify:track:1EpGeaPY1xl7AKDwTA5ICI	6081303033068	6081303033068	UDYNP0900112	Hsvwst Qhhosqyjwtu	Qoyvwy Mstfnkz		Jemdeu	5	0.7039
CO	Lsmwts Onysolwtu Ys	10	spotify:track:3XcGI3U2oubSZ81biq57b9		6081303032065	UDYNP5000448	Wpp Dn Kseo Mqt	Qttq Yqpgw		Qttq Yqpgw	5	0.2283
''' },

		{ 'delimiter' : "\t", 'sample' :  # success: "\t"
'''01-12-2011	31-12-2011	PRLXA0300433	Denz Qxq	Hwpxa Xljexo	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	9	0.0401
01-12-2011	31-12-2011	PRLXA0300808	Denz Qxq	Ojx Inoq Abyxo Qe Dbpjq	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	8	0.2521
01-12-2011	31-12-2011	PRLXA0300800	Denz Qxq	Aemx Lzv	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	9	0.0401
01-12-2011	31-12-2011	PRLXA0300809	Denz Qxq	Obwp	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	5	0.012
01-12-2011	31-12-2011	PRLXA0300802	Denz Qxq	Lbzlabwp	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	9	0.0401
01-12-2011	31-12-2011	PRLXA0300805	Denz Qxq	Qjbo Nwdeaso	Qjxzx Bo Aemx Bw Ven	6095707076560	PR	5	0.012
01-12-2011	31-12-2011	PRLXA2200759	Raees Ezhwpx	Onqujbw Renaxmhzs	Onqujbw Renaxmhzs	6095707257061	PR	24	0.975
''' },

		{ 'delimiter' : "\t", 'sample' :  # success: "\t"
'''Start Date	End Date	UPC	ISRC/ISBN	Vendor Identifier	Quantity	Partner Share	Extended Partner Share	Partner Share Currency	Sales or Return	Apple Identifier	Artist/Show/Developer/Author	Title	Label/Studio/Network/Developer/Publisher	Grid	Product Type Identifier	ISAN/Other Identifier	Country Of Sale	Pre-order Flag	Promo Code	Customer Price	Customer Currency
05/06/2012	06/02/2012		KIUDS0400639	KIUDS0400639	5	0.002240662	0.002240662	EOB		403440397	Usfzfu	Cwsovwcc	Byafzy Pduypbo		N4		IP				
05/06/2012	06/02/2012		KIUDS0900070	KIUDS0900070	6	0.002240662	0.05508092	EOB		689702292	Vnd Awkzdvfu Cfdsbo	Sdv'o Jpdvdzdb Qd'pd Iezzl Pwiifvo	Byafzy Pduypbo		N4		WP				
05/06/2012	06/02/2012		KIUDS0800513	KIUDS0800513	5	0.002240662	0.002240662	EOB		621009036	Hezfyp Iylo	Uweknv Fz w Qwtd	Byafzy Pduypbo		N4		IP				
05/06/2012	06/02/2012		KIUDS0100859	KIUDS0100859	5	0.002240662	0.002240662	EOB		636890988	Pyidpv Qlwvv	Sfvvsd Pdb Pyifz Nyyb Nfv vnd Pywb	Byafzy Pduypbo		N4		WP				
05/06/2012	06/02/2012		KIUDS0200146	KIUDS0200146	54	0.002240662	0.075136362	EOB		10370786	Cpwzr Cdpbfzwzb	Dsdwzyp Jev Lyep Iyyvo Yz	Byafzy Pduypbfzk Uy Svb		N4		US				
05/06/2012	06/02/2012		KIUDS0800574	KIUDS0800574	5	0.002240662	0.002240662	EOB		542377384	Wpuvfu Ayzgdlo	Qny vnd Ceug Wpd Wpuvfu Ayzgdlo?	Byafzy Pduypbfzk Uy Svb		N4		JD				
''' },

		{ 'delimiter' : "\t", 'sample' :  # success: "\t"
'''DSN	Actual Ship Date	Carrier Name	SCAC	Carrier Route Reference	Tracking Number	SSCC	Warehouse Short Name	RETAILER NAME	Purchase Order Id	Sales Order Id	ITEM NAME	PRODUCT CODE NAME	ASIN	UPC	Reseller Item Code
50867707487408X3	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
5086770748740ZS2	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
5086770748740R0Z	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
5086770748740R8W	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
5086770748740B0O	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
5086770748740B90	2015-07-31	DABBJDI DXCCEJC	DDDD	02275851086558021		002275859971801442	LQ-EPBRQI	Etidapjs, Etd	716427	QAIMHETQAN.8	Hetai 3MF, YeWE, OH64QOE, CAY/JL/DX/PS/FC/NX, ATBETJ/AWWBETJ	Hetai	F00RM1MFOP	131685037747	IX000KOB09
''' },

		{ 'delimiter' : "\t", 'sample' :  # success: "\t"
'''Product Context	Product Attribute	Product Value	Product Description	UOM	Primary UOM	Line Type	Price Break Type	Application Method	Value	Static Formula	Start Date	End Date	Precedence	[ ]	
Rpwt	Rpwt Oftdwh	D008N0QKYW	Lrogqw Nrhw Yqwwew	WM		Uhriw Qryp Qrow		Forp Uhriw	35.55			73-TMH-2012	330		
Rpwt	Rpwt Oftdwh	D008N0QKYW	Lrogqw Nrhw Yqwwew	WM		Uhriw Qryp Qrow		Forp Uhriw	32.55		74-TMH-2012		330		
Rpwt	Rpwt Oftdwh	D008NH35BT	Lrogqw Nrhw Gwtj - FY	WM		Uhriw Qryp Qrow		Forp Uhriw	725				330		
Rpwt	Rpwt Oftdwh	D008N0QKGA	Lrogqw Pjfik Qwmpkwh Ijewh	WM		Uhriw Qryp Qrow		Forp Uhriw	45.55				330		
Rpwt	Rpwt Oftdwh	D002YG348M	Lrogqw Pjfik Qrskpwg Qwmpkwh Ijewh	WM		Uhriw Qryp Qrow		Forp Uhriw	85.55				330		
Rpwt	Rpwt Oftdwh	D008NH3MDM	Lrogqw Pjfik 4S Gwtj - FY	WM		Uhriw Qryp Qrow		Forp Uhriw	50				330		
''' },

		{ 'delimiter' : "\t", 'sample' :  # success: "\t"
'''Modifier No	Level	Modifier Type	Start Date	End Date	Print On Invoice	Automatic	Override	Pricing Phase	Incompatibility Group	Bucket	Proration Type	Comparison Value	Product Attribute	Product Attribute Value	Product Description	Volume Type	Break Type	Operator	UOM	Value From	Value To	[ ]	Charge Name	Include On Returns	Formula	Application Method	Value	Benefit Quantity	Benefit UOM	Expiration Date	Expiration Period Start Date	Expiration Period	Period Type	Rebate Transaction Type	Accrual Redemption Rate	Accrual Conversion Rate	Upgrade Item	Terms Attribute	Terms Value	Benefit Quantity	Benefit UOM	Redemption Rate	Coupon Conversion Rate	Expiration Date	Expiration Start Date	Expiration Period	Expiration Period Type	Coupon Modifier Number	Adjustment Type	Net Amount Calculation	Expiration Date	Expiration Start Date	Expiration Duration	Period Type	Rebate Transaction Type	Accrual Redemption Rate	
F0014L12EM	Uabp	Tamjnkbz			*	*	*	Uamz Uabp Rtdkmzepbz	Upipu 6 Abjneyrzafauazs	6	Bnbp		Azpe Bkefph	F0014L12EM	Wabtup Cahp OT 7" 63XF - HNV				PR							Bpv Yhajp	806																														
F003LLM5GG	Uabp	Tamjnkbz			*	*	*	Uamz Uabp Rtdkmzepbz	Upipu 6 Abjneyrzafauazs	6	Bnbp		Azpe Bkefph	F003LLM5GG	Wabtup Va-Ca 3" P-Abw				PR							Bpv Yhajp	12																														
F007EA8CKG	Uabp	Tamjnkbz			*	*	*	Uamz Uabp Rtdkmzepbz	Upipu 6 Abjneyrzafauazs	6	Bnbp		Azpe Bkefph	F007EA8CKG	Jpupmzp Va-Ca, HNV/PK				PR							Bpv Yhajp	656																														
''' },

		{ 'delimiter' : ",", 'sample' :  # success: ","
'''Name,Given Name,Additional Name,Family Name,Yomi Name,Given Name Yomi,Additional Name Yomi,Family Name Yomi,Name Prefix,Name Suffix,Initials,Nickname,Short Name,Maiden Name,Birthday,Gender,Location,Billing Information,Directory Server,Mileage,Occupation,Hobby,Sensitivity,Priority,Subject,Notes,Group Membership,E-mail 1 - Type,E-mail 1 - Value,E-mail 2 - Type,E-mail 2 - Value,E-mail 3 - Type,E-mail 3 - Value,E-mail 4 - Type,E-mail 4 - Value,Phone 1 - Type,Phone 1 - Value,Phone 2 - Type,Phone 2 - Value,Phone 3 - Type,Phone 3 - Value,Address 1 - Type,Address 1 - Formatted,Address 1 - Street,Address 1 - City,Address 1 - PO Box,Address 1 - Region,Address 1 - Postal Code,Address 1 - Country,Address 1 - Extended Address,Address 2 - Type,Address 2 - Formatted,Address 2 - Street,Address 2 - City,Address 2 - PO Box,Address 2 - Region,Address 2 - Postal Code,Address 2 - Country,Address 2 - Extended Address,Address 3 - Type,Address 3 - Formatted,Address 3 - Street,Address 3 - City,Address 3 - PO Box,Address 3 - Region,Address 3 - Postal Code,Address 3 - Country,Address 3 - Extended Address,Organization 1 - Type,Organization 1 - Name,Organization 1 - Yomi Name,Organization 1 - Title,Organization 1 - Department,Organization 1 - Symbol,Organization 1 - Location,Organization 1 - Job Description,Website 1 - Type,Website 1 - Value,Website 2 - Type,Website 2 - Value
Woydwyu Ltai Pixxwft,Woydwyu Ltai,,Pixxwft,,,,,,,,,,,,,,,,,,"Cooking, Biking, Yoga",,,,"Program: MBA
Country: Philippines
City: San Fernando Pampanga
Relationship Status: In a Relationship
Address in Boston: 217 Pjapmk Hzrooz (Phiylwm), #1552A, Tpuarqyno
Area of Focus: Healthcare/Biotech
''' },

		{ 'delimiter' : ",", 'sample' :  # success: ","
'''?????????Poqz,EffectiveDate,ExpiryDate,ExternalSku
Y005SQTCAN,30-Ivt-2014,01-Ivt-2017,100
Y00LSBCUYE,24-Tax-14,,UE000LSH01
Y00IM8MYSP,24-Tax-14,,UE000LSH03
Y00LBP8HK8,24-Tax-14,,EW00LSH03
Y008YESU4L,24-Tax-14,,EW00LSH08
Y006MZA624,24-Tax-14,,EW001LSH01
''' },

		{ 'delimiter' : ",", 'sample' :  # success: ","
'''Amazon DE MP3 Sales (Cost in Euros),,,,,,,,,,,,
01/01/2010 - 01/31/2010,,,,,,,,,,,,
"Amazon EU S??????rl (AEU) is based in Luxembourg and issues payments automatically.?????? Unless you are established in Luxembourg and will charge us Luxembourg VAT we do not need to receive a VAT invoice from you before we can make payment . ????????????AEU?????????s ??????address is Amazon EU S??????rl, 5, Rue Plaetis, L-2338 Luxembourg.?????? VAT registration number is LU 20260743",,,,,,,,,,,,
ASIN,ALBUM_ID,RELATED_UPC,Track_ID,ISRC,ALBUM_TRACK,Units,COST,Amount_Due,ALBUM_ARTIST,ALBUM_NAME,Track_Name,LABEL_NAME
Y003S6BUB3,5096303033059,5096303033059,,,V,20,8.1,632.00,"Vfnjhn Zdisupq","Tczxcy","","Wdzhid Fundfwq"
K003P6NGYH,5096303033059,5096303033059,YX-NUA-07-00663,YX-NUA-07-00663,J,8,.88,9.78,"Vfnjhn Zdisupq","Tczxcy","Zp Bfdbuaauf","Wdzhid Fundfwq"
Q003P6FEC3,5096303033059,5096303033059,YX-NUA-07-00662,YX-NUA-07-00662,J,6,.88,3.86,"Vfnjhn Zdisupq","Tczxcy","Ehfu Viw Jtu Jtcw","Wdzhid Fundfwq"
''' },

		{ 'delimiter' : ",", 'sample' :  # success: ","
'''artist_name,album_name,album_id
Ntijin,3GXh,2438
"Upg Cdzjguin Vigtbh","69 Taqg Hajzh",2439
"Xgdwijz Tizpuh",936,2440
"Xgdwijz Tizpuh","936 (Hxgnidt Eajoh Gbiuiaj)",2441
Ugtg:vojwgj,"D Nattgnuiaj Av Ing-Nsgdc Qdjh",2442
"Tdosd Cdstijz","D Nsgduosg I Baj'u Wjak",2443
''' },

		{ 'delimiter' : " ", 'sample' :  # success: " "
'''   6.0000000e+00   3.4109180e-01  -4.5289375e+00
   5.0000000e+00   4.4413086e-01  -5.4968125e+00
   4.0000000e+00   2.3100195e-01  -2.8867500e+00
   7.0000000e+00   2.0027539e-01  -3.5343750e+00
   3.0000000e+00   2.9193555e-01  -4.3520625e+00
   6.0000000e+00   2.1278516e-01  -3.7213750e+00
   3.0000000e+00   2.0337891e-01  -3.3363125e+00
''' },

		{ 'delimiter' : "|", 'sample' :  # success: "|"
'''Transmissionno|"Start_Date"|"End_Date"|"Service_provider_country"|"Consumer_country_code"|"ISRC"|"UPC"|"Digital_offering_id"|"Product_type"|Quantity|"Royalty_currency"|Wholesale_price|Wholesale_value|"PaymentCurrency"|WholesalevaluePC|"Artist_name"|"Album_name"|"Track_name"|"Commitment_type"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808080775"|""|"CHPRZ YVMONT"|90|"JPW"|9.34186226|93.41862260|"RAO"|88.361899590000009|"Bvcgl Bmvongcgo"|"Txgnjdt"|""|"Adxvt-Tmvz-98 Yxzzntzmgt"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808085674"|""|"CHPRZ YVMONT"|90|"JPW"|9.34186226|93.41862260|"RAO"|88.361899590000009|"Tdm Unhha"|"Phxxo Wvmaarvma"|""|"Adxvt-Tmvz-98 Yxzzntzmgt"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808087472"|""|"CHPRZ YVMONT"|939|"JPW"|9.54170080|965.42878280|"RAO"|395.76740759666664|"Cvytny Zxgumsa"|"Aryu Nt cgo Amm"|""|"Hxgj-Tmvz Yxzzntzmgt"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808087472"|""|"CHPRZ YVMONT"|90|"JPW"|9.64460230|96.44602300|"RAO"|38.906461120000003|"Cvytny Zxgumsa"|"Aryu Nt cgo Amm"|""|"Adxvt-Tmvz Yxzzntzmgt"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808087472"|""|"CHPRZ YVMONT"|18|"JPW"|9.34186226|66.44732924|"RAO"|929.87668892|"Cvytny Zxgumsa"|"Aryu Nt cgo Amm"|""|"Adxvt-Tmvz-98 Yxzzntzmgt"
273536|"20110801"|"20110831"|"JP"|"JP"|""|"7035808082079"|""|"CHPRZ YVMONT"|95|"JPW"|9.54170080|80.48700840|"RAO"|33.280687126666666|"Cggc Ychin"|"Cggc Ychin"|""|"Hxgj-Tmvz Yxzzntzmgt"
''' },

		{ 'delimiter' : "|", 'sample' :  # success: "|"
'''Transmissionno|"Start_Date"|"End_Date"|"Service_provider_country"|"Consumer_country_code"|"ISRC"|"UPC"|"Digital_offering_id"|"Product_type"|Quantity|"Royalty_currency"|Wholesale_price|Wholesale_value|"PaymentCurrency"|WholesalevaluePC|"Artist_name"|"Album_name"|"Track_name"|"Commitment_type"
Transmission_#|"Start_Date"|"End_Date"|"Service_provider_country"|"usage_type"|"ISRC"|"UPC"|"Activity_type"|quantity|"royalty_currency"|royalty_price_LC|royalty_amount_lc|"payment_currency"|royalty_amount_pc|"artist_name"|"album_name"|"track_name"|"Commitment_type"
Transmission_#|"Start_Date"|"End_Date"|"Service_provider_country"|"usage_type"|"ISRC"|"UPC"|"Activity_type"|quantity|"royalty_currency"|royalty_price_LC|royalty_amount_lc|"payment_currency"|royalty_amount_pc|"artist_name"|"album_name"|"track_name"|"Commitment_type"
Transmissionno|"Start_Date"|"End_Date"|"Service_provider_country"|"Consumer_country_code"|"ISRC"|"UPC"|"Digital_offering_id"|"Product_type"|Quantity|"Royalty_currency"|Wholesale_price|Wholesale_value|"PaymentCurrency"|WholesalevaluePC|"Artist_name"|"Album_name"|"Track_name"|"Commitment_type"
Transmission_#|"Start_Date"|"End_Date"|"Service_provider_country"|"usage_type"|"ISRC"|"UPC"|"Activity_type"|quantity|"royalty_currency"|royalty_price_LC|royalty_amount_lc|"payment_currency"|royalty_amount_pc|"artist_name"|"album_name"|"track_name"|"Commitment_type"
Transmission_#|"Start_Date"|"End_Date"|"Service_provider_country"|"usage_type"|"ISRC"|"UPC"|"Activity_type"|quantity|"royalty_currency"|royalty_price_LC|royalty_amount_lc|"payment_currency"|royalty_amount_pc|"artist_name"|"album_name"|"track_name"|"Commitment_type"
Transmissionno|"Start_Date"|"End_Date"|"Service_provider_country"|"Consumer_country_code"|"ISRC"|"UPC"|"Digital_offering_id"|"Product_type"|Quantity|"Royalty_currency"|Wholesale_price|Wholesale_value|"PaymentCurrency"|WholesalevaluePC|"Artist_name"|"Album_name"|"Track_name"|"Commitment_type"
''' },

		{ 'delimiter' : "|", 'sample' :  # success: "|"
'''Transmission_#|"Start_Date"|"End_Date"|"Service_provider_country"|"usage_type"|"ISRC"|"UPC"|"Activity_type"|quantity|"royalty_currency"|royalty_price_LC|royalty_amount_lc|"payment_currency"|royalty_amount_pc|"artist_name"|"album_name"|"track_name"|"Commitment_type"
598775|"20110701"|"20110731"|"EB"|"VOE"|"EBCIP1100059"|"9043808085896"|"Cpgivo Mpjnh"|84|"EBM"|.01821272|.86324163|"QHL"|.37236695|"Rqvgxs Bxnh"|"Go'h Jpp Osqi"|"Goctn Dgveish"|""
598775|"20110701"|"20110731"|"EB"|"VOE"|"EBCIP0900286"|"9043808181943"|"Liwgci Mpjnh"|4|"EBM"|.01821272|.04239543|"QHL"|.05831866|"Dsjva Dislgvjvl"|"Fjpk Jfjn"|"Fjpk Jfjn"|""
598775|"20110701"|"20110731"|"LI"|"MSIYGQY"|"EBCIP1100012"|"9043808131995"|"Hosijy"|1|"IQS"|.01034151|.01034151|"QHL"|.01366514|"Jbxqo Esxqm"|"Lxv'o Fxssn"|"Lxv'o Fxssn"|""
598775|"20110701"|"20110731"|"LI"|"VOE"|"EBCIP0901172"|"5034202016656"|"Cpgivo Mpjnh"|1|"IQS"|.01026032|.01026032|"QHL"|.01959972|"Oipiwghgxv Mishxvjpgogih"|"Yn Ljsk Mpjcih"|"Vx Yxsi G Tjoi Nxqh"|""
598775|"20110701"|"20110731"|"LI"|"MSIYGQY"|"EBCIP1000756"|"9043808085091"|"Cpgivo Mpjnh"|182|"IQS"|.01034151|1.44983502|"QHL"|1.61690347|"Jvvj Cjpwg"|"Jvvj Cjpwg"|"Hqajvvi Jvl G"|""
598775|"20110701"|"20110731"|"EB"|"VOE"|"EBCIP0200485"|"5034202019558"|"Liwgci Mpjnh"|1|"EBM"|.01821272|.01821272|"QHL"|.08020344|"Osgckn"|"Kvxfpi Fiho Bxn"|"Bjcjogwi"|""
''' },

		{ 'delimiter' :"\t", 'sample' :
'''a	b	c
1	2	3
4	5	6''' }
	]
	
	for sample in delimiter_samples:
		sniffer = csv.Sniffer()
		try:
			dialect = sniffer.sniff(sample["sample"])
			print("%s: Expected %s got %s" % ( sample["delimiter"] == dialect.delimiter, repr(sample["delimiter"]), repr(dialect.delimiter)))
		except:
			print(r"False: Expected %s got Exception" % repr(sample["delimiter"]))



"""
False: Expected '\t' got Exception
False: Expected '\t' got Exception
False: Expected ',' got Exception
False: Expected ',' got Exception
False: Expected ',' got Exception
False: Expected '\t' got Exception
False: Expected ',' got Exception
False: Expected '\t' got Exception
False: Expected ',' got 'c'
False: Expected ' ' got 'e'
False: Expected '\t' got Exception
False: Expected '\t' got ' '
False: Expected '\t' got ' '
False: Expected '\t' got ' '
False: Expected '\t' got ','
False: Expected '\t' got ':'
False: Expected '\t' got Exception
False: Expected '\t' got Exception
True: Expected '\t' got '\t'
True: Expected '\t' got '\t'
True: Expected '\t' got '\t'
True: Expected '\t' got '\t'
True: Expected '\t' got '\t'
True: Expected ',' got ','
True: Expected ',' got ','
True: Expected ',' got ','
True: Expected ',' got ','
True: Expected ' ' got ' '
True: Expected '|' got '|'
True: Expected '|' got '|'
True: Expected '|' got '|'
True: Expected '\t' got '\t'
"""

From report at bugs.python.org  Sat Aug  8 01:10:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Aug 2015 23:10:33 +0000
Subject: [issue24825] visual margin indicator for breakpoints in IDLE
In-Reply-To: <1438956994.9.0.955708326842.issue24825@psf.upfronthosting.co.za>
Message-ID: <1438989033.72.0.350413943355.issue24825@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe one of Saimadhav's original patches used a symbol. I suggested color highlighting instead, and it seems to work better.  In any case, debating such details is part of an issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default.

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

From report at bugs.python.org  Sat Aug  8 01:15:00 2015
From: report at bugs.python.org (John Ehresman)
Date: Fri, 07 Aug 2015 23:15:00 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1438989300.46.0.0130996701575.issue4214@psf.upfronthosting.co.za>


John Ehresman added the comment:

I just ran into this again when I installed 2.7.10 -- evidently I had patched my local installation and forgot about it.  This is very important to anyone who tries to use the Visual Studio C debugger to debug extension modules.

----------
nosy: +jpe

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

From report at bugs.python.org  Sat Aug  8 01:43:04 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 23:43:04 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1438990984.82.0.852908433186.issue9262@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Sat Aug  8 01:49:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Aug 2015 23:49:57 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <20150807234953.29394.53681@psf.io>


Roundup Robot added the comment:

New changeset adb510322c8f by Eric Snow in branch '3.5':
Issue #24667: Resize odict in all cases that the underlying dict resizes.
https://hg.python.org/cpython/rev/adb510322c8f

New changeset 47287c998bb0 by Eric Snow in branch 'default':
Merge from 3.5 (issue #24667).
https://hg.python.org/cpython/rev/47287c998bb0

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  8 01:51:02 2015
From: report at bugs.python.org (Eric Snow)
Date: Fri, 07 Aug 2015 23:51:02 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1438991462.54.0.308328654701.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've pushed the fix for RC1.  Thanks again Fabian for bringing it to our attention.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 02:03:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Aug 2015 00:03:36 +0000
Subject: [issue24812] All standard keystrokes not recognized in IDLE dialogs
 on Mac
In-Reply-To: <1438920938.34.0.296980992753.issue24812@psf.upfronthosting.co.za>
Message-ID: <1438992216.12.0.491172178485.issue24812@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Then either simpledialog should changed, or Idle should subclass or rewrite it to work as it should.

----------

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

From report at bugs.python.org  Sat Aug  8 02:09:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Aug 2015 00:09:15 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1438992555.67.0.791668993356.issue24765@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

And if the older version is still present, as 2.7 will be for years, copy back to .idlerc.  To me, having two copies of the directory, one in the 'wrong' place, is worse than one copy in the wrong place.

----------

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

From report at bugs.python.org  Sat Aug  8 02:40:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 08 Aug 2015 00:40:15 +0000
Subject: [issue24774] inconsistency in http.server.test
In-Reply-To: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>
Message-ID: <1438994415.2.0.239547473811.issue24774@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yeah you are probably right. This way keeps things simple.

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Aug  8 03:21:53 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 08 Aug 2015 01:21:53 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1438996913.09.0.0903950658418.issue4214@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +steve.dower

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

From report at bugs.python.org  Sat Aug  8 03:43:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 08 Aug 2015 01:43:57 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1438998237.59.0.859141687282.issue19771@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v4 just uses an explicit encoding in the test suite rather than relying on the environment?s encoding.

Laura: I think my patch may already handle your case. Assuming this is one way to reproduce it:

$ mkdir test
$ : > test/__init__.py
$ python2 -c 'import test'
$ rm test/__init__.py
$ ./python -m test
/media/disk/home/proj/python/cpython/python: Error while finding spec for 'test.__main__' (<class 'ImportError'>: bad magic number in 'test': b'\x03\xf3\r\n'); 'test' is a package and cannot be directly executed
[Exit 1]
$ hg qpush --move issue_19771_runpy.patch.v4
applying issue_19771_runpy.patch.v4
now at: issue_19771_runpy.patch.v4
$ ./python -m test
/media/disk/home/proj/python/cpython/python: Error while finding spec for 'test.__main__' (ImportError: bad magic number in 'test': b'\x03\xf3\r\n')
[Exit 1]

Perhaps the error could be improved further, though. I guess the problem is there is a bad magic number in test/__init__.pyc. And I have no idea what the ?finding spec? bit is about; it is meaningless noise to me.

----------
Added file: http://bugs.python.org/file40150/issue_19771_runpy.patch.v4

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

From report at bugs.python.org  Sat Aug  8 03:47:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Aug 2015 01:47:19 +0000
Subject: [issue24822] IDLE: Accelerator key doesn't work for Options
In-Reply-To: <1438928181.3.0.0815993516884.issue24822@psf.upfronthosting.co.za>
Message-ID: <1438998439.77.0.611370276286.issue24822@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Issue is easy once agreement is reached. I prefer a solution different from one in patch.  Add your opinion.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE: Menu accelerator conflict between Format and Options

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

From report at bugs.python.org  Sat Aug  8 04:31:30 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Aug 2015 02:31:30 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
In-Reply-To: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>
Message-ID: <1439001090.66.0.0743442173113.issue24826@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Many of us want to reorganize Idle from multiple windows, some with menus, to one window with multiple frame or panes.  The initial steps: 

a) create a new application window with an application menu. (I believe OSX partially forces this on Macs anyway.) The menu should have items added or deleted, or just activated or not, according to the active window and other conditions. Adjust the menu construction functions, including the ones used in extension files, accordingly.

b) remove the menu and Toplevel from the base editor window used for editor, shell, and output.  Leave frame that can be added to other containers, whether Toplevel, Frame, Paned Window, or Notebook.

c) remove the Toplevel from dialogs that we think should be non-modal and insertable into containers.  I think the debugger, as you say, aumented config dialog, and improved search/replace dialog, are all candidates for this treatment.

I think users, or at least class instructors, should have some control over placement.  There definitely should not be a single, locked down design.

----------
stage:  -> test needed

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

From report at bugs.python.org  Sat Aug  8 04:44:47 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 02:44:47 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1439001887.45.0.995540422128.issue4214@psf.upfronthosting.co.za>


Steve Dower added the comment:

This option is no longer set in 3.5/3.6 (which don't use msvc9compiler.py).

I'll get it for 2.7 and 3.4.

----------
type: compile error -> behavior
versions:  -Python 3.5

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

From report at bugs.python.org  Sat Aug  8 04:51:40 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Aug 2015 02:51:40 +0000
Subject: [issue17776] IDLE Internationalization
In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za>
Message-ID: <1439002300.22.0.0285675605498.issue17776@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I just noticed https://pypi.python.org/pypi/idle-lif/1.0 Python IDLE Language Pack.  Have not looked at it.

If someone decides to work on this, I have ideas on how i18n could be done with minimal impact on the code, partly based on https://pythonhosted.org/flufl.i18n/

----------

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

From report at bugs.python.org  Sat Aug  8 05:02:04 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 03:02:04 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
Message-ID: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>


New submission from umedoblock:

round(1.65, 1) return 1.6 with decimal.
I feel bug adobe result.
not bug ?

>>> import decimal
>>> d1 = decimal.Decimal("1.65")
>>> d2 = decimal.Decimal(10 ** -2) * 5
>>> d1
Decimal('1.65')
>>> d2
Decimal('0.05000000000000000104083408559')
>>> d1 + d2
Decimal('1.700000000000000001040834086')
>>> data = list(map(decimal.Decimal, "1.05 1.15 1.25 1.35 1.45 1.55 1.65 1.75 1.85 1.95".split()))
>>> for x in data:
...   print("round({}, 1) = {}".format(x, round(x, 1)))
... 
round(1.05, 1) = 1.0
round(1.15, 1) = 1.2
round(1.25, 1) = 1.2
round(1.35, 1) = 1.4
round(1.45, 1) = 1.4
round(1.55, 1) = 1.6
round(1.65, 1) = 1.6
round(1.75, 1) = 1.8
round(1.85, 1) = 1.8
round(1.95, 1) = 2.0
>>> round(2.675, 2)
2.67
>>> d4 = decimal.Decimal("2.675")
>>> round(d4, 2)
Decimal('2.68')

----------
components: Library (Lib)
messages: 248246
nosy: umedoblock
priority: normal
severity: normal
status: open
title: round(1.65, 1) return 1.6 with decimal
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug  8 05:13:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 08 Aug 2015 03:13:53 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439003633.17.0.806991261669.issue24827@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The rounding mode of the default context is ROUND_HALF_EVEN[1]:

>>> import decimal
>>> decimal.getcontext()
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999, Emax=999999, capitals=1, clamp=0, flags=[], traps=[InvalidOperation, DivisionByZero, Overflow])

For your examples near the end, see [2]:

>>> round(2.675, 2)
2.67
>>> round(decimal.Decimal('2.675'), 2)
Decimal('2.68')
>>> decimal.Decimal(2.675)
Decimal('2.67499999999999982236431605997495353221893310546875')
>>> round(_, 2)
Decimal('2.67')

[1] https://docs.python.org/3/library/decimal.html#decimal.ROUND_HALF_EVEN
[2] https://docs.python.org/3/tutorial/floatingpoint.html

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 07:26:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Aug 2015 05:26:25 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <20150808052621.5517.43849@psf.io>


Roundup Robot added the comment:

New changeset 418095f0d711 by Steve Dower in branch '2.7':
Issue #4214: Remove ineffectual /pdb:none option from msvc9compiler.py
https://hg.python.org/cpython/rev/418095f0d711

New changeset 7c322c296a3b by Steve Dower in branch '3.4':
Issue #4214: Remove ineffectual /pdb:none option from msvc9compiler.py
https://hg.python.org/cpython/rev/7c322c296a3b

New changeset 6a1c2c7b0ee0 by Steve Dower in branch '3.5':
Issue #4214: Remove ineffectual /pdb:none option from msvc9compiler.py
https://hg.python.org/cpython/rev/6a1c2c7b0ee0

New changeset b35df92f69e4 by Steve Dower in branch 'default':
Issue #4214: Remove ineffectual /pdb:none option from msvc9compiler.py
https://hg.python.org/cpython/rev/b35df92f69e4

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  8 07:26:50 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 05:26:50 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1439011610.68.0.580360022866.issue4214@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
assignee: tarek -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 07:38:41 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 05:38:41 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decima modulel
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439012321.54.0.470801950622.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

I don't agree with "not a bug".

>>> s1, v1, ndigits1 = "1.65", 1.65, 1
>>> s2, v2, ndigits2 = "2.675", 2.675, 2

>>> decimal.Decimal(v1)
Decimal('1.649999999999999911182158029987476766109466552734375')
>>> round(v1, ndigits1)
1.6
>>> round(decimal.Decimal(s1), ndigits1)
Decimal('1.6') # EQUAL expression round(v1, ndigits1)

>>> decimal.Decimal(v2)
Decimal('2.67499999999999982236431605997495353221893310546875')
>>> round(v2, ndigits2)
2.67
>>> round(decimal.Decimal(s2), ndigits2)
Decimal('2.68') # DIFFERENT expression round(v2, ndigits2)

decimal module should give me different expression about below.
round(decimal.Decimal(s1), ndigits1) and round(v1, ndigits1).

BECAUSE

round(decimal.Decimal(s2), ndigits2) and round(v2, ndigits2)
give me DIFFERENT expression.

----------
title: round(1.65, 1) return 1.6 with decimal -> round(1.65, 1) return 1.6 with decima modulel

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

From report at bugs.python.org  Sat Aug  8 08:36:25 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 08 Aug 2015 06:36:25 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439015785.17.0.458900927605.issue24827@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I think the key point that you're missing (and which I could have made clearer in my previous message) is that `Decimal(2.675) != Decimal('2.675')`.  In the first case, a Decimal instance is created from a float, and 2.675 cannot be represented perfectly in base-2.  The float is actually 2.67499999999999982236431605997495353221893310546875, but Python knows you're human and almost certainly didn't want that number, so it shows you 2.675 when asked.  The second Decimal instance is created from the string '2.675', and is converted straight to base-10.

Moving on to the rounding, both the float 2.675 and the Decimal created from the float 2.675 round down to 2.67 (or nearly, in the case of the float), because they're actually 2.674999..., and 4 rounds down.  The Decimal created from a string rounds to 2.68, because it actually is 2.675 and 5 rounds to even (in this case, 8).

>>> from decimal import Decimal as D
>>> f = 2.675
>>> s = str(f)
>>> s # Python chooses the shortest representation
'2.675'
>>> df = D(f)
>>> ds = D(s)
>>> f, df, ds
(2.675, Decimal('2.67499999999999982236431605997495353221893310546875'), Decimal('2.675'))
>>> f == df
True
>>> f == ds
False
>>> df == ds
False
>>> D(round(f, 2)), D(round(df, 2)), D(round(ds, 2))
(Decimal('2.6699999999999999289457264239899814128875732421875'), Decimal('2.67'), Decimal('2.68'))

The moral of the story is: everything is working as expected and don't create Decimals from floats unless you want the base-2 approximation of the value.

----------
title: round(1.65, 1) return 1.6 with decima modulel -> round(1.65, 1) return 1.6 with decimal

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

From report at bugs.python.org  Sat Aug  8 09:11:41 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 07:11:41 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439017901.21.0.365029270297.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

last compared results are different.
should be bug or at least think that how to get a same result
about "D(round(df2, 2)) == D(round(ds2, 2))"

>>> from decimal import Decimal as D
>>> f1 = 1.65
>>> s1 = str(f1)
>>> df1 = D(f1)
>>> ds1 = D(s1)
>>> f2 = 2.675
>>> s2 = str(f2)
>>> df2 = D(f2)
>>> ds2 = D(s2)

>>> f1, df1, ds1
(1.65, Decimal('1.649999999999999911182158029987476766109466552734375'), Decimal('1.65'))
>>> f2, df2, ds2
(2.675, Decimal('2.67499999999999982236431605997495353221893310546875'), Decimal('2.675'))

>>> D(round(df1, 1)) == D(round(ds1, 1))
True
>>> D(round(df2, 2)) == D(round(ds2, 2))
False

----------

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

From report at bugs.python.org  Sat Aug  8 09:20:03 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 07:20:03 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439018403.68.0.934206230608.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

In addition.
>>> D(round(D("2.675"), 2)) == D("2.68")
True
>>> D(round(D("1.65"), 1)) == D("1.7")
False

I believe a bug or at least change the __round__().

----------

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

From report at bugs.python.org  Sat Aug  8 09:30:08 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 07:30:08 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439019008.66.0.103786342561.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

In this case.
>>> round(1.65, 1) == 1.7
False
>>> round(2.675, 2) == 2.68
False

I never say anything.
Because I understand what you said.
But I use the decimal module.
please pay attention to use decimal module.

----------

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

From report at bugs.python.org  Sat Aug  8 09:49:08 2015
From: report at bugs.python.org (Peter Otten)
Date: Sat, 08 Aug 2015 07:49:08 +0000
Subject: [issue24787] csv.Sniffer guesses "M" instead of \t or ,
 as the delimiter
In-Reply-To: <1438646757.5.0.369285576748.issue24787@psf.upfronthosting.co.za>
Message-ID: <1439020148.66.0.277716626142.issue24787@psf.upfronthosting.co.za>


Peter Otten added the comment:

Have you considered writing your own little sniffer? Getting it right for your actual data is usually easier to achieve than a general solution.

The following simplistic sniffer should work with your samples:

def make_dialect(delimiter):
    class Dialect(csv.excel):
        pass
    Dialect.delimiter = delimiter
    return Dialect

def sniff(sample):
    count, delimiter = max(
        ((sample.count(delim), delim) for delim in ",\t|;"),
        key=operator.itemgetter(0))
    if count == 0:
        if " " in sample:
            delimiter = " "
        else:
            raise csv.Error("Could not determine delimiter")
    return make_dialect(delimiter)

Tiago, If you want to follow that path we should take the discussion to the general python mailing list.

----------

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

From report at bugs.python.org  Sat Aug  8 09:59:38 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 08 Aug 2015 07:59:38 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439020778.42.0.295836433426.issue17570@psf.upfronthosting.co.za>


Carol Willing added the comment:

Steve and Zach, If you are happy with the changes, I have no objection to committing and closing this issue.

----------

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

From report at bugs.python.org  Sat Aug  8 10:45:58 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 08:45:58 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439023558.34.0.160116821459.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

I have a headache.
because python reports many error after I patched below patches.

--- Lib/test/test_decimal.py.orig       2015-08-08 17:41:01.986316738 +0900
+++ Lib/test/test_decimal.py    2015-08-08 17:41:05.470316878 +0900
@@ -1935,6 +1935,7 @@
             ('123.456', 4, '123.4560'),
             ('123.455', 2, '123.46'),
             ('123.445', 2, '123.44'),
+            ('1.65', 1, '1.7'),
             ('Inf', 4, 'NaN'),
             ('-Inf', -23, 'NaN'),
             ('sNaN314', 3, 'NaN314'),

--- ./Lib/decimal.py.orig       2015-08-08 17:42:20.662319881 +0900
+++ ./Lib/decimal.py    2015-08-08 17:39:40.210313472 +0900
@@ -1782,7 +1782,7 @@
     def _round_half_even(self, prec):
         """Round 5 to even, rest to nearest."""
         if _exact_half(self._int, prec) and \
-                (prec == 0 or self._int[prec-1] in '02468'):
+                (prec == 0 or self._int[prec-1] in '01234'):
             return -1
         else:
             return self._round_half_up(prec)

----------

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

From report at bugs.python.org  Sat Aug  8 11:25:36 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 09:25:36 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439025936.56.0.88766929138.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This is a legitimate problem and I'd definitely like it fixed.
However, the angle brackets and the quote marks are ugly:

        decode(obj, encoding='<sys.getdefaultencoding()>', errors='strict')

Attached is a tweaked version of the patch that sidesteps the quote marks and the angle brackets, by substituting in an object with a custom repr.

Yury, if my change to your patch looks good to you, please go ahead and check it in. That way it won't slow down 3.5.0rc1.  Thanks!

----------
Added file: http://bugs.python.org/file40151/larry.fix.pydoc.for.calls.with.functions.1.diff

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

From report at bugs.python.org  Sat Aug  8 11:43:05 2015
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 08 Aug 2015 09:43:05 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438960331.89.0.990932142548.issue24764@psf.upfronthosting.co.za>
Message-ID: <CA+gUBLQnU8sjpGF_2t0zbnkoGzJSdV+dc_6uGCak5jEbWJ28ug@mail.gmail.com>


Pierre Quentel added the comment:

Victor, you can apply the patch and close the issue.
Le 7 ao?t 2015 17:12, "Peter Landry" <report at bugs.python.org> a ?crit :

>
> Peter Landry added the comment:
>
> A new patch that simply removes Content-Length from part headers when
> present.
>
> ----------
> Added file: http://bugs.python.org/file40145/cgi_multipart.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24764>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Aug  8 12:36:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Aug 2015 10:36:47 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439030207.8.0.74822176038.issue24824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How with more complex expressions, like "sys.getdefaultencoding() or 'utf-8'".

----------

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

From report at bugs.python.org  Sat Aug  8 12:52:29 2015
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 08 Aug 2015 10:52:29 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439031149.55.0.270447565265.issue24827@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

As Zachary explained, the behavior is correct. There are three issues in play here.

1) The rounding method. With the ROUND_HALF_EVEN rounding mode, .5 is rounded to the nearest *even* number, so 1.65 is rounded to 1.6, while 1.75 is rounded to 1.8.

2) Rounding of floats. Floats cannot represent every number, and numbers are therefore rounded.

 - round(2.675, 2) = round(2.6749999999999998, 2) and is thus rounded to 2.67
 - round(1.65, 1) = round(1.6499999999999999, 1) and is thus rounded to 1.6

3a) In Python 2, round returns a float, so Decimal(round(Decimal("1.65"))) = Decimal(1.6) =  Decimal('1.600000000000000088817841970012523233890533447265625') != Decimal('1.6')

3b) In Python 3, Decimal.__round__ is implemented, so round(D("1.65"), 1) == D("1.6") as expected.

----------
nosy: +valhallasw

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

From report at bugs.python.org  Sat Aug  8 13:39:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Aug 2015 11:39:43 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <20150808113939.41835.73907@psf.io>


Roundup Robot added the comment:

New changeset e33f2b8b937f by Stefan Krah in branch '3.5':
Issue #15944: memoryview: Allow arbitrary formats when casting to bytes.
https://hg.python.org/cpython/rev/e33f2b8b937f

New changeset c7c4b8411037 by Stefan Krah in branch 'default':
Merge #15944.
https://hg.python.org/cpython/rev/c7c4b8411037

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  8 13:45:15 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 11:45:15 +0000
Subject: [issue15944] memoryviews and ctypes
In-Reply-To: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>
Message-ID: <1439034315.31.0.62847501475.issue15944@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Done.  Thanks for the patch.

----------
components: +Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5

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

From report at bugs.python.org  Sat Aug  8 14:09:21 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 12:09:21 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1439035761.32.0.469682900778.issue23756@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I would commit this, except that I'm not too happy with the use of
the term "bytes-like" in general. Yesterday I mistyped this:

>>> import ctypes
>>> x = ctypes.c_double
>>> m = memoryview(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: memoryview: a bytes-like object is required, not '_ctypes.PyCSimpleType'


The previous error message was (changed in #16518) was:

"_ctypes.PyCSimpleType does not support the buffer interface".


Which I find much clearer. Memoryviews (for better or worse,
but PEP-3118 was accepted) are Mini-NumPy-arrays. I'm still not
sure if we should hide that from users.

----------

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

From report at bugs.python.org  Sat Aug  8 14:10:47 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Aug 2015 12:10:47 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1439035847.08.0.785390515965.issue23756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The thing is, most users don't know what the buffer protocol is (even Numpy users, probably), while "bytes-like" at least will make some sense - even though I agree it's an imperfect approximation.

----------

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

From report at bugs.python.org  Sat Aug  8 14:29:05 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 12:29:05 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1439036945.29.0.85965536326.issue23756@psf.upfronthosting.co.za>


Stefan Krah added the comment:

For end users it's probably adequate. But several committers find
the term confusing (msg236283, msg188484). :)

Anyway, I'm going to commit this since it adds clarity.

----------

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

From report at bugs.python.org  Sat Aug  8 14:34:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Aug 2015 12:34:51 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <20150808123448.94774.35248@psf.io>


Roundup Robot added the comment:

New changeset d1ef54751412 by Stefan Krah in branch '3.5':
Issue #23756: Clarify the terms "contiguous" and "bytes-like object".
https://hg.python.org/cpython/rev/d1ef54751412

New changeset c59b2c4f4cac by Stefan Krah in branch 'default':
Merge #23756.
https://hg.python.org/cpython/rev/c59b2c4f4cac

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  8 14:37:35 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 12:37:35 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1439037455.7.0.13751077234.issue23756@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Martin, thanks for the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sat Aug  8 15:14:47 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 13:14:47 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439039687.47.0.924401974694.issue24827@psf.upfronthosting.co.za>


umedoblock added the comment:

excuse me.
I understand ROUND_HALF_EVEN meaning.
I think that __round__() function work ROUND_HALF_UP.
so sorry.
I don't have exactly knowledge about ROUND_HALF_EVEN.
I misunderstand about ROUND_HALF_EVEN.
I have thought ROUND_HALF_EVEN means ROUND_HALF_UP.

SO SORRY.

----------

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

From report at bugs.python.org  Sat Aug  8 16:03:34 2015
From: report at bugs.python.org (Xavier Morel)
Date: Sat, 08 Aug 2015 14:03:34 +0000
Subject: [issue24828] Segfault when using store-context AST node in a load
 context
Message-ID: <1439042614.34.0.045626812152.issue24828@psf.upfronthosting.co.za>


New submission from Xavier Morel:

It looks to be fixed in 3.3 and up, but in Python 2.7

    import ast
    m = ast.Module(body=[
        ast.Expr(value=ast.Name(id='foo', ctx=ast.Store()))
    ])
    ast.fix_missing_locations(m)
    code = compile(m, '', mode='exec')
    eval(code)
 
will segfault on eval. So will a similarly incorrect ast.Attribute node.

Version tested:

Python 2.7.10 (default, May 28 2015, 12:02:55) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

----------
components: Library (Lib)
messages: 248269
nosy: xmorel
priority: normal
severity: normal
status: open
title: Segfault when using store-context AST node in a load context
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Aug  8 16:15:25 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sat, 08 Aug 2015 14:15:25 +0000
Subject: [issue12854] PyOS_Readline usage in tokenizer ignores
 sys.stdin/sys.stdout
In-Reply-To: <1314640965.12.0.413941920183.issue12854@psf.upfronthosting.co.za>
Message-ID: <1439043325.02.0.784753282394.issue12854@psf.upfronthosting.co.za>


Adam Barto? added the comment:

http://bugs.python.org/issue17620 is a duplicate, but with more discussion.

----------
nosy: +Drekin

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

From report at bugs.python.org  Sat Aug  8 16:22:29 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 08 Aug 2015 14:22:29 +0000
Subject: [issue12854] PyOS_Readline usage in tokenizer ignores
 sys.stdin/sys.stdout
In-Reply-To: <1314640965.12.0.413941920183.issue12854@psf.upfronthosting.co.za>
Message-ID: <1439043749.14.0.0024133619341.issue12854@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python interactive console doesn't use sys.stdin for input

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

From report at bugs.python.org  Sat Aug  8 16:48:56 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sat, 08 Aug 2015 14:48:56 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
Message-ID: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>


New submission from Adam Barto?:

Currently, if one redirects stdout, readline hook is not used (see https://hg.python.org/cpython/file/default/Parser/myreadline.c#l208). I would assume that if I run Python as "py -i > output.txt", I can use GNU readline or other readline hook for input just like normal; only the output is redirected to the file.

----------
messages: 248271
nosy: Drekin
priority: normal
severity: normal
status: open
title: Use interactive input even if stdout is redirected
type: behavior

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

From report at bugs.python.org  Sat Aug  8 16:55:20 2015
From: report at bugs.python.org (kedar mhaswade)
Date: Sat, 08 Aug 2015 14:55:20 +0000
Subject: [issue24830] IndexError should (must?) report the index in error!
Message-ID: <1439045720.08.0.367506604724.issue24830@psf.upfronthosting.co.za>


New submission from kedar mhaswade:

I am a n00b Python programmer. So far, I am loving Python! Thank you.

Apologies if this has been already reported. A rudimentary search did not fetch anything and hence I am filing this as an enhancement request. If it has been already reported, please point me in the right direction so that I can stand corrected.

I believe following experience could be improved:
-----------------------------
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> l = []
>>> l[2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range
-----------------------------

if the message would indicate the index in error. This, I believe, is a low-hanging fruit that has several debugging benefits.

I hate to compare things, but I do want to note that Java does better in this regard:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 10
	at Foo.main(Foo.java:5)

----------
messages: 248272
nosy: kedar mhaswade
priority: normal
severity: normal
status: open
title: IndexError should (must?) report the index in error!
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug  8 17:21:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Aug 2015 15:21:20 +0000
Subject: [issue24830] IndexError should (must?) report the index in error!
In-Reply-To: <1439045720.08.0.367506604724.issue24830@psf.upfronthosting.co.za>
Message-ID: <1439047280.06.0.529259425405.issue24830@psf.upfronthosting.co.za>


R. David Murray added the comment:

Although this isn't a strict duplicate of issue 18162, the strict duplicate, issue 1534607, was closed as a duplicate of issue 18162, so I'm doing the same here.  Issue 18162 will address this issue by providing a useful default message that the interpreter would then use.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add index attribute to IndexError

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

From report at bugs.python.org  Sat Aug  8 17:24:46 2015
From: report at bugs.python.org (Chetan Reddy)
Date: Sat, 08 Aug 2015 15:24:46 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1439047486.96.0.733246080582.issue23548@psf.upfronthosting.co.za>


Chetan Reddy added the comment:

I'm seeing the same exception as op with Python-3.5.0b4.

I'm writing a function in a library, and am using asyncio to make my function run faster. I'd like my library function to be useful even to users who aren't using asyncio and therefore won't call get_event_loop().close() at the end of their main function.

I can't call get_event_loop().close() in my own library function, because i don't want to be closing the event loop in case the user is using the event loop.

Is the recommended approach here for me to create my own loop and close it in my function (while saving and restoring the existing event loop in case the user has already created an event loop)? Guido's comment at http://bugs.python.org/msg205027 makes me think not.

The easiest solution might be to not require the user to call get_event_loop().close() . This will allow library writers to use asyncio.run_until_complete without worrying the user seeing an exception on exit. If you agree with this, I'm willing to spend the effort to track down this particular exception and provide a patch to fix it.

----------
nosy: +chetan

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

From report at bugs.python.org  Sat Aug  8 17:38:48 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 15:38:48 +0000
Subject: [issue24831] Load average in test suite too high
Message-ID: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>


New submission from Stefan Krah:

On my machine (Lenovo T400, Linux) the load average during running
the 2.7 test suite is about 0.5 (with some exceptions like test_io).
The system is still usable even during test_io.


In 3.6 the load average is > 2.0, with some tests making
the system practically unusable (e.g. test_mmap).

----------
components: Tests
messages: 248275
nosy: skrah
priority: high
severity: normal
stage: needs patch
status: open
title: Load average in test suite too high
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug  8 17:46:29 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 15:46:29 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439048789.74.0.861948833999.issue24831@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Scratch the comment about test_io in 2.7: It also renders the
system unusable.

----------

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

From report at bugs.python.org  Sat Aug  8 17:48:18 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 08 Aug 2015 15:48:18 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439048898.6.0.0152873821019.issue24824@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Larry, Serhiy,

After giving this some thought I think that my initial patch is a wrong approach here -- inspect module should not be touched to fix this issue.  

With this patch applied, signature object for codecs.encode would have a Parameter with a bogus default value, breaking functions like 'BoundArguments.apply_defaults()' etc.  In other words, whatever AC puts in 'signature.parameters['encoding'].default' must be an object that will be accepted by the function.

codecs.encode, if implemented in Python, would look like:

   def encode(obj, encoding=None, errors='strict'):
       if encoding is None:
           encoding = sys.getdefaultencoding()
       ...

And that's how the signature should be defined for the C version (because that's what is actually happening in C code as well!)

The new patch changes the AC specs from

  _codecs.encode
      obj: object
      encoding: str(c_default="NULL") = sys.getdefaultencoding()
      errors: str(c_default="NULL") = "strict"

to

  _codecs.encode
      obj: object
      encoding: str(accept={str, NoneType}) = NULL
      errors: str(c_default="NULL") = "strict"

(docstring is updated too).

This change, by the way, is in accordance with PEP 436:

   The values supplied for these [default] parameters must be compatible with ast.literal_eval.

----------
nosy: +ncoghlan
Added file: http://bugs.python.org/file40152/codecs_ac.diff

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

From report at bugs.python.org  Sat Aug  8 18:04:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 16:04:48 +0000
Subject: [issue24476] Statically link vcruntime140.dll
In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za>
Message-ID: <1439049888.56.0.701169056385.issue24476@psf.upfronthosting.co.za>


Steve Dower added the comment:

Fixed this, and forgot I had a bug open for it so I didn't reference it from the commit.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 18:05:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 16:05:24 +0000
Subject: [issue23970] Update distutils.msvccompiler for VC14
In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za>
Message-ID: <1439049924.55.0.0050363863989.issue23970@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 18:06:55 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 16:06:55 +0000
Subject: [issue24186] OpenSSL causes buffer overrun exception
In-Reply-To: <1431578584.97.0.131803354946.issue24186@psf.upfronthosting.co.za>
Message-ID: <1439050015.13.0.865631275892.issue24186@psf.upfronthosting.co.za>


Steve Dower added the comment:

I did not get a helpful response from the compiler team, so the optimized function will have to stay disabled for 3.5.

Moving this to 3.6 in the hope that we can figure it out by then.

----------
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Sat Aug  8 18:07:27 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 16:07:27 +0000
Subject: [issue19450] Bug in sqlite in Windows binaries
In-Reply-To: <1383131558.55.0.853606379194.issue19450@psf.upfronthosting.co.za>
Message-ID: <1439050047.81.0.830156056673.issue19450@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 18:14:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Aug 2015 16:14:23 +0000
Subject: [issue24634] Importing uuid should not try to load libc on Windows
In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za>
Message-ID: <20150808161420.29388.80537@psf.io>


Roundup Robot added the comment:

New changeset 1df7a0821c73 by Steve Dower in branch '3.5':
Issue #24634: Importing uuid should not try to load libc on Windows
https://hg.python.org/cpython/rev/1df7a0821c73

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  8 18:18:18 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 16:18:18 +0000
Subject: [issue24634] Importing uuid should not try to load libc on Windows
In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za>
Message-ID: <1439050698.68.0.0675934106121.issue24634@psf.upfronthosting.co.za>


Steve Dower added the comment:

Done for 2.7, 3.5 and 3.6. Decided against touching 3.4 because it's not really an issue with MSVC 10.0, just 9.0 and 14.0. And I used eryksun's suggested approach.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug  8 18:18:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Aug 2015 16:18:40 +0000
Subject: [issue24634] Importing uuid should not try to load libc on Windows
In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za>
Message-ID: <20150808161634.1397.3152@psf.io>


Roundup Robot added the comment:

New changeset 90e2747425ad by Steve Dower in branch '2.7':
Issue #24634: Importing uuid should not try to load libc on Windows
https://hg.python.org/cpython/rev/90e2747425ad

----------

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

From report at bugs.python.org  Sat Aug  8 18:30:54 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Aug 2015 16:30:54 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439051454.83.0.983850050783.issue24831@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Just to diagnose this, try to run the test suite with "nice". If it still make the system unusable, then it's probably an I/O issue rather than CPU scheduling.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Aug  8 18:35:52 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sat, 08 Aug 2015 16:35:52 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
In-Reply-To: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>
Message-ID: <1439051752.93.0.98038454738.issue24826@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Yes that's exactly what I was thinking. If everything is a frame rather than a toplevel it'll be much easier to reconfigure things.

----------

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

From report at bugs.python.org  Sat Aug  8 18:48:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Aug 2015 16:48:15 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
Message-ID: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>


New submission from R. David Murray:

After doing a make clean in Doc, the built documents no longer rendered correctly.  I tracked this down to the Sphinx warning I'd been ignoring for a while:

WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default.

Now, this seems problematic, because we don't know which version of Sphinx is going to be used to build the docs, so it doesn't seen correct to just change "inherit = default" to "inherit = classic" in tools/pydoctheme.conf.

Any sphinx experts know what the correct solution is here?  Do we change it and thus (IIUC) require 1.3.1 as the minimum Sphinx version?

----------
assignee: docs at python
components: Documentation
messages: 248285
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Issue building docs with newer sphix (default theme -> classic)

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

From report at bugs.python.org  Sat Aug  8 19:28:55 2015
From: report at bugs.python.org (Chetan Reddy)
Date: Sat, 08 Aug 2015 17:28:55 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1439054935.77.0.307920796597.issue23548@psf.upfronthosting.co.za>


Chetan Reddy added the comment:

Disregard my previous comment. I realize now that I shouldn't be calling run_until_complete in a library function because it will fail if the user had already started running the event loop. I will attempt to use a create and use a new event loop in my library function. Apologies for adding noise to this page.

----------

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

From report at bugs.python.org  Sat Aug  8 19:57:34 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 08 Aug 2015 17:57:34 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439056654.11.0.346550378824.issue24832@psf.upfronthosting.co.za>


Carol Willing added the comment:

Is the behavior different in default or 3.5 release and 2.7 release? 

The default branch has html_theme in Doc/conf.py https://hg.python.org/cpython/file/default/Doc/conf.py set to 'pydoctheme'.

The 2.7 branch has html_theme in Doc/conf.py https://hg.python.org/cpython/file/2.7/Doc/conf.py to 'default'.

Iss24400 made a recent change https://hg.python.org/cpython/rev/68996acdec6f.

----------
nosy: +willingc

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

From report at bugs.python.org  Sat Aug  8 20:24:20 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 18:24:20 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1439058260.61.0.32983530762.issue24667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

FWIW I set up a test harness that runs test_collections and odict_reproduce with monotonically increasing PYTHONHASHSEED values.  I let it run overnight; it's now past iteration 158600.  Apart from some weirdness in the low 70ks that I can't reproduce it's been rock solid.

So, looks good!

----------

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

From report at bugs.python.org  Sat Aug  8 20:27:31 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 18:27:31 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439058451.96.0.672170719261.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can we do better?  How about a new field on the Parameter object, "symbolic_default_value", which shows you the expression used to compute the value?  We could then set default_value to the result of the expression, pydoc could print the symbolic expression, and codecs encode/decode could be more straightforward.

----------

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

From report at bugs.python.org  Sat Aug  8 21:10:47 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 08 Aug 2015 19:10:47 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1439058451.96.0.672170719261.issue24824@psf.upfronthosting.co.za>
Message-ID: <D01561FE-DF89-41E0-86DB-7E993FCD66A3@gmail.com>


Yury Selivanov added the comment:

> Can we do better?  How about a new field on the Parameter object, "symbolic_default_value", which shows you the expression used to compute the value?  We could then set default_value to the result of the expression, pydoc could print the symbolic expression, and codecs encode/decode could be more straightforward.

Maybe it's a good idea, but I'm -1 on pushing new APIs to 3.5 without some careful consideration at this super late stage (and it's not going to be a small change btw).

Let's just fix the codecs module.

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Sat Aug  8 21:48:49 2015
From: report at bugs.python.org (David Bolen)
Date: Sat, 08 Aug 2015 19:48:49 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <1439063329.66.0.0526428223173.issue24751@psf.upfronthosting.co.za>


David Bolen added the comment:

While running a manual test (make buildbottest) on my 2.7 Ubuntu buildbot, I ran into an exception in this patch:

The tail end of the test run:

[401/401/1] test_signal
379 tests OK.
1 test failed:
    test_curses
21 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl
    test_dl test_gl test_imgfile test_kqueue test_linuxaudiodev
    test_macos test_macostools test_msilib test_ossaudiodev
    test_scriptpackages test_startfile test_sunaudiodev test_winreg
    test_winsound test_zipfile64
Those skips are all expected on linux2.
Re-running failed tests in verbose mode
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1598, in <module>
    main()
  File "./Lib/test/regrtest.py", line 655, in main
    for test in bad[:]:
TypeError: 'set' object has no attribute '__getitem__'


The code is attempting to iterate over a sliced copy of bad (bad[:]) due to later possible mutation, but by that point, if you had failures, bad is a set, from the block shortly above where it subtracts out the environment changed list.  I was testing 2.7, but I think the issue affects all branches.

Perhaps list(bad) instead of bad[:]?

----------
nosy: +db3l

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

From report at bugs.python.org  Sat Aug  8 21:53:24 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 19:53:24 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439063604.5.0.0360827338276.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I just tried every module, simulating pydoc on it.  codecs is the only one that failed.  So, I can live with just changing codecs for now.  But let's do it properly in 3.6.  Go ahead and check in for 3.5--or, if you don't get it done before I want to tag the release, I'll do it.

Explain one thing to me, though--how would docs.python.org get "utf-8" for the encoding argument to encode/decode?  The docs are built from .rst files, not from introspection on a live interpreter.

----------

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

From report at bugs.python.org  Sat Aug  8 21:54:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Aug 2015 19:54:01 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439063641.52.0.903679270952.issue24832@psf.upfronthosting.co.za>


R. David Murray added the comment:

I only checked this on 3.5 and 3.6, but 3.4 is using pydoctheme, and python2.7 is using default.  So presumably none of them will build using Sphinx 1.3.1.

Yuri's change appears to be undoing a change he inadvertently committed, which was probably a change he made locally so he could get the docs to build because of this very problem.

----------
assignee: docs at python -> 
nosy: +georg.brandl, yselivanov

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

From report at bugs.python.org  Sat Aug  8 21:55:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Aug 2015 19:55:49 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439063749.23.0.391069476079.issue24824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

sys.getdefaultencoding() always returns "utf-8" in 3.x (it left for compatibility with 2.x). I suggested to set defaults to literal "utf-8". This matches documentation and signatures of str.encode() and bytes.decode().

----------

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

From report at bugs.python.org  Sat Aug  8 21:59:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Aug 2015 19:59:33 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <1439063973.3.0.911976631179.issue24751@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sat Aug  8 22:03:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Aug 2015 20:03:08 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439064188.75.0.324889895796.issue24831@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Any specific tests or all tests? 3.x has many new features in comparison with 2.x, and new tests for these features. For example zipfile and tarfile tests run much longer due to testing with bzip2 and lzma compressions.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Aug  8 22:04:19 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 20:04:19 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439064259.75.0.294970198722.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

That's a fine change for 3.5.  For 3.6 I want to solve the general problem, at which point we can switch back to calling sys.getdefaultencoding() if we like.

Serhiy, can you make a patch a post it here?  I want to tag 3.5.0rc1 in one or two hours.

----------

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

From report at bugs.python.org  Sat Aug  8 22:22:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Aug 2015 20:22:14 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439065334.52.0.467083029681.issue24824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is easy.

In future we should unify docstrings for codecs.encode() and codecs.decode() with str.encode(), bytes.decode() and like.

----------
Added file: http://bugs.python.org/file40153/codecs_default_encoding.patch

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

From report at bugs.python.org  Sat Aug  8 22:23:20 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 Aug 2015 20:23:20 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439065400.06.0.708170570171.issue24824@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Please use encoding='utf-8' as definition for codecs.encode() and codecs.decode().

There is no adjustable default encoding in Python 3 anymore.

For Python 3.6 this should probably be fixed everywhere.

----------

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

From report at bugs.python.org  Sat Aug  8 22:52:24 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 08 Aug 2015 20:52:24 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439067144.0.0.755779713775.issue24832@psf.upfronthosting.co.za>


Carol Willing added the comment:

David, Thanks for pointing this out. I totally forgot that the 2 and 3 versions use different themes :(

----------

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

From report at bugs.python.org  Sat Aug  8 22:58:00 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 20:58:00 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439067480.47.0.329399556974.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Please change "Default encoding is" to "The default encoding is".  Apart from that, LGTM, please check in!

----------

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

From report at bugs.python.org  Sat Aug  8 23:54:15 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 21:54:15 +0000
Subject: [issue23973] PEP 484 implementation
In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za>
Message-ID: <1439070855.34.0.64937603723.issue23973@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can we mark this closed now?

----------
nosy: +larry

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

From report at bugs.python.org  Sat Aug  8 23:54:40 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 21:54:40 +0000
Subject: [issue24585] Windows installer does not detect existing installs
In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za>
Message-ID: <1439070880.31.0.346090210682.issue24585@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Did this work as hoped in beta 4?  Can we mark it as fixed now?

----------

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

From report at bugs.python.org  Sat Aug  8 23:55:24 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 21:55:24 +0000
Subject: [issue24732] 3.5.0b3 Windows accept() on unready non-blocking socket
 raises PermissionError
In-Reply-To: <1437963228.18.0.486881534673.issue24732@psf.upfronthosting.co.za>
Message-ID: <1439070924.91.0.702773944954.issue24732@psf.upfronthosting.co.za>


Larry Hastings added the comment:

If this is now fixed but still needs a unit test, can I change it from "release blocker" to "high" priority?

----------
nosy: +larry

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

From report at bugs.python.org  Sat Aug  8 23:57:02 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 08 Aug 2015 21:57:02 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1439071022.93.0.848839700217.issue24272@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I assume what we've got is good enough for rc1?

Can we mark this closed / reduce the priority from "release blocker"?

Note that there are few (if any) restrictions on fixing docs during the release candidates.  (Though after today we'll be switching to the Bitbucket "pull request" workflow, so that will complicate matters slightly.)

----------
nosy: +larry

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

From report at bugs.python.org  Sun Aug  9 00:02:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Aug 2015 22:02:34 +0000
Subject: [issue24585] Windows installer does not detect existing installs
In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za>
Message-ID: <1439071354.18.0.179881361268.issue24585@psf.upfronthosting.co.za>


Steve Dower added the comment:

We won't really know until we've gotten feedback from people with b4 who install rc1 - the upgrade step is the part that needs testing, and that takes two releases.

If you want to pull the priority down though, go ahead.

----------

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

From report at bugs.python.org  Sun Aug  9 00:56:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Aug 2015 22:56:01 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <CA+gUBLQnU8sjpGF_2t0zbnkoGzJSdV+dc_6uGCak5jEbWJ28ug@mail.gmail.com>
Message-ID: <CAMpsgwYf6EO-ppQ3nXb4m+jAdNBzFx+00Pnj9Hs2C39AU_tAGw@mail.gmail.com>


STINNER Victor added the comment:

Not today. I'm in holiday. Ping me in two weeks or find another core dev.

----------

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

From report at bugs.python.org  Sun Aug  9 03:15:36 2015
From: report at bugs.python.org (Al Sweigart)
Date: Sun, 09 Aug 2015 01:15:36 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
In-Reply-To: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>
Message-ID: <1439082936.08.0.90634727062.issue24826@psf.upfronthosting.co.za>


Al Sweigart added the comment:

Is this a duplicate of https://bugs.python.org/issue9262 Either way, there's some good discussion there and also on https://bugs.python.org/issue24750 (ctrl-f for "tabbed")

----------
nosy: +Al.Sweigart

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

From report at bugs.python.org  Sun Aug  9 04:24:29 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 09 Aug 2015 02:24:29 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <1439087069.01.0.597840233475.issue24751@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ah.  The problem is on 2.7 only; 3.x calls sorted() on the set operation.  The set operation should just go away, though; we don't count ENV_CHANGED as 'bad' anymore.

Will fix shortly.

----------

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

From report at bugs.python.org  Sun Aug  9 04:27:11 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 09 Aug 2015 02:27:11 +0000
Subject: [issue24827] round(1.65, 1) return 1.6 with decimal
In-Reply-To: <1439002924.0.0.989734122739.issue24827@psf.upfronthosting.co.za>
Message-ID: <1439087231.68.0.986212078022.issue24827@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'm glad you understand it now :)

----------

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

From report at bugs.python.org  Sun Aug  9 04:35:44 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 09 Aug 2015 02:35:44 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439087744.2.0.457723634271.issue24832@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Which version of Sphinx are you using?  The Docs buildbot is happily building with 1.3.1 (though failing the lint check, which I missed when it started).

----------
nosy: +zach.ware

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

From report at bugs.python.org  Sun Aug  9 05:05:42 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 09 Aug 2015 03:05:42 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <1439089542.36.0.130056883267.issue24751@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> zach.ware
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Aug  9 05:05:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Aug 2015 03:05:48 +0000
Subject: [issue24751] regrtest/buildbot: test run marked as failure even when
 re-run succeeds
In-Reply-To: <1438205156.51.0.585052183342.issue24751@psf.upfronthosting.co.za>
Message-ID: <20150809030544.111014.82652@psf.io>


Roundup Robot added the comment:

New changeset 7d69b214e668 by Zachary Ware in branch '2.7':
Issue #24751: Fix running regrtest with '-w' flag in case of test failures.
https://hg.python.org/cpython/rev/7d69b214e668

----------

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

From report at bugs.python.org  Sun Aug  9 09:08:16 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 09 Aug 2015 07:08:16 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1439071022.93.0.848839700217.issue24272@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKBhm_Kn3Qd7RE67nNB0r+RWgiohxjA98XWxXqHXH6Eqg@mail.gmail.com>


Guido van Rossum added the comment:

Yeah, there's another diff but I didn't get to it.

----------

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

From report at bugs.python.org  Sun Aug  9 09:09:03 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 09 Aug 2015 07:09:03 +0000
Subject: [issue23973] PEP 484 implementation
In-Reply-To: <1439070855.34.0.64937603723.issue23973@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLY7cpzz8NHa=_2oUzLGQxBhPNFoKLUTRh3OynOjd=mOQ@mail.gmail.com>


Guido van Rossum added the comment:

There's more, but you can reduce the priority now.

----------

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

From report at bugs.python.org  Sun Aug  9 09:51:59 2015
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCb0LjRgdC+0LI=?=)
Date: Sun, 09 Aug 2015 07:51:59 +0000
Subject: [issue24833] IDLE tabnanny check fails
Message-ID: <1439106719.71.0.370110584661.issue24833@psf.upfronthosting.co.za>


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

idlelib.ScriptBinding line 72: tokenize.TokenError object is not iterable

----------
components: IDLE
messages: 248314
nosy: ?????? ?????
priority: normal
severity: normal
status: open
title: IDLE tabnanny check fails
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  9 11:25:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Aug 2015 09:25:58 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <20150809092554.41839.81720@psf.io>


Roundup Robot added the comment:

New changeset bdd1df816f84 by Serhiy Storchaka in branch '3.5':
Issue #24824: Signatures of codecs.encode() and codecs.decode() now are
https://hg.python.org/cpython/rev/bdd1df816f84

New changeset ad65cad76331 by Serhiy Storchaka in branch 'default':
Issue #24824: Signatures of codecs.encode() and codecs.decode() now are
https://hg.python.org/cpython/rev/ad65cad76331

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  9 12:02:47 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:02:47 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1439114567.86.0.422824262702.issue24667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yeah, I stopped it at 300k iterations.  No problems.  Glad this fix got in for rc1.

----------

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

From report at bugs.python.org  Sun Aug  9 12:04:40 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:04:40 +0000
Subject: [issue24824] Pydoc fails with codecs
In-Reply-To: <1438943432.6.0.304623132164.issue24824@psf.upfronthosting.co.za>
Message-ID: <1439114680.92.0.0970506885649.issue24824@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Fixed.  Thanks, Serhiy!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Aug  9 12:10:56 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:10:56 +0000
Subject: [issue24834] pydoc should display the expression for a builtin
 argument default, not its result
Message-ID: <1439115056.44.0.0298304719355.issue24834@psf.upfronthosting.co.za>


New submission from Larry Hastings:

As discussed in #24824, inspect.Parameter currently only has a place to store the value of a default argument.  Which means, if a complicated bit of code was used to produce that default argument, all we have left is the value, not the code that arrived at that value.  Which means all pydoc can do is display the value.

When C extensions pass in their default arguments as expressions, it'd be great if we could preserve that text and present it to the user.  The example that resulted in us creating this issue: _codecs.encode() and _codecs.decode() both took an "encoding" parameter that defaulted to sys.getdefaultencoding().  The value of that function was (always) "utf-8".  It's slightly more meaningful to display
    encoding=sys.getdefaultencoding(),
than
    encoding="utf-8",
in pydoc.

As a first approach, I propose we add a new member to inspect.Parameter, call it "symbolic_default_value", which contains the expression passed in by Argument Clinic (if present).  pydoc should look for this member when computing the documentation for a function, and prefer to present it to the user over the actual default value.

----------
assignee: larry
messages: 248318
nosy: larry, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc should display the expression for a builtin argument default, not its result
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Aug  9 12:11:30 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:11:30 +0000
Subject: [issue24732] 3.5.0b3 Windows accept() on unready non-blocking socket
 raises PermissionError
In-Reply-To: <1437963228.18.0.486881534673.issue24732@psf.upfronthosting.co.za>
Message-ID: <1439115090.42.0.847371824963.issue24732@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
priority: release blocker -> high

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

From report at bugs.python.org  Sun Aug  9 12:12:23 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:12:23 +0000
Subject: [issue24585] Windows installer does not detect existing installs
In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za>
Message-ID: <1439115143.75.0.624592098531.issue24585@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Quoting from PEP 101:

   release blocker - Stops the release dead in its tracks.  You may not
                     make any release with any open release blocker bugs.

So, yeah, I want to.

----------
priority: release blocker -> critical

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

From report at bugs.python.org  Sun Aug  9 12:12:36 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:12:36 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1439115156.82.0.0303082258462.issue24272@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
priority: release blocker -> high

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

From report at bugs.python.org  Sun Aug  9 12:12:45 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:12:45 +0000
Subject: [issue23973] PEP 484 implementation
In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za>
Message-ID: <1439115165.48.0.199005320996.issue23973@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
priority: release blocker -> high

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

From report at bugs.python.org  Sun Aug  9 12:26:26 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:26:26 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
Message-ID: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The Python 3.5 buildbot for Windows 7 consistently fails during test_asyncio.  The buildbots are here:

http://buildbot.python.org/all/waterfall?category=3.5.stable

An example log file:

http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/173/steps/test/logs/stdio

The error is at the end and looks like this:

    test_winsocketpair_ipv6 (test.test_asyncio.test_windows_utils.WinsocketpairTests) ... D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\asyncio\base_subprocess.py:122: ResourceWarning: unclosed transport <_WindowsSubprocessTransport pid=3388 running>
      warnings.warn("unclosed transport %r" % self, ResourceWarning)
    test test_asyncio failed
    ok

Who's the expert for the asyncio implementation on Windows?  Could one of you guys nosy him/her on the bug?

----------
messages: 248320
nosy: gvanrossum, haypo, larry, steve.dower
priority: critical
severity: normal
stage: needs patch
status: open
title: Consistent failure in test_asyncio on Windows 7 buildbot
type: crash

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

From report at bugs.python.org  Sun Aug  9 12:29:22 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:29:22 +0000
Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard
 buildbot for Python 3.5
Message-ID: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The Snow Leopard buildbot for Python 3.5 consistently fails in the regression test for the email module.

The 3.5 buildbots are here:

http://buildbot.python.org/all/waterfall?category=3.5.stable

Example log file:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.5/builds/185/steps/test/logs/stdio

Sample failure:

    ======================================================================
    FAIL: test_formatdate (test.test_email.test_utils.FormatDateTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/support/__init__.py", line 1531, in inner
        return func(*args, **kwds)
      File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_email/test_utils.py", line 145, in test_formatdate
        self.assertEqual(string, 'Thu, 01 Dec 2011 15:00:00 -0000')
    AssertionError: 'Thu, 01 Dec 2011 16:00:00 -0000' != 'Thu, 01 Dec 2011 15:00:00 -0000'
    - Thu, 01 Dec 2011 16:00:00 -0000
    ?                   ^
    + Thu, 01 Dec 2011 15:00:00 -0000
    ?                   ^


    ======================================================================
    FAIL: test_formatdate_with_localtime (test.test_email.test_utils.FormatDateTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/support/__init__.py", line 1531, in inner
        return func(*args, **kwds)
      File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_email/test_utils.py", line 157, in test_formatdate_with_localtime
        self.assertEqual(string, 'Thu, 01 Dec 2011 18:00:00 +0300')
    AssertionError: 'Thu, 01 Dec 2011 18:00:00 +0200' != 'Thu, 01 Dec 2011 18:00:00 +0300'
    - Thu, 01 Dec 2011 18:00:00 +0200
    ?                             ^
    + Thu, 01 Dec 2011 18:00:00 +0300
    ?                             ^

Ned...?

----------
messages: 248321
nosy: larry, ned.deily
priority: critical
severity: normal
stage: needs patch
status: open
title: Consistent failure in test_email on OS X Snow Leopard buildbot for Python 3.5
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug  9 13:56:30 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 09 Aug 2015 11:56:30 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439121390.78.0.12525199761.issue24831@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It's very likely an I/O issue. There are several large file
tests that run even if 'largefile' is disabled. It already
helps a lot if the following tests are decorated with requires_resource('largefile'):

test_mmap: class LargeMmapTests()

test_io: large_file_ops()

test_largefile: all tests

----------

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

From report at bugs.python.org  Sun Aug  9 14:33:27 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 09 Aug 2015 12:33:27 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439123607.54.0.609872983904.issue24835@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Probably Vincent knows? FWIW the actual failure from the log file is:

FAIL: test_popen_error (test.test_asyncio.test_subprocess.SubprocessProactorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_asyncio\test_subprocess.py", line 428, in test_popen_error
    self.loop.run_until_complete(create)
AssertionError: ZeroDivisionError not raised

The test refers to issue #24763.

----------

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

From report at bugs.python.org  Sun Aug  9 14:41:25 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 09 Aug 2015 12:41:25 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439124085.79.0.120051608975.issue24835@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Actually, this seems to be Yuri's mistake -- in rev 99550a01fa6e (in the 3.4 case, I suppose it's been merged into 3.5 and 3.6) he (accidentally, I assume) reverted Victor's (not Vincent's -- sorry!) fix from issue #24763. But apparently Victor didn't copy that fix to the upstream asyncio repo.

----------
nosy: +yselivanov

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

From report at bugs.python.org  Sun Aug  9 15:17:41 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Aug 2015 13:17:41 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439126261.73.0.402208063914.issue24831@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note some of those large file tests work on sparse files, which shouldn't be a problem if they are supported by the filesystem (which is most Linux filesystems, AFAIK).

----------

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

From report at bugs.python.org  Sun Aug  9 16:16:36 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 09 Aug 2015 14:16:36 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439129796.53.0.557261217184.issue24831@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks, this clears up the mystery! -- I made the mistake of choosing
the eCryptfs-homedir option when installing Ubuntu, so now I have eCryptfs on top of LVM on top of full-disk encryption.

So I can't create sparse files in my home directory, but I *can*
create sparse files with zero overhead in /tmp.


The test suite runs smoothly from /usr/local.  Should we perhaps create
temp files in /tmp rather than in a subdir of the build directory?

----------

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

From report at bugs.python.org  Sun Aug  9 17:54:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Aug 2015 15:54:34 +0000
Subject: [issue24832] Issue building docs with newer sphix (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439135674.76.0.84190922557.issue24832@psf.upfronthosting.co.za>


R. David Murray added the comment:

1.3.1.  The doc build doesn't *fail*, it's just that if you try to view the built pages they don't render correctly, because there is no default.css that the pydoctheme depends on.

I wonder what the web site is using for the build.  Although copying default.css from an old build works (as would, presumably, copying classic.css to default.css or hardlinking it).

----------

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

From report at bugs.python.org  Sun Aug  9 17:56:19 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Aug 2015 15:56:19 +0000
Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard
 buildbot for Python 3.5
In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za>
Message-ID: <1439135779.6.0.159999797778.issue24836@psf.upfronthosting.co.za>


R. David Murray added the comment:

The buildbot needs to upgrade its timezone files, they are quite out of date.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Aug  9 17:59:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Aug 2015 15:59:08 +0000
Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard
 buildbot for Python 3.5
In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za>
Message-ID: <1439135948.66.0.605262867964.issue24836@psf.upfronthosting.co.za>


R. David Murray added the comment:

"quite out of date" being pre 2011k, FYI.  See issue 22932.

----------

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

From report at bugs.python.org  Sun Aug  9 18:01:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Aug 2015 16:01:41 +0000
Subject: [issue24832] Issue building docs with newer sphinx (default theme ->
 classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439136101.59.0.516818455027.issue24832@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Issue building docs with newer sphix (default theme -> classic) -> Issue building docs with newer sphinx (default theme -> classic)

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

From report at bugs.python.org  Sun Aug  9 18:01:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Aug 2015 16:01:59 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439136119.18.0.577414511491.issue24832@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Issue building docs with newer sphinx (default theme -> classic) -> Issue building viewable docs with newer sphinx (default theme -> classic)

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

From report at bugs.python.org  Sun Aug  9 19:00:24 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 09 Aug 2015 17:00:24 +0000
Subject: [issue11677] make test has horrendous performance on an ecryptfs
In-Reply-To: <1301092248.42.0.811586375377.issue11677@psf.upfronthosting.co.za>
Message-ID: <1439139624.03.0.153841360669.issue11677@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I don't know whether this is worth reopening, but the ecryptfs
performance is still very poor on my Lenovo T400 (see #24831).

For most people an extra option for choosing the tmpdir
would not help, since they'd simply blame the hardware
or the test suite.

----------
nosy: +skrah

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

From report at bugs.python.org  Sun Aug  9 20:25:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Aug 2015 18:25:55 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439144755.77.0.529442772581.issue24831@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Should we perhaps create
temp files in /tmp rather than in a subdir of the build directory?

That would sound reasonable, I don't know why it hasn't been done like that from the start. Perhaps Ezio or Victor know.

----------
nosy: +ezio.melotti, haypo

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

From report at bugs.python.org  Sun Aug  9 20:47:40 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 Aug 2015 18:47:40 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439146060.56.0.131947585857.issue24492@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
versions: +Python 3.6

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

From report at bugs.python.org  Sun Aug  9 21:39:16 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 09 Aug 2015 19:39:16 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439149156.75.0.0788247092758.issue24745@psf.upfronthosting.co.za>


Ned Deily added the comment:

Unfortunately, we didn't test this change with Tk 8.4: TkFixedFont does not exist in 8.4.  This means that, unless the user has already modified the IDLE configuration to use an explicit font, IDLE linked with Tk 8.4 crashes in initialization.

$ mv .idlerc/ .idlerc-OLD
$ idle3.5
Traceback (most recent call last):
  File "/usr/local/bin/idle3.5", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 1560, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 320, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 867, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/EditorWindow.py", line 233, in __init__
    text['font'] = idleConf.GetFont(self.root, 'main', 'EditorWindow')
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/configHandler.py", line 691, in GetFont
    f = Font(name='TkFixedFont', exists=True, root=root)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tkinter/font.py", line 87, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font TkFixedFont does not already exist
n

A workaround is to manually create or edit the IDLE configuration file and define an explicit font, for example on OS X:

$ cat >.idlerc/config-main.cfg <<EOF
[EditorWindow]
font-size = 11
font = monaco
EOF

This is a release blocker for 3.5.0, first seen in 3.5.0rc1.

----------
nosy: +benjamin.peterson, larry
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sun Aug  9 21:43:50 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 09 Aug 2015 19:43:50 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439149430.18.0.0258980992841.issue24745@psf.upfronthosting.co.za>


Ned Deily added the comment:

Unfortunately, we didn't test this change with Tk 8.4: TkFixedFont does not exist in 8.4.  This means that, unless the user has already modified the IDLE configuration to use an explicit font, IDLE linked with Tk 8.4 crashes in initialization.

$ mv .idlerc/ .idlerc-OLD
$ idle3.5
Traceback (most recent call last):
  File "/usr/local/bin/idle3.5", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 1560, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 320, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/PyShell.py", line 867, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/EditorWindow.py", line 233, in __init__
    text['font'] = idleConf.GetFont(self.root, 'main', 'EditorWindow')
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/configHandler.py", line 691, in GetFont
    f = Font(name='TkFixedFont', exists=True, root=root)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tkinter/font.py", line 87, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font TkFixedFont does not already exist
n

A workaround is to manually create or edit the IDLE configuration file and define an explicit font, for example on OS X:

$ cat > ~/.idlerc/config-main.cfg <<EOF
[EditorWindow]
font-size = 11
font = monaco
EOF

This is a release blocker for 3.5.0, first seen in 3.5.0rc1.

----------

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

From report at bugs.python.org  Sun Aug  9 21:44:02 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 09 Aug 2015 19:44:02 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439149442.59.0.16122233115.issue24745@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg248332

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

From report at bugs.python.org  Sun Aug  9 21:58:37 2015
From: report at bugs.python.org (Eric Snow)
Date: Sun, 09 Aug 2015 19:58:37 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1439114567.86.0.422824262702.issue24667@psf.upfronthosting.co.za>
Message-ID: <CALFfu7DxMLdQ60pEQoU3smOCw4fECSyhHXNmDmEnqr5S4Cn0Hw@mail.gmail.com>


Eric Snow added the comment:

> Yeah, I stopped it at 300k iterations.  No problems.  Glad this fix got
in for rc1.

Thanks for the double-check, Larry.  I'd done similar testing, though not
as exhaustively. :)  Getting a fix in for RC1 was pretty important to me.
It stretched me a bit, but I got it done.

----------

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

From report at bugs.python.org  Sun Aug  9 22:36:00 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 20:36:00 +0000
Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard
 buildbot for Python 3.5
In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za>
Message-ID: <1439152560.79.0.207984444334.issue24836@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Thanks for diagnosing the problem, David!

----------
keywords: +buildbot
priority: critical -> normal

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

From report at bugs.python.org  Sun Aug  9 22:46:59 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 20:46:59 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439153219.64.0.622411071398.issue24745@psf.upfronthosting.co.za>


Larry Hastings added the comment:

We're retagging 3.5.0rc1 to fix this and one other regression.  Can someone step up and get this fix checked in in the next six or eight hours?  You can just check in to the 3.5 branch on hg.python.org/cpython like normal (you won't have to use Bitbucket and "pull requests" for this).

----------

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

From report at bugs.python.org  Sun Aug  9 22:47:11 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 20:47:11 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439153231.6.0.623014963697.issue24835@psf.upfronthosting.co.za>


Larry Hastings added the comment:

We're retagging 3.5.0rc1 to fix this and one other regression.  Can someone step up and get this fix checked in in the next six or eight hours?  You can just check in to the 3.5 branch on hg.python.org/cpython like normal (you won't have to use Bitbucket and "pull requests" for this).

----------

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

From report at bugs.python.org  Sun Aug  9 23:22:12 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 09 Aug 2015 21:22:12 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439153231.6.0.623014963697.issue24835@psf.upfronthosting.co.za>
Message-ID: <6C004742-57A9-47FF-B49A-636BF8833E8F@gmail.com>


Yury Selivanov added the comment:

I can commit the fix in an hour or so.

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Sun Aug  9 23:49:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 09 Aug 2015 21:49:03 +0000
Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results
In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za>
Message-ID: <1439156943.84.0.00152516878567.issue15989@psf.upfronthosting.co.za>


Robert Collins added the comment:

It looks fine to me, for whatever thats worth. I think you should commit it.

----------

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

From report at bugs.python.org  Sun Aug  9 23:53:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Aug 2015 21:53:48 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <20150809215345.1393.53965@psf.io>


Roundup Robot added the comment:

New changeset 7c78279afc30 by Robert Collins in branch 'default':
Issue #20059: urllib.parse raises ValueError on all invalid ports.
https://hg.python.org/cpython/rev/7c78279afc30

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  9 23:54:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 09 Aug 2015 21:54:02 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1439157242.91.0.950495015404.issue20059@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Aug 10 00:22:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Aug 2015 22:22:43 +0000
Subject: [issue24763] asyncio.BaseSubprocessTransport triggers an unavoidable
 ResourceWarning if process doesn't start
In-Reply-To: <1438354626.92.0.802065077035.issue24763@psf.upfronthosting.co.za>
Message-ID: <20150809222240.29410.43077@psf.io>


Roundup Robot added the comment:

New changeset 2648dddd3248 by Yury Selivanov in branch '3.4':
Issue #24763: Fix asyncio test on Windows (fix reverted change)
https://hg.python.org/cpython/rev/2648dddd3248

New changeset aa527ee0d27f by Yury Selivanov in branch '3.5':
Merge 3.4 (issues #24835, #24763)
https://hg.python.org/cpython/rev/aa527ee0d27f

New changeset f304ba9425a3 by Yury Selivanov in branch 'default':
Merge 3.5 (issues #24835, #24763)
https://hg.python.org/cpython/rev/f304ba9425a3

----------

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

From report at bugs.python.org  Mon Aug 10 00:22:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Aug 2015 22:22:43 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <20150809222240.29410.23200@psf.io>


Roundup Robot added the comment:

New changeset 2648dddd3248 by Yury Selivanov in branch '3.4':
Issue #24763: Fix asyncio test on Windows (fix reverted change)
https://hg.python.org/cpython/rev/2648dddd3248

New changeset aa527ee0d27f by Yury Selivanov in branch '3.5':
Merge 3.4 (issues #24835, #24763)
https://hg.python.org/cpython/rev/aa527ee0d27f

New changeset f304ba9425a3 by Yury Selivanov in branch 'default':
Merge 3.5 (issues #24835, #24763)
https://hg.python.org/cpython/rev/f304ba9425a3

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug 10 00:23:53 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 09 Aug 2015 22:23:53 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439159033.91.0.0122425352675.issue24835@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Guido, thanks for investigating this.

Larry, it should be fixed now (although I don't have a windows machine at hand to test it)

----------

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

From report at bugs.python.org  Mon Aug 10 00:24:05 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 09 Aug 2015 22:24:05 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439159045.8.0.113949528292.issue24835@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Aug 10 00:30:32 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 22:30:32 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439159432.26.0.0911038101939.issue24835@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I don't have one either.  But that's why we've got buildbots.  The Windows 7 buildbot, where I first noticed the regression, is here:

http://buildbot.python.org/all/builders/x86%20Windows7%203.5

It should be done testing your patch 1 hour and 15 minutes from now.

----------

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

From report at bugs.python.org  Mon Aug 10 01:40:00 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 Aug 2015 23:40:00 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439163600.85.0.0658999121484.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a patch that adds a test, fixes the issue, and for good measure stops assuming that __name__ will always be a string.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40154/issue24492.diff

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

From report at bugs.python.org  Mon Aug 10 05:20:34 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Aug 2015 03:20:34 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439176834.75.0.235097941417.issue24832@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ah, sorry; I missed that distinction.

I can't reproduce, though: in a clean checkout of default, I just did:

cd Doc/
make venv PYTHON=python3
source venv/bin/activate
make html

The resulting build did emit the warning about the themes, but the docs produced render just fine.

----------

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

From report at bugs.python.org  Mon Aug 10 05:25:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Aug 2015 03:25:19 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <20150810032516.53993.37102@psf.io>


Roundup Robot added the comment:

New changeset e39c4373b83f by Ned Deily in branch '3.5':
Issue #24745: Prevent IDLE initialization crash with Tk 8.4:
https://hg.python.org/cpython/rev/e39c4373b83f

New changeset 8c55fb5a11d8 by Ned Deily in branch 'default':
Issue #24745: merge from 3.5
https://hg.python.org/cpython/rev/8c55fb5a11d8

----------

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

From report at bugs.python.org  Mon Aug 10 05:31:25 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Aug 2015 03:31:25 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439177485.1.0.707900492718.issue24745@psf.upfronthosting.co.za>


Ned Deily added the comment:

At Larry's request so that we can get 3.5.0rc1 out the door, I've checked in a temporary fix for 3.5 (and for 3.6) that should prevent the IDLE crash when linked with Tk 8.4.  I'll leave the issue open for Terry to review and provide the final fix for all branches.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Mon Aug 10 05:40:14 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 03:40:14 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439178014.59.0.968514434879.issue24835@psf.upfronthosting.co.za>


Larry Hastings added the comment:

The buildbot passes the test!  Hooray!

----------

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

From report at bugs.python.org  Mon Aug 10 10:25:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Aug 2015 08:25:33 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439144755.77.0.529442772581.issue24831@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbOvOBuL0HCHOqZPcfP=Z78SEKR=p6YFP_o-AWdxxD48w@mail.gmail.com>


STINNER Victor added the comment:

There is not option to choose the temporary directory like $TMPDIR?

I had issues with /tmp when creating large files because /tmp is now a
tmpfs on Fedora by default.

Maybe we can blacklist some filesystems to choose the temporary directory.

----------

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

From report at bugs.python.org  Mon Aug 10 10:33:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Aug 2015 08:33:05 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439124085.79.0.120051608975.issue24835@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaKBKkhaNb-0m5oedvDrkiPk43f0G3s2+p71zBXyb7=fQ@mail.gmail.com>


STINNER Victor added the comment:

Le 9 ao?t 2015 14:41, "Guido van Rossum" <report at bugs.python.org> a ?crit :
> But apparently Victor didn't copy that fix to the upstream asyncio repo.

Yeah sorry about that. Hopefully it's now fixed.

Yury: be careful when synchonizing github and cpython code. It's common to
have changes only on one side.

----------

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

From report at bugs.python.org  Mon Aug 10 10:35:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Aug 2015 08:35:18 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439195718.5.0.449425703597.issue24831@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lib/test/regrtest.py:
# When tests are run from the Python build directory, it is best practice
# to keep the test files in a subfolder.  This eases the cleanup of leftover
# files using the "make distclean" command.
if sysconfig.is_python_build():
    TEMPDIR = os.path.join(sysconfig.get_config_var('srcdir'), 'build')
else:
    TEMPDIR = tempfile.gettempdir()

----------

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

From report at bugs.python.org  Mon Aug 10 11:30:38 2015
From: report at bugs.python.org (Chetan Reddy)
Date: Mon, 10 Aug 2015 09:30:38 +0000
Subject: [issue24837] await process.wait() does not work with a new_event_loop
Message-ID: <1439199038.24.0.690620901041.issue24837@psf.upfronthosting.co.za>


New submission from Chetan Reddy:

Attached test.py hangs with the following output when run with PYTHONASYNCIODEBUG1= and -Wdefault.

DEBUG:asyncio:Using selector: EpollSelector
DEBUG:asyncio:run shell command 'sleep 2'
DEBUG:asyncio:process 'sleep 2' created: pid 13801
INFO:asyncio:run shell command 'sleep 2': <_UnixSubprocessTransport pid=13801 running>

After i Ctrl-C it, i see the following traceback (paths edited)

^CTraceback (most recent call last):
  File "/chetan/test.py", line 17, in <module>
    main()
  File "/chetan/test.py", line 12, in main
    result =loop.run_until_complete(sleepWithShell(loop))
  File "/Python-3.5.0b4-clang/lib/python3.5/asyncio/base_events.py", line 329, in run_until_complete
    self.run_forever()
  File "/Python-3.5.0b4-clang/lib/python3.5/asyncio/base_events.py", line 300, in run_forever
    self._run_once()
  File "/Python-3.5.0b4-clang/lib/python3.5/asyncio/base_events.py", line 1142, in _run_once
    event_list = self._selector.select(timeout)
  File "/Python-3.5.0b4-clang/lib/python3.5/selectors.py", line 432, in select
    fd_event_list = self._epoll.poll(timeout, max_ev)
KeyboardInterrupt
/Python-3.5.0b4-clang/lib/python3.5/asyncio/base_subprocess.py:117: ResourceWarning: unclosed transport <_UnixSubprocessTransport pid=13801 running>
/Python-3.5.0b4-clang/lib/python3.5/asyncio/base_events.py:384: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=True>
DEBUG:asyncio:Close <_UnixSelectorEventLoop running=False closed=False debug=True>

----------
components: asyncio
files: test.py
messages: 248353
nosy: chetan, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: await process.wait() does not work with a new_event_loop
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40155/test.py

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

From report at bugs.python.org  Mon Aug 10 11:48:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Aug 2015 09:48:44 +0000
Subject: [issue24837] await process.wait() does not work with a new_event_loop
In-Reply-To: <1439199038.24.0.690620901041.issue24837@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbebK4i0m7O07_PT=YouGCdQhG=jgV=_E1OsVeog8k72w@mail.gmail.com>


STINNER Victor added the comment:

It's better to use asyncio.get_event_loop() to create the event loop.
Otherwise, you have to create manually the child watcher:
https://docs.python.org/dev/library/asyncio-subprocess.html#subprocess-and-threads

If I recall correctly, you have to call asyncio. get_child_watcher().

What is your OS?

Maybe subprocess_exec/shell may ensure that a child watcher exist. Maybe
only in debug mode?

----------

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

From report at bugs.python.org  Mon Aug 10 12:14:08 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 10 Aug 2015 10:14:08 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439201648.17.0.961818757449.issue24831@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yes, the current scheme is probably good for easy buildbot cleanup.


> Maybe we can blacklist some filesystems to choose the temporary directory.

If that's easily possible, it would be a good solution at least
for ecryptfs.


I've removed ecryptfs from my setup, since speedwise it's not
production-ready for encrypting an entire home directory.


The Ubuntu setup is a bit of a trap, since the encryption is
completely transparent to the user (i.e. mounting ecryptfs
occurs automatically on login).

So if you install Ubuntu as the first system on new hardware
and choose the ecryptfs option, after a while you forget about
ecryptfs entirely and blame any slowness on the hardware or
the software.

----------
priority: high -> normal

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

From report at bugs.python.org  Mon Aug 10 12:25:42 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 10 Aug 2015 10:25:42 +0000
Subject: [issue24831] Load average in test suite too high
In-Reply-To: <1439048328.2.0.659609134841.issue24831@psf.upfronthosting.co.za>
Message-ID: <1439202342.08.0.705788472658.issue24831@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Actually, for ecryptfs we could just check for ~/.ecryptfs and
then use /tmp.

----------

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

From report at bugs.python.org  Mon Aug 10 15:03:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Aug 2015 13:03:55 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439211835.61.0.306012435597.issue24832@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  All I do is 'make clean; make html', but I don't see why that would make a difference to the problem on point.  

I didn't know about this make venv thing...that must be newish?  When I try it, that does indeed work.  Building that way produces a 'default.css' in build/html/_static, whereas building without the venv (but with sphinx 1.3.1) does not.  I have no idea why, it doesn't really make sense that that would be the case.

Perhaps the experiment of using the installed sphinx to build the docs is a failure and we should just make using local copies the default again?

----------

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

From report at bugs.python.org  Mon Aug 10 15:05:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Aug 2015 13:05:22 +0000
Subject: [issue24837] await process.wait() does not work with a new_event_loop
In-Reply-To: <1439199038.24.0.690620901041.issue24837@psf.upfronthosting.co.za>
Message-ID: <1439211922.58.0.217401062047.issue24837@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think it's unfortunate that this doesn't work. Note that the example program has no threads -- it just has a loop that isn't the default loop. The docs you refer to aren't very helpful.

----------

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

From report at bugs.python.org  Mon Aug 10 15:16:47 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Aug 2015 13:16:47 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439212607.1.0.544057200765.issue24769@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Apologies for the delay; I was on vacation.

This was indeed a mistake in PEP 489 implementation. I agree with Nick on the solution.
Here is a patch that adds exec_builtin, with implementation shared with exec_dynamic.

----------
keywords: +patch
Added file: http://bugs.python.org/file40156/issue24769.patch

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

From report at bugs.python.org  Mon Aug 10 17:50:51 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 10 Aug 2015 15:50:51 +0000
Subject: [issue24835] Consistent failure in test_asyncio on Windows 7 buildbot
In-Reply-To: <1439115986.79.0.206255859862.issue24835@psf.upfronthosting.co.za>
Message-ID: <1439221851.71.0.417805521166.issue24835@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury: be careful when synchonizing github and cpython code. It's common to
have changes only on one side.

Victor, I agree.  But let's make sure that it's no more "common" to have two repos out of sync.  I shouldn't sync your changes (and you, likewise, shouldn't sync mine) because I'm not really familiar with them, and it is sometimes hard to guess what's going on.  Let's stick to the workflow, please.

----------

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

From report at bugs.python.org  Mon Aug 10 18:50:29 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Aug 2015 16:50:29 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439225429.95.0.257125822515.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Larry, does this warrant going into 3.5.0?

----------
assignee: brett.cannon -> larry

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

From report at bugs.python.org  Mon Aug 10 20:00:56 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 10 Aug 2015 18:00:56 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1439229656.41.0.593574766598.issue12892@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

I don't understand why encoding with `surrogateescape` isn't supported still; is it the fact that a surrogate would have to produce *single bytes* rather than double? E.g. b'\x80' -> '\udc80' -> b'\x80' doesn't work because that would mean the UTF-16 and UTF-32 codec could then end up producing an odd number of bytes?

----------
nosy: +mjpieters

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

From report at bugs.python.org  Mon Aug 10 20:04:23 2015
From: report at bugs.python.org (Roddy Shuler)
Date: Mon, 10 Aug 2015 18:04:23 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
Message-ID: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>


New submission from Roddy Shuler:

GNU and USTAR formats use a special case if the file path is longer than 100 bytes. The detection for this, though, incorrectly checked for 100 characters rather than 100 bytes. So, if the length was close to but not exceeding 100 characters and included special characters such that the encoded length is greater than 100 bytes, the encoded string was truncated to 100 bytes and thus the resulting file name was truncated within the tar file.

For example...

/gt-education/Colecci?n Educativa Guatemala/thumbs/Libro de Texto Comunicacion y Lenguaje 1 Grado.jpg

is truncated as:

/gt-education/Colecci?n Educativa Guatemala/thumbs/Libro de Texto Comunicacion y Lenguaje 1 Grado.jp

The attached patch fixes this.  Initially found on Python 3.3.  Patch is tested on Linux with version 3.4.3-6 from Debian.  Looking at the source code, I am pretty confident that the problem still exists upstream in Python 3.5.

----------
files: fix-tarfile-path-truncation.patch
keywords: patch
messages: 248363
nosy: Roddy Shuler
priority: normal
severity: normal
status: open
title: tarfile.py: fix GNU and USTAR formats to properly handle paths with special characters that are encoded with more than one byte each
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40157/fix-tarfile-path-truncation.patch

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

From report at bugs.python.org  Mon Aug 10 20:15:44 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 10 Aug 2015 18:15:44 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
Message-ID: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>


New submission from Steve Dower:

platform._syscmd_ver() calls platform.popen() which raises a DeprecationWarning. This causes tests with `@skip(platform.machine() == '...')` decorators to fail.

The fix is to call `os.popen()` - patch attached. (platform.popen() just raises the warning and then calls os.popen(), so should be no risk here.)

Larry - since this causes spurious failures in numpy's test suite, can we get it into 3.5?

----------
files: platform_popen.patch
keywords: patch
messages: 248364
nosy: larry, lemburg, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: platform._syscmd_ver raises DeprecationWarning
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40158/platform_popen.patch

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

From report at bugs.python.org  Mon Aug 10 20:59:05 2015
From: report at bugs.python.org (sanad)
Date: Mon, 10 Aug 2015 18:59:05 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1439233145.72.0.0787078110316.issue23672@psf.upfronthosting.co.za>


sanad added the comment:

These observations are noted when the system locale is set to 'iso-88591'

1. Ok, for some reason I'm able to execute this command without any error in Linux (idle window is opening with a file name as 'astralE.py'). Because the character '?' is automatically being shown and treated as 'E' in both terminal and python command line interpreter(similar for chars '?' = 'z' and '?' = 'P').

2. But i'm unable to save/make a file with filname 'astral?.py' and hence unable to run it. The following errors are thrown then : 

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/sanad/devpy/pessoc/cpython/Lib/tkinter/__init__.py", line 1549, in __call__
    return self.func(*args)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/MultiCall.py", line 176, in handler
    r = l[i](event)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/IOBinding.py", line 339, in save
    self.save_as(event)
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/IOBinding.py", line 353, in save_as
    if self.writefile(filename):
  File "/home/sanad/devpy/pessoc/cpython/Lib/idlelib/IOBinding.py", line 379, in writefile
    with open(filename, "wb") as f:
UnicodeEncodeError: 'ascii' codec can't encode character '\U0001d53c' in position 39: ordinal not in range(128)

I'm trying to figure out the root of the problem, feel free to give your inputs

----------

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

From report at bugs.python.org  Mon Aug 10 22:02:30 2015
From: report at bugs.python.org (Gregory Szorc)
Date: Mon, 10 Aug 2015 20:02:30 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1439236950.74.0.247069513666.issue23051@psf.upfronthosting.co.za>


Gregory Szorc added the comment:

For posterity, I think we ran into a similar problem in https://bugzilla.mozilla.org/show_bug.cgi?id=1191877, where our code uses apply_async():

11:09:47     INFO -  Exception in thread Thread-2:
11:09:47     INFO -  Traceback (most recent call last):
11:09:47     INFO -    File "/tools/python/lib/python2.7/threading.py", line 551, in __bootstrap_inner
11:09:47     INFO -      self.run()
11:09:47     INFO -    File "/tools/python/lib/python2.7/threading.py", line 504, in run
11:09:47     INFO -      self.__target(*self.__args, **self.__kwargs)
11:09:47     INFO -    File "/tools/python/lib/python2.7/multiprocessing/pool.py", line 319, in _handle_tasks
11:09:47     INFO -      put(task)
11:09:47     INFO -  RuntimeError: dictionary changed size during iteration

This resulted in deadlock, just like this issue.

The added try..except around the iteration of taskseq likely fixes this as well.

----------
nosy: +Gregory.Szorc

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

From report at bugs.python.org  Mon Aug 10 22:41:40 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 20:41:40 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439239300.11.0.292675015092.issue24839@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yes, I'll accept that for 3.5.0.  Paste a link to a pull request here at your earliest convenience (and opportunity).

----------

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

From report at bugs.python.org  Mon Aug 10 22:44:09 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 20:44:09 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439239449.91.0.638130901567.issue24492@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I would like the fix in 3.5.  However, I'm not qualified to review the code.  Can you get a qualified reviewer in to look over the code?

Once someone suitable has reviewed it, I'll accept a pull request (pasted in here naturally).

----------

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

From report at bugs.python.org  Mon Aug 10 22:44:36 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 20:44:36 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439239476.7.0.64760437832.issue24492@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
assignee: larry -> brett.cannon

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

From report at bugs.python.org  Mon Aug 10 23:08:36 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 10 Aug 2015 21:08:36 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439240916.11.0.645248352085.issue24492@psf.upfronthosting.co.za>


Eric Snow added the comment:

patch LGTM.  Presumably the divergence between importlib (in _handle_fromlist) and import.c was strictly accidental (i.e. lack of test coverage).

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Aug 10 23:16:26 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Aug 2015 21:16:26 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1439241386.83.0.854851965478.issue24764@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug 10 23:23:20 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 10 Aug 2015 21:23:20 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439241800.73.0.62454963332.issue24769@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looks fine to me.  Nick had suggested calling exec_builtin from exec_dynamic (to the same effect as your patch), but I don't consider that much of an issue. :)

----------
stage:  -> commit review

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

From report at bugs.python.org  Mon Aug 10 23:24:55 2015
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 10 Aug 2015 21:24:55 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439241895.41.0.3603246415.issue24492@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Patch LGTM too.  Optionally a test is needed for each of the other cases in it too, but please don't cause that comment to stop it from getting in.

----------

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

From report at bugs.python.org  Mon Aug 10 23:35:37 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 10 Aug 2015 21:35:37 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439242537.95.0.18152364979.issue24839@psf.upfronthosting.co.za>


Steve Dower added the comment:

Have you opened up the repo yet? I'm getting "no access" errors from BB.

----------

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

From report at bugs.python.org  Mon Aug 10 23:36:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Aug 2015 21:36:34 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439242594.33.0.616739774699.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the reviews, Eric and Armin. I will get the patch in 3.5.0, 3.5.1, and 3.6 sometime this week and then open another issue for adding more tests for the other branches in the code.

----------
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Mon Aug 10 23:44:42 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Aug 2015 21:44:42 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439243082.78.0.207708608596.issue24769@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Right. I think a common helper is cleaner than calling a clinic-generated wrapper.

----------

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

From report at bugs.python.org  Mon Aug 10 23:47:31 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 10 Aug 2015 21:47:31 +0000
Subject: [issue24760] IDLE settings dialog shouldn't be modal
In-Reply-To: <1438297628.71.0.179622085434.issue24760@psf.upfronthosting.co.za>
Message-ID: <1439243251.23.0.975551448598.issue24760@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I've attached decouple_config.patch, which removes some internal knowledge about EditorWindow from configDialog. This is a step towards making the preferences dialog non-modal (and also to launching either the current dialog, or a new ttk-dependent one).

The thing that could currently break things if we switched to non-modal is that when configuration changes, we directly examine "parent.instance_dict". Unfortunately, it's possible that parent will have been destroyed before this happens.

Instead of holding onto parent, the patch holds onto the FileList object, which should persist. It also takes the opportunity to delegate the specifics of what should happen to active editor windows on config changes (previously in configDialog) to FileList, which in turn delegates the specifics back to each EditorWindow instance.

A separate patch, depending on this refactoring, will then change the dialog so that it can be launched non-modally, and make sure only a single instance is present.

----------
keywords: +patch
Added file: http://bugs.python.org/file40159/decouple_config.patch

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

From report at bugs.python.org  Tue Aug 11 00:50:56 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 22:50:56 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439247056.39.0.413389644814.issue24839@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Not yet.  I'll open it after I release 3.5.0rc1.  I'll send email to clp-d and clp-c when I do.  I can email you privately too if you like.

----------

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

From report at bugs.python.org  Tue Aug 11 00:51:34 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Aug 2015 22:51:34 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439247094.54.0.342221441931.issue24492@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yes, Eric and Armin are both qualified reviewers in my book.  You have my blessing to send a pull request.

Thanks, everybody!

----------

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

From report at bugs.python.org  Tue Aug 11 02:09:32 2015
From: report at bugs.python.org (Mike Lundy)
Date: Tue, 11 Aug 2015 00:09:32 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
Message-ID: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>


New submission from Mike Lundy:

There's a slightly odd edge case which can be summarized as follows:

====================
from enum import Enum

class Bool(Enum):
    Yep = True
    Nope = False

for value in Bool:
    print('%18r is %r' % (value, bool(value)))
====================

output:
====================
  <Bool.Yep: True> is True
<Bool.Nope: False> is True
====================

This isn't really a big deal, but can be made better with the attached patch. I can't think of any odd consequences this might cause, but others may know better.

----------
messages: 248378
nosy: novas0x2a
priority: normal
severity: normal
status: open
title: implement bool conversion for enums to prevent odd edge case
type: enhancement

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

From report at bugs.python.org  Tue Aug 11 02:13:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2015 00:13:49 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439252029.49.0.837490482204.issue24840@psf.upfronthosting.co.za>


R. David Murray added the comment:

No patch is attached.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Aug 11 02:16:59 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Aug 2015 00:16:59 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439252219.73.0.53478030419.issue24840@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Tue Aug 11 02:18:49 2015
From: report at bugs.python.org (Mike Lundy)
Date: Tue, 11 Aug 2015 00:18:49 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439252329.62.0.385063782287.issue24840@psf.upfronthosting.co.za>


Mike Lundy added the comment:

@r.david.murray man you're fast :) Sorry, realized I forgot to actually run the tests for 3.5 and 3.4, I'd only run them for master (I've now run them for 3.5 and 3.4 now, too).

----------
keywords: +patch
Added file: http://bugs.python.org/file40160/issue24840.master.patch

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

From report at bugs.python.org  Tue Aug 11 02:20:36 2015
From: report at bugs.python.org (Mike Lundy)
Date: Tue, 11 Aug 2015 00:20:36 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439252436.99.0.67074112481.issue24840@psf.upfronthosting.co.za>


Mike Lundy added the comment:

(I should note that I just recently signed the contributor agreement, not that this a particularly complex fix, but it hasn't propagated to my profile yet).

----------

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

From report at bugs.python.org  Tue Aug 11 02:29:01 2015
From: report at bugs.python.org (Vinson Lee)
Date: Tue, 11 Aug 2015 00:29:01 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
Message-ID: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>


New submission from Vinson Lee:

'make test' runs all the network tests.

Some of the tests in test_ssl fail instead of skip if svn.python.org is not accessible.

$ ./python -m test -v -u all test_ssl

======================================================================
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vinson/workspace/cpython-master/Lib/test/test_ssl.py", line 1404, in test_non_blocking_connect_ex
    s.do_handshake()
  File "Lib/ssl.py", line 978, in do_handshake
    self._check_connected()
  File "Lib/ssl.py", line 776, in _check_connected
    self.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

======================================================================
FAIL: test_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_ssl.py", line 1381, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("svn.python.org", 443)))
AssertionError: 0 != 111

======================================================================
FAIL: test_timeout_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_ssl.py", line 1428, in test_timeout_connect_ex
    self.assertIn(rc, (errno.EAGAIN, errno.EWOULDBLOCK))
AssertionError: 111 not found in (11, 11)

----------------------------------------------------------------------
Ran 117 tests in 3.123s

FAILED (failures=2, errors=1, skipped=20)
test test_ssl failed
1 test failed:
    test_ssl

----------
components: Tests
messages: 248382
nosy: vlee
priority: normal
severity: normal
status: open
title: Some test_ssl network tests fail if svn.python.org is not accessible.
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 11 02:29:05 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 00:29:05 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439252945.79.0.868775991244.issue24839@psf.upfronthosting.co.za>


Larry Hastings added the comment:

My Bitbucket repo is now public.

https://bitbucket.org/larry/cpython350

----------

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

From report at bugs.python.org  Tue Aug 11 02:29:18 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 00:29:18 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439252958.83.0.821165626988.issue24492@psf.upfronthosting.co.za>


Larry Hastings added the comment:

My Bitbucket repo is now public.

https://bitbucket.org/larry/cpython350

----------

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

From report at bugs.python.org  Tue Aug 11 02:48:47 2015
From: report at bugs.python.org (Vinson Lee)
Date: Tue, 11 Aug 2015 00:48:47 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1439254127.71.0.385568519563.issue24841@psf.upfronthosting.co.za>


Changes by Vinson Lee <vlee at freedesktop.org>:


----------
versions: +Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Aug 11 05:18:06 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Tue, 11 Aug 2015 03:18:06 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1439263086.53.0.355514242065.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

Here's a patch for the second half of remaining classes (this file is a complement of Ivan Levkivskyi's patch).

----------

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

From report at bugs.python.org  Tue Aug 11 05:19:36 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Tue, 11 Aug 2015 03:19:36 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1439263176.52.0.470933849034.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

Missing Generator.

----------
Added file: http://bugs.python.org/file40161/typying_documentation_part2.patch

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

From report at bugs.python.org  Tue Aug 11 06:03:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Aug 2015 04:03:55 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <20150811040352.31697.59054@psf.io>


Roundup Robot added the comment:

New changeset 7cfe20a6395d by Steve Dower in branch '3.5':
Issue #24839: platform._syscmd_ver raises DeprecationWarning
https://hg.python.org/cpython/rev/7cfe20a6395d

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug 11 06:08:08 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 04:08:08 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439266088.28.0.517899356881.issue24839@psf.upfronthosting.co.za>


Steve Dower added the comment:

PR is at https://bitbucket.org/larry/cpython350/pull-requests/1/issue-24839-platform_syscmd_ver-raises/diff

(For my sanity, your 3.5 branch and the hg.p.o 3.5 branch *are* currently in sync, yes? Any value in adding a 3.5.0 branch for your divergence so we can avoid the need for multiple clones?)

----------

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

From report at bugs.python.org  Tue Aug 11 06:11:22 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 04:11:22 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439266282.51.0.611499193045.issue24839@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 06:17:28 2015
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 11 Aug 2015 04:17:28 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
Message-ID: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>


New submission from Chris Rebert:

There is a cross-reference to namedtuple in SimpleNamespace's docs, but not vice-versa, despite these types being fairly similar.

----------
assignee: docs at python
components: Documentation
messages: 248389
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: Mention SimpleNamespace in namedtuple docs
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 11 06:40:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Aug 2015 04:40:33 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439268033.24.0.421419352099.issue24842@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Tue Aug 11 07:16:59 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Aug 2015 05:16:59 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1439270219.23.0.406366470079.issue24832@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Please keep the doc build compatible with Sphinx 1.2.*. Sphinx 1.3.1 has a problem with LaTeX generation, so we can't upgrade the automated docs build to use it until 1.3.2 is released.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Aug 11 07:41:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Aug 2015 05:41:15 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439271675.0.0.731712062228.issue24840@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks to me as very special case. Enum doesn't delegates the __bool__ method as well as it doesn't delegates __float__, __lt__, __len__, etc. It is left to user to add these methods if needed.

It is easy to add the __bool__ method to user enum. In your case you also can inherit from IntEnum.

>>> class Bool(IntEnum):
...     Yep = True
...     Nope = False
... 
>>> bool(Bool.Yep)
True
>>> bool(Bool.Nope)
False

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Tue Aug 11 08:04:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Aug 2015 06:04:31 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1439273071.36.0.963320980607.issue12892@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two causes:

1. UTF-16 and UTF-32 are based on 2- and 4-bytes units. If the surrogateescape error handler will support UTF-16 and UTF-32, encoding could produce the data that can't be decoded back correctly. For example '\udcac \udcac' -> b'\xac\x20\x00\xac' -> '\u20ac\uac20' == '??'.

2. ASCII bytes (0x00-0x80) can't be escaped with surrogateescape. UTF-16 and UTF-32 data can contain illegal ASCII bytes (b'\xD8\x00' in UTF-16-BE, b'abcd' in UTF-32). For the same reason surrogateescape is not compatible with UTF-7 and CP037.

----------

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

From report at bugs.python.org  Tue Aug 11 08:13:33 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Aug 2015 06:13:33 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439273613.12.0.0778299550824.issue24842@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The NT docs are already very long and I don't think an additional crossref is beneficial (NTs are closer to tuples and SNs are closer to dicts).   Also, the uptake for SNs are nearly zero.

----------

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

From report at bugs.python.org  Tue Aug 11 08:15:25 2015
From: report at bugs.python.org (Mike Lundy)
Date: Tue, 11 Aug 2015 06:15:25 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439273725.42.0.785745227098.issue24840@psf.upfronthosting.co.za>


Mike Lundy added the comment:

@serhiy.storchaka: It's somewhat of a special case, to be sure. However, I do think it's justified to put it into the base (rather than a user type) for three reasons:

1) It makes IntEnum and Enum consistent. IntEnum actually already handles this case just fine, because it's an int and therefore already supports __bool__ correctly. It feels odd that changing the storage format from an IntEnum to a Enum should break the logic- correctly used, the actual enum values should never matter. This small change just brings them into line.

2) It is less surprising than the current case; I discovered this when I did something like the Enum.Nope case here, and I naively used the enum in an if statement, assuming that the value would control the __bool__ value. (This was caught by my tests, of course, but the point remains that I wrote the code). Normally in python, you'd expect the default bool conversion to be unconditionally True, but enums aren't really normal objects; for any use case for which there is a default noop value, you'd generally put that value _into_ the enum:

class FilterType(Enum):
    NONE = None
    SUB  = 'Sub'
    UP   = 'Up'
    ...

3) It's not logically inconsistent with the idea of Enums. The other dunder methods you mention aren't consistent with the concept: __float__ (enum values aren't generally numbers except as an implementation detail), __lt__ (enums aren't generally ordered), __len__ (enums aren't generally containers). The one thing an enum does have is a value, and it feels consistent to me to check the truthiness of an enum without having to reach into the .value to do so.

Anyway, that's my case for inclusion!

----------

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

From report at bugs.python.org  Tue Aug 11 08:35:10 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 11 Aug 2015 06:35:10 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439274910.91.0.269736808315.issue24842@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Also, the uptake for SNs are nearly zero.

That suggests to me that pointing users to it could help. It's currently hidden in the types module and if I didn't know it existed, I could end up looking in collections, and failing to find it there, write my own.

----------
nosy: +scoder

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

From report at bugs.python.org  Tue Aug 11 09:46:43 2015
From: report at bugs.python.org (gladman)
Date: Tue, 11 Aug 2015 07:46:43 +0000
Subject: [issue24843] 2to3 not working
Message-ID: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>


New submission from gladman:

when I try to use the 2to3 script on the command line on Windows x64, I get the response:

  C:\Program Files\Python34\Tools\scripts>2to3 C:\Users\brian\Downloads\puzzles.py
  At least one file or directory argument required.
  Use --help to show usage.

When I ask for help I get:

  C:\Program Files\Python34\Tools\scripts>2to3 --help
  At least one file or directory argument required.
  Use --help to show usage.

In fact this is always the response I obtain irrespective of what I enter after '2to3' on the command line.  Python 3.5rc1 also behaves in the same way.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 248396
nosy: gladman
priority: normal
severity: normal
status: open
title: 2to3 not working
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 11 10:01:04 2015
From: report at bugs.python.org (gladman)
Date: Tue, 11 Aug 2015 08:01:04 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439280064.03.0.280245669443.issue24843@psf.upfronthosting.co.za>


gladman added the comment:

I have now got it working using the command line:

C:\Program Files\Python35\Tools\scripts>"C:\Program Files\Python34\python" 2to3.py --help

I am not sure why the default Windows invocation of Python doesn't work with 2to3 as this works fine with other python scripts that I have tried.

----------

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

From report at bugs.python.org  Tue Aug 11 12:18:44 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 11 Aug 2015 10:18:44 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439288324.6.0.562940327451.issue24843@psf.upfronthosting.co.za>


eryksun added the comment:

Your .py file association isn't configured to pass command-line arguments. Revert to using the "Python.File" type that was created by Python's installer. The associated command should be something like 

    "C:\Windows\py.exe" "%1" %*

depending on where py.exe is located.

----------
components: +Windows -2to3 (2.x to 3.x conversion tool)
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Tue Aug 11 12:21:42 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 11 Aug 2015 10:21:42 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439288502.57.0.445470972915.issue9232@psf.upfronthosting.co.za>


Adam Barto? added the comment:

Some remarks:

? A trailing comma after a non-empty argument list is allowed in every call form, including class statement and optional call in decorator syntax. In the grammar, this correponds to `arglist`.

? In function definition, trailing comma is allowed only if there is no star before:
def f(a, b, c,): # allowed
def f(a=1, b=2, c=3,): # allowed
def f(*args,): # disallowed
def f(**kwargs,): # disallowed
def f(*, a, b, c,): # disallowed
The last example is what bothers me. The presence of the star should not affect whether trailing comma is allowed or not. If `f(a, b, c,)` is allowed as a call, it should be allowed in a definition, and if def `f(a, b, c,)` is allowed, `f(*, a, b, c,)` should be allowed as well.

In the grammar this corresponds to `typedargslist` for functions and `varargslist` for lambdas.

? A traling comma is allowed in tuples, lists, dicts, sets, the corresponding comprehensions, augmented assignments, and subscripts. It is also allowed in `from module import names` in the names part, but only if there are surrounding parentheses. Also a trailing semicolon is allowed for multiple statements in one line.

? A traling comma is *not* allowed in with statement, `import modules`, assert statement (there is just optional second argument), global and nonlocal statements. In all these cases surrounding parentheses are not allowed.

----------

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

From report at bugs.python.org  Tue Aug 11 12:49:01 2015
From: report at bugs.python.org (gladman)
Date: Tue, 11 Aug 2015 10:49:01 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439290141.57.0.996658562082.issue24843@psf.upfronthosting.co.za>


gladman added the comment:

Thanks for the explanation. My apologies for this posting, which I will now close

----------
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 12:54:30 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 10:54:30 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439290470.27.0.466502228815.issue24839@psf.upfronthosting.co.za>


Larry Hastings added the comment:

They are currently in sync, yes.  The 3.5 branch has been a ghost town the last day or two, which tbh has been pleasant for me.helpfu

----------

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

From report at bugs.python.org  Tue Aug 11 13:04:17 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 11:04:17 +0000
Subject: [issue24839] platform._syscmd_ver raises DeprecationWarning
In-Reply-To: <1439230543.98.0.21493600703.issue24839@psf.upfronthosting.co.za>
Message-ID: <1439291057.04.0.437597048049.issue24839@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Merged.  Please forward-port to 3.5.1 and 3.6.  Thanks!

(See?  Already I can tell this rc-cycle is going to be way easier on me than 3.4 was.)

----------

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

From report at bugs.python.org  Tue Aug 11 13:13:29 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 11:13:29 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439291609.06.0.679669361697.issue24769@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Uh, Nick?  You didn't add me to this bug.

----------
nosy: +larry

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

From report at bugs.python.org  Tue Aug 11 13:28:28 2015
From: report at bugs.python.org (tmp12342)
Date: Tue, 11 Aug 2015 11:28:28 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1439292508.02.0.41876431185.issue12892@psf.upfronthosting.co.za>


tmp12342 added the comment:

Serhiy, I understand the first reason, but https://docs.python.org/3/library/codecs.html says
> applicable to text encodings:
> [...]
> This code will then be turned back into the same byte when the 'surrogateescape' error handler is used when encoding the data.
Shouldn't it be corrected? Text encoding is defined as "A codec which encodes Unicode strings to bytes."


And about second one, could you explain a bit more? I mean, I don't know how to interpret it.

You say b'\xD8\x00' are invalid ASCII bytes, but from these two only 0xD8 is invalid. Also, we are talking about encoding here, str -> bytes, so who cares are resulting bytes ASCII compatible or not?

----------
nosy: +tmp12342

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

From report at bugs.python.org  Tue Aug 11 15:04:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 13:04:53 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439298293.88.0.989670077241.issue24843@psf.upfronthosting.co.za>


Steve Dower added the comment:

If this occurs in 3.5 then it needs to be fixed (though I thought I'd already fixed it once...).

I'll take a look.

----------
assignee:  -> steve.dower
status: closed -> open
versions: +Python 3.5, Python 3.6 -Python 3.4

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

From report at bugs.python.org  Tue Aug 11 15:59:30 2015
From: report at bugs.python.org (gladman)
Date: Tue, 11 Aug 2015 13:59:30 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439301570.61.0.13811505162.issue24843@psf.upfronthosting.co.za>


gladman added the comment:

Hi Steve,

The behaviour I reported was the same on Python 3.4 and 3.5rc1.  But eryksun was correct in suggesting that this was a problem in the way my file association for Python was set up. My py_auto_file association was set to: 

"C:\Program Files\Python34\python.exe" "%1"

adding %* on the end fixed the problem.
 
(by the way, thank you for your work on _msvccompiler.py).

   best regards,

     Brian

----------

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

From report at bugs.python.org  Tue Aug 11 16:51:22 2015
From: report at bugs.python.org (Chris Hogan)
Date: Tue, 11 Aug 2015 14:51:22 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439304682.58.0.314917378169.issue21167@psf.upfronthosting.co.za>


Chris Hogan added the comment:

Producing NaN by Py_HUGE_VAL / Py_HUGE_VAL as in the suggested patch is unsafe as it can generate a FP exception during runtime. Also aggresive compiler FP optimizations can eliminate this calculation on compile-time. For this reason, we've used constant referencing in our fix, which will work regardless of how -fp-model is set.

The problem is that the compiler is free to pre-compute the result as both values in 0*Inf are constants. An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is. So under aggressive floating point optimizations setting we could get a wrong value, and that is indeed what happens. 

Another problem is that 0 * Inf along with resulting in a QNaN value should raise an invalid floating point exception flag. If the result is pre-computed at compile time, then the user won?t see the flag (it is another question whether the user wanted the flag or not originally).

Our patch preserves both the value and the side effect, and leaves people free to build with the flags they want.

----------
nosy: +christopher.hogan
Added file: http://bugs.python.org/file40162/intel-nan-safe.patch

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

From report at bugs.python.org  Tue Aug 11 16:59:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2015 14:59:13 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439305153.85.0.982672208167.issue24840@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that it seems odd that testing a 'value' that is false for its truth value would return True.  It is surprising, even if it is an edge case.

----------

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

From report at bugs.python.org  Tue Aug 11 17:02:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2015 15:02:30 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439305350.77.0.914265775233.issue24842@psf.upfronthosting.co.za>


R. David Murray added the comment:

I use SimpleNamespace in just about every project I'm currently working on.  I would *not* say that their uptake is "nearly zero" :)

And yes, I wouldn't be aware of it if I hadn't been following python-dev when it was introduced, and had (before it was introduced) written my own variations numerous times.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Aug 11 17:17:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2015 15:17:06 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439306226.55.0.101749033408.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that Chris' patch is coming from Intel.  (The ICC buildbots are currently building with -fp-model strict, by the way.)

Mark, Stefan, what do you think?  Is this a good idea?  IIUC we would then not have to worry about differentiating between the python build and the distutils flags, and users would get whatever they specified at python build time.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Aug 11 17:22:43 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Aug 2015 15:22:43 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439306563.76.0.994929287701.issue9232@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm +1 on adding this. I don't believe it requires a PEP. A trailing comma in definitions is already supported in some places, so I don't buy the argument that it catches errors. During the moratorium we were perhaps too strict.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Aug 11 18:23:02 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 11 Aug 2015 16:23:02 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1439310182.64.0.482558082619.issue24798@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

This change broke all my builds that link statically against 3rd party libraries built with the `/MD` flag. `/MD` was used at least since Python 2.3 and is the default for static libraries in Visual Studio 2015. Some of the broken builds: lxml, pillow, matplotlib, pygame, pycuda, pymssql, netcdf4, GDAL, psycopg2, pycurl, gmpy, and pyopenssl. All of these packages built OK with Python 3.5.0b4.

The build errors are of this kind: 
`error LNK2001: unresolved external symbol __imp_memchr`
`error LNK2001: unresolved external symbol __imp_strstr`

The linker throws the following warning:
`LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library`

----------
nosy: +cgohlke

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

From report at bugs.python.org  Tue Aug 11 18:36:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2015 16:36:50 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1439311010.69.0.292570820084.issue24798@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please open a new issue, referencing this one.  Priority should be set to release blocker.  (I forget if regular users can do that; if you can't I will.)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Aug 11 19:03:58 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 11 Aug 2015 17:03:58 +0000
Subject: [issue24760] IDLE settings dialog shouldn't be modal
In-Reply-To: <1438297628.71.0.179622085434.issue24760@psf.upfronthosting.co.za>
Message-ID: <1439312638.62.0.891342578053.issue24760@psf.upfronthosting.co.za>


Mark Roseman added the comment:

The attached demodalize.patch (which includes the changes from the previously posted decouple_config.patch) changes both the settings dialog and the about dialog to be non-modal.

There's a new class UIFactory which is responsible for launching these kinds of windows, keeping track of them, and making sure there's only one of each kind at a time. This is also where the logic for choosing ttk vs. non-ttk components will go.

As a (questionable) bonus, the about dialog, which now incorporates the README's etc directly into the window rather than launching further modal dialogs, also has some other minor cosmetic changes.

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file40163/demodalize.patch

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

From report at bugs.python.org  Tue Aug 11 19:06:44 2015
From: report at bugs.python.org (David Beazley)
Date: Tue, 11 Aug 2015 17:06:44 +0000
Subject: [issue24844] Python 3.5rc1 compilation error on OS X 10.8
Message-ID: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>


New submission from David Beazley:

Just a note that Python-3.5.0rc1 fails to compile on Mac OS X 10.8.5 with the following compiler:

bash$ clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
bash$ 

Here is the resulting compilation error:

/usr/bin/clang -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c
fatal error: error in backend: Cannot select: 0x102725710: i8,ch =
      AtomicSwap 0x102c45ce0, 0x102725010, 0x102725510<Volatile
      ST1[@gil_drop_request.0.b]> [ID=7]
  0x102725010: i64 = X86ISD::WrapperRIP 0x102723710 [ID=6]
    0x102723710: i64 = TargetGlobalAddress<i1* @gil_drop_request.0.b> 0 [ID=4]
  0x102725510: i8 = Constant<1> [ID=2]
In function: take_gil
make: *** [Python/ceval.o] Error 1

Problem can be fixed by commenting out the following line in pyconfig.h

/* Has builtin atomics */
// #define HAVE_BUILTIN_ATOMIC 1   


Not really sure what to advise.  To my eyes, it looks like a bug in clang or Xcode.  So, maybe this is more just an FYI that source builds might fail on certain older Mac systems.

----------
messages: 248415
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Python 3.5rc1 compilation error on OS X 10.8
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 11 19:12:07 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Aug 2015 17:12:07 +0000
Subject: [issue24844] Python 3.5rc1 compilation error on OS X 10.8
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1439313127.89.0.637297605057.issue24844@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +benjamin.peterson, ned.deily, yselivanov
priority: normal -> release blocker

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

From report at bugs.python.org  Tue Aug 11 19:48:47 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 17:48:47 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439315327.65.0.102051065803.issue24843@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yes, I see. Thanks for clarifying, it seems all the installers are fine but Windows will generate associations that don't forward arguments.

----------
assignee: steve.dower -> 
resolution:  -> not a bug
status: open -> closed
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 11 19:56:52 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 11 Aug 2015 17:56:52 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439315812.92.0.832965646535.issue24843@psf.upfronthosting.co.za>


eryksun added the comment:

> My py_auto_file association

Oh, it's that auto filetype again. Steve, when you say you fixed this for 3.5, does that means there's a simple command or API to revert this automatic ProgId back to the Python.File type? This problem shows up repeatedly on Stack Overflow, so it would be nice to have a solution that works consistently from Windows 7 to 10. 

cmd.exe's built-in assoc and ftype commands only modify the local machine association and filetype. A per-user install doesn't use those, and sometimes Explorer instead uses a per-executable command defined in Software\Classes\Applications. Also, just modifying the command doesn't actually select what ShellExecuteEx will choose to run. I used to directly modify Explorer's FileExts\...\UserChoice for a given file extension, but that's actively discouraged by a deny ACL nowadays. Fine, but I've run into cases where Explorer's dialog doesn't let me choose a an existing ProgId.

----------
assignee:  -> steve.dower
resolution: not a bug -> 
status: closed -> open
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 11 19:58:49 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 11 Aug 2015 17:58:49 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439315929.53.0.477291138331.issue24843@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 19:59:27 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 11 Aug 2015 17:59:27 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439315967.86.0.362372720922.issue24843@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
versions: +Python 3.4 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 11 20:09:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 18:09:19 +0000
Subject: [issue24843] 2to3 not working
In-Reply-To: <1439279203.37.0.380376183604.issue24843@psf.upfronthosting.co.za>
Message-ID: <1439316559.22.0.0282162227433.issue24843@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm afraid there's no easy way to revert it. I may get to invest the time for 3.6's launcher[1] to make it available in Default Programs, but I've always struggled to get that to work properly.

Explorer should always use the per-user command if it's there, and it's basically the responsibility of users to not change it if they don't want it to change.

[1] The launcher owns the shortcut, not the core Python installation - the separation is only important to users in that if you don't include the launcher you don't get the association, and if you install the launcher for all users then the shortcut is for all users.

(Also cleared the Versions field, since Python 3.4 creates the correct association too. Preventing user customization on a user's machine is not something we're going to get into, but that's the only way to "solve" this problem.)

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Tue Aug 11 20:14:39 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 18:14:39 +0000
Subject: [issue24640] no ensurepip in embedded Windows distribution
In-Reply-To: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za>
Message-ID: <1439316879.37.0.417432830699.issue24640@psf.upfronthosting.co.za>


Steve Dower added the comment:

Updated the documentation and it should be in 3.5.0rc1's docs on using with Windows.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 20:15:27 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 18:15:27 +0000
Subject: [issue23626] Windows per-user install of 3.5a2 doesn't associate .py
 files with the new launcher
In-Reply-To: <1425994717.16.0.260924440644.issue23626@psf.upfronthosting.co.za>
Message-ID: <1439316927.59.0.144673514792.issue23626@psf.upfronthosting.co.za>


Steve Dower added the comment:

I haven't seen this at all, so until we see a repro of it, I'm closing.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 20:16:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 18:16:32 +0000
Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi
 release) contains 64-bit objects
In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za>
Message-ID: <1439316992.75.0.715782114372.issue24385@psf.upfronthosting.co.za>


Steve Dower added the comment:

Doesn't seem to be anything left to do here, so closing as fixed.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 20:24:49 2015
From: report at bugs.python.org (Ilia Kurenkov)
Date: Tue, 11 Aug 2015 18:24:49 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1439317489.35.0.114705360162.issue20362@psf.upfronthosting.co.za>


Ilia Kurenkov added the comment:

Bump :)

Let's close this one, guys!

----------

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

From report at bugs.python.org  Tue Aug 11 20:48:32 2015
From: report at bugs.python.org (William Scullin)
Date: Tue, 11 Aug 2015 18:48:32 +0000
Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to
 plat-$(PLATFORM_TRIPLET)
In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za>
Message-ID: <1439318912.26.0.68451086299.issue23968@psf.upfronthosting.co.za>


William Scullin added the comment:

This would likely improve life for folks with cross-compile toolchains.

----------
nosy: +wscullin

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

From report at bugs.python.org  Tue Aug 11 21:04:06 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Aug 2015 19:04:06 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439319846.65.0.443855085337.issue21167@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Looks fine to me.  IIRC, we moved the PyFloat_FromString implementation away from using Py_NAN in Python 3 for exactly this reason.

On this point, though:

> An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is.

Wouldn't such a compiler be in violation of the C standard, at least if it defines __STDC_IEC_559__?

----------

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

From report at bugs.python.org  Tue Aug 11 22:00:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Aug 2015 20:00:34 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <20150811200016.53418.53374@psf.io>


Roundup Robot added the comment:

New changeset 419ceb531bab by Robert Collins in branch 'default':
Issue #9232: Support trailing commas in function declarations.
https://hg.python.org/cpython/rev/419ceb531bab

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug 11 22:01:47 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 11 Aug 2015 20:01:47 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439323307.57.0.71506925665.issue9232@psf.upfronthosting.co.za>


Robert Collins added the comment:

The patch had some conflicts in the reference docs, I think I resolved it correctly: if someone wanted to cross check my work that would be great. However I was feeling (perhaps wrongly :)) confident so I have committed it as-is.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Aug 11 22:18:19 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 11 Aug 2015 20:18:19 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439324299.08.0.0457811167808.issue9232@psf.upfronthosting.co.za>


Adam Barto? added the comment:

Do we want to allow a trailing comma after *args or **kwargs in a function definition? Unlike in a call, **kwargs is always the last thing in the list and nothing can be added after that. Just asking.

----------

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

From report at bugs.python.org  Tue Aug 11 22:38:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 11 Aug 2015 20:38:01 +0000
Subject: [issue24845] IDLE functional/integration testing
Message-ID: <1439325481.18.0.135721195599.issue24845@psf.upfronthosting.co.za>


New submission from Mark Roseman:

This is a placeholder issue for adding automated functional/integration tests to complement the existing unit tests.

----------
messages: 248428
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE functional/integration testing
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 11 22:38:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 11 Aug 2015 20:38:28 +0000
Subject: [issue24845] IDLE functional/integration testing
In-Reply-To: <1439325481.18.0.135721195599.issue24845@psf.upfronthosting.co.za>
Message-ID: <1439325508.27.0.158105501676.issue24845@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
components: +IDLE
keywords: +patch
Added file: http://bugs.python.org/file40164/functionaltests.patch

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

From report at bugs.python.org  Tue Aug 11 22:42:29 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 11 Aug 2015 20:42:29 +0000
Subject: [issue24845] IDLE functional/integration testing
In-Reply-To: <1439325481.18.0.135721195599.issue24845@psf.upfronthosting.co.za>
Message-ID: <1439325749.66.0.0286863627656.issue24845@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I've attached functionaltests.patch which provides a starting point, using Tk introspection and event generation to exercise the running application. The heart of it is the (very much in progress) TkTestCase class which provides a bunch of Tkinter-specific utilities to be used for tests.

One thing I'm not sure about is that because these run somewhat slower than the existing unit tests, should they be shut off by default if someone is running a repository-wide test?

----------
Added file: http://bugs.python.org/file40165/functionaltests.patch

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

From report at bugs.python.org  Tue Aug 11 23:44:03 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 21:44:03 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439329443.8.0.801043314878.issue9232@psf.upfronthosting.co.za>


Larry Hastings added the comment:

With PEP 448, we can now have

    fronkulate(**kwargs, **kwargs2)

----------

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

From report at bugs.python.org  Tue Aug 11 23:48:07 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Aug 2015 21:48:07 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1439329687.63.0.8786618461.issue24844@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is a regression from previous releases of Python.  It was introduced by fbe87fb071a6 (for Issue22038) which added the use of C built-in functions for atomic memory access for additional architectures like x86_64.  It seems that the relatively early version of Apple's clang included with Xcode 4 fails compiling this code.  The specific clang version that failed ("Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)") is the version included with the last shipped version of Xcode 4, Xcode 4.6.3, for OS X 10.7 and 10.8.  For OS X 10.8, there is available a more recent version of Xcode, Xcode 5.1.1, which includes a new version of clang, "Apple LLVM 5.1 (clang-503.0.40)", which does correctly compile this code.  In general, we always recommend using the most recent available version of Xcode- or Command Line Tools-installed build tools for a particular version of OS X (with the notable exception of OS X 10.6 - stick with Xcode 3.2.6 there).  So upgrading to Xcode 5.1.1 on OS X 10.8.5 should solve the problem there.  Unfortunately, for OS X 10.7.x, Xcode 4.6.3 is the most recent version and Xcode 4 has always been somewhat problematic for Python builds.  It was in Xcode 4 that Apple stopped shipping the "native" gcc-4.2 compiler in favor of clang and the hybrid Apple llvm-gcc-4.2 compiler (which uses gcc as the front end and LLVM as the backend).  The llvm-gcc-4.2 compiler was a transitional tool, not well-maintained, and is known to incorrectly compile recent versions of Python 3 (Issue13241) so it cannot be used as a substitute for clang in this case on OS X 10.7 (it was no longer shipped as of Xcode 5).

Support for OS X 10.8 is much more important than OS X 10.7: I doubt there are *that* many users are still on 10.7.  So I think a case could be made for marking this as "won't fix".  On the other hand, it should be possible to add tests to ./configure to skip trying to use the atomic builtins when this compiler is in use.

----------
nosy: +haypo, larry
title: Python 3.5rc1 compilation error on OS X 10.8 -> Python 3.5rc1 compilation error with Apple clang 4.2 included with Xcode 4

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

From report at bugs.python.org  Tue Aug 11 23:49:14 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Aug 2015 21:49:14 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1439329754.4.0.105476636286.issue24844@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I'd need to see the patch to be certain, but yes my assumption is I'd accept a pull request for this.

----------

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

From report at bugs.python.org  Wed Aug 12 01:25:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 11 Aug 2015 23:25:14 +0000
Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010
In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>
Message-ID: <1439335514.15.0.148552041078.issue16296@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I think this can now be closed as "out of date".

----------

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

From report at bugs.python.org  Wed Aug 12 01:38:02 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Aug 2015 23:38:02 +0000
Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010
In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>
Message-ID: <1439336282.17.0.457531948496.issue16296@psf.upfronthosting.co.za>


Steve Dower added the comment:

It doesn't apply to 3.5 or later, so it's up to Martin whether he wants to apply it for 3.4. (I suspect not, but I'm not about to preempt his call.)

----------
versions:  -Python 3.5

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

From report at bugs.python.org  Wed Aug 12 03:09:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Aug 2015 01:09:47 +0000
Subject: [issue24846] Add tests for ``from ... import ...` code
Message-ID: <1439341787.78.0.664651085427.issue24846@psf.upfronthosting.co.za>


New submission from Brett Cannon:

issue24492 showed that we need some more tests for ceval regarding ``from ... import ...`` code.

----------
components: Interpreter Core
messages: 248435
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add tests for ``from ... import ...` code
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 12 03:10:00 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Aug 2015 01:10:00 +0000
Subject: [issue24846] Add tests for ``from ... import ...` code
In-Reply-To: <1439341787.78.0.664651085427.issue24846@psf.upfronthosting.co.za>
Message-ID: <1439341800.35.0.263691510492.issue24846@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +using custom objects as modules: AttributeErrors new in 3.5

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

From report at bugs.python.org  Wed Aug 12 03:10:12 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Aug 2015 01:10:12 +0000
Subject: [issue24846] Add tests for ``from ... import ...` code
In-Reply-To: <1439341787.78.0.664651085427.issue24846@psf.upfronthosting.co.za>
Message-ID: <1439341812.41.0.62246396744.issue24846@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +arigo

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

From report at bugs.python.org  Wed Aug 12 03:10:28 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Aug 2015 01:10:28 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439341828.36.0.29128421517.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Created https://bitbucket.org/larry/cpython350/pull-requests/2/issue-24492-make-sure-that-from-import/diff without the PyUnicode_FromFormat() change as I realized that was conflating two changes in one patch and it wasn't even being tested (verified all tests still pass and a quick check in the interpreter shows ImportError is still raised).

Larry, let me know when you have accepted the PR and I will commit to 3.5 and default on hg.python.org.

I also created http://bugs.python.org/issue24846 to track adding more tests for the code.

----------
assignee: brett.cannon -> larry

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

From report at bugs.python.org  Wed Aug 12 03:14:33 2015
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 12 Aug 2015 01:14:33 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
Message-ID: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>


New submission from Matthew Barnett:

I'm unable to import tkinter in Python 3.5.0rc1.

The console says:

C:\Python35>python
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Python35\lib\tkinter\__init__.py", line 35, in <module>
     import _tkinter # If this fails your Python may not be configured for Tk
ImportError: DLL load failed: The specified module could not be found.


I'm on Windows 10 Home (64-bit).

----------
components: IDLE
messages: 248437
nosy: mrabarnett, steve.dower
priority: normal
severity: normal
status: open
title: Can't import tkinter in Python 3.5.0rc1
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug 12 03:22:05 2015
From: report at bugs.python.org (Stephen Coulson)
Date: Wed, 12 Aug 2015 01:22:05 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1439342525.53.0.048050668437.issue16041@psf.upfronthosting.co.za>


Stephen Coulson added the comment:

Broke for me today. Hacked the _MAXLINE to get around it.
I don't see any size limit on multi-line in rfc. Only requirement is dot-stuffing. I think this fix might need a rethink.

----------
nosy: +scoulson

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

From report at bugs.python.org  Wed Aug 12 03:22:20 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 01:22:20 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439342540.95.0.258955220037.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yep, this is my fix for the same issue pre-RC1 not quite working out (I'm guessing some difference between my dev box and my build box).

If you go into your DLLs directory there's an extra subdirectory (Microsoft.VC140.CRT or similar) with a single DLL in it. Move that DLL up one level to the DLLs folder and you should be fine.

I'll work up a setup authoring fix immediately, but really I want to patch Tcl/tk to not rely on that DLL so that we can be truly independent of CRT versioning.

----------
assignee:  -> steve.dower
nosy: +larry
priority: normal -> release blocker
versions: +Python 3.6

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

From report at bugs.python.org  Wed Aug 12 03:30:12 2015
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 12 Aug 2015 01:30:12 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439343012.9.0.465633048031.issue24847@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Yes, I can confirm that that works for me.

----------

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

From report at bugs.python.org  Wed Aug 12 03:37:05 2015
From: report at bugs.python.org (William Scullin)
Date: Wed, 12 Aug 2015 01:37:05 +0000
Subject: [issue22699] cross-compilation of Python3.4
In-Reply-To: <1413992946.14.0.956103683321.issue22699@psf.upfronthosting.co.za>
Message-ID: <1439343425.36.0.657725506446.issue22699@psf.upfronthosting.co.za>


William Scullin added the comment:

I thought this was originally a help request and was going to re-direct this. Cross-compile with 3.4.3 and later seems broken.

Procedure followed:

wget https://www.python.org/ftp/python/3.5.0/Python-3.5.0rc1.tgz
tar -xf Python-3.5.0rc1.tgz
mkdir buildpowerpc64-linux-gnu
cd buildpowerpc64-linux-gnu
../Python-3.5.0rc1/configure \
--disable-shared \
--prefix=/local/soft/python/3.5.0rc1/powerpc64-linux-gnu/gcc-4.4.7
make
make install

# now for the actual cross-compile build

cd ..
mkdir buildpowerpc64-bgq-linux
export PYTHON_FOR_BUILD=/local/soft/python/3.5.0rc1/powerpc64-linux-gnu/gcc-4.4.7/bin/python3.5
../Python-3.5.0rc1/configure \
--host=powerpc64-bgq-linux \
--build=powerpc64-linux-gnu \
--disable-ipv6 \
--disable-shared \
ac_cv_pthread_system_supported=yes \
ac_cv_file__dev_ptmx=no \
ac_cv_file__dev_ptc=no \
ac_cv_big_endian_double=yes
make

which succeeds in building a cross-compiled interpreter, then fails to build modules as setup.py gets the srcdir wrong:

[wscullin at vestalac1 buildpowerpc64-bgq-linux]$ make
running build
running build_ext
building '_struct' extension
powerpc64-bgq-linux-gcc -fPIC -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I../Python-3.5.0rc1/Include -I/local/soft/python/3.5.0rc1/powerpc64-linux-gnu
/gcc-4.4.7/include -I. -IInclude -I/usr/local/include -I/local/soft/python/3.5.0rc1/powerpc64-linux-gnu/gcc-4.4.7/include/python3.5m -c _struct.c -o build/temp.linux-ppc64-3.5/_struct.o
powerpc64-bgq-linux-gcc: _struct.c: No such file or directory
powerpc64-bgq-linux-gcc: no input files

----------
components: +Build, Cross-Build
versions: +Python 3.5

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

From report at bugs.python.org  Wed Aug 12 03:51:32 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Aug 2015 01:51:32 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1439344292.28.0.986031163072.issue24840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks for finding that, Mike.

I'll review and merge in the next few days.

----------
assignee:  -> ethan.furman
stage:  -> patch review

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

From report at bugs.python.org  Wed Aug 12 03:53:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Aug 2015 01:53:43 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <20150812015340.31701.2136@psf.io>


Roundup Robot added the comment:

New changeset 3cb97ffd9ddf by Steve Dower in branch '3.5':
Issue #24847: Fixes tcltk installer layout of VC runtime DLL
https://hg.python.org/cpython/rev/3cb97ffd9ddf

New changeset 13ceedb92923 by Steve Dower in branch 'default':
Issue #24847: Fixes tcltk installer layout of VC runtime DLL
https://hg.python.org/cpython/rev/13ceedb92923

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Aug 12 04:01:15 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 02:01:15 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439344875.18.0.641878802703.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Pull request for 3.5.0 is at https://bitbucket.org/larry/cpython350/pull-requests/3/issue-24847-fixes-tcltk-installer-layout/diff. When merged, this can change back to normal priority for the rest of the fix.

Long term (probably 3.5.1, possibly 3.5.0rc2 if I can get it done) I want to build tcl/tk differently so we don't have the dependency on this unstable part of the VC runtime, but deploying it now is the easiest way to keep tcl/tk working.

The biggest risk is that extension authors may plan to depend on it - currently distutils bdist_ext does not use it, but that is already causing compatibility issues with old code (a.k.a. code that needs updating for a newer compiler), so there'll be a bit of wait and see. 

Maybe we'll just have to accumulate all versions of vcruntime*.dll from now until forever (and backport them), but I hope we can avoid that.

----------

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

From report at bugs.python.org  Wed Aug 12 04:02:00 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 12 Aug 2015 02:02:00 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439344920.2.0.946707982191.issue24847@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I trust you, Steve, but I still want to see it get a review before I pull it.  Can you find someone qualified to review the change?

----------

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

From report at bugs.python.org  Wed Aug 12 04:25:29 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 02:25:29 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439346329.85.0.0351698596159.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Zach has the best chance of being able to review, if only because he can probably build the installer. I've added all the Windows experts just in case. There's quite a bit of MSBuild magic involved here though - I have trouble getting good reviews of this kind of change at work :(

For whoever is looking - the InstallFiles items are processed by getting all the Included files, stripping SourceBase off the start and replacing it with Source (so a nop in this case) and including that file in the installer. The file is installed into Target (which is actually a directory reference into the installer, but DLLs is as self-explanatory as it seems) plus the relative path from TargetBase to the original filename. In this case, the old TargetBase was too short and so the file was installed with the last directory segment; after the fix the last directory segment is excluded. (Yes, the Source and SourceBase changes aren't really necessary, but changing them to match will avoid unnecessary questions in the future.)

I should really add more documentation about this... Tools/msi/readme.txt has a bit, but not at this level.

----------
nosy: +paul.moore, tim.golden, zach.ware
stage:  -> commit review

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

From report at bugs.python.org  Wed Aug 12 04:39:27 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 12 Aug 2015 02:39:27 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439347167.93.0.350142223123.issue24847@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Works fine for me, also on Windows 10 Home 64 bit.

c:\Python35>python.exe
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter.__file__
'c:\\Python35\\lib\\tkinter\\__init__.py'

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 12 05:18:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 03:18:38 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439349518.06.0.573029698344.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Mark, IIRC you've got VS 2015? Anyone with VS 2015 installed (or the full CRT redistributable) is unaffected because the required file is already in their system path - this includes my build machine, which is why all my tkinter tests passed before pushing the release (currently figuring out a way to avoid this in future without needing extra machines).

This is also why I'm worried about extensions built with non-distutils based tools. Anyone with the compiler has the current version of vcruntime.dll, but users may not (this is the versioning issue - someone might build with vcruntime150.dll which then won't work with vcruntime140.dll, so I'm trying to just block the DLL entirely).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 12 08:38:23 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Aug 2015 06:38:23 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1439361503.84.0.748754004276.issue9232@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

To be explicit, yes, I want to allow trailing comma even after *args or **kwds. And that's what the patch does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Wed Aug 12 09:36:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Aug 2015 07:36:05 +0000
Subject: [issue24848] Warts in UTF-7 error handling
Message-ID: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Trying to implement UTF-7 codec in Python I found some warts in error handling.

1. Non-ASCII bytes.

No errors:
>>> 'a?b'.encode('utf-7')
b'a+IKw-b'
>>> b'a+IKw-b'.decode('utf-7')
'a?b'

Terminating '-' at the end of the string is optional.
>>> b'a+IKw'.decode('utf-7')
'a?'

And sometimes it is optional in the middle of the string (if following char is not used in BASE64).
>>> b'a+IKw;b'.decode('utf-7')
'a?;b'

But if following char is not ASCII, it is accepted as well, and this looks as a bug.
>>> b'a+IKw\xffb'.decode('utf-7')
'a??b'

In all other cases non-ASCII byte causes an error:
>>> b'a\xffb'.decode('utf-7')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode byte 0xff in position 1: unexpected special character
>>> b'a\xffb'.decode('utf-7', 'replace')
'a?b'

2. Ending lone high surrogate.

Lone surrogates are silently accepted by utf-7 codec.

>>> '\ud8e4\U0001d121'.encode('utf-7')
b'+2OTYNN0h-'
>>> '\U0001d121\ud8e4'.encode('utf-7')
b'+2DTdIdjk-'
>>> b'+2OTYNN0h-'.decode('utf-7')
'\ud8e4?'
>>> b'+2OTYNN0h'.decode('utf-7')
'\ud8e4?'
>>> b'+2DTdIdjk-'.decode('utf-7')
'?\ud8e4'

Except at the end of unterminated shift sequence:
>>> b'+2DTdIdjk'.decode('utf-7')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-8: unterminated shift sequence

3. Incorrect shift sequence.

Strange behavior happens when shift sequence ends with wrong bits.
>>> b'a+IKx-b'.decode('utf-7', 'ignore')
'a?b'
>>> b'a+IKx-b'.decode('utf-7', 'replace')
'a??b'
>>> b'a+IKx-b'.decode('utf-7', 'backslashreplace')
'a?\\x2b\\x49\\x4b\\x78\\x2db'

The decoder first decodes as much characters as can, and then pass all shift sequence (including already decoded bytes) to error handler. Not sure this is a bug, but this differs from common behavior of other decoders.

----------
components: Unicode
messages: 248450
nosy: ezio.melotti, haypo, lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Warts in UTF-7 error handling
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24848>
_______________________________________

From report at bugs.python.org  Wed Aug 12 09:43:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Aug 2015 07:43:59 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1439365439.58.0.400849637129.issue22598@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Warts in UTF-7 error handling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22598>
_______________________________________

From report at bugs.python.org  Wed Aug 12 12:47:16 2015
From: report at bugs.python.org (flying sheep)
Date: Wed, 12 Aug 2015 10:47:16 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
Message-ID: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>


New submission from flying sheep:

Things like progressbars want len() to work on iterated objects.

It?s possible to define __len__ for many of the iterables returned by itertools.

some arguments have to be iterated to find the len(): of course we have to check if those are reentrant, and raise a TypeError if they are non-reentrant. (signified by ?(r)??)

for the predicate functions, it?s questionable if we should offer it, since they might take a long time and ?len? is a property-like function that feels like it should return fast.

map(func, iterable) ? len(iterable)

count(), cycle(), repeat()  ? infinty, but because len() returns integers, and there?s only float infinity, that?s impossible

accumulate(iterable)  ?  len(iterable)
chain(*iterables)  ?  sum(len(it) for it in iterables)
chain.from_iterable(iterables)  (r)?  like the above
compress(data, selectors)  (r)?  sum(1 for s in selectors if s)
dropwhile(pred, iterable)  (r)?  for skip, r in enumerate(map(pred, iterable)): if r: return len(iterable) - skip
filterfalse(pred, iterable)  (r)?  sum(1 for r in map(pred, iterable) if r)
groupby(iterable[, keyfunc])  (r)?  no way but to actually execute it all
islice(seq, [start,] stop [, step])  ?  calculatable if len(seq) is possible
starmap(function, iterables)  ?  len(iterables)
takewhile(pred, iterable)  (r)?  for skip, r in enumerate(map(pred, iterable)): if not r: return skip
tee(iterable[, n])  ?  n
zip_longest(*iterables[, fillvalue])  (r)?  max(len(it) for it in iterables)


product(), permutations(), combinations(), combinations_with_replacement()  ?  there?s math for that.

----------
components: Library (Lib)
messages: 248451
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Add __len__ to map, everything in itertools
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 13:21:23 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 12 Aug 2015 11:21:23 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1439378483.16.0.247469046414.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

After struggling to get helpful output from gdb it is looking like it will not be possible due to the lack of debugging symbols in the libs on the android device.

Still investigating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Aug 12 13:38:39 2015
From: report at bugs.python.org (Stian Lode)
Date: Wed, 12 Aug 2015 11:38:39 +0000
Subject: [issue17703] Trashcan mechanism segfault during interpreter
 finalization in Python 2.7.4
In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za>
Message-ID: <1439379519.6.0.578450644623.issue17703@psf.upfronthosting.co.za>


Stian Lode added the comment:

I'm seeing this bug in Python 3.4.2 as well, and the patch here (tstate_trashcan.patch) appears to fix it. I'm using boost 1.57.0, and Python was compiled on a vanilla rhel6 system.

----------
nosy: +Stian Lode, larry
versions: +Python 3.4 -Python 2.7
Added file: http://bugs.python.org/file40166/bt.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17703>
_______________________________________

From report at bugs.python.org  Wed Aug 12 13:44:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 11:44:04 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1439379844.13.0.992807395222.issue16041@psf.upfronthosting.co.za>


R. David Murray added the comment:

It has been, see the referenced issue.  Now we just need someone to write a patch.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Wed Aug 12 13:46:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 11:46:44 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1439380004.08.0.153153601858.issue23906@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that the max message size solution can be applied to the maintenance releases as a fix for this issue by choosing a suitable large default message size.  The 'feature' part is just the part exposing the size limit in the library API...that part is a feature for 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23906>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:11:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 12:11:58 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439381518.34.0.215637547603.issue24849@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, you may not iterate the iterator in order to compute the len, because then the iterator would be exhausted.  In addition, the point of itertools is to *lazily* do operations on iterables of indefinite length, so to offer __len__ if and only if the arguments supported len (for cases where that would work) would be essentially false advertising :)

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:16:45 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 12 Aug 2015 12:16:45 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439381805.05.0.246766437692.issue24849@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Unfortunately, this fails because there is no way to tell how long an arbitrary iterable is, or whether it is reentrant or not. Consider:

def gen():
    while True:
        if random.random() < 0.5:
            return random.random()

Not only is it not reentrant, but you cannot tell in advance how long it will be.

There's also the problem that not all iterables need to have a defined length. The iterator protocol, for example, does not demand that iterators define a length, and we should not put that burden on the programmer.

There's one more serious problem with the idea of giving iterators a length. Consider this case:

it = iter([1, 2, 3, 4, 5])
next(it)
next(it)
print(len(it))

What should be printed? 5, the length of the underlying list, or 3, the number of items still remaining to be seen? Whichever answer you give, it will be misleading and a bug magnet under certain circumstances.

I don't believe it is worth giving iterators like map, zip etc. a length depending on the nature of what they are iterating over. That can only lead to confusion. Programmers just have to understand that sequences have lengths, but arbitrary iterables may not.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 16:18:45 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 12 Aug 2015 14:18:45 +0000
Subject: [issue24846] Add tests for ``from ... import ...` code
In-Reply-To: <1439341787.78.0.664651085427.issue24846@psf.upfronthosting.co.za>
Message-ID: <1439389125.52.0.552401566965.issue24846@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24846>
_______________________________________

From report at bugs.python.org  Wed Aug 12 16:27:23 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Wed, 12 Aug 2015 14:27:23 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1439378483.16.0.247469046414.issue23496@psf.upfronthosting.co.za>
Message-ID: <AB88715B-01B9-4EBC-8223-56A31DA97EC8@gmail.com>


Ryan Gonzalez added the comment:

Doesn't Python still have debug symbols? The system ones don't matter too much.

On August 12, 2015 6:21:23 AM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>After struggling to get helpful output from gdb it is looking like it
>will not be possible due to the lack of debugging symbols in the libs
>on the android device.
>
>Still investigating.
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Aug 12 17:05:26 2015
From: report at bugs.python.org (shiyao.ma)
Date: Wed, 12 Aug 2015 15:05:26 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1439391926.81.0.167019075452.issue23906@psf.upfronthosting.co.za>


shiyao.ma added the comment:

Instead of setting a MAXSIZE for the email body, rasing up the MAXLINE might be more meaningful.


Consider the case of MAXSIZE, it's essentially the same as MAXLINE. If MAXSIZE is relatively small, some messages won't pass through. If the MAXSIZE is relatively large, then what's the meaning of setting it?


Thus, it might be more practical to increase the value of MAXLINE so that 99% messages can pass through.

----------
nosy: +introom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23906>
_______________________________________

From report at bugs.python.org  Wed Aug 12 17:24:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 15:24:20 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1439393060.51.0.166182516225.issue23906@psf.upfronthosting.co.za>


R. David Murray added the comment:

If maxline is too small, messages won't get through.  If maxline is too large *huge* messages will get through...and the DDOS danger of exhausting the server's resources will occur.  So, we really ought to provide a way to limit the maximum message size *anyway*...at which point a separate maxline value doesn't make any sense, since the RFC specifies no maximum line size.

I'm much more comfortable setting a large maximum message size than setting a large enough maximum line size to permit that size of message consisting of mostly a single line.  Since we aren't going to back out the DDOS fix, we have to put the limit *somewhere*.  At least in 3.6 we can make it easy for the application to set it.  (Programs using earlier versions will just have to monkey-patch, unfortunately...which they have to do right now anyway.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23906>
_______________________________________

From report at bugs.python.org  Wed Aug 12 17:48:47 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 12 Aug 2015 15:48:47 +0000
Subject: [issue24039] Idle: some modal dialogs maximize, don't minimize
In-Reply-To: <1429811337.7.0.183903934829.issue24039@psf.upfronthosting.co.za>
Message-ID: <1439394527.43.0.697576097077.issue24039@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24039>
_______________________________________

From report at bugs.python.org  Wed Aug 12 17:49:49 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 12 Aug 2015 15:49:49 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1439394589.76.0.636653404087.issue2053@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
_______________________________________

From report at bugs.python.org  Wed Aug 12 18:22:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 12 Aug 2015 16:22:28 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1439396548.83.0.973196893491.issue9262@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Roger's extension is an amazingly cool hack. With some of the decoupling mentioned in #24826, the actual switching should get easier.

Regarding cosmetics, I wanted to make a suggestion. The tabs provided by ttk::notebook aren't ideally suited for this task, both visually on some platforms (hello Mac) and also because they're designed for a fixed (small) number of tabs.

One of the better implementations of tabs I've seen is in the Mac editor TextMate. I've attached a set of annotated screenshots as tmtabs.png. It's nice and clean. Doing this as a widget based on the Tkinter canvas looks very feasible.

----------
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file40167/tmtabs.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:01:25 2015
From: report at bugs.python.org (Cyril Bouthors)
Date: Wed, 12 Aug 2015 17:01:25 +0000
Subject: [issue24850] syslog.syslog() does not return error when unable to
 send the log
Message-ID: <1439398885.55.0.81268943259.issue24850@psf.upfronthosting.co.za>


New submission from Cyril Bouthors:

Hi guys,

syslog.syslog() does not report any error when it fails to send messages to syslog. To reproduce:

Stop sysglog:

sudo /etc/init.d/rsyslog stop

Run than Python code:

import syslog
syslog.syslog('test')

It does not fail.

Strace shows that's it's been unable to send the message to syslog:

connect(3, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fc899e4a8d0}, {0x55e6b0, [], SA_RESTORER, 0x7fc899e4a8d0}, 8) = 0
brk(0x20ed000)                          = 0x20ed000
exit_group(0)                           = ?
+++ exited with 0 +++

I've tested all those versions:

echo -e "import syslog\nsyslog.syslog('test')\n" | python3.5
echo -e "import syslog\nsyslog.syslog('test')\n" | python3.4
echo -e "import syslog\nsyslog.syslog('test')\n" | python3.3
echo -e "import syslog\nsyslog.syslog('test')\n" | python3.2
echo -e "import syslog\nsyslog.syslog('test')\n" | python2.7
echo -e "import syslog\nsyslog.syslog('test')\n" | python2.6

Can we please get syslog() to report errors?

Thanks.

----------
components: Library (Lib)
messages: 248462
nosy: Cyril Bouthors
priority: normal
severity: normal
status: open
title: syslog.syslog() does not return error when unable to send the log
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24850>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:05:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Aug 2015 17:05:51 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1439399151.83.0.984835944784.issue9262@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A tabbed widget, however implemented, should be a component that can either be in a Toplevel with menu by itself, or added to an application window (#24826).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:08:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Aug 2015 17:08:09 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
In-Reply-To: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>
Message-ID: <1439399289.34.0.386960794597.issue24826@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#9262 is step b) above, and therefore a dependency for this issue.

----------
dependencies: +IDLE: Use tabbed shell and edit windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24826>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:08:32 2015
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 12 Aug 2015 17:08:32 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1439399312.62.0.112891270867.issue9262@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:11:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 17:11:44 +0000
Subject: [issue24850] syslog.syslog() does not return error when unable to
 send the log
In-Reply-To: <1439398885.55.0.81268943259.issue24850@psf.upfronthosting.co.za>
Message-ID: <1439399504.88.0.875503629122.issue24850@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  Normally the way errors are reported in python is via exception.  personally I would not want syslog raising an exception if it couldn't deliver the message.

I suppose we could have it return a status code.  That would be a new feature, though.

----------
nosy: +r.david.murray
type: behavior -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24850>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:30:07 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Aug 2015 17:30:07 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1439400607.77.0.940376797479.issue24745@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I just returned from a trip. I think restoring the status quo is sufficient, so I will likely apply to 2.7 and 3.4 and null merge forward.

Is there anyway to get test run with 8.4 automatically, as least intermittantly, before the rc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24745>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:49:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Aug 2015 17:49:15 +0000
Subject: [issue24826] ability to integrate editor, shell,
 debugger in one window
In-Reply-To: <1438957748.57.0.555891700476.issue24826@psf.upfronthosting.co.za>
Message-ID: <1439401755.59.0.487308655356.issue24826@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#24760 - config dialog not modal, is part of c)

----------
dependencies: +IDLE settings dialog shouldn't be modal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24826>
_______________________________________

From report at bugs.python.org  Wed Aug 12 19:59:30 2015
From: report at bugs.python.org (Tim Peters)
Date: Wed, 12 Aug 2015 17:59:30 +0000
Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported
 (e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1439402370.38.0.224596460706.issue5288@psf.upfronthosting.co.za>


Tim Peters added the comment:

> The only reason for the restriction that
> I can think of is that some text representation
> of datetime only provide 4 digits for timezone.

There never was a compelling reason.  It was simply intended to help catch programming errors for a (at the time) brand new feature, and one where no concrete timezone support was supplied at first.  Lots of people were writing their own tzinfo subclasses, and nobody at the time was, e.g., volunteering to wrap the Olson database.

I'm in favor of removing all restrictions on offsets.  Speed is of minor concern here - if it simplifies the code to delegate all offset arithmetic to classic datetime +/- timedelta operations, fine.

String representations are a mess.  If some popular standard doesn't cater to sub-minute (or sub-second!) offsets, fine, make up a format consistent with what such a standard "would have" defined had it addressed the issue, and document that if a programmer picks a timezone whose offsets go beyond what that standard supports, tough luck.  Then Python will give something sensible Python can live with, but won't try to hide that what they're doing does in fact go beyond what the standard supports.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5288>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:12:32 2015
From: report at bugs.python.org (Chris Hogan)
Date: Wed, 12 Aug 2015 18:12:32 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439403152.18.0.275228617025.issue21167@psf.upfronthosting.co.za>


Chris Hogan added the comment:

>From Clark Nelson:

> In my opinion, exactly how and where the macro is defined that indicates our conformance to the FP standard
> doesn't really matter. The point is that it is our intention to conform, at least to some degree and under 
> some circumstances.
>
> Under those circumstances, it would be wrong to map (0 * x) to 0 without regard to what x might be.
>
> Clark

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:25:45 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Wed, 12 Aug 2015 18:25:45 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1439403945.02.0.141322986341.issue23749@psf.upfronthosting.co.za>


Changes by Alex Gr?nholm <alex.gronholm+python at nextday.fi>:


----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:56:48 2015
From: report at bugs.python.org (Ralf Gommers)
Date: Wed, 12 Aug 2015 18:56:48 +0000
Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010
In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>
Message-ID: <1439405808.74.0.315881631224.issue16296@psf.upfronthosting.co.za>


Ralf Gommers added the comment:

I'll note that in Numpy we have now worked around the issue (with https://github.com/numpy/numpy/pull/4892), basically by monkeypatching distutils and doing:

    if '/MANIFEST' not in ldflags:
        ldflags.append('/MANIFEST')

The bug report is still valid though; it should not be specific to numpy. A more detailed report of what was broken before and fixed by this patch would have been helpful. I cannot be sure that this is 100% correct because I don't have Windows+MSVC available, but it should be this:

- Take Python 3.4 installed from the python.org .exe installer
- Create a new virtualenv and activate it
- pip install numpy==1.8.0   # this will fail
- apply the patch
- pip install numpy==1.8.0   # this will work

Furthermore I think that this is a duplicate of http://bugs.python.org/issue4431, which is also a valid bug report confirmed by multiple people (but closed as "not a bug"). 

Given that applying the patch is harmless and not applying it clearly does create problems for users, it would make sense to apply it. But honestly, given for how long the bug reports on 4431 were ignored, I'm not willing to spend much effort on this. So if no one else does either, this issue may indeed just as well be closed as outdated like Marc Lawrence suggests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16296>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:59:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 18:59:34 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439405974.69.0.602842673254.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Attaching two patches that fix the tcl/tk build to not require vcruntime140.dll at all. This is the better fix, though I haven't yet tested it thoroughly enough to convince myself that it's ready. One patch is for tcl/tk/tix themselves (which I'll submit upstream if accepted) and the other is for our side of the build process. (There'll also be a change to our installer if these go in.)

Presented here for openness, reviews and feedback. Still want to get testing on the existing 3.5.0 change to convince Larry that it's good to go.

----------
keywords: +patch
Added file: http://bugs.python.org/file40168/remove_vc140_ext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:59:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Aug 2015 18:59:42 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439405982.46.0.537291180232.issue24847@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


Added file: http://bugs.python.org/file40169/remove_vc140_py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 12 22:40:48 2015
From: report at bugs.python.org (Paul Murphy)
Date: Wed, 12 Aug 2015 20:40:48 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
Message-ID: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>


New submission from Paul Murphy:

This is a duplicate of Issue 23654, except it occurs on GCC 5.1 with -O2 when building for a ppc64le target.

GCC is optimizes this as a tail call, removing the accesses to the "unused" stack variables.

----------
components: Extension Modules
files: fix_stack_overflow.patch
keywords: patch
messages: 248472
nosy: Paul Murphy
priority: normal
severity: normal
status: open
title: infinite loop in faulthandler._stack_overflow
versions: Python 3.4
Added file: http://bugs.python.org/file40170/fix_stack_overflow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Wed Aug 12 22:46:15 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 12 Aug 2015 20:46:15 +0000
Subject: [issue17703] Trashcan mechanism segfault during interpreter
 finalization in Python 2.7.4
In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za>
Message-ID: <1439412375.9.0.920877589843.issue17703@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can anyone else confirm this bug in 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17703>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:22:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Aug 2015 21:22:43 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1439414563.07.0.124652143678.issue24841@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24841>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:23:26 2015
From: report at bugs.python.org (flying sheep)
Date: Wed, 12 Aug 2015 21:23:26 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439414606.92.0.637422862697.issue24849@psf.upfronthosting.co.za>


flying sheep added the comment:

Hi, and sorry David, but I think you haven?t understood what I was proposing.

Maybe that was too much text and detail to read at once, while skipping the relevant details:

Python has iterators and iterables. iterators are non-reentrant iterables: once they are exhausted, they are useless.

But there are also iterables that create new, iterators whenever iter(iterable) is called (e.g. implicitly in a for loop). They are reentrant. This is why you can loop sequences such as lists more than once.

???????????????????????

One of those reentrant iterables is range(), whose __iter__ functions creates new lazy iterables, which has a __len__, and so on. It even has random access just like a sequence.

Now it?s always entirely possible to *lazily* determine len(chain(range(200), [1,2,5])), which is of course len(range(200)) + len([1,2,5]) = 200 + 3 = 203. No reentrant iterables are necessary here, only iterables with a __len__. (Simply calling len() on them all is sufficient, as it could only create a TypeError which would propagate upwards)

???????????????????????

To reiterate:

1. Lazy doesn?t mean non-reentrant, just like range() demonstrates.
2. I didn?t propose that this works on arbitrary iterables, only that it works if you supply iterables with suitable properties (and throws ValueError otherwise, just like len(some_generator_function()) already does)
3. I know what I?m doing, please trust me and read my proposal carefully ;)

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:31:38 2015
From: report at bugs.python.org (flying sheep)
Date: Wed, 12 Aug 2015 21:31:38 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439415097.99.0.771393095383.issue24849@psf.upfronthosting.co.za>


flying sheep added the comment:

To elaborate more on my second point (?No reentrant iterables are necessary here, only iterables with a __len__?)

What i meant here is that inside a call of chain(*iterables), such as chain(foo, bar, *baz_generator()), the paramter ?iterables? is always a tuple, i.e. a sequence.

So it is always possible to just call len() on each element of ?iterables? and either get a ValueError or a collection of summable integers.

With other itertools functions, we?d need to determine beforehand if we have reentrant iterables or not. This might be a problem, and for some too un-lazy (e.g. groupby)

But at the very very least, we could implement this for everything where i didn?t write ?(r)?: map, accumulate, chain, islice, starmap, tee, product, permutations, combinations, combinations_with_replacement

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:36:09 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 12 Aug 2015 21:36:09 +0000
Subject: [issue21126] Return results from doctest.run_docstring_examples()
In-Reply-To: <1396375944.72.0.495252715824.issue21126@psf.upfronthosting.co.za>
Message-ID: <1439415369.43.0.386380241349.issue21126@psf.upfronthosting.co.za>


Robert Collins added the comment:

So, I think this needs a test; returning a generator would be nice but would be an API break.

Also the doc update needs to say 3.6 now.

Thanks; moving back to patch review.

----------
nosy: +rbcollins
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21126>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:42:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 21:42:08 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439415728.95.0.14781620053.issue24849@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, I guessed that despite saying "some arguments have to be iterated" that you were really talking about arguments that had __len__.  That's why I added the sentence about it not being appropriate even if you only did it when the inputs had __len__.

But I'll let Raymond re-close this.  Who knows, maybe I'll be surprised and it will turn out that he's interested :)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:45:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Aug 2015 21:45:17 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439415917.28.0.786927343637.issue24849@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:56:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 21:56:41 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439416601.47.0.238345332388.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've applied this patch to 2.7 on OSX and compiled without -fp-model strict, and all of the tests now pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:01:50 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 12 Aug 2015 22:01:50 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1439416910.03.0.997267711198.issue18383@psf.upfronthosting.co.za>


Robert Collins added the comment:

@ashkop so append=True could be clearer as 'atend=True' - both forms of call are expected to add the filter, but one adds to the front, one to the end.

Looking at warn_explicit, its takes the first matching filter, and then acts on its action.

So the following:
simplefilter("ignore")
simplefilter("error", append=True)
simplefilter("ignore", append=True)

will ignore all warnings today.

With this patch it will error on all warnings.

So at *best* I think this is a breaking API change.

Old:
>>> from warnings import simplefilter, warn
>>> simplefilter("ignore")
>>> simplefilter("error", append=True)
>>> simplefilter("ignore", append=True)
>>> warn("boo")
>>> 

With this patch:
>>> from warnings import simplefilter, warn
>>> simplefilter("ignore")
>>> simplefilter("error", append=True)
>>> simplefilter("ignore", append=True)
>>> warn("boo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UserWarning: boo
>>> 

Now, perhaps its desirable to make this change. I haven't decided yet about the tastefulness of the new API, but if we do we're going to need docstring updates, and API doc changes to match it.

Since the goal here is to fix module reloads, I think the right way to do that is to only change the module initialisation code.

e.g. add an optional 'no_duplicate' parameter to simplefilter and use that from the module initialisation. Thats backwards compatible and opt-in. If we don't think it should be public, make it a _ prefixed parameter. I think it would be fine to be public though.

----------
nosy: +rbcollins
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:22:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 22:22:39 +0000
Subject: [issue24440] Move the buildslave setup information from the wiki to
 the devguide
In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>
Message-ID: <1439418159.81.0.745771854202.issue24440@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is an updated version of my buildslave patch, incorporating what I've learned in getting the Intel mac buildbot fully functional, and some additions from my review of the issue 13124 patch.

This is ready for final review and commit.  Note that the windows stuff is 'TBD'; hopefully someone who has actually set up a Windows buildslave (Zach?) will fill in those sections, updating the information from http://wiki.python.org/moin/BuildbotOnWindows to modern reality.  But I think we can commit this before making those additions, and deal with that in a separate patch.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file40171/buildslave.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24440>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:34:53 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 12 Aug 2015 22:34:53 +0000
Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to
 the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1439418893.79.0.47224478127.issue24079@psf.upfronthosting.co.za>


Robert Collins added the comment:

So it is downplayed but it is still documented as being application usable.

I'll give this another week for Ned to reply, then commit it in the absence of a reply: I think its ok as is. I'd be ok with a tweaked version along the lines Ned proposed too: both ways are better than whats in tree today.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24079>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:37:10 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 12 Aug 2015 22:37:10 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1439419030.55.0.173794127994.issue23725@psf.upfronthosting.co.za>


Robert Collins added the comment:

Sorry, I didn't realise that Zbigniew was an alternative spelling of your first name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:00:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 23:00:27 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439420427.1.0.217744164575.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Now, what's the equivalent patch for python3?  Should I open a new issue for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:04:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 23:04:27 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439420667.81.0.680030878896.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nevermind, I forgot to try and see if it applied...and it does :)

----------
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:06:12 2015
From: report at bugs.python.org (Carol Willing)
Date: Wed, 12 Aug 2015 23:06:12 +0000
Subject: [issue24440] Move the buildslave setup information from the wiki to
 the devguide
In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>
Message-ID: <1439420772.01.0.292288861822.issue24440@psf.upfronthosting.co.za>


Carol Willing added the comment:

This looks great. Two very minor typos. Overall, the patch renders nicely and can be merged. I agree that it is worth merging with or without windows instructions (which may be added later).

Missing 'd' in email address
+python-builsbots at python.org to discuss adding your buildslave and to obtain the

Missing 'd' in title of section
+Builslave operation

Thanks David!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24440>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:12:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Aug 2015 23:12:34 +0000
Subject: [issue24440] Move the buildslave setup information from the wiki to
 the devguide
In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>
Message-ID: <1439421154.86.0.831606948923.issue24440@psf.upfronthosting.co.za>


R. David Murray added the comment:

Drat, I keep forgetting to put issue numbers in devguide commits :(.

Changeset id is 7368a61d28de.

Thanks for the review, Carol.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24440>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:13:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 12 Aug 2015 23:13:01 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1439421181.17.0.149429813824.issue24570@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I did some followup on this today, and could reproduce it with a few lines of Tcl/Tk code. As Ned noted, it seems particular to the ActiveTcl build, as when I built my own 8.5.18 it also worked fine.

(If you're curious, the thing that is failing is the MacWindowStyle call to set the window to type "help". If you use that, the window just doesn't show up. Oddly, other types, e.g. "utility" work properly).

I tried various introspection techniques to see if I could detect that this problem had occurred from code, but no luck. As far as Tk was concerned, the window was there.

Will send a message to tcl-core list regarding this. For reference, Tcl script to reproduce is:

wm geometry . +32+32
toplevel .t
wm geometry .t +60+60
tk::unsupported::MacWindowStyle style .t help "noActivates"
grid [label .t.l -bg yellow -text "tooltip window"]

----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:22:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Aug 2015 23:22:45 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439329754.4.0.105476636286.issue24844@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYiRCixBvyfCOzKXj53sL5ro-kmm5Ynn4Z5+69rwfV2aw@mail.gmail.com>


STINNER Victor added the comment:

You can try to add an ifdef in Include/pyatomic.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24844>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:38:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Aug 2015 23:38:58 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <20150812233854.53414.70879@psf.io>


Roundup Robot added the comment:

New changeset 51d00482d403 by Robert Collins in branch '3.5':
Issue #23725: Overhaul tempfile docs.
https://hg.python.org/cpython/rev/51d00482d403

New changeset 256d2f01e975 by Robert Collins in branch 'default':
Issue #23725: Overhaul tempfile docs.
https://hg.python.org/cpython/rev/256d2f01e975

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:41:21 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 12 Aug 2015 23:41:21 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1439422881.28.0.613875882426.issue23725@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch. I've committed the current status as an unambiguous improvement; we can add tempdir as deprecated later if there is consensus on that, the current patch did improve its docs per R. David Murray's request anyhow.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Thu Aug 13 02:20:34 2015
From: report at bugs.python.org (John Hagen)
Date: Thu, 13 Aug 2015 00:20:34 +0000
Subject: [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
Message-ID: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>


New submission from John Hagen:

https://docs.python.org/3.5/howto/webservers.html#setting-up-fastcgi

The "HOWTO Use Python in the web" documentation for 3.5.0rc1 prescribes to use flup in its example, which is not compatible with Python 3.

This has led to some confusion: https://stackoverflow.com/questions/23482357/fastcgi-wsgi-library-in-python-3

Perhaps the whole article could be given a once over to ensure it is still the best advice as of 2015.

----------
assignee: docs at python
components: Documentation
messages: 248491
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24852>
_______________________________________

From report at bugs.python.org  Thu Aug 13 02:47:10 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 13 Aug 2015 00:47:10 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439414606.92.0.637422862697.issue24849@psf.upfronthosting.co.za>
Message-ID: <20150813004658.GI5249@ando.pearwood.info>


Steven D'Aprano added the comment:

On Wed, Aug 12, 2015 at 09:23:26PM +0000, flying sheep wrote:

> Python has iterators and iterables. iterators are non-reentrant 
> iterables: once they are exhausted, they are useless.

Correct.

> But there are also iterables that create new, iterators whenever 
> iter(iterable) is called (e.g. implicitly in a for loop). They are 
> reentrant. This is why you can loop sequences such as lists more than 
> once.

The *iterable* itself may be reentrant, but the iterator formed from 
iter(iterable) is not. So by your previous comment, giving the iterator 
form a length is not appropriate.

Do you know of any non-iterator iterables which do not have a length 
when they could? With the exception of tee, all the functions in 
itertools return iterators.

> One of those reentrant iterables is range(), whose __iter__ functions 
> creates new lazy iterables, which has a __len__, and so on. It even 
> has random access just like a sequence.

You are misinterpreting what you are seeing. range objects already 
are sequences with a length, and nothing needs be done with them. But 
iter(range) are not sequences, they are iterators, and then are not 
sized and have no __len__ method:

py> it = iter(range(10))
py> len(it)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'range_iterator' has no len()

If range_iterator objects were given a length, what would it be? Should 
it be the length of the underlying range object, which is easy to 
calculate but wrong? That's what you suggest below (your comments about 
chain). Or the length of how many items are yet to be seen, which is 
surprising in other ways?

> Now it?s always entirely possible to *lazily* determine 
> len(chain(range(200), [1,2,5])), 

Sure. But chain doesn't just accept range objects and lists as 
arguments, it accepts *arbitrary iterables* which you accept cannot be 
sized. So len(chain_obj) *may or may not* raise TypeError. Since you 
can't rely on it having a length, you have to program as if it doesn't. 
So in practice, I believe this will just add complication.

> which is of course len(range(200)) + 
> len([1,2,5]) = 200 + 3 = 203. No reentrant iterables are necessary 
> here, only iterables with a __len__. (Simply calling len() on them all 
> is sufficient, as it could only create a TypeError which would 
> propagate upwards)

That would be wrong. Consider:

it = chain("ab", "cd")
throw_away = next(it)
assert len(it) == 2 + 2  # call len() on the sequences
assert len(list(it)) == len(it)  # fails since 3 != 4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Thu Aug 13 03:29:43 2015
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 13 Aug 2015 01:29:43 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1439429383.85.0.865881016973.issue24570@psf.upfronthosting.co.za>


Kevin Walzer added the comment:

I experimented with Mark's sample code (thanks for that, BTW), and found that the window with the "help" tag applied would display with this simple addition:

raise .t

I believe the equivalent call in Tinter is lift(), because raise() is for error handling? Perhaps someone can experiment with appropriate calls to lift() in the relevant sections of IDLE. 

The "help" style is excluded from becoming a frontmost window by default in OS X. Here is the relevant code in tkMacOSXWm.c:

- (BOOL) canBecomeKeyWindow
{
    TkWindow *winPtr = TkMacOSXGetTkWindow(self);

    return (winPtr && winPtr->wmInfoPtr && (winPtr->wmInfoPtr->macClass ==
	    kHelpWindowClass || winPtr->wmInfoPtr->attributes &
	    kWindowNoActivatesAttribute)) ? NO : YES;
}


Therefore, an explicit call to raise may be helpful in displaying the window.

I realize that such calls are not present in the current IDLE code, and did not seem to be required previously--there likely was some change in recent Tk-Cocoa commits in event loop handling, memory management, window display, and drawing that caused this new bug to crop up. Tracking the actual source of the bug at the C level is likely to prove very difficult because there have been so many changes. However, since the fix at the script level is trivial, I do not think a major effort is necessary to step through the code at the C level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

From report at bugs.python.org  Thu Aug 13 03:36:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Aug 2015 01:36:51 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1439429811.97.0.389280231225.issue24570@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, *raise* is a keyword and .lift() is the substitute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

From report at bugs.python.org  Thu Aug 13 04:10:34 2015
From: report at bugs.python.org (Alex Budovski)
Date: Thu, 13 Aug 2015 02:10:34 +0000
Subject: [issue24853] Py_Finalize doesn't clean up PyImport_Inittab
Message-ID: <1439431834.18.0.462174995045.issue24853@psf.upfronthosting.co.za>


New submission from Alex Budovski:

This means initialize/run script/finalize will crash the second time, since the inittab can have stale entries.

----------
messages: 248495
nosy: Alex Budovski
priority: normal
severity: normal
status: open
title: Py_Finalize doesn't clean up PyImport_Inittab
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24853>
_______________________________________

From report at bugs.python.org  Thu Aug 13 04:24:15 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 13 Aug 2015 02:24:15 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439432655.01.0.263031731258.issue24851@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Thu Aug 13 06:29:49 2015
From: report at bugs.python.org (raylu)
Date: Thu, 13 Aug 2015 04:29:49 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1439440189.32.0.00415020206957.issue3244@psf.upfronthosting.co.za>


Changes by raylu <lurayl at gmail.com>:


----------
nosy: +raylu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Thu Aug 13 06:44:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Aug 2015 04:44:20 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439441060.69.0.0658932411384.issue24849@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I had explored this idea previously at some length (no pun intended) but it was mostly a dead-end.  The best we ended-up with has having __length_hint__ to indicate size to list().   

There were several issues some of which at detailed in the comment at the top of https://hg.python.org/cpython/file/tip/Lib/test/test_iterlen.py .  Another *big* issue was that Guido was adamantly opposed to iterators having a length because it changed their boolean value from always-true and it broke some of his published code that depended on iterators never being false, even when empty.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Thu Aug 13 07:09:18 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 13 Aug 2015 05:09:18 +0000
Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4
In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za>
Message-ID: <1439442558.66.0.670630548136.issue15601@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Terry Reedy asked me to add this here.  Either this bug is not fixed, or I am getting a new one.

I have tried this on several debian unstable releases.

lac at smartwheels:~$ lsb_release -a
 LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
 Distributor ID:	Debian
 Description:		Debian GNU/Linux unstable (sid)
 Release:		unstable
 Codename:		sid

Idle shows my tk version as 8.6.4
python3 -m test -ugui -v test_tk gives 3 failures

= CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3]
==   Linux-3.16.0-4-amd64-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==   /tmp/test_python_7974
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)

test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL

======================================================================
FAIL: test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 163, in test_default
      self.assertIs(v.get(), False)
      AssertionError: 0 is not False

======================================================================
FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 167, in test_get
      self.assertIs(v.get(), True)
      AssertionError: 1 is not True

======================================================================
FAIL: test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 186, in test_set
      self.assertEqual(self.root.globalgetvar("name"), true)
      AssertionError: 42 != 1

----------------------------------------------------------------------
Ran 660 tests in 3.901s

FAILED (failures=3)
1 test failed:
    test_tk

----------
nosy: +lac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15601>
_______________________________________

From report at bugs.python.org  Thu Aug 13 08:04:14 2015
From: report at bugs.python.org (Pankaj Sharma)
Date: Thu, 13 Aug 2015 06:04:14 +0000
Subject: [issue24854] Null check handle return by new_string()
Message-ID: <1439445854.64.0.39313915879.issue24854@psf.upfronthosting.co.za>


New submission from Pankaj Sharma:

The issue reported in python-2.7.10/Parser/tokenizer.c:237 to handle NULL return by new_string() if PyMem_MALLOC() failed. So need to check for NULL and return to prevent from crash happened in get_normal_name().this issue related with issue18470 has been taken care by setting error code "E_NOMEM" in 3.4.X. i have attached patch,
please review it.

----------
files: Python-2.7.10-tokenizer.patch
keywords: patch
messages: 248498
nosy: benjamin.peterson, pankaj.s01
priority: normal
severity: normal
status: open
title: Null check handle return by new_string()
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40172/Python-2.7.10-tokenizer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24854>
_______________________________________

From report at bugs.python.org  Thu Aug 13 08:11:49 2015
From: report at bugs.python.org (Alex Shkop)
Date: Thu, 13 Aug 2015 06:11:49 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1439446309.43.0.796211151977.issue18383@psf.upfronthosting.co.za>


Alex Shkop added the comment:

@rbcollins that is exactly what was trying to say in previous comment. We can make a change to current patch that won't affect behavior. In old API in this sequence of filters last filter was never used:

simplefilter("ignore")
simplefilter("error", append=True)
simplefilter("ignore", append=True)  # never used

So I suggest that new patch should work like this:


simplefilter("error")
simplefilter("ignore", append=True)  # appends new filter to the end

simplefilter("ignore")
simplefilter("error", append=True)
simplefilter("ignore", append=True)  # does nothing since same filter is present.

This way filtering will work in the same way it worked before patch and we won't have duplicates.

I'll update the patch as soon as I will get to my computer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu Aug 13 08:56:17 2015
From: report at bugs.python.org (sih4sing5hong5)
Date: Thu, 13 Aug 2015 06:56:17 +0000
Subject: [issue24855] fail to mock the urlopen function
Message-ID: <1439448977.69.0.239329434858.issue24855@psf.upfronthosting.co.za>


New submission from sih4sing5hong5:

I also posted in stackoverflow: http://stackoverflow.com/questions/30978207/python-urlopen-mock-fail

```
from unittest.mock import patch
import urllib
from urllib import request
from urllib.request import urlopen

@patch('urllib.request.urlopen')
def openPatch(urlopenMock):
    print(urlopenMock)
    print(urlopen)
    print(request.urlopen)
    print(urllib.request.urlopen)

openPatch()
```
and got

```
<MagicMock name='urlopen' id='140645541554384'>
<function urlopen at 0x7fea9764c268>
<MagicMock name='urlopen' id='140645541554384'>
<MagicMock name='urlopen' id='140645541554384'>
```
request.urlopen and urllib.request.urlopen worked. Why urlopen had been not mocked?

----------
components: Library (Lib)
messages: 248500
nosy: sih4sing5hong5
priority: normal
severity: normal
status: open
title: fail to mock the urlopen function
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24855>
_______________________________________

From report at bugs.python.org  Thu Aug 13 09:35:53 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 13 Aug 2015 07:35:53 +0000
Subject: [issue24856] Mock.side_effect as iterable or iterator
Message-ID: <1439451353.27.0.842295634164.issue24856@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The documentation states that `side_effect` can be set to an [iterable](https://docs.python.org/3/glossary.html#term-iterable):

> If you pass in an iterable, it is used to retrieve an iterator which must yield a value on every call. This value can either be an exception instance to be raised, or a value to be returned from the call to the mock (`DEFAULT` handling is identical to the function case).

but the [actual handling of the side effect](https://github.com/testing-cabal/mock/blob/27a20329b25c8de200a8964ed5dd7762322e91f6/mock/mock.py#L1112-L1123) expects it to be an [*iterator*](https://docs.python.org/3/glossary.html#term-iterator):

if not _callable(effect):
    result = next(effect)

This excludes using a list or tuple object to produce the side effect sequence.

Can the documentation be updated to state an *iterator* is required (so an object that defines __next__ and who's __iter__ method returns self), or can the CallableMixin constructor be updated to call iter() on the side_effect argument if it is not an exception or a callable? You could even re-use the [_MockIter() class](https://hg.python.org/cpython/file/256d2f01e975/Lib/unittest/mock.py#l348) already used for the [NonCallableMock.side_effect property](https://hg.python.org/cpython/file/256d2f01e975/Lib/unittest/mock.py#l509).

----------
components: Library (Lib)
messages: 248501
nosy: mjpieters
priority: normal
severity: normal
status: open
title: Mock.side_effect as iterable or iterator
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24856>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:07:23 2015
From: report at bugs.python.org (flying sheep)
Date: Thu, 13 Aug 2015 08:07:23 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439453243.29.0.844118671448.issue24849@psf.upfronthosting.co.za>


flying sheep added the comment:

> The *iterable* itself may be reentrant, but the iterator formed 
> from iter(iterable) is not. So by your previous comment, giving
> the iterator form a length is not appropriate.

> With the exception of tee, all the functions in itertools return
> iterators.

ah, so your gripe is that the itertools functions return iterators, not (possibly) reentrant objects like range(). and changing that would break backwards compatibility, since the documentation says ?iterator?, not ?iterable? (i.e. people can expect e.g. next(groupby(...))) to work.

that?s probably the end of this :(

the only thing i can imagine that adds reentrant properties (and an useful len()) to iterators would be an optional function (maybe __uniter__ :D) that returns an iterable whose __iter__ function creates a restarted iterator copy, or an optional function that directly returns such a copy. probably too much to ask for :/

> Since you can't rely on it having a length, you have to program as if
> it doesn't. So in practice, I believe this will just add complication.

I don?t agree here. If something accepts iterables and expects to sometimes be called on iterators and sometimes on sequences/len()gthy objects, it will already try/catch len(iterable) and do something useful if that succeeds.

> The best we ended-up with has having __length_hint__ to indicate size to list().

Just out of interest, how does my __uniter__ compare?

> because it changed their boolean value from always-true

it does? is it forbidden to define methods so that int(bool(o)) != len(o)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:12:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 08:12:12 +0000
Subject: [issue23530] os and multiprocessing.cpu_count do not respect
 cpuset/affinity
In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za>
Message-ID: <1439453532.71.0.587887799844.issue23530@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Argument Clinic code was not regenerated. Actually the commit breaks Argument Clinic.

$ make clinic
./python -E ./Tools/clinic/clinic.py --make
Error in file "./Modules/posixmodule.c" on line 11211:
Docstring for os.cpu_count does not have a summary line!
Every non-blank function docstring must start with
a single line summary followed by an empty line.
make: *** [clinic] Error 255

----------
nosy: +serhiy.storchaka
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23530>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:34:41 2015
From: report at bugs.python.org (Wilfred Hughes)
Date: Thu, 13 Aug 2015 08:34:41 +0000
Subject: [issue24857] Crash on comparing call_args with long strings
Message-ID: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>


New submission from Wilfred Hughes:

What steps will reproduce the problem?

>>> from mock import Mock
>>> m = Mock()
>>> m(1, 2)
<Mock name='mock()' id='139781492681104'>
>>> m.call_args == "foob"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wilfred/.py_envs/trifle/lib/python2.7/site-packages/mock.py", line 2061, in __eq__
    first, second = other
ValueError: too many values to unpack

What is the expected output? What do you see instead?

Expected False, got an error instead.

(Migrated from https://github.com/testing-cabal/mock/issues/232 )

----------
components: Library (Lib)
messages: 248504
nosy: Wilfred.Hughes
priority: normal
severity: normal
status: open
title: Crash on comparing call_args with long strings
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:45:44 2015
From: report at bugs.python.org (sih4sing5hong5)
Date: Thu, 13 Aug 2015 08:45:44 +0000
Subject: [issue24855] fail to mock the urlopen function
In-Reply-To: <1439448977.69.0.239329434858.issue24855@psf.upfronthosting.co.za>
Message-ID: <1439455544.63.0.161872870049.issue24855@psf.upfronthosting.co.za>


sih4sing5hong5 added the comment:

It is normal because of __all__ syntax.

By:
https://github.com/testing-cabal/mock/issues/313#issuecomment-130564364

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24855>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:48:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 13 Aug 2015 08:48:53 +0000
Subject: [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1439455733.65.0.890349009187.issue24852@psf.upfronthosting.co.za>


Berker Peksag added the comment:

+1

I'd delete most of the CGI section, add a note about PEP 3333 and mention Gunicorn, uwsgi and Waitress. The frameworks section also needs a cleanup.

Do you want to work on a patch?

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24852>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:50:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 08:50:22 +0000
Subject: [issue24857] Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439455822.45.0.413376951978.issue24857@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +michael.foord
stage:  -> needs patch
type: crash -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:01:39 2015
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Aug 2015 09:01:39 +0000
Subject: [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1439456499.38.0.21406933837.issue24852@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It's probably better to remove the document for now, and add a rewritten version back when it arrives.

Although, this topic sees lot of change regularly, so it is probably not a good one for the standard documentation after all.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24852>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:07:12 2015
From: report at bugs.python.org (Michael Foord)
Date: Thu, 13 Aug 2015 09:07:12 +0000
Subject: [issue24857] Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439456832.59.0.0837118814217.issue24857@psf.upfronthosting.co.za>


Michael Foord added the comment:

call_args is not user settable! It is set for you by the mock when it is called. Arguably it could be a property instead.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:08:10 2015
From: report at bugs.python.org (Michael Foord)
Date: Thu, 13 Aug 2015 09:08:10 +0000
Subject: [issue24857] Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439456890.26.0.272072236875.issue24857@psf.upfronthosting.co.za>


Michael Foord added the comment:

Oops, I misunderstood the bug report - however, call_args is a tuple, so you can't compare it directly to a string like that. Please refer to the docs on using call_args.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:09:34 2015
From: report at bugs.python.org (Wilfred Hughes)
Date: Thu, 13 Aug 2015 09:09:34 +0000
Subject: [issue24857] mock: Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439456974.89.0.90224645896.issue24857@psf.upfronthosting.co.za>


Changes by Wilfred Hughes <yowilfred at gmail.com>:


----------
title: Crash on comparing call_args with long strings -> mock: Crash on comparing call_args with long strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:13:16 2015
From: report at bugs.python.org (Wilfred Hughes)
Date: Thu, 13 Aug 2015 09:13:16 +0000
Subject: [issue24857] mock: Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439457196.66.0.56814473063.issue24857@psf.upfronthosting.co.za>


Wilfred Hughes added the comment:

This caught me by surprise and I spent a while debugging due to this issue. Isn't it reasonable that I can compare two values in Python without exceptions being raised?

>>> (1, 2) == "foob"
False

I'm happy to write a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:15:44 2015
From: report at bugs.python.org (Wilfred Hughes)
Date: Thu, 13 Aug 2015 09:15:44 +0000
Subject: [issue24857] mock: Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439457344.15.0.760171019075.issue24857@psf.upfronthosting.co.za>


Wilfred Hughes added the comment:

This bug is particularly subtle because it only applies to *long* strings.

>>> m.call_args == "f"
False
>>> m.call_args == "fo"
False
>>> m.call_args == "foo"
False
>>> m.call_args == "foob"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-x86_64/egg/mock.py", line 2061, in __eq__
ValueError: too many values to unpack

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:28:42 2015
From: report at bugs.python.org (Michael Foord)
Date: Thu, 13 Aug 2015 09:28:42 +0000
Subject: [issue24857] mock: Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439458122.35.0.883781812384.issue24857@psf.upfronthosting.co.za>


Michael Foord added the comment:

Ok, fair enough.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 12:56:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Aug 2015 10:56:44 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1439463404.77.0.91470581907.issue20180@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, so will someone commit 3), or would you like me to do so? After that it sounds like we can move this back to patch review, since there will be nothing left ready for commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Thu Aug 13 13:53:26 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Aug 2015 11:53:26 +0000
Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4
In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za>
Message-ID: <1439466806.01.0.0602155946853.issue15601@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Andrew (and others): I wasn't sure whether to reopen this or start a new issue.  Will re-close this and open new if preferable.

----------
nosy: +terry.reedy
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15601>
_______________________________________

From report at bugs.python.org  Thu Aug 13 14:03:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 12:03:03 +0000
Subject: [issue24856] Mock.side_effect as iterable or iterator
In-Reply-To: <1439451353.27.0.842295634164.issue24856@psf.upfronthosting.co.za>
Message-ID: <1439467383.45.0.666806711797.issue24856@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documentation is accurate.  The object being manipulated by the code clause you site is not the original object passed in to the side_effect argument.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24856>
_______________________________________

From report at bugs.python.org  Thu Aug 13 14:04:50 2015
From: report at bugs.python.org (John Hagen)
Date: Thu, 13 Aug 2015 12:04:50 +0000
Subject: [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1439467490.94.0.406441763167.issue24852@psf.upfronthosting.co.za>


John Hagen added the comment:

A couple other notes I saw:

The examples (https://docs.python.org/3.5/howto/webservers.html#setting-up-fastcgi) do not follow PEP 8 (should not have an encoding statement if it is UTF-8 Python 3) or the current guidance in PEP 394 to use "python3" in the shebang rather than "python".

Unfortunately, I think I should defer writing the patch/new page to someone with more experience in the Python/web world.  I am still pretty new to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24852>
_______________________________________

From report at bugs.python.org  Thu Aug 13 14:09:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 12:09:03 +0000
Subject: [issue24857] mock: Crash on comparing call_args with long strings
In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za>
Message-ID: <1439467743.31.0.371868326049.issue24857@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, if it isn't comparable it should return either False or NotImplemented, not raise an exception.  False would be better here, I think.

----------
keywords: +easy
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24857>
_______________________________________

From report at bugs.python.org  Thu Aug 13 14:15:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 12:15:03 +0000
Subject: [issue24855] fail to mock the urlopen function
In-Reply-To: <1439448977.69.0.239329434858.issue24855@psf.upfronthosting.co.za>
Message-ID: <1439468103.84.0.506254965449.issue24855@psf.upfronthosting.co.za>


R. David Murray added the comment:

It has nothing to do with __all__, and everything to do with the way namespaces work in Python.  'from urllib.request import urllib' creates a name 'urllib' in the global namespace of your module pointing to the urlopen function (*before* you do your patch), and patch has no effect on the global namespace of your module, only on the global namespace of urllib.request.  By contrast, urllib in your module's global namespace points to the urllib module, so urllib.request points to the urllib.request's global namespace, which patch has altered to point to your mock by the time you print its value.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24855>
_______________________________________

From report at bugs.python.org  Thu Aug 13 16:09:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Aug 2015 14:09:51 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <20150813140947.31687.97328@psf.io>


Roundup Robot added the comment:

New changeset d9c85b6bab3a by R David Murray in branch '2.7':
#21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/d9c85b6bab3a

New changeset 5e71a489f01d by R David Murray in branch '3.4':
#21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/5e71a489f01d

New changeset e3008318f76b by R David Murray in branch '3.5':
Merge: #21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/e3008318f76b

New changeset 1dd4f473c627 by R David Murray in branch 'default':
Merge: #21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/1dd4f473c627

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 16:12:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 14:12:12 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439475132.42.0.584356714642.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks Chris, and Mark.

I ran the tests on 3.6 both on Linux (non ICC) and on Mac (with ICC without -fp-model strict) and all the tests passed.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 16:22:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 14:22:28 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439475748.57.0.266953967376.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Larry, do you want this for 3.5.0a2?  It's an innocuous patch for anyone not using ICC, and makes ICC "just work" (with the default ICC build arguments) for people using ICC.  (Well, on (lin/u)nux and mac, anyway, I'm not sure we've resolved all the ICC issues on Windows yet.)

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Thu Aug 13 16:54:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2015 14:54:11 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439477651.35.0.168270128993.issue24847@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is this buildbot failure:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/189

related to this issue?

LINK : fatal error LNK1104: cannot open file 'C:\buildbot.python.org\3.5.kloth-win64\build\PCBuild\amd64\_tkinter_d.pyd' [C:\buildbot.python.org\3.5.kloth-win64\build\PCbuild\_tkinter.vcxproj]

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Thu Aug 13 17:03:57 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Aug 2015 15:03:57 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439478237.08.0.254479999213.issue24851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To fix this in a generic way, perhaps the function could update a volatile global variable after the recursive call?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Thu Aug 13 17:15:49 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 13 Aug 2015 15:15:49 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1439478949.28.0.192656363132.issue24570@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Awesome, thanks Kevin. Have attached calltip.patch. The extra lift() call doesn't seem to hurt on Windows or X11, so didn't make it conditional.

----------
keywords: +patch
Added file: http://bugs.python.org/file40173/calltip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

From report at bugs.python.org  Thu Aug 13 17:47:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Aug 2015 15:47:11 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439480831.55.0.29763087814.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

No, any machine with Visual Studio installed is unaffected by this. That buildbot seems to have a previous failed/aborted build that still has some files locked. A reboot is the easiest solution, but going through and killing any extra processes is what's needed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:14:30 2015
From: report at bugs.python.org (Paul Murphy)
Date: Thu, 13 Aug 2015 16:14:30 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439482470.39.0.153413208225.issue24851@psf.upfronthosting.co.za>


Paul Murphy added the comment:

Somehow, you need to preserve access to the stack memory. The generated code is still growing the stack, it just fails to touch any of it.

I'm guessing a volatile access would just add an extra non-stack access to the infinite loop.

Initially, I had tried creating a non-inlined function to touch the stack memory. It worked in this case, but still required some undesirable compiler specific assistance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:16:18 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Aug 2015 16:16:18 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439482578.02.0.923275439444.issue24851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Initially, I had tried creating a non-inlined function to touch the
> stack memory. It worked in this case, but still required some
> undesirable compiler specific assistance.

Hmm... store the non-inlined function's pointer in a volatile global, and call that pointer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:39:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 16:39:04 +0000
Subject: [issue15601] tkinter test_variables fails with OS X Aqua Tk 8.4
In-Reply-To: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za>
Message-ID: <1439483944.29.0.87111420352.issue15601@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please open a new issue Laura.

----------
nosy: +serhiy.storchaka
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15601>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:23:00 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 13 Aug 2015 17:23:00 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
Message-ID: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>


New submission from Laura Creighton:

I have tried this on several debian unstable releases, and get the following 3 failures

lac at smartwheels:~$ lsb_release -a
 LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
 Distributor ID:	Debian
 Description:		Debian GNU/Linux unstable (sid)
 Release:		unstable
 Codename:		sid

Idle shows my tk version as 8.6.4
python3 -m test -ugui -v test_tk gives 3 failures

= CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3]
==   Linux-3.16.0-4-amd64-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==   /tmp/test_python_7974
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)

test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL
test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar) ... FAIL

======================================================================
FAIL: test_default (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 163, in test_default
      self.assertIs(v.get(), False)
      AssertionError: 0 is not False

======================================================================
FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 167, in test_get
      self.assertIs(v.get(), True)
      AssertionError: 1 is not True

======================================================================
FAIL: test_set (tkinter.test.test_tkinter.test_variables.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_variables.py", line 186, in test_set
      self.assertEqual(self.root.globalgetvar("name"), true)
      AssertionError: 42 != 1

----------------------------------------------------------------------
Ran 660 tests in 3.901s

FAILED (failures=3)
1 test failed:
    test_tk

----------
components: Tkinter
messages: 248529
nosy: lac, terry.reedy
priority: normal
severity: normal
status: open
title: python3 -m test -ugui -v test_tk gives 3 failures under Debian unstable (sid)
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:32:07 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 13 Aug 2015 17:32:07 +0000
Subject: [issue24856] Mock.side_effect as iterable or iterator
In-Reply-To: <1439451353.27.0.842295634164.issue24856@psf.upfronthosting.co.za>
Message-ID: <1439487127.51.0.567241259575.issue24856@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Bugger, that's the last time I take someone's word for it and not test properly. Indeed, I missed the inheritance of NonCallableMock, so the property is inherited from there.

Mea Culpa!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24856>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:33:34 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Aug 2015 17:33:34 +0000
Subject: [issue17703] Trashcan mechanism segfault during interpreter
 finalization in Python 2.7.4
In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za>
Message-ID: <1439487214.39.0.338807970888.issue17703@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I'm seeing this bug in Python 3.4.2 as well, and the patch here (tstate_trashcan.patch) appears to fix it.

What is the context? Some specific C code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17703>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:41:02 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Aug 2015 17:41:02 +0000
Subject: [issue24853] Py_Finalize doesn't clean up PyImport_Inittab
In-Reply-To: <1439431834.18.0.462174995045.issue24853@psf.upfronthosting.co.za>
Message-ID: <1439487662.43.0.00434638948354.issue24853@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24853>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:37:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Aug 2015 18:37:58 +0000
Subject: [issue16554] The description of the argument of MAKE_FUNCTION and
 MAKE_CLOSURE is incorrect
In-Reply-To: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>
Message-ID: <20150813183754.10874.23958@psf.io>


Roundup Robot added the comment:

New changeset c515b40a70eb by Antoine Pitrou in branch '3.4':
Issue #16554: fix description for MAKE_CLOSURE.  Initial patch by Daniel Urban.
https://hg.python.org/cpython/rev/c515b40a70eb

New changeset 2a41fb63c095 by Antoine Pitrou in branch '3.5':
Issue #16554: fix description for MAKE_CLOSURE.  Initial patch by Daniel Urban.
https://hg.python.org/cpython/rev/2a41fb63c095

New changeset 7aed2d7e7dd5 by Antoine Pitrou in branch 'default':
Issue #16554: fix description for MAKE_CLOSURE.  Initial patch by Daniel Urban.
https://hg.python.org/cpython/rev/7aed2d7e7dd5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16554>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:38:33 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Aug 2015 18:38:33 +0000
Subject: [issue16554] The description of the argument of MAKE_FUNCTION and
 MAKE_CLOSURE is incorrect
In-Reply-To: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>
Message-ID: <1439491113.47.0.0570694233811.issue16554@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The description for MAKE_FUNCTION had already been fixed in the meantime, so I pushed the changes for MAKE_CLOSURE. Thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16554>
_______________________________________

From report at bugs.python.org  Thu Aug 13 21:04:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 19:04:36 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439492676.44.0.198236542096.issue24858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks strange. Current default Tcl in Debian unstable is 8.6 [1]. New Python3 builds depend on libtcl8.6 [2]. The full version of the 8.4 branch is 8.4.20 [3], this is the last release in the 8.4 branch. Perhaps your installation was not updated too long time if you see 8.6.4.

[1] https://packages.debian.org/sid/tcl
[2] https://packages.debian.org/sid/python3-tk
[3] https://packages.debian.org/sid/tcl8.4

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Thu Aug 13 21:15:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 19:15:33 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439493333.8.0.318752732748.issue24858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Even on Debian Squeeze (oldoldstable) Python 2 (2.6) [1] and Python 3 (3.1) [2] depend on Tcl 8.5 [3]. So I think we can ignore all issues with Tcl/Tk 8.4 on Debian. They are related to very old unsupported Debian versions.

[1] https://packages.debian.org/squeeze/python-tk
[2] https://packages.debian.org/squeeze/python3-tk
[3] https://packages.debian.org/squeeze/tcl8.5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Thu Aug 13 21:20:46 2015
From: report at bugs.python.org (zeero)
Date: Thu, 13 Aug 2015 19:20:46 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
Message-ID: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>


New submission from zeero:

I'm implementing a CAN SAEJ1939 stack in Python and convert CAN message ids in between integers and structures, tunneling them through a Union object with 4 bytes like what i would do in C.

I was checking that particular function and the 3 priority bits were at the wrong position. Some trials later i concluded the bits are reversed and inverted the order in my structure. Now it works fine.

I'm not sure if it's a bug but i would expect ctypes.Structure to
store the fields in the order i provide and not the other way around.
On the other hand the bytes are in the order i provided.

The System I'm running on is 64Bit Ubuntu AMD A1046 but it shows the same behaviour an a 64bit Windows 7 Intel I5

----------
components: ctypes
files: test_structure.py
messages: 248536
nosy: zeero
priority: normal
severity: normal
status: open
title: ctypes.Structure bit order is reversed - counts from right
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40174/test_structure.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Thu Aug 13 21:37:16 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 13 Aug 2015 19:37:16 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439494636.79.0.205157346385.issue24858@psf.upfronthosting.co.za>


Laura Creighton added the comment:

You are misunderstanding me, so originally posting this in a report
that mentioned tk and tcl 8.4 was a bad idea. 

I have tk and tcl 8.6 and am getting these errors.  It has nothing
at all to do with 8.4

lac at fido:~$ apt-cache policy tcl tk
tcl:
  Installed: 8.6.0+8
  Candidate: 8.6.0+8
  Version table:
 *** 8.6.0+8 0
        500 http://mirror.openend.se/debian/ stable/main i386 Packages
        500 http://ftp.se.debian.org/debian/ unstable/main i386 Packages
        500 http://ftp.debian.org/debian/ unstable/main i386 Packages
        100 /var/lib/dpkg/status
tk:
  Installed: 8.6.0+8
  Candidate: 8.6.0+8
  Version table:
 *** 8.6.0+8 0
        500 http://mirror.openend.se/debian/ stable/main i386 Packages
        500 http://ftp.se.debian.org/debian/ unstable/main i386 Packages
        500 http://ftp.debian.org/debian/ unstable/main i386 Packages
        100 /var/lib/dpkg/status
lac at fido:~$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Thu Aug 13 21:37:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Aug 2015 19:37:30 +0000
Subject: [issue23530] os and multiprocessing.cpu_count do not respect
 cpuset/affinity
In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za>
Message-ID: <20150813193728.27292.69208@psf.io>


Roundup Robot added the comment:

New changeset 23c6cc5d5b8f by Charles-Fran?ois Natali in branch 'default':
Issue #23530: fix clinic comment.
https://hg.python.org/cpython/rev/23c6cc5d5b8f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23530>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:02:23 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 13 Aug 2015 20:02:23 +0000
Subject: [issue24860] handling of IDLE 'open module' errors
Message-ID: <1439496143.45.0.879606750769.issue24860@psf.upfronthosting.co.za>


New submission from Mark Roseman:

In EditorWindow.open_module... once switch to querydialog, display errors (e.g. module not found) in askstring dialog itself, not open up subsequent 'showerror' dialog

----------
components: IDLE
messages: 248539
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: handling of IDLE 'open module' errors
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24860>
_______________________________________

From report at bugs.python.org  Thu Aug 13 23:11:49 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 13 Aug 2015 21:11:49 +0000
Subject: [issue24861] deprecate importing components of IDLE
Message-ID: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za>


New submission from Mark Roseman:

One of the concerns with making significant structural changes to the IDLE codebase is breakage of external that might import a piece of idlelib (so not just 'import idlelib' but a particular submodule). 

PEP 434 already makes the case that this behaviour is unsupported ("the modules are undocumented and effectively private implementations"). In the interests of not digging this particular hole any further, I'm suggesting we make this official. 

I don't know what the appropriate mechanism would be (e.g. something in IDLE's README.txt file, something at the top of each IDLE module, etc.).

Based on some suggestions on idle-dev, I did some searching to find out what impact this might have. As expected, most uses import the whole thing, either documenting how to run IDLE, or launching it as an external editor. This is done as both "import idlelib" but also as "import idlelib.idle"

Turtledemo appears to be the only thing in stdlib that imports a piece of idlelib.

>From nullege.com, one reference to a now-defunct wiki/collaboration tool called Springnote.  From programcreek.com, nothing significant.

Multiple applications do import PyShell as a way of starting a Python shell in their application. Usually they do just call PyShell.main(). Sometimes though they do "reach inside" in fairly significant ways that might break if the code were substantially changed. For example, search for PyShell in http://igraph.org/python/doc/igraph.app.shell-pysrc.html

I could locate no other significant uses based on Google search, etc.

The one exception I would therefore suggest to the "no importing submodules" would be importing PyShell to open up a Python shell window. I'd go further to suggest that the existing PyShell be called something else, and a new PyShell wrapper be created which documents an official API (with therefore very limited mucking inside), and then delegates to an actual implementation.

----------
components: IDLE
messages: 248540
nosy: Al.Sweigart, kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: deprecate importing components of IDLE
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24861>
_______________________________________

From report at bugs.python.org  Thu Aug 13 23:45:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 13 Aug 2015 21:45:26 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439502326.66.0.785020946966.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I noticed you accepted the PR on Bitbucket, Larry. Should I consider your part done and I can now pull the commit into the 3.5 and default branches on hg.python.org?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24492>
_______________________________________

From report at bugs.python.org  Fri Aug 14 00:10:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Aug 2015 22:10:14 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439503814.87.0.18671935687.issue24858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry.

The issue still looks strange to me. It looks as a result of mix Python core, library or tests of different versions.

Could you please test what following commands output?

>>> import tkinter
>>> tcl = tkinter.Tcl()
>>> tcl.getboolean(42)
True
>>> tkinter.BooleanVar.set
<function BooleanVar.set at 0xb6ed5614>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:30:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Aug 2015 23:30:00 +0000
Subject: [issue24860] handling of IDLE 'open module' errors
In-Reply-To: <1439496143.45.0.879606750769.issue24860@psf.upfronthosting.co.za>
Message-ID: <1439508600.27.0.556477105736.issue24860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I see this as two related changes:

a) Leave the module name query box open when there is a error, so the user can either correct a mistake (or hit Cancel) without reopening the box and re-entering the module name.  Good idea.

b) Put the error message in the box itself, perhaps with a beep.  I presume there would be no [OK] button, but rather the cursor would remain in the entry box.  Nice simplification.

I believe 'not a source-based module' means 'not a python-coded module', which seems a little clearer. We could check the importlib doc.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24860>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:50:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Aug 2015 23:50:38 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <20150813235035.10872.93484@psf.io>


Roundup Robot added the comment:

New changeset 267422f7c927 by Robert Collins in branch '3.4':
Issue #21159: Improve message in configparser.InterpolationMissingOptionError.
https://hg.python.org/cpython/rev/267422f7c927

New changeset 1a144ff2d78b by Robert Collins in branch '3.5':
Issue #21159: Improve message in configparser.InterpolationMissingOptionError.
https://hg.python.org/cpython/rev/1a144ff2d78b

New changeset fb4e67040779 by Robert Collins in branch 'default':
Issue #21159: Improve message in configparser.InterpolationMissingOptionError.
https://hg.python.org/cpython/rev/fb4e67040779

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:53:08 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Aug 2015 23:53:08 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1439509988.68.0.967399593084.issue21159@psf.upfronthosting.co.za>


Robert Collins added the comment:

I've applied this since it seems Lukasz was busy. Thanks for the patch Lukasz!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:53:31 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Aug 2015 23:53:31 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1439510011.5.0.544253965439.issue21159@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 02:16:34 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Aug 2015 00:16:34 +0000
Subject: [issue24861] deprecate importing components of IDLE
In-Reply-To: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za>
Message-ID: <1439511394.76.0.774001099131.issue24861@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you for doing the research.  It seems that extensions are the only unknown. Steps for doing this.

1. Nick once said to start with a notice in idlelib.__init__.  How about the following.

The idlelib package implements the Idle application, which include an interactive shell and editor.  The files named idle.* should be used to start Idle.  The other files are private implementations and should not be imported by other applications. Their details are subject to change. See PEP 434  for more informaton.

2. Put same in NEWS.txt -- not just a notice that a notice was added to .__init__, but the notice itself.

3. Put a single line at the top of each 'new' file. Perhaps

# Private implementation module. API subject to change.

4. 'Old' files, which will go away someday, perhaps as soon as 3.6, are less of a concern to me.  If one that has been replaced by a ttk version is imported when use_ttk is true, we can assume that it is being imported by an extension and issue a DeprecationWarning.

5. PyShell is a special case since "from idlelib.PyShell import main; main()" (essentially the content of idlelib.__main__) was once advertised as the way to start Idle. PyShell is also a special case because it includes startup code, shell code, and editor debug code, making it a prime target for refactoring. If main() were moved elsewhere and __main__.py and idle.* files modified to point to the new location, we could raise a DeprecationWarning in PyShell.main before calling the new main.

----------
assignee:  -> terry.reedy
priority: normal -> high
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24861>
_______________________________________

From report at bugs.python.org  Fri Aug 14 02:16:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Aug 2015 00:16:51 +0000
Subject: [issue24861] deprecate importing components of IDLE
In-Reply-To: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za>
Message-ID: <1439511411.57.0.37747263995.issue24861@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24861>
_______________________________________

From report at bugs.python.org  Fri Aug 14 02:53:39 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 14 Aug 2015 00:53:39 +0000
Subject: [issue24860] handling of IDLE 'open module' errors
In-Reply-To: <1439496143.45.0.879606750769.issue24860@psf.upfronthosting.co.za>
Message-ID: <1439513619.68.0.116154136906.issue24860@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Exactly. The "querydialog" code (which will replace the simpledialog askstring/askinteger calls) displays errors as shown in querydialog.png, with the error messages disappearing as soon as you hit another key.

You can also pass in a 'validator' to check if the input is ok, so in this case it would check if the module could be loaded and return the appropriate message if not.

----------
Added file: http://bugs.python.org/file40175/querydialog.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24860>
_______________________________________

From report at bugs.python.org  Fri Aug 14 03:13:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Aug 2015 01:13:36 +0000
Subject: [issue24860] handling of IDLE 'open module' errors
In-Reply-To: <1439496143.45.0.879606750769.issue24860@psf.upfronthosting.co.za>
Message-ID: <1439514816.95.0.0113805140069.issue24860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Where is querydialog? (It looks like something than should be in tkinter ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24860>
_______________________________________

From report at bugs.python.org  Fri Aug 14 03:33:37 2015
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Aug 2015 01:33:37 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439516017.75.0.0491407715958.issue21167@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Assuming that "ICC_NAN_STRICT" is only on for Intel icc: yes, please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Fri Aug 14 03:36:39 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 14 Aug 2015 01:36:39 +0000
Subject: [issue24860] handling of IDLE 'open module' errors
In-Reply-To: <1439496143.45.0.879606750769.issue24860@psf.upfronthosting.co.za>
Message-ID: <1439516199.97.0.585538751918.issue24860@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Work in progress, have a few more tweaks to make, but here's a snapshot...

----------
Added file: http://bugs.python.org/file40176/querydialog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24860>
_______________________________________

From report at bugs.python.org  Fri Aug 14 03:44:11 2015
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Aug 2015 01:44:11 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439516651.61.0.443417587164.issue24492@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yep.  This time I have foisted nearly all the work, including the forward-merging, onto y'all.

*sits back, sips iced coffee*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24492>
_______________________________________

From report at bugs.python.org  Fri Aug 14 04:38:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Aug 2015 02:38:21 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
In-Reply-To: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>
Message-ID: <1439519901.87.0.932911775348.issue24859@psf.upfronthosting.co.za>


Martin Panter added the comment:

It would be helpful if you could trim down your example code a bit. Without studying the whole file, it is hard to see exactly what order you are seeing and what order you expect, since there are two versions with different orders in the code.

My understanding of the ?ctypes? module is that it is for interacting with the local OS, ABI, compiler, etc, which could use various layouts depending on the platform. According to the Linux x86-64 ABI <http:/www.x86-64.org/documentation/abi.pdf>, page 14, ?bit-fields are allocated from right to left?, which I interpret to mean from least-significant to most-significant bit. Not so sure about Windows, but <https://msdn.microsoft.com/en-us/library/yszfawxh.aspx> suggests a similar story (LSB first). This behaviour agrees with my experiments on Linux and Wine:

>>> class Bitfield(Structure):
...     _fields_ = (("a", c_uint8, 4), ("b", c_uint8, 4))
... 
>>> bytes(Bitfield(0xA, 0xB))
b'\xba'

Does this agree with what you expect? Otherwise, what leads you to expect something different?

Also:
* bytes(saej1939_message_id) should copy the bytes directly; no need for a union.
* struct.unpack() should also accept a ?ctypes? object directly; no need for the copy.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Fri Aug 14 04:55:39 2015
From: report at bugs.python.org (Andre Merzky)
Date: Fri, 14 Aug 2015 02:55:39 +0000
Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process
 tree
Message-ID: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za>


New submission from Andre Merzky:

- create a class which is a subclass of multiprocessing.Process ('A')
 - in its __init__ create new thread ('B') and share a queue with it
 - in A's run() method, run 'C=subprocess.Popen(args="/bin/false")'
 - push 'C' though the queue to 'B'
 - call 'C.pull()' --> returns 0

Apart from returning 0, the pull will also return immediately, even if the task is long running.  The task does not die -- 'ps' shows it is well alive.

I assume that the underlying reason is that 'C' is moved sideways in the process tree, and the wait is happening in a thread which is not the parent of C.  I assume (or rather guess, really) that the system level waitpid call raises a 'ECHILD' (see wait(2)), but maybe that is misinterpreted as 'process gone'?

I append a test script which shows different combinations of process spawner and watcher classes.  All of them should report an exit code of '1' (as all run /bin/false), or should raise an error.  None should report an exit code of 0 -- but some do.

PS.: I implore you not to argue if the above setup makes sense -- it probably does not.  However, it took significant work to condense a real problem into that small excerpt, and it is not a full representation of our application stack.  I am not interested in discussing alternative approaches: we have those, and I can live with the error not being fixed.

#!/usr/bin/env python

from subprocess      import Popen
from threading       import Thread  as T
from multiprocessing import Process as P
import multiprocessing as mp

class A(P):

    def __init__(self):

        P.__init__(self)

        self.q = mp.Queue()
        def b(q):
            C = q.get()
            exit_code = C.poll()
            print "exit code: %s" % exit_code
        B = T(target = b, args=[self.q])
        B.start ()

    def run(self):
        C = Popen(args  = '/bin/false')
        self.q.put(C)

a = A()
a.start()
a.join()

----------
components: Library (Lib)
files: test_mp.py
messages: 248553
nosy: Andre Merzky
priority: normal
severity: normal
status: open
title: subprocess.Popen behaves incorrect when moved in process tree
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40177/test_mp.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24862>
_______________________________________

From report at bugs.python.org  Fri Aug 14 05:42:58 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 14 Aug 2015 03:42:58 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439523778.45.0.572562921698.issue24858@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Python 3.4.3+ (default, Jul 28 2015, 13:17:50) 
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>import tkinter
>>>tcl = tkinter.Tcl()
>>>tcl.getboolean(42)
42
>>>tkinter.BooleanVar.set
<function BooleanVar.set at 0x7f15b780bea0>
>>>print (tkinter)
<module 'tkinter' from '/usr/lib/python3.4/tkinter/__init__.py'>
>>>import _tkinter
>>>print(_tkinter)
<module '_tkinter' from '/usr/lib/python3.4/lib-dynload_tkinter.cpython-34m-x86_64-linux-gnu.so'>


I have the libpython3.4-testsuite installed

lac at fido:~$  apt-cache policy libpython3.4-testsuite
libpython3.4-testsuite:
  Installed: 3.4.3-8
  Candidate: 3.4.3-8
  Version table:
 *** 3.4.3-8 0
        500 http://ftp.se.debian.org/debian/ unstable/main amd64 Packages
        500 http://ftp.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status

I am getting these same errors on multiple machines.  As far as I know every one of them gets their packages from the same place, ftp.se.debian.org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:26:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 04:26:43 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439526403.9.0.0543899221822.issue24858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Laura. Looks as binary _tkinter is out of sync with the library and tests. Failing tests were added in issue15133 together with related changes in Python library (added BooleanVar.set and other changes) and _tkinter (changed getboolean()). If Debian version includes 117f45749359, getboolean() always should return boolean. Otherwise failing tests shouldn't exist.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:33:30 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 14 Aug 2015 04:33:30 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439526810.89.0.5317319785.issue24858@psf.upfronthosting.co.za>


Laura Creighton added the comment:

So this is a debian packaging issue we need to tell the debian package maintainers about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:53:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 04:53:15 +0000
Subject: [issue24854] Null check handle return by new_string()
In-Reply-To: <1439445854.64.0.39313915879.issue24854@psf.upfronthosting.co.za>
Message-ID: <20150814045312.27294.63679@psf.io>


Roundup Robot added the comment:

New changeset 208d6d14c2a3 by Benjamin Peterson in branch '2.7':
add missing NULL checks to get_coding_spec (closes #24854)
https://hg.python.org/cpython/rev/208d6d14c2a3

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24854>
_______________________________________

From report at bugs.python.org  Fri Aug 14 07:12:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 05:12:11 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439529131.05.0.0141253957579.issue24858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, this looks as packaging issue. Added Matthias Klose, the Debian package maintainer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Fri Aug 14 08:47:26 2015
From: report at bugs.python.org (Alex Shkop)
Date: Fri, 14 Aug 2015 06:47:26 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1439534846.25.0.869226310298.issue18383@psf.upfronthosting.co.za>


Alex Shkop added the comment:

This is updated patch that doesn't alter warn_explicit behavior.

So the following:
simplefilter("ignore")
simplefilter("error", append=True)
simplefilter("ignore", append=True)

will ignore all warnings with this patch and no duplicates are inserted to warnings.filters. Also added a test for that case.

----------
Added file: http://bugs.python.org/file40178/issue18383_34_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Fri Aug 14 09:07:42 2015
From: report at bugs.python.org (Christian Klein)
Date: Fri, 14 Aug 2015 07:07:42 +0000
Subject: [issue24863] Incoherent bevavior with umlaut in regular expressions
Message-ID: <1439536062.63.0.589470343497.issue24863@psf.upfronthosting.co.za>


New submission from Christian Klein:

The Python 2.7 re module seems not to agree what to consider a word character:

import re
s = u'f\xfc'
print re.sub('\W', '*', s, re.UNICODE)
print re.findall('\w', s, re.UNICODE)

The application of re.sub removes the character u'?' which implies it's considered a non word character (\W).
But then re.findall shows it as a word character (\w).

Python 3.4 and Python 3.5 are correct respectively coherent.
(But that's unfortunately not an option for Google App Engine)

----------
components: Regular Expressions
messages: 248560
nosy: cklein, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Incoherent bevavior with umlaut in regular expressions
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24863>
_______________________________________

From report at bugs.python.org  Fri Aug 14 09:43:07 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 14 Aug 2015 07:43:07 +0000
Subject: [issue24863] Incoherent bevavior with umlaut in regular expressions
In-Reply-To: <1439536062.63.0.589470343497.issue24863@psf.upfronthosting.co.za>
Message-ID: <1439538187.41.0.91799092905.issue24863@psf.upfronthosting.co.za>


eryksun added the comment:

You're passing re.UNICODE (32) as the value of the count parameter, i.e. the function signature is re.sub(pattern, repl, string, count=0, flags=0).

----------
nosy: +eryksun
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24863>
_______________________________________

From report at bugs.python.org  Fri Aug 14 09:46:46 2015
From: report at bugs.python.org (Christian Klein)
Date: Fri, 14 Aug 2015 07:46:46 +0000
Subject: [issue24863] Incoherent bevavior with umlaut in regular expressions
In-Reply-To: <1439536062.63.0.589470343497.issue24863@psf.upfronthosting.co.za>
Message-ID: <1439538406.48.0.609277160282.issue24863@psf.upfronthosting.co.za>


Christian Klein added the comment:

Wow, that's very embarrassing. Thank you.
(I tried to get further help before but nobody recognized that stupid mistake)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24863>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:08:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 08:08:03 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1439539683.6.0.642781743289.issue21159@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You forgot to merge default with 3.5.

----------
nosy: +serhiy.storchaka
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:10:43 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 08:10:43 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1439539843.44.0.472416543948.issue21159@psf.upfronthosting.co.za>


Robert Collins added the comment:

Huh? I definitely did. I can see there's a extra head now, but I did the merge up per protocol locally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:16:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 08:16:27 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <20150814081624.23559.76175@psf.io>


Roundup Robot added the comment:

New changeset 7191910aeb45 by Robert Collins in branch 'default':
Issue #21159: Improve message in configparser.InterpolationMissingOptionError.
https://hg.python.org/cpython/rev/7191910aeb45

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:17:04 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 08:17:04 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1439540224.56.0.374800185436.issue21159@psf.upfronthosting.co.za>


Robert Collins added the comment:

anyhow fixed

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:37:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 08:37:29 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1439541449.41.0.0918878112528.issue24750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I were wrong. 8.4 still is supported in 3.5. The support of 8.3 was dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24750>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:43:01 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 14 Aug 2015 08:43:01 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439541781.77.0.289429956622.issue24851@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

GCC has a pragma and function attributes for changing the optimisation flags, that could be used to disable the tail call optimazation here.

Something like the following (using a pragma):

#pragma GCC push_options
#pragma GCC optimize ("-fno-optimize-sibling-calls")
<functions go here>
#pragma GCC pop_options

Note: completely untested, and would need preprocessor guards to avoid warnings with some other compilers.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:55:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 08:55:49 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1439542549.71.0.821192010071.issue24801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as right button on Mac corresponds to middle button on X Window (paste selection and scroll if moved). This behavior is standard for all Tk applications. I don't think we should break this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24801>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:59:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 08:59:02 +0000
Subject: [issue24864] errors writing to stdout are uncatchable and exit with
 status 0
Message-ID: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>


New submission from Robert Collins:

I was trying to demonstrate how testing some code is hard, and I stumbled upon this.

The following code should be debuggable when run with a bad stdout - e.g.

python foo.py > /dev/full

---
import sys
import traceback

import pdb;pdb.Pdb(stdout=sys.stderr).set_trace()
try:
    print("What... is your quest?")
except:
    sys.stderr.write("Exception in program.\n")
    traceback.print_exc(file=sys.stderr)
---

Here is a transcript of a session with it:
---
$ python ./02.py > /dev/full 
> /home/robertc/work/Presentations/reveal.js/effectsnippets/02.py(5)<module>()
-> try:
(Pdb) n
> /home/robertc/work/Presentations/reveal.js/effectsnippets/02.py(6)<module>()
-> print("What... is your quest?")
(Pdb) n
--Return--
> /home/robertc/work/Presentations/reveal.js/effectsnippets/02.py(6)<module>()->None
-> print("What... is your quest?")
(Pdb) n
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
OSError: [Errno 28] No space left on device
$ echo $?
0
---

The same thing done on stderr exits with an exit code of 0 as well.

----------
messages: 248570
nosy: rbcollins
priority: normal
severity: normal
status: open
title: errors writing to stdout are uncatchable and exit with status 0
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:09:45 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 09:09:45 +0000
Subject: [issue24864] errors writing to stdout are uncatchable and exit with
 status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439543385.06.0.424314086618.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, and for added joy sys.last_value is not set here, so I've yet to manage to poke at what is being executed - clearly pdb is still managing to single-step, ish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:10:21 2015
From: report at bugs.python.org (Vlad Gumerov)
Date: Fri, 14 Aug 2015 09:10:21 +0000
Subject: [issue24865] IDLE crashes on entering diacritical mark (Alt-E) on Mac
 OS X
Message-ID: <1439543421.01.0.111029936537.issue24865@psf.upfronthosting.co.za>


New submission from Vlad Gumerov:

Mac OS X 10.10.3
IDLE 3.4.3, Python 3.4.3

Steps:
1)Open IDLE
2)Input diacritical mark ? (Alt+E)

Result:
IDLE crashes

----------
components: IDLE
messages: 248572
nosy: Vlad Gumerov
priority: normal
severity: normal
status: open
title: IDLE crashes on entering diacritical mark (Alt-E) on Mac OS X
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24865>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:12:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 09:12:47 +0000
Subject: [issue24864] errors writing to stdout are uncatchable and exit with
 status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439543567.11.0.367565361635.issue24864@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue11380.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:13:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 09:13:24 +0000
Subject: [issue24865] IDLE crashes on entering diacritical mark (Alt-E) on Mac
 OS X
In-Reply-To: <1439543421.01.0.111029936537.issue24865@psf.upfronthosting.co.za>
Message-ID: <1439543604.19.0.298033193741.issue24865@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +ned.deily, ronaldoussoren, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24865>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:32:56 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 09:32:56 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1439544776.5.0.700970648001.issue11380@psf.upfronthosting.co.za>


Robert Collins added the comment:

See also issue24864 which is not *quite* a dupe, I also found that it exits 0, unreasonably so.

The reporting thing is interesting, but the main thing I care about is that we can catch it and do something reasonable with it... and that if not caught it signals an error :)

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:37:04 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 09:37:04 +0000
Subject: [issue24864] errors writing to stdout are uncatchable and exit with
 status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439545024.69.0.0378437528794.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

FWIW Python 2.7.8 behaves the same way (different message, same behaviour).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:38:57 2015
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 14 Aug 2015 09:38:57 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1439545137.56.0.166266573726.issue24838@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

Thanks for the detailed report and the patch. I haven't checked yet, but I suppose that the entire 3.x branch is affected. The first thing I have to do now is to come up with a comprehensive testcase.

----------
assignee:  -> lars.gustaebel
components: +Library (Lib)
nosy: +lars.gustaebel
stage:  -> test needed
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Fri Aug 14 12:06:01 2015
From: report at bugs.python.org (Frunit)
Date: Fri, 14 Aug 2015 10:06:01 +0000
Subject: [issue24866] Boolean representation of Q/queue objects does not fit
 behaviour of lists etc.
Message-ID: <1439546761.55.0.496059409555.issue24866@psf.upfronthosting.co.za>


New submission from Frunit:

Usually, list-like objects return False when they are empty and True when at least one element is in the list. However, Queue (Python 2) resp. queue (Python 3) objects always return True. I am aware of that objects should always return True unless otherwise stated, but as queues are (at least in my perception) related to lists, they should behave similarly in this case.

Python3 (similar in Python2):
>>> import queue
>>> q = queue.Queue()
>>> bool(q)
True
(Should be False, in my opinion; the same for PriorityQueue and LifoQueue)

I searched for reasons for returning True in empty Queues, but I could not find any in the net or in the Python docs.

----------
messages: 248577
nosy: Frunit
priority: normal
severity: normal
status: open
title: Boolean representation of Q/queue objects does not fit behaviour of lists etc.
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24866>
_______________________________________

From report at bugs.python.org  Fri Aug 14 12:38:08 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 10:38:08 +0000
Subject: [issue24864] errors writing to stdout are uncatchable and exit with
 status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439548688.0.0.846509551874.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, one nuance - the reason my except isn't triggering is that the write is happening in interpreter shutdown - in flush_std_files.

Adding a a flush there allows that to work, but its fugly:

---
import sys

try:
    print("What... is your quest?")
    # Workaround bug 24864: force the write to be immediate
    sys.stdout.flush()
except:
    sys.stderr.write("Exception in program.\n")
    e = sys.exc_info()[1]
    try:
        # Workaround bug 24864 close the file so flush_std_files doesn't run
        # during interpreter cleanup.
        sys.stdout.close()
    finally:
        raise e from None
        
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 12:46:31 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 10:46:31 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1439549191.91.0.339917662802.issue11380@psf.upfronthosting.co.za>


Robert Collins added the comment:

@zzeeek

For Python 3 pipeline tools you need something like this:

try:
   <all your stuff>
finally:
   try:
       sys.stdout.flush()
   finally:
       try:
           sys.stdout.close()
       finally:  
           try:
               sys.stderr.flush()
           finally:
               sys.stderr.close()

This will:
 - capture any exceptions *you've* raised as the context for the errors raised in this handler
 - expose any exceptions generated during this thing itself
 - prevent the interpreter dying during shutdown in flush_std_files by closing the files (you can't easily wipe out the pending writes that have failed)

You could alternatively reopen stdout and stderr on the same fds, giving you new buffers with no pending writes. Anyhow - the key thing is:

- ensure that at shutdown, there are no pending writes for the interpreter lifecycle to flush, and you won't hit this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Fri Aug 14 12:58:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 10:58:42 +0000
Subject: [issue24864] errors writing to stdout during interpreter exit exit
 with status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439549922.96.0.4738490402.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

Updating the title to reflect my deeper understanding: the only issue here is that we don't alter the exit code.

----------
title: errors writing to stdout are uncatchable and exit with status 0 -> errors writing to stdout during interpreter exit exit with status 0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 13:00:05 2015
From: report at bugs.python.org (zeero)
Date: Fri, 14 Aug 2015 11:00:05 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
In-Reply-To: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>
Message-ID: <1439550005.67.0.905025120124.issue24859@psf.upfronthosting.co.za>


zeero added the comment:

Sorry for the inconvenience.

The format specification can be found in chapter 2.1 in 

http://vector.com/portal/medien/cmc/application_notes/AN-ION-1-3100_Introduction_to_J1939.pdf

So I would write down the field contents in that order

    _fields_ = [('reserved',c_uint8,3),
                ('priority',c_uint8,3),
                ('extended_data_page',c_uint8,1),
                ('data_page',c_uint8,1)
                ...
                ]

I expect the first Byte to be 0x1C when I set priority to 7 but it came out as 0x38, after tunneling it through the Union object.

Reversing the order of the bit fields makes it work like expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Fri Aug 14 13:21:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Aug 2015 11:21:10 +0000
Subject: [issue24864] errors writing to stdout during interpreter exit exit
 with status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439551270.81.0.119933437116.issue24864@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t know much about PDB, but if this is just about setting the exit code, it may be a dupe of Issue 5319. The fix proposed there is a new Py_FinalizeEx() API that returns an exit status, if I remember correctly.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Fri Aug 14 14:48:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2015 12:48:05 +0000
Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process
 tree
In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za>
Message-ID: <1439556485.08.0.0777286650349.issue24862@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'll let someone else analyze this in detail if they want to, but I'll just note that mixing multiprocessing and threads is not a good idea and will lead to all sorts of strangeness.  Especially if you are using the unix default of fork for multiprocessing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24862>
_______________________________________

From report at bugs.python.org  Fri Aug 14 14:52:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2015 12:52:03 +0000
Subject: [issue24863] Incoherent bevavior with umlaut in regular expressions
In-Reply-To: <1439536062.63.0.589470343497.issue24863@psf.upfronthosting.co.za>
Message-ID: <1439556723.84.0.533830970161.issue24863@psf.upfronthosting.co.za>


R. David Murray added the comment:

Don't be embarrassed; a report like this turns up on this tracker about every three or four months.  Unfortunately there's nothing we can do to make the situation better because of backward compatibility concerns.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24863>
_______________________________________

From report at bugs.python.org  Fri Aug 14 15:00:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2015 13:00:21 +0000
Subject: [issue24866] Boolean representation of Q/queue objects does not fit
 behaviour of lists etc.
In-Reply-To: <1439546761.55.0.496059409555.issue24866@psf.upfronthosting.co.za>
Message-ID: <1439557221.91.0.912989803295.issue24866@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe this is intentional; see the documentation of the "empty' method for the motivation.  The reason for not just reflecting the result of an empty call in __bool__ is that not doing so forces you to use empty, which gives you an opportunity to learn about the lack of guarantees.  And every time you use it, or read it in someone else's code, you are reminded that a Queue is *different* from a list in this very important way.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24866>
_______________________________________

From report at bugs.python.org  Fri Aug 14 15:29:01 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Aug 2015 13:29:01 +0000
Subject: [issue24865] IDLE crashes on entering diacritical mark (Alt-E) on Mac
 OS X
In-Reply-To: <1439543421.01.0.111029936537.issue24865@psf.upfronthosting.co.za>
Message-ID: <1439558941.55.0.33832382.issue24865@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is due to an old Tk bug (http://sourceforge.net/p/tktoolkit/bugs/2722/) still present in the Apple-supplied versions of Tcl/Tk 8.5 on OS X.  See https://www.python.org/download/mac/tcltk/ and/or Issue22566. If you are using Python 3.4.x from a python.org installer, install a newer version of Tcl/Tk 8.5 in /Library/Frameworks (not /System/Library/Frameworks) from ActiveState or build your own.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> International keyboard makes IDLE crash on OSX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24865>
_______________________________________

From report at bugs.python.org  Fri Aug 14 15:40:23 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 14 Aug 2015 13:40:23 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1439559623.17.0.411630117694.issue24801@psf.upfronthosting.co.za>


Mark Roseman added the comment:

There is no notion of middle button on Mac, hence right button is B2. It's documented. Current Tk 8.6 has even removed the <<PasteSelection>> binding from B2 on Aqua because of this (I've filed a Tk bug report to backport this to 8.5). 8.6 also defines a <<ContextMenu>> virtual event, which on Mac is tied to B2.

Mac UI guidelines define use of 'right button' (when available) to be used for context menu clicks.

So yeah, we should change this. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24801>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:17:58 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 14 Aug 2015 14:17:58 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1439561878.72.0.0380403856747.issue24844@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24844>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:33:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 14:33:50 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1439562830.88.0.0727598495309.issue24801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, so this is a workaround of 8.5- bug. Then looks reasonable to me.

Added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24801>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:34:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 14:34:00 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1439562840.46.0.797171594504.issue24801@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24801>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:26:22 2015
From: report at bugs.python.org (David Griffin)
Date: Fri, 14 Aug 2015 15:26:22 +0000
Subject: [issue24867] Asyncio get_frame fails with native coroutines
Message-ID: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>


New submission from David Griffin:

I've been playing around with native coroutines and asyncio, and came across an issue with retrieving exceptions from tasks: The get_frame method on a Task in asyncio fails with an AttibuteError because it assumes that gi_frame as the attribute containing the stack frame; with native coroutines it's cr_frame.

I've attached a quick patch that just uses hasattr to see if gi_frame is present, and if not try cr_frame. This may not be the most elegant solution, but it does fix the issue. If there's any other stuff I can provide to help with this (within reason), just say the word.

----------
components: asyncio
files: fix_asyncio_task_get_frame.diff
keywords: patch
messages: 248589
nosy: David Griffin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio get_frame fails with native coroutines
versions: Python 3.5
Added file: http://bugs.python.org/file40179/fix_asyncio_task_get_frame.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:27:37 2015
From: report at bugs.python.org (David Griffin)
Date: Fri, 14 Aug 2015 15:27:37 +0000
Subject: [issue24867] Asyncio Task.get_stack fails with native coroutines
In-Reply-To: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>
Message-ID: <1439566057.11.0.368388664785.issue24867@psf.upfronthosting.co.za>


David Griffin added the comment:

It should be noted that when I said get_frame in the original comment, I actually meant get_stack

----------
title: Asyncio get_frame fails with native coroutines -> Asyncio Task.get_stack fails with native coroutines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:32:52 2015
From: report at bugs.python.org (Paul Murphy)
Date: Fri, 14 Aug 2015 15:32:52 +0000
Subject: [issue24851] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1439412048.1.0.772925582506.issue24851@psf.upfronthosting.co.za>
Message-ID: <1439566372.64.0.130914888992.issue24851@psf.upfronthosting.co.za>


Paul Murphy added the comment:

...
#pragma GCC optimize ("no-optimize-sibling-calls")
...

Does preserve the desired behavior under -O2 and -O3, probably a bit nicer than using O0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24851>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:48:22 2015
From: report at bugs.python.org (Andre Merzky)
Date: Fri, 14 Aug 2015 15:48:22 +0000
Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process
 tree
In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za>
Message-ID: <1439567302.81.0.93504940878.issue24862@psf.upfronthosting.co.za>


Andre Merzky added the comment:

As mentioned in the PS, I understand that the approach might be questionable.  But (a) the attached test shows the problem also for watcher *processes*, not threads, and (b) an error should be raised in unsupported uses, not a silent, unexpected behavior which mimics success.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24862>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:54:20 2015
From: report at bugs.python.org (jack)
Date: Fri, 14 Aug 2015 15:54:20 +0000
Subject: [issue24868] Python start
Message-ID: <1439567660.73.0.152242410467.issue24868@psf.upfronthosting.co.za>


New submission from jack:

I just installed Python 3.4.3 on a 32-bit machine, 2 GB memory, Win XP SP3. When I try to start IDLE, pythonw.exe appears briefly in the Windows Task Manager, then disappears, and nothing else happens. If I run just python.exe in a command window, that runs OK. The same behavior happens after installing version 2.7.10. This happens for both of these versions, regardless of whether the other one is installed or not. The same also happened for version 3.1.2.

On the other hand, version 2.5 runs just fine. I tried all this also in Windows Safe Mode, where there were only about half a dozen core Windows processes in the task manager, with the same result.

----------
components: IDLE
messages: 248593
nosy: jack
priority: normal
severity: normal
status: open
title: Python start
type: crash
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:53:01 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 16:53:01 +0000
Subject: [issue24863] Incoherent bevavior with umlaut in regular expressions
In-Reply-To: <1439536062.63.0.589470343497.issue24863@psf.upfronthosting.co.za>
Message-ID: <1439571181.71.0.285403329968.issue24863@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24863>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:58:07 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Aug 2015 16:58:07 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439571487.8.0.444432274764.issue17570@psf.upfronthosting.co.za>


Carol Willing added the comment:

Zach, Steve, Ezio: The latest patch is ready to be committed. Thanks.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:01:07 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 17:01:07 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439571667.02.0.0137299252612.issue17570@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The part of the patch that I pointed out in my previous message hasn't changed, and is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:01:31 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 17:01:31 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439571691.03.0.102462916008.issue17570@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:06:03 2015
From: report at bugs.python.org (Robert Escriva)
Date: Fri, 14 Aug 2015 17:06:03 +0000
Subject: [issue24869] shlex lineno inaccurate with certain inputs
Message-ID: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za>


New submission from Robert Escriva:

The newlines calculated by the shlex module are inaccurate for certain inputs with comments inline.  I've attached a simple script that illustrates the problem.

My assumption here is that the lineno is supposed to match a line related to the current token.  I'm trying to use changes in the lineno to aggregate tokens into commands.  This may not be an intended use case.

----------
components: Library (Lib)
files: badlex.py
messages: 248596
nosy: rescrv
priority: normal
severity: normal
status: open
title: shlex lineno inaccurate with certain inputs
versions: Python 3.4
Added file: http://bugs.python.org/file40180/badlex.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24869>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:27:29 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Aug 2015 17:27:29 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439573249.44.0.139496187124.issue17570@psf.upfronthosting.co.za>


Carol Willing added the comment:

Zach, Sorry for not comprehending your comment re: latest patch correctly.

Since Rietveld isn't available on devguide, which makes comparison of patches difficult (at least for me), here's some proposed wording to see if I am understanding your comment correctly. If so, I will submit a new patch. Thanks.


Suggested wording for:

Minimal Configuration
---------------------
To use Mercurial as a committer (both of your and others? patches),
you should set up some basic options in your configuration file.
On all platforms, you must edit ~/.hgrc. On Windows, TortoiseHg has a
graphical settings dialog for most options, meaning you don?t need to edit
the file directly if you find a graphical interface more helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:10:29 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 18:10:29 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <20150814181021.33575.74548@psf.io>


Roundup Robot added the comment:

New changeset cf3a62a8d786 by Brett Cannon in branch '3.5':
Issue #24492: make sure that ``from ... import ...` raises an
https://hg.python.org/cpython/rev/cf3a62a8d786

New changeset bbe6b215df5d by Brett Cannon in branch '3.5':
Merge from 3.5.0 for issue #24492
https://hg.python.org/cpython/rev/bbe6b215df5d

New changeset b0a6bba16b9c by Brett Cannon in branch 'default':
Merge from 3.5 for issue #24492
https://hg.python.org/cpython/rev/b0a6bba16b9c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24492>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:11:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:11:34 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1439575894.7.0.709810757292.issue24492@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have merged my 3.5.0 patch into 3.5 and default, so that should fix the issue Armin and CFFI was having.

----------
assignee: larry -> brett.cannon
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24492>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:18:24 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:18:24 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1439576303.99.0.516702364216.issue23810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Merging with the other issue so there is a single place to track this

----------
superseder:  -> Suboptimal stacklevel of deprecation warnings for formatter and imp modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:18:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:18:34 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1439576313.99.0.435164116654.issue23810@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:18:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:18:57 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1439576337.98.0.904661976509.issue23810@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
superseder: Suboptimal stacklevel of deprecation warnings for formatter and imp modules -> The new import system makes it impossible to correctly issue a deprecation warning for a module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:28:34 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 18:28:34 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439576914.96.0.802505530582.issue17570@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sorry, I don't think we're on the same page yet :).  My issue was with a different hunk further down.

Looking at it again, the fix I want is simple enough I'll just do it at commit; I'll get it later today.

----------
assignee: willingc -> zach.ware
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:30:49 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:30:49 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439577049.9.0.163635632987.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have merged over issue #23810 because they are aiming to solve the same problem and the conversation is split too much.

Just thinking out loud, this situation is compounded by the fact that importlib itself has some warnings and so automatically stripping out stack frames might make those warnings look odd.

Still not sure if Larry considers this a release blocker for 3.5.0. And any solution will need to be solved in warnings.py and _warnings.c.

Some days I really hate our warnings system.

----------
dependencies:  -Suboptimal stacklevel of deprecation warnings for formatter and imp modules
keywords: +3.2regression
priority: normal -> release blocker
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:30:59 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 18:30:59 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439577059.45.0.93205655117.issue24305@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> larry
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:24:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Aug 2015 19:24:31 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439580271.57.0.0128153483092.issue24305@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Frames can be skipped only for warnings issued by imported module code, not for warnings issued by import machinery itself.

I propose following algorithm:

Before executing module code push the current frame and the number of frames to skip in global stack in the warnings module, and pop it after execution (public context manager can help). In warnings.warn() skip stacklevel frames and if saved frame was skipped, skip corresponding additional number of frames. Repeat for all saved frames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:27:00 2015
From: report at bugs.python.org (Erik Bray)
Date: Fri, 14 Aug 2015 19:27:00 +0000
Subject: [issue24766] Subclass of property doesn't preserve instance __doc__
 when using doc= argument
In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za>
Message-ID: <1439580420.89.0.724692626702.issue24766@psf.upfronthosting.co.za>


Erik Bray added the comment:

Sorry for the hold up.  Attached is another diff providing a test.  I think this is all that's really needed (since this is just a special case of the issue already tested for in this particular test class.

----------
Added file: http://bugs.python.org/file40181/property-doc-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24766>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:31:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 19:31:26 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439580686.48.0.483209831849.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Will that be thread-safe? Plus storing that value in a way that _warnings and warnings can read will require something like a single-item list that can be mutated in-place.

The other option is to teach warnings to skip anything coming from importlib/_bootstrap* unless stacklevel==1 and that frame happens to be in the importlib code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:32:28 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Aug 2015 19:32:28 +0000
Subject: [issue24766] Subclass of property doesn't preserve instance __doc__
 when using doc= argument
In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za>
Message-ID: <1439580748.21.0.190932489907.issue24766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Larry, can we get this into 3.5?  I'll create a pull-request in a couple days.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24766>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:35:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 19:35:26 +0000
Subject: [issue24867] Asyncio Task.get_stack fails with native coroutines
In-Reply-To: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>
Message-ID: <20150814193520.36727.17924@psf.io>


Roundup Robot added the comment:

New changeset 53d2a7c023bc by Yury Selivanov in branch '3.4':
Issue #24867: Fix Task.get_stack() for 'async def' coroutines
https://hg.python.org/cpython/rev/53d2a7c023bc

New changeset d25022765186 by Yury Selivanov in branch '3.5':
Merge 3.4 (Issue #24867)
https://hg.python.org/cpython/rev/d25022765186

New changeset c0b7829e3074 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24867)
https://hg.python.org/cpython/rev/c0b7829e3074

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:37:17 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Aug 2015 19:37:17 +0000
Subject: [issue24867] Asyncio Task.get_stack fails with native coroutines
In-Reply-To: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>
Message-ID: <1439581037.97.0.389895073645.issue24867@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Looks like we didn't have unittests for Task.get_stack()/Task.print_stack().

Anyways, it's now fixed, I'll make a PR for Larry to get this in 3.5.0rc2.

----------
assignee:  -> yselivanov
nosy: +larry
priority: normal -> release blocker
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:40:41 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 14 Aug 2015 19:40:41 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439581241.79.0.870887043769.issue24305@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

For 3.4/3.5 purposes, I propose a simpler algorithm: first, define a function which takes a module name and returns true if it is part of the internal warning machinery and false otherwise. This is easy because we know what import machinery we ship.

Then, to walk the stack in warnings.py, do something like:

frame = sys._get frame(1)
if is_import_machinery(frame.module_name):
  skip_frame = lambda modname: False
else:
  skip_frame = is_import_machinery
def next_unskipped_frame(f):
  new = f
  while new is f or skip_frame(new.module_name):
    new = new.caller
for i in range(stacklevel - 1):
  frame = next_unskipped_frame(frame)

This produces reasonable behavior for warnings issued by both regular user code and by warnings issued from inside the warning machinery, and it avoids having to explicitly keep track of call depths.

Then we can worry about coming up with an all-singing all-dancing generalized version for 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:53:49 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Aug 2015 19:53:49 +0000
Subject: [issue24866] Boolean representation of Q/queue objects does not fit
 behaviour of lists etc.
In-Reply-To: <1439546761.55.0.496059409555.issue24866@psf.upfronthosting.co.za>
Message-ID: <1439582029.33.0.493478674238.issue24866@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24866>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:06:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Aug 2015 20:06:40 +0000
Subject: [issue24849] Add __len__ to map, everything in itertools
In-Reply-To: <1439376436.18.0.92807776881.issue24849@psf.upfronthosting.co.za>
Message-ID: <1439582800.27.0.300883261671.issue24849@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[flying sheep]
> that?s probably the end of this :(

Yes, I think so.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24849>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:13:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 20:13:44 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <20150814201339.47410.76294@psf.io>


Roundup Robot added the comment:

New changeset 49be7fba3568 by Zachary Ware in branch 'default':
Closes #17570: Improve instructions for Windows.
https://hg.python.org/devguide/rev/49be7fba3568

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:17:05 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 20:17:05 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439583425.14.0.53342863312.issue17570@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Made a couple of other fixes while fixing the point I'd already raised:

- Changed all instances of "`...`" to "*...*"
- Changed from "PCbuild\python.exe" to "python.bat"
- Wrapped a couple long lines

Thanks for the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:25:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 20:25:15 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439583915.13.0.513057978165.issue24847@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'll try to get a proper review done before Wednesday.  From a cursory glance, this looks fine, but unpalatable.  The solution I'd really like would be to create proper .vcxprojs for Tcl/Tk/Tix (partly because that would also fix an issue with building with ICC), but that's a *lot* of extra work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:27:19 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Aug 2015 20:27:19 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439584039.79.0.013597575073.issue24847@psf.upfronthosting.co.za>


Zachary Ware added the comment:

To expand on 'unpalatable': I'd rather we not have to carry any patches against the Tcl/Tk sources (Tix I care less about, since we seem to be the de facto maintainers of it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:29:34 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Aug 2015 20:29:34 +0000
Subject: [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1439584174.18.0.908589120978.issue24852@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> It's probably better to remove the document for now

I concur.

> Although, this topic sees lot of change regularly, 
> so it is probably not a good one for the standard
> documentation after all.

This makes sense.  We typically use wiki pages for
this kind of material.  For example, see the debugging
tools page at:
https://wiki.python.org/moin/PythonDebuggingTools

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24852>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:43:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Aug 2015 20:43:02 +0000
Subject: [issue24833] IDLE tabnanny check fails
In-Reply-To: <1439106719.71.0.370110584661.issue24833@psf.upfronthosting.co.za>
Message-ID: <1439584982.87.0.599147766736.issue24833@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think there are two issues here.

1. tabnanny is run on the editor file every time Check Module Alt-X or Run Module F5 is used. However, Tabnanny is only rum after the file has been compiled as syntactically correct.  I don't think that the tokenize module should fail on a file that compiles. Please cut your file to the minimum needed to raise an error.  Then upload the complete traceback.

2. When a TokenError does occur, Idle executes
            except tokenize.TokenError as msg:
                msgtxt, (lineno, start) = msg
This must be the line that failed (the traceback would have said).  It is line 74 in 3.4.3.  (Which version are you using?)  The fix is to add '.args' at the end.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24833>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:43:32 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Aug 2015 20:43:32 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439585012.54.0.231594025876.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Nathaniel's solution is basically what I came up with in issue #23810 except I simply skipped subtracting from the stack level if it was found to be an internal import frame instead of swapping in and out a callable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:00:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Aug 2015 21:00:42 +0000
Subject: [issue24833] IDLE tabnanny check fails
In-Reply-To: <1439106719.71.0.370110584661.issue24833@psf.upfronthosting.co.za>
Message-ID: <20150814210028.47402.30368@psf.io>


Roundup Robot added the comment:

New changeset 724d9b589cfc by Terry Jan Reedy in branch '2.7':
Issue #24833: Add attribute reference needed for 3.x, but optional for 2.7,
https://hg.python.org/cpython/rev/724d9b589cfc

New changeset cce226356477 by Terry Jan Reedy in branch '3.4':
Issue #24833: Add attribute reference needed for 3.x.
https://hg.python.org/cpython/rev/cce226356477

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24833>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:01:32 2015
From: report at bugs.python.org (Mikhail Terekhov)
Date: Fri, 14 Aug 2015 21:01:32 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439586092.45.0.614179632925.issue24769@psf.upfronthosting.co.za>


Changes by Mikhail Terekhov <termim at gmail.com>:


----------
nosy: +termim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:02:38 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Aug 2015 21:02:38 +0000
Subject: [issue24833] IDLE tabnanny check fails
In-Reply-To: <1439106719.71.0.370110584661.issue24833@psf.upfronthosting.co.za>
Message-ID: <1439586158.66.0.939460500462.issue24833@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I fixed the Idle part but would really like to see the cause of the tokenize error.

----------
type:  -> behavior
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24833>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:41:10 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Aug 2015 21:41:10 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1439588470.51.0.87332989089.issue17570@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Zach :D Makes more sense now ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17570>
_______________________________________

From report at bugs.python.org  Sat Aug 15 00:22:38 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 14 Aug 2015 22:22:38 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1439590958.29.0.773290402085.issue24798@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

It seems the switch to '/MT' was consciously intended as Python 3.5 itself is now compiled with '/MT'. 
For now I have patched _msvccompiler.py to use '/MD' and continue to link libraries built with '/MD'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24798>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:13:46 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Aug 2015 23:13:46 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1439594026.67.0.447039314407.issue23749@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:37:57 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Aug 2015 23:37:57 +0000
Subject: [issue24798] _msvccompiler.py doesn't properly support manifests
In-Reply-To: <1438791934.66.0.561634074582.issue24798@psf.upfronthosting.co.za>
Message-ID: <1439595477.83.0.553910777035.issue24798@psf.upfronthosting.co.za>


Steve Dower added the comment:

Those libraries will depend on vcruntime140.dll which is not installed with CPython right now. In order for packages built with future compilers to work we need to statically link that dependency but not ucrt, which there are linker options for.

I'm thinking hard to come up with better approaches, but most of them require predicting the future. Create a new issue if you like or I'll make one when I have something to propose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24798>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:40:21 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Aug 2015 23:40:21 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439595621.7.0.57005859272.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'll submit them upstream if we decide they're what we want, as I've done with other patches for them. Or if we want to figure out reliable builds with avcxproj I'm okay with that too.

The fix that needs testing now is already checked in for 3.5.1. We just need confirmation that it works to merge it into 3.5.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:57:31 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 23:57:31 +0000
Subject: [issue24864] errors writing to stdout during interpreter exit exit
 with status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439596651.06.0.0971844490268.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

This patch is a minimal stab at the issue.

We should do this change because as it stands genuine user affecting errors can be masked both in pipelines and non-pipeline cases.

A more comprehensive patch would also change e.g. Py_Exit, and the various other users of Py_Finalize like freeze.

I'm not sure where to add an automated test for this; it does sane things under my manual testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:58:11 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 23:58:11 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1439596691.15.0.607268383338.issue11380@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, just saw your comment Martin; yes, this does look like a dupe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:58:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 23:58:30 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1439596710.75.0.328601881891.issue11380@psf.upfronthosting.co.za>


Robert Collins added the comment:

Bah, wrong issue. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:58:37 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 23:58:37 +0000
Subject: [issue24864] errors writing to stdout during interpreter exit exit
 with status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439596717.95.0.172635713129.issue24864@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, just saw your comment Martin; yes, this does look like a dupe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Sat Aug 15 02:47:45 2015
From: report at bugs.python.org (Robert Collins)
Date: Sat, 15 Aug 2015 00:47:45 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1439599665.56.0.563093344903.issue5319@psf.upfronthosting.co.za>


Robert Collins added the comment:

I think you need to make the following changes:

 - Py_Exit with a non-zero status code should probably preserve the code rather than replacing it with 1.
 - Ditto in Py_Main.
 - Add a defs entry for Py_FinalizeEx - should be a copy of the Py_Finalize entry with the return type modified.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Sat Aug 15 02:48:35 2015
From: report at bugs.python.org (Robert Collins)
Date: Sat, 15 Aug 2015 00:48:35 +0000
Subject: [issue24864] errors writing to stdout during interpreter exit exit
 with status 0
In-Reply-To: <1439542742.23.0.792306494997.issue24864@psf.upfronthosting.co.za>
Message-ID: <1439599715.59.0.296363868678.issue24864@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24864>
_______________________________________

From report at bugs.python.org  Sat Aug 15 02:52:16 2015
From: report at bugs.python.org (Robert Collins)
Date: Sat, 15 Aug 2015 00:52:16 +0000
Subject: [issue13224] Change str(x) to return only the qualname for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1439599936.43.0.630286688722.issue13224@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, so needs more work. Moving back to patch review.

----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Sat Aug 15 03:49:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Aug 2015 01:49:54 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439567660.73.0.152242410467.issue24868@psf.upfronthosting.co.za>
Message-ID: <1439603394.87.0.546056019122.issue24868@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For 3.4.3, run 'python -m idlelib' in the command window and you should see some error message.  But first run 'python' and at the >>> prompt, 'import tkinter' to see if tkinter is working properly.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 05:08:44 2015
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 Aug 2015 03:08:44 +0000
Subject: [issue24870] surrogateescape is too slow
Message-ID: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>


New submission from INADA Naoki:

surrogateescape is recommended way to mix binary data in string protocol.
But surrogateescape is too slow and it cause usability problem.

One actual problem is: https://github.com/PyMySQL/PyMySQL/issues/366

surrogateescape is slow because errorhandler is called with UnicodeError object.
bs.decode('utf-8', 'surrogateescape') may produce len(bs)/2 error objects internally when bs is random bytes.

surrogateescape is used with ASCII and UTF-8 encoding in ordinal.
Specialized implementation can make it faster.

I want to Python 3.4 and Python 3.5 solve this issue since it's critical problem
for some people.

----------
components: Unicode
messages: 248631
nosy: ezio.melotti, haypo, naoki
priority: normal
severity: normal
status: open
title: surrogateescape is too slow
type: performance
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 05:13:43 2015
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 Aug 2015 03:13:43 +0000
Subject: [issue24870] surrogateescape is too slow
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439608423.88.0.0757117336714.issue24870@psf.upfronthosting.co.za>


INADA Naoki added the comment:

On MacBook Pro (Core i5 2.6GHz), surrogateescape 1MB data takes 250ms.

In [1]: bs = bytes(range(256)) * (4 * 1024)

In [2]: len(bs)
Out[2]: 1048576

In [3]: %timeit x = bs.decode('ascii', 'surrogateescape')
1 loops, best of 3: 249 ms per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 05:13:46 2015
From: report at bugs.python.org (Mikhail Terekhov)
Date: Sat, 15 Aug 2015 03:13:46 +0000
Subject: [issue24871] freeze.py doesn't work on x86_64 Linux out of the box
Message-ID: <1439608426.85.0.852954620494.issue24871@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov:

On 64-bit Linux freeze.py uses lib instead of lib64 when constructing
path to Makefile etc. Using sysconfig fixes this issue.


Without encodings.ascii resulting program fails with the following error:

Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: unknown encoding: ANSI_X3.4-1968
Aborted

Attached patch fixes both issues.

----------
components: Demos and Tools
files: freeze-lib64.diff
keywords: patch
messages: 248633
nosy: termim
priority: normal
severity: normal
status: open
title: freeze.py doesn't work on x86_64 Linux out of the box
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40182/freeze-lib64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24871>
_______________________________________

From report at bugs.python.org  Sat Aug 15 06:06:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 04:06:58 +0000
Subject: [issue24866] Boolean representation of Q/queue objects does not fit
 behaviour of lists etc.
In-Reply-To: <1439546761.55.0.496059409555.issue24866@psf.upfronthosting.co.za>
Message-ID: <1439611618.97.0.330203864031.issue24866@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

RDM is correct.  Queues having qsize() instead of __len__() was an intentional part of the design.  Code relying on the boolean value would be fragile.   

FWIW, this code is very old (originally designed by Guido when dinosaurs roamed the earth) and it is far too late to alter its API.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24866>
_______________________________________

From report at bugs.python.org  Sat Aug 15 10:32:47 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 15 Aug 2015 08:32:47 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439627567.2.0.350956207461.issue24305@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

Yeah, yours is probably better in fact, I was just trying to make the semantics as obvious as explicit as possible for a comment :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sat Aug 15 14:09:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Aug 2015 12:09:23 +0000
Subject: [issue24870] surrogateescape is too slow
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439640563.73.0.12169303641.issue24870@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why are bytes being escaped in a binary blob? The reason to use surrogateescape is when you have data that is mostly text, should be processed as text, but can have occasional binary data.  That wouldn't seem to apply to a database binary blob.

But that aside, if you want to submit a patch to speed up surrogateescape without changing its functionality, I'm sure it would be considered.  It would certainly be useful for the email library, which currently does do the stupid thing of encoding binary message attachments using surrogateescape (and I'm guessing the reason pymysql does it is something similar to why email does it: the code would need to be significantly reorganized to do things right).

----------
nosy: +r.david.murray
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 14:55:45 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 15 Aug 2015 12:55:45 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
In-Reply-To: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>
Message-ID: <1439643345.26.0.508788911271.issue24859@psf.upfronthosting.co.za>


eryksun added the comment:

It seems you want a BigEndianStructure:

    from ctypes import *

    class SAEJ1939MsgId(BigEndianStructure):

        _fields_ = (('reserved',           c_uint8, 3),
                    ('priority',           c_uint8, 3),
                    ('extended_data_page', c_uint8, 1),
                    ('data_page',          c_uint8, 1),
                    ('pdu_format',         c_uint8),
                    ('pdu_specific',       c_uint8),
                    ('source_address',     c_uint8))
        
        def __init__(self, *args, pgn=0, **kwds):
            super().__init__(*args, **kwds)
            if pgn > 0:
                self.pgn = pgn

        def __int__(self):
            return int.from_bytes(self, 'big')

        @property
        def pgn(self):
            """pgn is an 18-bit number consisting of EDP, DP, PF, and PS"""
            return (int(self) >> 8) & 0x3FFFF

        @pgn.setter
        def pgn(self, value):
            value |= self.priority << 18
            view = (c_char * 3).from_buffer(self)
            view[:] = value.to_bytes(3, 'big')

        @classmethod
        def from_bytes(cls, msg_id):
            return cls.from_buffer_copy(msg_id)

        @classmethod
        def from_integer(cls, msg_id):
            msg_id_bytes = msg_id.to_bytes(sizeof(cls), 'big')
            return cls.from_buffer_copy(msg_id_bytes)

Example:

    >>> a = SAEJ1939MsgId(priority=7, source_address=3)
    >>> hex(int(a))
    '0x1c000003'

    >>> b = SAEJ1939MsgId(pgn=0xf004, priority=7, source_address=3)
    >>> hex(int(b))
    '0x1cf00403'
    >>> b.priority
    7
    >>> b.pdu_format
    240
    >>> b.pdu_specific
    4
    >>> b.source_address
    3

    >>> c = SAEJ1939MsgId.from_integer(int(b))
    >>> hex(int(c))
    '0x1cf00403'

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Sat Aug 15 14:56:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Aug 2015 12:56:05 +0000
Subject: [issue24870] surrogateescape is too slow
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439643365.83.0.32085855256.issue24870@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Few months ago I wrote a patch that drastically speeds up encoding and decoding with surrogateescape and surrogatepass error handlers. However it causes 25% regression in decoding some UTF-8 data (U+0100-U+07FF if I remember correct) with strict error handler, so it needs some work. I hope that it is possible to rewrite UTF-8 decoder so that avoid a regression. The patch was postponed until 3.5 is released. In any case the patch is large and complex enough to be new feature that can appear only in 3.6.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:06:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Aug 2015 13:06:59 +0000
Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass
 error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439644019.22.0.35180025262.issue24870@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
title: surrogateescape is too slow -> Optimize coding with surrogateescape and surrogatepass error handlers
Added file: http://bugs.python.org/file40183/faster_surrogates_hadling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:11:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Aug 2015 13:11:30 +0000
Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete
 statement parsing for detection
In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za>
Message-ID: <1439644290.51.0.0226777466874.issue21718@psf.upfronthosting.co.za>


R. David Murray added the comment:

Attached is the patch ported to python2.7.  However, the test doesn't fail for me before I apply (compile) the fix.

----------
Added file: http://bugs.python.org/file40184/f67fa9c898a4713850e16934046f0fe2cba8c44c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21718>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:11:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Aug 2015 13:11:38 +0000
Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete
 statement parsing for detection
In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za>
Message-ID: <1439644298.11.0.50441854294.issue21718@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: commit review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21718>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:22:01 2015
From: report at bugs.python.org (Andre Merzky)
Date: Sat, 15 Aug 2015 13:22:01 +0000
Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process
 tree
In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za>
Message-ID: <1439644921.5.0.0461716476381.issue24862@psf.upfronthosting.co.za>


Andre Merzky added the comment:

Looking a little further, it seems indeed to be a problem with ignoring SIGCHLD.  The behavior has been introduced with [1] at [2] AFAICS, which is a response to issue15756 [3].  IMHO, that issue should have been resolved with raising an exception instead of assuming that the child exited successfully (neither is true in this case, not the 'exited' nor the 'successfully').

[1] https://hg.python.org/cpython/rev/484c50bf445c/
[2] https://github.com/python/cpython/blob/2.7/Lib/subprocess.py#L1370
[3] http://bugs.python.org/issue15756

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24862>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:33:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Aug 2015 13:33:26 +0000
Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process
 tree
In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za>
Message-ID: <1439645606.36.0.47738968861.issue24862@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24862>
_______________________________________

From report at bugs.python.org  Sat Aug 15 18:01:21 2015
From: report at bugs.python.org (Ilya Kulakov)
Date: Sat, 15 Aug 2015 16:01:21 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1439654481.38.0.497055397104.issue17797@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

I see issue to be fixed but patch wasn't applied yet. Is it still supposed to be included in 3.5 or there is something wrong?

----------
nosy: +Ilya.Kulakov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Sat Aug 15 18:53:22 2015
From: report at bugs.python.org (zeero)
Date: Sat, 15 Aug 2015 16:53:22 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
In-Reply-To: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>
Message-ID: <1439657602.96.0.970279420833.issue24859@psf.upfronthosting.co.za>


zeero added the comment:

Thanks for the advise. I'll give it a try.

So ctypes.Structure is always little endian regardless from the underlying architecture. 
I just checked on a raspberry pi 2 that should be a big endian device, and got the same results as before.

I'm still not sure if it's right that ctypes.Structure swaps the order of the bit items but apparently it's the intended behaviour.

I'll close the issue then. Thanks again.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Sat Aug 15 20:31:50 2015
From: report at bugs.python.org (jack)
Date: Sat, 15 Aug 2015 18:31:50 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439603394.87.0.546056019122.issue24868@psf.upfronthosting.co.za>
Message-ID: <55CF92B3.2010407@gmail.com>


jack added the comment:

Thanks a lot for the tip. This revealed that Python 3.4.3 was looking 
for tcl from Python 2.2 on my machine. That version had been on my 
machine more than 10 years ago, but was no longer there. It had left 
behind a whole bunch of registry crumbs, which I removed. I then 
uninstalled all the versions on my machine and reinstalled 3.4.3. That 
did the trick. The question is, why would installing 3.4.3 or other 
versions be contaminated by stuff from another version, especially an 
ancient one?

Jack

On 8/14/2015 8:49 PM, Terry J. Reedy wrote:
> Terry J. Reedy added the comment:
>
> For 3.4.3, run 'python -m idlelib' in the command window and you should see some error message.  But first run 'python' and at the>>>  prompt, 'import tkinter' to see if tkinter is working properly.
>
> ----------
> nosy: +terry.reedy
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue24868>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 20:50:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 18:50:01 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1439664601.54.0.172363154875.issue17797@psf.upfronthosting.co.za>


Steve Dower added the comment:

Rereading the discussion, there seems to be agreement that this is an enhancement. It does not apply for Python 3.5 (which requires a compiler without the bug that causes this), and Python 3.4 is no longer eligible for enhancements. I'm closing this as out of date.

The patches will be here, so anyone who is rebuilding Python 3.4 or earlier for their own use with VS 2012 is welcome to apply the patch themselves.

----------
resolution: fixed -> out of date
status: open -> closed
type:  -> enhancement
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Sat Aug 15 21:16:40 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Aug 2015 19:16:40 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439567660.73.0.152242410467.issue24868@psf.upfronthosting.co.za>
Message-ID: <1439666200.94.0.245592171752.issue24868@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> ... why would installing 3.4.3 or other versions be contaminated by stuff from another version, especially an ancient one?

I don't know.  Steve has revamped the installer for 3.5.

Steve: This issue is solved and I am closing it, but I hope you either have or are able to make the installer more robust against this sort of situation.  It seems to be fairly common.  Could a 'purge all traces of tcl and python' option be added?

----------
nosy: +steve.dower
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 21:20:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 19:20:38 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Message-ID: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>


New submission from Steve Dower:

The C Runtime used for Python 3.5 and later consists of two DLLs. One, ucrtbase.dll, is an operating system component that can be assumed to be available and up to date (or will be installed by the Python installer).

The second DLL is vcruntimeXXX.dll, where XXX is a version number that is directly tied to the version of the compiler that was used to build. 

In order to maintain version-independence from the C Runtime, vcruntime should be statically, rather than dynamically, linked. This ensures that extensions linking to a different vcruntime will run on machines with builds of Python prior to that version being available (i.e. we'd have needed a time machine to be able to ensure all future versions of vcruntime are available). This would essentially put us back in a place where you need to match compilers to build extensions.

To achieve this semi-static linking, the following options must be used.

cl /c /MT /GL <file.c>
link <file.obj> /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib

Building with /MT links everything statically, and the last two linker options substitute the non-static ucrtbase.dll. /GL and /LTCG (link-time code generation) ensures the correct stubs for dynamic linking are created - compiling with /MD instead of /MT generates these at compile time instead of link time.

One problem appears to be including custom-built static libraries that compiled objects with /MD instead of /MT:

cl /C testlib.c /MD
lib testlib.c
cl /C test.c /MT /GL
link test.obj testlib.lib /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib
<linker errors occur>

These are because testlib.lib pulls in the MSVCRT library (which indirectly includes the dynamic vcruntime.lib and ucrt.lib) instead of the LIBCMT library (which indirectly includes the static libvcruntime.lib and libucrt.lib). Building test.c with /MT pulls in LIBCMT and conflicts ensue.

This may be fixed by using /MD for test.c, but this causes a dependency on vcruntimeXXX.dll. It appears that it can also be fixed by excluding MSVCRT from the final link step:

link test.obj testlib.lib /LTCG **/NODEFAULTLIB:msvcrt.lib** /NODEFAULTLIB:libucrt.lib ucrt.lib

Christoph - I know you've already patched your _msvccompiler.py to use /MD instead of /MT, but I wonder if you could try reverting that and adding the /NODEFAULTLIB:msvcrt.lib linker option instead and see if that helps? For my test cases it's been fine, but you have a much larger collection of libraries to work with. I'm very keen to see if this is a satisfactory solution.

FWIW, I've spent a lot of time considering ways we could actually include vcruntime*.dll such that old Python versions would include or get future versions of the DLL and have come up with nothing. Requiring users to install every VC redistributable that is released is unacceptable to me, and I would much rather help extension builders to create extensions that do not require extra DLLs.

----------
assignee: steve.dower
components: Windows
messages: 248646
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Add /NODEFAULTLIB:MSVCRT to _msvccompiler
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Aug 15 21:20:51 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 19:20:51 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439666451.36.0.52980751943.issue24872@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Aug 15 21:55:20 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 19:55:20 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439567660.73.0.152242410467.issue24868@psf.upfronthosting.co.za>
Message-ID: <1439668520.38.0.732519627158.issue24868@psf.upfronthosting.co.za>


Steve Dower added the comment:

Actually, that's a pretty good idea (I'd certainly use it), though it would come with a big fat warning sign. I'll add an issue for it.

Whether it would fix this particular issue is unclear. I suspect this one is due to environment variables (TCL_LIBRARY overrides tkinter's regular search) which could not be aggressively cleaned up on uninstall. I have no idea whether older installers used to set that environment variable, but recent 2.7 and 3.5 don't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:00:39 2015
From: report at bugs.python.org (jack)
Date: Sat, 15 Aug 2015 20:00:39 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439668520.38.0.732519627158.issue24868@psf.upfronthosting.co.za>
Message-ID: <55CFA78C.4080901@gmail.com>


jack added the comment:

If you zap all existing traces of Python and tcl it would affect users 
who need to run multiple versions. I would suggest completely 
encapsulating each version and all its dependencies, in order to avoid 
mutual interference.

On 8/15/2015 2:55 PM, Steve Dower wrote:
> Steve Dower added the comment:
>
> Actually, that's a pretty good idea (I'd certainly use it), though it would come with a big fat warning sign. I'll add an issue for it.
>
> Whether it would fix this particular issue is unclear. I suspect this one is due to environment variables (TCL_LIBRARY overrides tkinter's regular search) which could not be aggressively cleaned up on uninstall. I have no idea whether older installers used to set that environment variable, but recent 2.7 and 3.5 don't.
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue24868>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:01:13 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:01:13 +0000
Subject: [issue24873] Add "full cleanup" checkbox to uninstaller
Message-ID: <1439668873.0.0.348804017402.issue24873@psf.upfronthosting.co.za>


New submission from Steve Dower:

On uninstallation, we should display a checkbox to aggressively clean up the install. This would include:

* delete the main registry key and all children, regardless of whether we created them or not
* delete the main install directory and all subdirectories and files

This may corrupt some programs, essentially those that install packages directly into a Python install or register their own search paths in the registry (which is actually a valid thing for them to do). There will be an extra confirmation prompt if the checkbox is selected, but it'll still be easier than finding all the paths and deleting them manually.

----------
components: Installation, Windows
messages: 248649
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add "full cleanup" checkbox to uninstaller
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24873>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:02:16 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:02:16 +0000
Subject: [issue24873] Add "full cleanup" checkbox to uninstaller
In-Reply-To: <1439668873.0.0.348804017402.issue24873@psf.upfronthosting.co.za>
Message-ID: <1439668936.85.0.998767019044.issue24873@psf.upfronthosting.co.za>


Steve Dower added the comment:

(Terry - FYI as it was your suggestion, but feel free to un-nosy yourself if you want.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24873>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:04:46 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 15 Aug 2015 20:04:46 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439669086.19.0.0249196494874.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Thank you for looking into this.

I just tried '/NODEFAULTLIB:msvcrt.lib' with Pillow and matplotlib but still get the linker errors:

tiff.lib(jbig.obj) : error LNK2001: unresolved external symbol __imp_memchr

freetype.lib(ftbase.obj) : error LNK2001: unresolved external symbol __imp_strrchr
freetype.lib(truetype.obj) : error LNK2001: unresolved external symbol __imp_strstr
freetype.lib(type1.obj) : error LNK2001: unresolved external symbol __imp_memchr
freetype.lib(sfnt.obj) : error LNK2001: unresolved external symbol __imp_memchr

Looks like I'll have to rebuild all the 3rd party libraries with '/MT' and link DLLs with '/NODEFAULTLIB:libucrt.lib ucrt.lib' to remove the dependency on vcruntimeXXX.dll.

This change should probably be mentioned in the release notes.

Maybe also bring it to the attention of Ilan Schnell (ilan) and Cournapeau David (cdavid) who build packages for Anaconda and Canopy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:19:31 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 15 Aug 2015 20:19:31 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439669971.36.0.160229578548.issue24872@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

What effect does this static linking of the VC runtime have on libraries that extension modules link at dynamically ?

E.g. say I have an extension which links against an ODBC driver DLL using a different VC runtime than the one used to build Python.

In the past, the has never been an issue, so adding a requirement to rebuild external libraries is pretty much a no-go for Python extension writing. You often have the case where you cannot rebuild the external libraries you want to link against.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:22:06 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:22:06 +0000
Subject: [issue24868] Python start
In-Reply-To: <1439567660.73.0.152242410467.issue24868@psf.upfronthosting.co.za>
Message-ID: <1439670126.75.0.404087362103.issue24868@psf.upfronthosting.co.za>


Steve Dower added the comment:

I can't vouch for Python 2.2, but Python 3.5 and later should not have any interference with other Python versions unless you choose to add it to PATH. We have kept all installed files and registry keys in their own versioned paths for a long time now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24868>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:41:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:41:36 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439671296.92.0.640361157336.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

I guess those imports are expected to come from vcruntime. Rebuilding the static libraries may be the only option then, sorry (on the bright side, VC 14 has much better C99 support than earlier versions, so things should be better once we get past the problems caused by change).

Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes.

* depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves)
* CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management.
* potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself)

The parts of the new CRT that will be statically linked are (broadly):
* process/DLL initialization
* exception handling
* some functions that are also compiler intrinsics

The first two don't apply for C static libraries, and even seem to be okay if the static lib is the one declaring main(). I did make the argument that they should be statically linked by default, but the response was that security patches may need to be applied to those parts of the code (particularly exception handling - corrupting the stack and then raising an exception is a great way to jump to whatever code you like). If Python shipped this DLL, it would not be updateable anyway, so static linking is a considered risk that could cause us to someday ship a security update due to a change in the CRT (exactly as has been the case for every other version of Python - nothing new here).

The last item is what Christoph just hit - because the compiler may partially inline those functions (memchr, strchr, etc.) for fast paths, it needs intimate knowledge about how they are implemented. As a result, they go in the compiler-version specific DLL and not the generic one. This lets the implementations make assumptions about what conditions the compiler has already tested and/or proven, but since this could change with compiler version the implementation may also change.

Since the functions are stateless, there's no issue if they happen to be included in a final DLL multiple times for different versions, but that will only happen if the original library is compiled with /MT (I checked - there's no way to override the code generated here under /MD other than to change the compiler option, but link-time code generation should be able to take /MT-compiled libraries and dynamically link them).

So basically, there are no new restrictions on linking to dynamic libraries. The biggest concern would be if those libraries depend on msvcr100.dll and worked with Python 3.4 (which shipped msvcr100), they may not work on Python 3.5 unless the user has obtained msvcr100.dll some other way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sat Aug 15 22:50:41 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:50:41 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439671841.16.0.645387443727.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've made a build of rc1 with the installer fix that's currently being considered for 3.5.0:

https://pythonbuilds.blob.core.windows.net/temp/python-24847-1.exe

(This is a test-marked build that *should not* affect another 3.5 install, but if it does please tell me so I can fix it. After removing it, a Repair on 3.5.0rc1 should fix any issues.)

Currently working on a test build of the fix based on the attached patches, which is the correct fix for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:13:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Aug 2015 21:13:27 +0000
Subject: [issue24873] Add "full cleanup" checkbox to uninstaller
In-Reply-To: <1439668873.0.0.348804017402.issue24873@psf.upfronthosting.co.za>
Message-ID: <1439673207.05.0.68283826205.issue24873@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There are two problem scenarios, which might meed different solutions.
1. Cannot install x.y(.z) for the first time, or if it does install, it does not run.  Zap all may be appropriate.
2, Cannot upgrade installed x.y.z.  This seems to be due to corruption of z.y.z. The current solution seem to be to re-download x.y.z installer (if deleted), which means remembering .z.  Then fixing (maybe). Or zapping x.y.z and maybe fiddling with the registry?  I went through this once and it is mess, and not something for non-expert users.

Would it be sensible for installer to check for TCL_LIBRARY and if found, display value and mention that it might interfere with install?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24873>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:23:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 21:23:07 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
Message-ID: <1439673787.63.0.997592700002.issue24874@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

When a cycle object has fully consumed its input iterable, __reduce__ method uses the returns a space-inefficient result when space-efficient alternative is available.

# Current way of restoring a cycle object with excess info in setstate:
>>> c = cycle(iter('de'))
>>> c.__setstate__((['a', 'b', 'c', 'd', 'e'], 1))
>>> ''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'

# The same result can be achieved in less info in setstate: 
>>> c = cycle(iter('de'))
>>> c.__setstate__((['a', 'b', 'c'], 0))
>>> ''.join(next(c) for i in range(20)) # next 20 values

----------
assignee: rhettinger
components: Extension Modules
messages: 248657
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve pickling efficiency of itertools.cycle
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:24:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Aug 2015 21:24:55 +0000
Subject: [issue24870] surrogateescape is too slow
In-Reply-To: <1439643365.83.0.32085855256.issue24870@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZQAk+niZV6Hgbczq6h-a5HFfWP_FyGy48w2XLLmSzKoA@mail.gmail.com>


STINNER Victor added the comment:

Serhiy: maybe we can start with ascii?

----------
title: Optimize coding with surrogateescape and surrogatepass error handlers -> surrogateescape is too slow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:26:39 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 21:26:39 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439673999.74.0.120704036095.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

A second test build with the attached patches applied directly to 3.5.0rc1. (You'll need to remove the first test build before installing this).

https://pythonbuilds.blob.core.windows.net/temp/python-24847-2.exe

Any confirmation that these work would be appreciated. I don't think we should rewrite the tcl/tk build for 3.5.0 completely at this stage, so this one is my preferred fix for 3.5.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:26:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Aug 2015 21:26:49 +0000
Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass
 error handlers
In-Reply-To: <1439644019.28.0.323969751351.issue24870@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaBO5wxnfxe3idLq_D=_FJwMEFEvPG+-3A--T2A0sc8rQ@mail.gmail.com>


STINNER Victor added the comment:

Oh. I restored the old title because i replied by email with an old email.

----------
title: surrogateescape is too slow -> Optimize coding with surrogateescape and surrogatepass error handlers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:29:10 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 15 Aug 2015 21:29:10 +0000
Subject: [issue24859] ctypes.Structure bit order is reversed - counts from
 right
In-Reply-To: <1439493646.78.0.611197737465.issue24859@psf.upfronthosting.co.za>
Message-ID: <1439674150.41.0.0755514272453.issue24859@psf.upfronthosting.co.za>


eryksun added the comment:

No, ctypes.Structure should use native endianness. So on a little-endian it's the same as ctypes.LittleEndianStructure, and on a big-endian system it's the same as ctypes.BigEndianStructure. ARM processors can work in either mode. IIRC, the Raspberry Pi is built as a little-endian system. Check sys.byteorder to be sure.

----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24859>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:32:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 21:32:26 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439673787.63.0.997592700002.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

When a cycle object has fully consumed its input iterable, __reduce__ method uses the returns a space-inefficient result when space-efficient alternative is available.

# Current way of restoring a cycle object with excess info in setstate:
>>> c = cycle(iter('de'))
>>> c.__setstate__((['a', 'b', 'c', 'd', 'e'], 1))
>>> ''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'

# The same result can be achieved with less information: 
>>> c = cycle(iter('de'))
>>> c.__setstate__((['a', 'b', 'c'], 0))
>>> ''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:32:35 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 21:32:35 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439674355.82.0.295742658622.issue24874@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg248657

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:37:21 2015
From: report at bugs.python.org (Tal Einat)
Date: Sat, 15 Aug 2015 21:37:21 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1439674641.03.0.670688277654.issue20180@psf.upfronthosting.co.za>


Tal Einat added the comment:

I'll commit #3 (unicodeobject.c) when I first get the chance, which should be in a few days.

I'll be happy to improve the rest as needed if someone can find the time to review them!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Sat Aug 15 23:54:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 21:54:15 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439675655.91.0.18464893023.issue24874@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also, looking at the source for itertools.cycle(), it looks like the overall speed could be boosted considerably by looping over the saved list directly rather than allocating a new list iterator every time the cycle loops around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:19:43 2015
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 15 Aug 2015 22:19:43 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439677183.95.0.206975205878.issue24847@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

On running the installer, Windows reports:

"""Windows SmartScreen prevented an unrecognised application from starting. Running this application might put your PC at risk.

Application: Python-24847-2.exe
Publisher: Unknown Publisher"""


When installed, Tkinter appears to work without a problem.

This is on Windows 10 Home (64-bit) without VS 2015.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:30:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 22:30:16 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439677816.33.0.567097234547.issue24874@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40185/time_cycle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:42:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Aug 2015 22:42:03 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1439678523.66.0.576619594657.issue21167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here's the pull request:

https://bitbucket.org/larry/cpython350/pull-requests/4/21167-fix-definition-of-nan-when-icc-used/diff

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:42:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 22:42:36 +0000
Subject: [issue24873] Add "full cleanup" checkbox to uninstaller
In-Reply-To: <1439668873.0.0.348804017402.issue24873@psf.upfronthosting.co.za>
Message-ID: <1439678556.23.0.0393807255177.issue24873@psf.upfronthosting.co.za>


Steve Dower added the comment:

#2 should be fixed with the new installer (not necessarily the 3.5.0a/b/rc versions, but final 3.5.0->3.5.1 and upwards should be fine).

The problems with 3.4's installer seem to be largely due to the pip bootstrap being a critical part of uninstall. I've deliberately made the 3.5 uninstaller not fail if pip won't uninstall cleanly, which should allow upgrades to occur even if the previous install is corrupt.

Another workaround here is to go through Programs and Features, though sometimes it is possible for the entry to not appear. That should be fixed with 3.5 (at least through the supported ways of installing it), but as I'm not 100% sure what causes the issue with earlier versions I can't guarantee it yet.

There's actually a sizable list of environment variables that could cause problems (PYTHONPATH, PYTHONHOME, etc.), worse on Windows because it's so much more common to have multiple versions installed and to set system-level environment variables. Maybe adding a "Compatibility Check" page to the installer could be handy? It could check these, maybe look for build tools or runtime dependencies and provide links or help for fixing/getting them. Another great idea, but not sure when I'll personally have the time to implement it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24873>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:56:56 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 22:56:56 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439679416.93.0.25676166433.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yeah, should have mentioned the smartscreen warning. The official builds are Authenticode signed, which prevents that warning appearing.

I promise the installers are safe :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Sun Aug 16 01:28:54 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 23:28:54 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439681334.44.0.706619154624.issue24874@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a partial patch:
* More than doubles the speed of cycle()
* Cuts size of __reduce__ result by about a third (on average)
* Still needs work on __setstate__ for a correct restore.

----------
keywords: +patch
Added file: http://bugs.python.org/file40186/cycle5_brokensetstate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 01:32:09 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 Aug 2015 23:32:09 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439681529.06.0.158904779348.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a pure Python patch that skips any frames that mentions 'importlib' and '_bootstrap' in the filename (it also skips _warnings.warn for easy testing since I didn't implement the C part). The only side-effect is that negative stack levels won't be the same because of the change in line numbers, but in that instance I'm not going to worry about it. It also causes test_venv and test_warnings to fail but I have not looked into why.

And still need a call by Larry as to whether this will go into 3.5.0.

----------
components: +Library (Lib)
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40187/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sun Aug 16 02:32:36 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sun, 16 Aug 2015 00:32:36 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1439685156.91.0.485018289756.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

I thought porting gdb would be the difficult part of getting debug info. I was so wrong.

Here is what I have so far, after lengthy consultation of the gdb manual.  Bear with me...it's basically a copy & paste of gdb session output:

(gdb) run
Starting program: /bld/pyt/cpython-android/python
setpgrp failed in child: No such process
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

Program received signal SIGILL, Illegal instruction.
0xb6a63cc8 in ?? ()
(gdb) f
#0  0xb6a63cc8 in ?? ()
(gdb) info f
Stack level 0, frame at 0xbefff618:
 pc = 0xb6a63cc8; saved pc = 0xb6a5feb0
 called by frame at 0xbefff618
 Arglist at 0xbefff618, args:
 Locals at 0xbefff618, Previous frame's sp is 0xbefff618
(gdb) info args
No symbol table info available.
(gdb) info local
No symbol table info available.
(gdb) info source
Current source file is ./Modules/python.c
Compilation directory is /bld/pyt/cpython-android
Located in /bld/pyt/cpython-android/Modules/python.c
Contains 80 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sun Aug 16 03:05:45 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sun, 16 Aug 2015 01:05:45 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1439685156.91.0.485018289756.issue23496@psf.upfronthosting.co.za>
Message-ID: <834264A8-10B2-4D4B-AAED-E3C2863FB477@gmail.com>


Ryan Gonzalez added the comment:

What if you run:

bt

?

On August 15, 2015 7:32:37 PM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>I thought porting gdb would be the difficult part of getting debug
>info. I was so wrong.
>
>Here is what I have so far, after lengthy consultation of the gdb
>manual.  Bear with me...it's basically a copy & paste of gdb session
>output:
>
>(gdb) run
>Starting program: /bld/pyt/cpython-android/python
>setpgrp failed in child: No such process
>warning: Unable to find dynamic linker breakpoint function.
>GDB will be unable to debug shared library initializers
>and track explicitly loaded dynamic code.
>
>Program received signal SIGILL, Illegal instruction.
>0xb6a63cc8 in ?? ()
>(gdb) f
>#0  0xb6a63cc8 in ?? ()
>(gdb) info f
>Stack level 0, frame at 0xbefff618:
> pc = 0xb6a63cc8; saved pc = 0xb6a5feb0
> called by frame at 0xbefff618
> Arglist at 0xbefff618, args:
> Locals at 0xbefff618, Previous frame's sp is 0xbefff618
>(gdb) info args
>No symbol table info available.
>(gdb) info local
>No symbol table info available.
>(gdb) info source
>Current source file is ./Modules/python.c
>Compilation directory is /bld/pyt/cpython-android
>Located in /bld/pyt/cpython-android/Modules/python.c
>Contains 80 lines.
>Source language is c.
>Compiled with DWARF 2 debugging format.
>Does not include preprocessor macro info.
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sun Aug 16 06:03:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Aug 2015 04:03:17 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439697797.59.0.993730869507.issue24874@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 06:24:00 2015
From: report at bugs.python.org (Nicolas Demarchi)
Date: Sun, 16 Aug 2015 04:24:00 +0000
Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?=
 =?utf-8?q?env_with_--system-site-package?=
Message-ID: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za>


New submission from Nicolas Demarchi:

When Envbuilder creates a new virtualenv with system_site_packages=True,
in the process of installing pip itself it actually doesn't install it inside the virtualenv because it is already there in the system.

However when you do it manually using "virtualenv" it does install pip inside the virtualenv as you would expect to.


```
(22d667c6-e383-47be-9785-ec044008b654)  ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ? pwd
/home/gilgamezh/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654
(22d667c6-e383-47be-9785-ec044008b654)  ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ? ll
total 16
drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 bin
drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 include
drwxr-xr-x 3 gilgamezh users 4096 Aug 16 00:05 lib
lrwxrwxrwx 1 gilgamezh users    3 Aug 16 00:05 lib64 -> lib
-rw-r--r-- 1 gilgamezh users   68 Aug 16 00:05 pyvenv.cfg
(22d667c6-e383-47be-9785-ec044008b654)  ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ? ll bin 
total 12
-rw-r--r-- 1 gilgamezh users 2251 Aug 16 00:05 activate
-rw-r--r-- 1 gilgamezh users 1367 Aug 16 00:05 activate.csh
-rw-r--r-- 1 gilgamezh users 2503 Aug 16 00:05 activate.fish
lrwxrwxrwx 1 gilgamezh users    7 Aug 16 00:05 python -> python3
lrwxrwxrwx 1 gilgamezh users   16 Aug 16 00:05 python3 -> /usr/bin/python3
(22d667c6-e383-47be-9785-ec044008b654)  ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ? bin/python -Im ensurepip --upgrade --default-pip -v 
Ignoring indexes: https://pypi.python.org/simple
URLs to search for versions for setuptools in /usr/lib/python3.4/site-packages:
Skipping link /tmp/tmpe8rbjkcq (from -f); not a file
Skipping link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl; wrong project name (not setuptools)
Found link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl, version: 12.0.5
Local files found: /tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl
Installed version (18.1) is most up-to-date (past versions: 12.0.5)
Requirement already up-to-date: setuptools in /usr/lib/python3.4/site-packages
URLs to search for versions for pip in /usr/lib/python3.4/site-packages:
Found link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl, version: 6.0.8
Skipping link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl; wrong project name (not pip)
Local files found: /tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl
Installed version (7.1.0) is most up-to-date (past versions: 6.0.8)
Requirement already up-to-date: pip in /usr/lib/python3.4/site-packages
Cleaning up...
(22d667c6-e383-47be-9785-ec044008b654)  ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ? 
```

"bin/python -Im ensurepip --upgrade --default-pip -v" is from /usr/lib/python3.4/venv/__init__.py line 255

----------
components: Library (Lib)
messages: 248673
nosy: gilgamezh
priority: normal
severity: normal
status: open
title: pyvenv doesn?t install PIP inside a new venv with --system-site-package
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24875>
_______________________________________

From report at bugs.python.org  Sun Aug 16 06:57:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Aug 2015 04:57:52 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439701072.58.0.838643104972.issue24874@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current cycle implementation is simple and clever, but can be optimized. The part about iterating LGTM (but looks the firstpass field can be eliminated at all). But __reduce__ doesn't look so optimal. It makes a copy of a list and makes iterating an unpickled cycle object slow. It would be more optimal if create new list with rotated content or even rotate original list inplace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 07:05:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2015 05:05:26 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439701526.9.0.1529133069.issue24874@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40188/cycle9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 07:52:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2015 05:52:39 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439704359.36.0.782169983031.issue24874@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Added an updated patch that passes all tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 08:34:09 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 16 Aug 2015 06:34:09 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439706849.56.0.582710639581.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

FWIW, I rebuilt static libraries for zlib, jbig, jpeg, openjpeg, tiff, webp, lcms, and freetype with /MT flag (a tedious task) and was able to build matplotlib and Pillow using Python 3.5.0rc1. As expected there is no dependency on the vcruntime DLL.

Even if everything is built with /MT and using UCRT, some extensions will still depend on version specific Visual C runtime DLLs, e.g. OpenMP, requiring users or distributors to install/bundle the VC runtime package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 10:44:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Aug 2015 08:44:11 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439714650.99.0.526029405196.issue24874@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Original Raymonds reason in msg248662 is not valid. Pickling a cycle object that fully consumed its input iterable is already space-inefficient.

>>> import itertools, pickle, pickletools
>>> c = itertools.cycle(iter('abcde'))
>>> [next(c) for i in range(8)]
['a', 'b', 'c', 'd', 'e', 'a', 'b', 'c']
>>> pickle.dumps(c)
b'\x80\x03citertools\ncycle\nq\x00cbuiltins\niter\nq\x01]q\x02(X\x01\x00\x00\x00aq\x03X\x01\x00\x00\x00bq\x04X\x01\x00\x00\x00cq\x05X\x01\x00\x00\x00dq\x06X\x01\x00\x00\x00eq\x07e\x85q\x08Rq\tK\x03b\x85q\nRq\x0bh\x02K\x01\x86q\x0cb.'
>>> pickletools.dis(pickle.dumps(c))
    0: \x80 PROTO      3
    2: c    GLOBAL     'itertools cycle'
   19: q    BINPUT     0
   21: c    GLOBAL     'builtins iter'
   36: q    BINPUT     1
   38: ]    EMPTY_LIST
   39: q    BINPUT     2
   41: (    MARK
   42: X        BINUNICODE 'a'
   48: q        BINPUT     3
   50: X        BINUNICODE 'b'
   56: q        BINPUT     4
   58: X        BINUNICODE 'c'
   64: q        BINPUT     5
   66: X        BINUNICODE 'd'
   72: q        BINPUT     6
   74: X        BINUNICODE 'e'
   80: q        BINPUT     7
   82: e        APPENDS    (MARK at 41)
   83: \x85 TUPLE1
   84: q    BINPUT     8
   86: R    REDUCE
   87: q    BINPUT     9
   89: K    BININT1    3
   91: b    BUILD
   92: \x85 TUPLE1
   93: q    BINPUT     10
   95: R    REDUCE
   96: q    BINPUT     11
   98: h    BINGET     2
  100: K    BININT1    1
  102: \x86 TUPLE2
  103: q    BINPUT     12
  105: b    BUILD
  106: .    STOP
highest protocol among opcodes = 2

An internal iterator is not pickled as iter("de"), but as an iterator of the list ["a", "b", "c", "d", "e"] with 3 items consumed. This list also saved as a part of a cycle object state, but not as a copy, but as a reference.

There are two alternative patches. Both keep Raymonds optimization of cycle iterating, but have advantages. cycle_reduce_2.patch makes __reduce__ faster and more memory efficient than Raymonds variant. cycle_reduce_3.patch makes unpickled cycle object so optimized as original.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 10:44:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Aug 2015 08:44:29 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439714669.2.0.456750467306.issue24874@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file40189/cycle_reduce_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 10:44:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Aug 2015 08:44:41 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439714681.46.0.682817498126.issue24874@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file40190/cycle_reduce_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 11:59:28 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 16 Aug 2015 09:59:28 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439719168.0.0.40079557966.issue24858@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Things work with python3.5 so this is an issue with what debian sid calls python3 (i.e. CPython 3.4.3+ (default, Jul 28 2015, 13:17:50) [GCC 4.9.3])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Sun Aug 16 12:01:00 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 16 Aug 2015 10:01:00 +0000
Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under
 Debian unstable (sid)
In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za>
Message-ID: <1439719260.92.0.20191644591.issue24858@psf.upfronthosting.co.za>


Laura Creighton added the comment:

(as expected) Fails when invoked as python3.4 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24858>
_______________________________________

From report at bugs.python.org  Sun Aug 16 13:34:52 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 16 Aug 2015 11:34:52 +0000
Subject: [issue24876] distutils.errors not wildcard-import-safe
Message-ID: <1439724892.22.0.0558175678878.issue24876@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

Docstring of the distutils.errors module reads:

This module is safe to use in "from ... import *" mode; it only exports
symbols whose names start with "Distutils" and end with "Error".

But in reality, the module exports also names that don't start with "Distutils":

>>> ns = {}
>>> exec('from distutils.errors import *', {}, ns)
>>> [k for k in ns.keys() if not k.startswith('Distutils')]
['LibError', 'UnknownFileError', 'LinkError', 'CompileError', 'CCompilerError', 'PreprocessError']

----------
components: Distutils
messages: 248680
nosy: dstufft, eric.araujo, jwilk
priority: normal
severity: normal
status: open
title: distutils.errors not wildcard-import-safe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24876>
_______________________________________

From report at bugs.python.org  Sun Aug 16 14:48:30 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 16 Aug 2015 12:48:30 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439729310.15.0.7061783047.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

I expect that, but most extensions don't seem to be in that category so this will help remove the administrator barrier.

Thanks for going through that tedious process. I'll put up a patch later today and submit for 3.5.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 15:02:57 2015
From: report at bugs.python.org (sih4sing5hong5)
Date: Sun, 16 Aug 2015 13:02:57 +0000
Subject: [issue24855] fail to mock the urlopen function
In-Reply-To: <1439448977.69.0.239329434858.issue24855@psf.upfronthosting.co.za>
Message-ID: <1439730177.48.0.390716925366.issue24855@psf.upfronthosting.co.za>


sih4sing5hong5 added the comment:

I moved the import urlopen inside the patch.
The mock worked.

Thank you for explanations. I understand now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24855>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:07:07 2015
From: report at bugs.python.org (Akira Li)
Date: Sun, 16 Aug 2015 15:07:07 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439737627.4.0.683378249099.issue24842@psf.upfronthosting.co.za>


Akira Li added the comment:

People do have problems that SimpleNamespace can solve:

- Why Python does not support record type i.e. mutable namedtuple [1]
- Does Python have anonymous classes? [2]
- How to create inline objects with properties in Python? [3]
- python create object and add attributes to it [4]

[1] http://stackoverflow.com/questions/5227839/why-python-does-not-support-record-type-i-e-mutable-namedtuple
[2] http://stackoverflow.com/questions/1123000/does-python-have-anonymous-classes
[3] http://stackoverflow.com/questions/1528932/how-to-create-inline-objects-with-properties-in-python
[4] http://stackoverflow.com/questions/2827623/python-create-object-and-add-attributes-to-it

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24842>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:32:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Aug 2015 15:32:18 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <20150816153212.6804.64016@psf.io>


Roundup Robot added the comment:

New changeset 678d93c273de by Raymond Hettinger in branch 'default':
Issue #24842:  Cross-reference types.SimpleNamespace from the namedtuple docs
https://hg.python.org/cpython/rev/678d93c273de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24842>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:32:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2015 15:32:46 +0000
Subject: [issue24842] Mention SimpleNamespace in namedtuple docs
In-Reply-To: <1439266648.77.0.275297386928.issue24842@psf.upfronthosting.co.za>
Message-ID: <1439739166.52.0.516121635931.issue24842@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24842>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:45:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2015 15:45:20 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439739920.91.0.341022756734.issue24874@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 19:46:10 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Sun, 16 Aug 2015 17:46:10 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <1439747170.03.0.0236696413162.issue23572@psf.upfronthosting.co.za>


Adam Barto? added the comment:

I was also bitten by this via Enum. Is there any chance this will be fixed in Python 3.5?

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23572>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:31:16 2015
From: report at bugs.python.org (Jairo Trad)
Date: Sun, 16 Aug 2015 18:31:16 +0000
Subject: [issue13691] pydoc help (or help('help')) should show the doc for help
In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za>
Message-ID: <1439749876.15.0.360335472607.issue13691@psf.upfronthosting.co.za>


Jairo Trad added the comment:

I just tested this issue in Python 3.6.0a0 and got this behavior:

help('help') brings 

"Help on _Helper in module _sitebuiltins object:"

help(help) brings:
Help on _Helper in module _sitebuiltins object:

help() invokes the help command line.

So this was fixes on the way to python3.6, I can make the test for 3.4 but is 3.4 closed for bug fixing?

Can someone check this in 3.5?

----------
nosy: +jairotrad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13691>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:31:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 16 Aug 2015 18:31:24 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439749884.85.0.0153436271307.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

Actually, on rereading this (during daylight hours, previous response was before 6am my time) the patch wouldn't help. I need to write some porting notes for rebuilding static libraries with suitable settings. I'll base it on my initial post and find somewhere appropriate in the docs (and maybe blog about it too for SEO purposes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:31:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 16 Aug 2015 18:31:52 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439749912.54.0.574068344296.issue24872@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
components: +Documentation, Extension Modules
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 21:19:30 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 16 Aug 2015 19:19:30 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439752770.22.0.996212376084.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

> Thanks for going through that tedious process
~140 libraries to go.

I hit the wall last night trying to build Boost DLLs. Boost's build tool b2 does not allow `link=shared runtime-link=static`, hence the `/MT /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` magic does not work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 22:00:23 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 16 Aug 2015 20:00:23 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439755223.37.0.972426614707.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

Boost requires C++ anyway doesn't it? So the full redist will be required. These options are only useful for pure C sources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 22:13:05 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 16 Aug 2015 20:13:05 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439755985.12.0.135354900224.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Matplotlib and my own extensions are using C++ sources but do not depend on msvcp140.dll, just the ucrt. Am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 22:48:08 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 16 Aug 2015 20:48:08 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439758088.69.0.262048121702.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

Probably I'm missing something. Maybe there's a subset of C++ that doesn't rely on it - a decent amount of the standard template library is generated at compile time.

If the dependency isn't there, it'll be fine.

Do you think it'll be worth having a check box in the installer to get the full runtime? Bearing in mind that most won't need it and many won't be able to install it? I'm not sure it is, but you've got a better idea of which packages are popular and which ones need it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Sun Aug 16 23:49:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Aug 2015 21:49:42 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <20150816214937.91825.32750@psf.io>


Roundup Robot added the comment:

New changeset 17b5c8ba6875 by Raymond Hettinger in branch 'default':
Issue #24874: Speed-up itertools and make it pickles more compact.
https://hg.python.org/cpython/rev/17b5c8ba6875

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Sun Aug 16 23:52:00 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2015 21:52:00 +0000
Subject: [issue24874] Improve pickling efficiency of itertools.cycle
In-Reply-To: <1439674346.53.0.142034370838.issue24874@psf.upfronthosting.co.za>
Message-ID: <1439761920.08.0.113136069784.issue24874@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Applied the cycle2 patch but kept the signature the same as the original reduce (using a number instead of a boolean).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24874>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:53:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Aug 2015 22:53:03 +0000
Subject: [issue13691] pydoc help (or help('help')) should show the doc for help
In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za>
Message-ID: <1439765583.58.0.432747521082.issue13691@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.5 is the same as 3.6 in that now both help(help) and help('help') show the not terribly helpful "Help on _Helper in module site object:...". Buried in the text is  
 |  Calling help() at the Python prompt starts an interactive help session.
 |  Calling help(thing) prints help for the python object 'thing'.

As before, I think the _Helpter stuff should be eliminated and 
explanation added for help('topic') and a description of what 'topic's are specially recognized.

There has been this improvement
>>> help('jslfjslfdjlskfj')  # 3.4
no Python documentation found for 'jslfjslfdjlskfj'

>>> help('jsflksjflkjsl')  # 3.5
No Python documentation found for 'jsflksjflkjsl'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.

but the latter omits decription of what 'topic' will give special output.  By experiment, keywords (help('if')), builtins, and unimported modules (help('itertools')) works.

Yes, 3.4 can be patched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13691>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:53:09 2015
From: report at bugs.python.org (=?utf-8?b?QmVuamFtaW4gUGVuZyAo54OI5LmL5papKQ==?=)
Date: Sun, 16 Aug 2015 22:53:09 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1439765589.63.0.69686850913.issue15809@psf.upfronthosting.co.za>


Changes by Benjamin Peng (???) <human.peng at gmail.com>:


----------
nosy: +Benjamin Peng (???)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Mon Aug 17 02:00:23 2015
From: report at bugs.python.org (Jairo Trad)
Date: Mon, 17 Aug 2015 00:00:23 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1439769623.75.0.185342900011.issue24746@psf.upfronthosting.co.za>


Jairo Trad added the comment:

I have patched this as explained by David. Also the tests are working. Another test broke because a missing trailing space. I fixed that too.

This is my first patch :D

----------
nosy: +jairotrad
Added file: http://bugs.python.org/file40191/issue24746.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Mon Aug 17 02:20:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Aug 2015 00:20:14 +0000
Subject: [issue24774] inconsistency in http.server.test
In-Reply-To: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>
Message-ID: <20150817002004.4939.44632@psf.io>


Roundup Robot added the comment:

New changeset d9e0c82d8653 by Robert Collins in branch '3.4':
Issue #24774: Fix docstring in http.server.test.
https://hg.python.org/cpython/rev/d9e0c82d8653

New changeset 845c79097c21 by Robert Collins in branch '3.5':
Issue #24774: Fix docstring in http.server.test.
https://hg.python.org/cpython/rev/845c79097c21

New changeset a8de693ebe66 by Robert Collins in branch 'default':
Issue #24774: Fix docstring in http.server.test.
https://hg.python.org/cpython/rev/a8de693ebe66

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24774>
_______________________________________

From report at bugs.python.org  Mon Aug 17 02:21:01 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 17 Aug 2015 00:21:01 +0000
Subject: [issue24774] inconsistency in http.server.test
In-Reply-To: <1438456789.62.0.107854309942.issue24774@psf.upfronthosting.co.za>
Message-ID: <1439770861.69.0.689418119807.issue24774@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch. Applied to 3.4 and up.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24774>
_______________________________________

From report at bugs.python.org  Mon Aug 17 02:52:02 2015
From: report at bugs.python.org (shiva prasanth)
Date: Mon, 17 Aug 2015 00:52:02 +0000
Subject: [issue24877] Bad Password for file using zipfile module
Message-ID: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>


New submission from shiva prasanth:

i created a zip file with password as getlost using Archive Manager which comes with ubuntu.
and when i try to extract the same file using zipfile module which comes with python2.7 with same password it is showing error as 
"Bad Password for file" which is absurd.
it should either give response of cant decrypt zipfile or some other.
when i try to do it with terminal command  

$zip --encrypt file.zip file

and upon entering the password it is working

my main point is it should not show Bad Password for file and 
and it should extractall

----------
components: Extension Modules
files: raj
messages: 248698
nosy: shiva prasanth
priority: normal
severity: normal
status: open
title: Bad Password for file using zipfile module
versions: Python 2.7
Added file: http://bugs.python.org/file40192/raj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Mon Aug 17 02:53:47 2015
From: report at bugs.python.org (shiva prasanth)
Date: Mon, 17 Aug 2015 00:53:47 +0000
Subject: [issue24877] Bad Password for file using zipfile module
In-Reply-To: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>
Message-ID: <1439772827.06.0.277077492924.issue24877@psf.upfronthosting.co.za>


shiva prasanth added the comment:

Python 2.7.9 (default, Apr  2 2015, 15:33:21) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> s=zipfile.ZipFile('random.zip')
>>> s.extractall(pwd='getlost')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/zipfile.py", line 1040, in extractall
    self.extract(zipinfo, path, pwd)
  File "/usr/lib/python2.7/zipfile.py", line 1028, in extract
    return self._extract_member(member, path, pwd)
  File "/usr/lib/python2.7/zipfile.py", line 1082, in _extract_member
    with self.open(member, pwd=pwd) as source, \
  File "/usr/lib/python2.7/zipfile.py", line 1007, in open
    raise RuntimeError("Bad password for file", name)
RuntimeError: ('Bad password for file', <zipfile.ZipInfo object at 0x7faf1d1921e0>)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:08:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 01:08:23 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1439773703.93.0.0434809687548.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From msg248192 (Serhiy - which 
...
>  File "/home/serhiy/py/cpython/Lib/idlelib/EditorWindow.py", line 899, in update_recent_files_list
>    if '\0' in path or not os.path.exists(path[0:-1]):
>  File "/home/serhiy/py/cpython/Lib/genericpath.py", line 19, in exists
>    os.stat(path)
> UnicodeEncodeError: 'latin-1' codec can't encode character '\U0001d53c' in position 22: ordinal not in range(256)

On Windows, os.stat(astralpath) raises
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'as\U00011111.py'
and os.path.exists(astralpath) catches the exception and returns False. It is a linux issue, and perhaps a bug, that os.path.exists does not catch the exception. To me, as I read the docstring, it should always return True or False, with the latter the default, for any input string.

The EditorWindow line is testing for 'badfiles' to be excluded from the recent files list.  We can work around the linux behavior with try-except.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:12:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2015 01:12:36 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1439773956.86.0.123185162342.issue24746@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unfortunately I was reminded a few days ago that there is a commit hook that prevents patches containing trailing whitespace from being committed to the repository.  So using doctest to test this isn't going to work.

The alternatives are to write a unit test, or to figure out how to write the doctest such there is no trailing whitespace...which would mean capturing the output of doctest.DoctTestRunner instead of letting it go the console, and then comparing it to an explicitly embedded string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:39:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 01:39:25 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1439775565.15.0.638346131329.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It appears that the failures in msg248192 and msg248365 are issues with non-latin1 chars in general, not with astral chars in particular.  Anyone who wants filenames with astral chars should be using a utf-8 locale.

This issue is about Idle working around the tk BMP limit where it can so as to not prevent editing and running files with system-legal names. According to msg248188, the patch works.  So I am closing the issue as fixed.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:50:06 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 17 Aug 2015 01:50:06 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439776206.15.0.826429225735.issue24379@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

So this has sign off on Python ideas, and it's not fundamentally changing the language (it's implemented in pure Python after all), it's passed a dozen code reviews. Can someone with commit privileges just finish this off please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:55:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Aug 2015 01:55:56 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <20150817015549.91833.76294@psf.io>


Roundup Robot added the comment:

New changeset d54aa163e4ec by Terry Jan Reedy in branch '2.7':
Issue #23672: ACKS
https://hg.python.org/cpython/rev/d54aa163e4ec

New changeset c1031eb12aa1 by Terry Jan Reedy in branch '3.4':
Issue #23672: ACKS
https://hg.python.org/cpython/rev/c1031eb12aa1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:04:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 02:04:41 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439777081.7.0.152582491775.issue24379@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:23:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2015 02:23:34 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439778214.89.0.559850186857.issue24379@psf.upfronthosting.co.za>


R. David Murray added the comment:

For future reference can you post a link to the python-ideas thread in which the signoff occurred?

----------
nosy: +r.david.murray
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:30:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 02:30:29 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439778628.99.0.863966744358.issue24379@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The old python ideas discussion stops way short of a "sign-off" but I'll go ahead an apply the patch.  If someone really hates it, they have a year and half to persuade someone to rip it out ;-)  

https://mail.python.org/pipermail/python-ideas/2015-June/034086.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:34:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 02:34:48 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1439778888.73.0.167618533147.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Do you consider the second patch ready as is (as a step toward doing the merge)?  Is so, I will do a commit review.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:45:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Aug 2015 02:45:04 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <20150817024501.4915.79982@psf.io>


Roundup Robot added the comment:

New changeset dccc4e63aef5 by Raymond Hettinger in branch 'default':
Issue #24379: Add operator.subscript() as a convenience for building slices.
https://hg.python.org/cpython/rev/dccc4e63aef5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:46:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 02:46:08 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439779568.12.0.48487615848.issue24379@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:48:10 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 02:48:10 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1439779690.51.0.38225439005.issue24776@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The side-by-side part I obviously like, but I think we need to keep 'Base Editor Font' since this and only this is affected by the selection.  I think there should be an option to increase the 'other' font used for everything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:51:21 2015
From: report at bugs.python.org (Joe Jevnik)
Date: Mon, 17 Aug 2015 02:51:21 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1439779881.97.0.651955067829.issue24379@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

Sorry about the ideas thread. Thank you for merging this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Mon Aug 17 05:00:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 03:00:51 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1439780451.81.0.945288169013.issue24781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As I think I said elsewhere, I want myself and others to be able to select among the style themes provided with ttk, as well as any other themes (a dark theme?) that we or users devise.  A custom theme would be a good project for a UI design class.

I do not understand the background color question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Mon Aug 17 06:28:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 04:28:58 +0000
Subject: [issue24878] Add docstrings to selected named tuples
Message-ID: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Add docstrings to some named tuples that could benefit from it (there was more documentation or useful information other than just the field name).  This makes the help() on those named tuples much more informative.

----------
assignee: docs at python
components: Documentation
files: ntdoc.diff
keywords: patch
messages: 248712
nosy: docs at python, rhettinger
priority: low
severity: normal
stage: patch review
status: open
title: Add docstrings to selected named tuples
versions: Python 3.6
Added file: http://bugs.python.org/file40193/ntdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Mon Aug 17 06:32:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 04:32:47 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <1439785967.22.0.910527052706.issue24878@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

For example:

>>> import sched
>>> help(sched.Event)

class Event(Event)
 |  Event(time, priority, action, argument, kwargs)
 | 
...
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from Event:
 |  
 |  action
 |      Executing the event means executing
 |      action(*argument, **kwargs)
 |  
 |  argument
 |      argument is a sequence holding the positional
 |      arguments for the action.
 |  
 |  kwargs
 |      kwargs is a dictionary holding the keyword
 |      arguments for the action.
 |  
 |  priority
 |      Events scheduled for the same time will be executed
 |      in the order of their priority.
 |  
 |  time
 |      Numeric type compatible with the return value of the
 |      timefunc function passed to the constructor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Mon Aug 17 06:33:15 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Aug 2015 04:33:15 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1439785995.32.0.159896342675.issue24613@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24613>
_______________________________________

From report at bugs.python.org  Mon Aug 17 06:34:56 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Aug 2015 04:34:56 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1439786096.83.0.871222668576.issue24683@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24683>
_______________________________________

From report at bugs.python.org  Mon Aug 17 06:55:13 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Aug 2015 04:55:13 +0000
Subject: [issue24734] Dereferencing a null returning value
In-Reply-To: <1437994491.85.0.821896249224.issue24734@psf.upfronthosting.co.za>
Message-ID: <1439787313.71.0.212818140999.issue24734@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24734>
_______________________________________

From report at bugs.python.org  Mon Aug 17 07:22:28 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 17 Aug 2015 05:22:28 +0000
Subject: [issue24735] Invalid access in combinations_with_replacement()
In-Reply-To: <1437995998.57.0.192445983391.issue24735@psf.upfronthosting.co.za>
Message-ID: <1439788948.11.0.0430437565467.issue24735@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24735>
_______________________________________

From report at bugs.python.org  Mon Aug 17 07:33:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 05:33:10 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
Message-ID: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently, help() lists out data descriptors in alphabetical order.  This is fine in the general case, however if the fields are parts of a named tuple, it is more sensible to list them in the order found in the tuple.

The presence of a named tuple can be detected by the presence of a _fields attribute that is a list of strings.  That strings can be used as a primary sort key before an alphabetical sort of anything not listed in _fields.

>>> Person = namedtuple('Person', ['nickname', 'firstname', 'age'])
>>> help(Person)
Help on class Person in module __main__:

class Person(builtins.tuple)
 |  Person(nickname, firstname, age)
 |  
 ...
 |  
 |  ----------------------------------------------------------------------
 |  Static methods defined here:
 |  
 |  __new__(_cls, nickname, firstname, age)
 |      Create new instance of Person(nickname, firstname, age)
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      A new OrderedDict mapping field names to their values
 |  
 |  age
 |      Alias for field number 2
 |  
 |  firstname
 |      Alias for field number 1
 |  
 |  nickname
 |      Alias for field number 0
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  _fields = ('nickname', 'firstname', 'age')
 |  
 ...

The data descriptors should list nickname, then firstname, then age to match the tuple order in _fields.

----------
components: Library (Lib)
messages: 248714
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Pydoc to list data descriptors in _fields order if it exists
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:13:53 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 17 Aug 2015 06:13:53 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439792033.41.0.841024762223.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

The matplotlib extensions compiled with Python 3.5.0rc1 (/MT) are larger than those compiled with 3.5.0b4 (/MD). The C++ runtime is statically linked. This seems undesirable for the same reasons the UCRT is not linked statically.

In "Introducing the Universal CRT" [1] James McNellis "strongly recommend against static linking of the Visual C++ libraries, for both performance and serviceability reasons". In "Visual Studio 2015 RTM Now Available" [2] the same author commented that one "may deploy the Universal CRT app-locally". Do these comments not apply to CPython?

[1] <http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx>
[2] <http://blogs.msdn.com/b/vcblog/archive/2015/07/20/visual-studio-2015-rtm-now-available.aspx>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:27:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 06:27:50 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439792870.6.0.0941897463424.issue24879@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40194/pydoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:28:06 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 06:28:06 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439792886.9.0.768126989729.issue24879@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:35:42 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 17 Aug 2015 06:35:42 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439793342.76.0.837938726429.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Another /MT only issue: cryptography-1.0 and other libraries depending on openssl fail to link to static MT openssl-1.0.1p:

cryptlib.obj : error LNK2001: unresolved external symbol __iob_func

This can be fixed manually [1].

[1] <http://openssl.6102.n7.nabble.com/Compiling-OpenSSl-Project-with-Visual-Studio-2015-td59416.html>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:42:46 2015
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 17 Aug 2015 06:42:46 +0000
Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass
 error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439793766.87.0.248749768404.issue24870@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I've stripped Serhiy's patch for ascii.

Here is benchmark result:
https://gist.github.com/methane/2376ac5d20642c05a8b6#file-result-md

Is there chance for applying this patch to 3.5.1?

----------
Added file: http://bugs.python.org/file40195/faster-decode-ascii-surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:44:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 06:44:39 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439793879.07.0.999470422485.issue24879@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

With the attached patch, the new output is:

 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  nickname
 |      Alias for field number 0
 |   
 |  firstname
 |      Alias for field number 1 
 | 
 |  age
 |      Alias for field number 2
 | 
 |  __dict__
 |      A new OrderedDict mapping field names to their values

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Mon Aug 17 09:06:43 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 07:06:43 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1439795203.81.0.072793603774.issue24776@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I would also like a pair of hotkeys, Cmd + and Cmd - to increase and decrease the font (this would greatly improve usability for font size changes).   There is good precedent for this in other editors and terminal programs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Mon Aug 17 09:09:05 2015
From: report at bugs.python.org (Pradeep)
Date: Mon, 17 Aug 2015 07:09:05 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1439795344.99.0.6647721999.issue24764@psf.upfronthosting.co.za>


Pradeep added the comment:

Hi Victor, 
I found similar problem at 
https://bugs.launchpad.net/barbican/+bug/1485452, 
is problem mentioned in the bug is same with mentioned bug?

----------
nosy: +pradeep

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Mon Aug 17 09:20:06 2015
From: report at bugs.python.org (Jan Wagner)
Date: Mon, 17 Aug 2015 07:20:06 +0000
Subject: [issue24880] ctypeslib patch for regular expression for symbols to
 include
Message-ID: <1439796006.75.0.0781056689434.issue24880@psf.upfronthosting.co.za>


New submission from Jan Wagner:

There is an issue in ctypeslib that affects xml2py.py option "-r". The usage informs that "-r EXPRESSION regular expression for symbols to include". However, when the expression is evaluated, only exact name matches are actually selected. For example, -r "set" would match only a function called set. 

The underlying issue is in codegenerator.py. Here is a small patch that changes the behaviour of codegenerator.py so that it (and xml2py.py) are more consistent with the usage instructions. With the patch, -r "set" will match all functions containing set, e.g., setData, setAxis, and so on.

----------
components: ctypes
files: codegenerator.patch
keywords: patch
messages: 248721
nosy: jwagner313
priority: normal
severity: normal
status: open
title: ctypeslib patch for regular expression for symbols to include
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40196/codegenerator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24880>
_______________________________________

From mal at egenix.com  Mon Aug 17 10:14:14 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 17 Aug 2015 10:14:14 +0200
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439671296.92.0.640361157336.issue24872@psf.upfronthosting.co.za>
References: <1439671296.92.0.640361157336.issue24872@psf.upfronthosting.co.za>
Message-ID: <55D197D6.60403@egenix.com>

On 15.08.2015 22:41, Steve Dower wrote:
> 
> Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes.
> 
> * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves)
> * CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management.
> * potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself)

These issues have always existed in the past, but were never a real
problem, AFAIK, since the libraries intended to be used externally
will typically come with e.g. memory management APIs to make sure
they retain ownership of the allocated memory on their heap.

It is quite natural to have to run VCredist as part of an application
installer to make sure that the target system has the right VC runtime
DLLs installed (and the installer will do the checking).

The purpose of having DLLs for the runtime is to reduce overall
size of the components as well as being able to easily address
bugs and security issues in the runtime DLLs *without* having
to recompile and redeploy all components using them.

By forcing or even suggesting statically compiled Python C extensions,
we would break this goal and potentially put our users at risk.

IMO, we should follow the MS recommendations for "Deployment in Visual C++"
as we did in the past:

https://msdn.microsoft.com/en-us/library/dd293574.aspx

"""
You can statically link a Visual C++ library to an application?that is, compile it into the
application?so that you don't have to deploy the Visual C++ library files separately. However, we
caution against this approach because statically linked libraries cannot be updated in place. If you
use static linking and you want to update a linked library, you have to recompile and redeploy your
application.
"""

Perhaps I'm missing something, but if the only advantage of statically
compiling in the runtime is to have users not need to run VCredist
at install time, it's not worth all the added trouble this introduces.

If you are trying to make it possible to compile extensions with
compilers following VC2015, then I also don't think this approach
will work: the new compilers will use a new runtime and so
issues you describe above come into play between the extensions
and the interpreter.

In that scenario, they will create real problems, as far as I
understand, the since the Python C API expects to be able to e.g.
share FDs, internal state such as which locale to assume, or
use and free memory allocated by either the interpreter or the
extension in the resp. other component (e.g. PyArg_ParseTuple()).

So in the end, you'll still have to use the same compiler for
extensions as the one used for compiling CPython to make sure
you don't run into these issues - which is essentially the same
situation as for Python <=3.4.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Mon Aug 17 10:14:44 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 17 Aug 2015 08:14:44 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439671296.92.0.640361157336.issue24872@psf.upfronthosting.co.za>
Message-ID: <55D197D6.60403@egenix.com>


Marc-Andre Lemburg added the comment:

On 15.08.2015 22:41, Steve Dower wrote:
> 
> Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes.
> 
> * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves)
> * CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management.
> * potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself)

These issues have always existed in the past, but were never a real
problem, AFAIK, since the libraries intended to be used externally
will typically come with e.g. memory management APIs to make sure
they retain ownership of the allocated memory on their heap.

It is quite natural to have to run VCredist as part of an application
installer to make sure that the target system has the right VC runtime
DLLs installed (and the installer will do the checking).

The purpose of having DLLs for the runtime is to reduce overall
size of the components as well as being able to easily address
bugs and security issues in the runtime DLLs *without* having
to recompile and redeploy all components using them.

By forcing or even suggesting statically compiled Python C extensions,
we would break this goal and potentially put our users at risk.

IMO, we should follow the MS recommendations for "Deployment in Visual C++"
as we did in the past:

https://msdn.microsoft.com/en-us/library/dd293574.aspx

"""
You can statically link a Visual C++ library to an application?that is, compile it into the
application?so that you don't have to deploy the Visual C++ library files separately. However, we
caution against this approach because statically linked libraries cannot be updated in place. If you
use static linking and you want to update a linked library, you have to recompile and redeploy your
application.
"""

Perhaps I'm missing something, but if the only advantage of statically
compiling in the runtime is to have users not need to run VCredist
at install time, it's not worth all the added trouble this introduces.

If you are trying to make it possible to compile extensions with
compilers following VC2015, then I also don't think this approach
will work: the new compilers will use a new runtime and so
issues you describe above come into play between the extensions
and the interpreter.

In that scenario, they will create real problems, as far as I
understand, the since the Python C API expects to be able to e.g.
share FDs, internal state such as which locale to assume, or
use and free memory allocated by either the interpreter or the
extension in the resp. other component (e.g. PyArg_ParseTuple()).

So in the end, you'll still have to use the same compiler for
extensions as the one used for compiling CPython to make sure
you don't run into these issues - which is essentially the same
situation as for Python <=3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 14:07:43 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 17 Aug 2015 12:07:43 +0000
Subject: [issue24880] ctypeslib patch for regular expression for symbols to
 include
In-Reply-To: <1439796006.75.0.0781056689434.issue24880@psf.upfronthosting.co.za>
Message-ID: <1439813263.25.0.175207142665.issue24880@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

This appears to be an issue for an external library <https://pypi.python.org/pypi/ctypeslib>, although one hosted at svn.python.org.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24880>
_______________________________________

From report at bugs.python.org  Mon Aug 17 14:08:50 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 17 Aug 2015 12:08:50 +0000
Subject: [issue24880] ctypeslib patch for regular expression for symbols to
 include
In-Reply-To: <1439796006.75.0.0781056689434.issue24880@psf.upfronthosting.co.za>
Message-ID: <1439813330.03.0.555630714831.issue24880@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24880>
_______________________________________

From report at bugs.python.org  Mon Aug 17 15:22:27 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Aug 2015 13:22:27 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439817747.39.0.554771756724.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

Unfortunately applocal deployment doesn't solve the versioning issue - you'll always need to use VS 2015 to build for Python 3.5.

There are only a few more libraries that are affected by /MT. msvcp140.dll is the most likely one here. Doing the same /nodefaultlib dance for that might work, but it may not.

All of the shared state like memory allocation and file descriptors are in ucrt, which will not change with compiler versions. CPython itself does not require any extensions to use VS 2015 as long as they link to ucrtbase and not another CRT, but it's looking like the same build process won't work everywhere else.

Installing the full runtime requires administrative privileges, and removing that requirement was one of the priorities. If certain extensions require it or if distros install it that's fine, but I don't want distutils to *help* people make wheels that won't work on another machine because the runtime isn't there.

Depending on the size difference, statically linking the C++ parts may not be so bad. It's certainly no worse than including it local to Python, and all of its potentially shared state should be handled by the ucrt already.

Also, I've already had that OpenSSL issue fixed upstream. You must have an older version - I've been building it fine without patching for months now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 15:47:54 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 17 Aug 2015 13:47:54 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439817747.39.0.554771756724.issue24872@psf.upfronthosting.co.za>
Message-ID: <55D1E5EF.8020803@egenix.com>


Marc-Andre Lemburg added the comment:

If I understand you correctly, the only advantage of using /MT is
not require admin privileges for installation of the VC2015 runtime
libs.

Since VC2015 will be used by a lot of applications in a few months,
and it's likely that MS will ship the runtime as Windows update anyway,
the advantage seems minor.

OTOH, the requirement of linking against external libraries which you
cannot recompile or don't support /MT is rather common and won't
go away. And the need for security updates to the ucrt is rather
inevitable as well based on experience with previous CRTs.

Being able to build a statically linked Python binary is a nice
feature for some special application settings, but given the rather
weak arguments for making this the default, I'm not convinced that
this is a good way forward, esp. not when even MS itself recommends
against doing this.

We can have Python run VCredist during the installation to make
sure the runtime DLLs are available. Then no one will have a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:01:23 2015
From: report at bugs.python.org (Jairo Trad)
Date: Mon, 17 Aug 2015 14:01:23 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1439820083.87.0.829847043817.issue24746@psf.upfronthosting.co.za>


Jairo Trad added the comment:

I can write a unittest for this, where should I write it? a new test file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:04:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2015 14:04:46 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1439820286.1.0.293700904776.issue24746@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe you can put it in the test_doctest file, and call it using the appropriate runner from test.support from the test_main function.  I haven't tried it though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:11:07 2015
From: report at bugs.python.org (Cosimo Lupo)
Date: Mon, 17 Aug 2015 14:11:07 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
Message-ID: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>


New submission from Cosimo Lupo:

the `_pyio` module at line 16 tries to check whether it is running on Windows platform, by doing:

```
if os.name == 'win32':
    from msvcrt import setmode as _setmode
else:
    _setmode = None
```

However, the string returned by os.name is 'nt' and not 'win32' (the latter is returned by `sys.platform`). Therefore, the value is always False and the setmode function from mscvrt module is never imported.

Thank you.
Cheers,

Cosimo

----------
components: IO
messages: 248728
nosy: Cosimo Lupo
priority: normal
severity: normal
status: open
title: _pyio checks that `os.name == 'win32'` instead of 'nt'
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:20:35 2015
From: report at bugs.python.org (Peter Landry)
Date: Mon, 17 Aug 2015 14:20:35 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1439821235.46.0.989477058724.issue24764@psf.upfronthosting.co.za>


Peter Landry added the comment:

Pradeep, that error seems to be in Barbican. This bug and patch only addresses content-length headers in MIME multipart messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:24:50 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Mon, 17 Aug 2015 14:24:50 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1439821490.35.0.403110450196.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Result:

(gdb) bt
#0  0xb6a63cc8 in ?? ()
#1  0xb6a5feb0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:39:55 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 17 Aug 2015 14:39:55 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1439821490.35.0.403110450196.issue23496@psf.upfronthosting.co.za>
Message-ID: <77128418-AD44-4A2A-827F-A73273AC099E@gmail.com>


Ryan Gonzalez added the comment:

Wait, did you compile this with Clang?

On August 17, 2015 9:24:50 AM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>Result:
>
>(gdb) bt
>#0  0xb6a63cc8 in ?? ()
>#1  0xb6a5feb0 in ?? ()
>Backtrace stopped: previous frame identical to this frame (corrupt
>stack?)
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:43:18 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 17 Aug 2015 14:43:18 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1439822598.63.0.131713213755.issue24881@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:59:00 2015
From: report at bugs.python.org (Matt Spitz)
Date: Mon, 17 Aug 2015 14:59:00 +0000
Subject: [issue24882] ThreadPoolExceutor doesn't reuse threads until #threads
 == max_workers
Message-ID: <1439823540.4.0.657998470812.issue24882@psf.upfronthosting.co.za>


New submission from Matt Spitz:

https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/thread.py#l114

ThreadPoolExecutor will keep spawning new threads, even if existing threads are waiting for new work. We should check against the queue length when deciding to spawn a new thread to avoid creating unnecessary threads.

----------
messages: 248732
nosy: Matt Spitz
priority: normal
severity: normal
status: open
title: ThreadPoolExceutor doesn't reuse threads until #threads == max_workers
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24882>
_______________________________________

From report at bugs.python.org  Mon Aug 17 17:09:29 2015
From: report at bugs.python.org (shiva prasanth)
Date: Mon, 17 Aug 2015 15:09:29 +0000
Subject: [issue24877] Bad Password for file using zipfile module
In-Reply-To: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>
Message-ID: <1439824169.93.0.0483166319743.issue24877@psf.upfronthosting.co.za>


Changes by shiva prasanth <kesavarapu.siva at gmail.com>:


----------
type:  -> compile error
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Mon Aug 17 17:49:42 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Mon, 17 Aug 2015 15:49:42 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <77128418-AD44-4A2A-827F-A73273AC099E@gmail.com>
Message-ID: <4FB845AA-1EA1-4754-A302-25BC76342AD5@gmail.com>


Cyd Haselton added the comment:

No...compiled with GCC 4.9.2

On August 17, 2015 9:39:55 AM CDT, Ryan Gonzalez <report at bugs.python.org> wrote:
>
>Ryan Gonzalez added the comment:
>
>Wait, did you compile this with Clang?
>
>On August 17, 2015 9:24:50 AM CDT, Cyd Haselton
><report at bugs.python.org> wrote:
>>
>>Cyd Haselton added the comment:
>>
>>Result:
>>
>>(gdb) bt
>>#0  0xb6a63cc8 in ?? ()
>>#1  0xb6a5feb0 in ?? ()
>>Backtrace stopped: previous frame identical to this frame (corrupt
>>stack?)
>>
>>----------
>>
>>_______________________________________
>>Python tracker <report at bugs.python.org>
>><http://bugs.python.org/issue23496>
>>_______________________________________
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Aug 17 17:50:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Aug 2015 15:50:12 +0000
Subject: [issue23003] traceback.{print_exc, print_exception, format_exc,
 format_exception}: Potential AttributeError
In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za>
Message-ID: <1439826612.3.0.523753278486.issue23003@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
superseder:  -> traceback: add a new thin class storing a traceback without storing local variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23003>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:05:45 2015
From: report at bugs.python.org (Sebastian Kreft)
Date: Mon, 17 Aug 2015 16:05:45 +0000
Subject: [issue24797] email.header.decode_header return type is not consistent
In-Reply-To: <1438787925.35.0.0505694721939.issue24797@psf.upfronthosting.co.za>
Message-ID: <1439827545.92.0.575101899158.issue24797@psf.upfronthosting.co.za>


Sebastian Kreft added the comment:

And what would the new API be?

There is nothing pointing to it either in the documentation https://docs.python.org/3.4/library/email.header.html or source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24797>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:10:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2015 16:10:37 +0000
Subject: [issue24797] email.header.decode_header return type is not consistent
In-Reply-To: <1438787925.35.0.0505694721939.issue24797@psf.upfronthosting.co.za>
Message-ID: <1439827837.96.0.236658945124.issue24797@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right, it's provisional in 3.4.  I'm working on the doc rewrite now (although I suppose there's a chance it won't get accepted for 3.5, I expect it to).

Take a look at https://docs.python.org/3/library/email.policy.html.  Basically, if you use EmailMessage instead of Message (and therefore policy.default instead of policy.compat32) header parsing and decoding is handled for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24797>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:24:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Aug 2015 16:24:38 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439828678.57.0.835733327529.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but because it looks like the design and not a bug it only comes up when you ask people directly what they'd like to change. (The most common bug is pip failing to install/uninstall, which is what you see on the issue tracker.)

The other benefits are that PYDs compiled with VS 2016+ (or whatever it's called) with these options will work with stock Python 3.5 on a clean machine - so if your extension links to python3.dll you can build once for all Python versions 3.5 and later and know that it will just copy and run. If you're building from source and only have a newer compiler than VC14, you will be able to build successfully. Also, we could decide to build some future Python 3.5.x with a newer compiler as it should not break any existing extensions (after much discussion and testing, obviously, but it is only feasible if we properly hide the VC version now).

To achieve these (apart from the last point) with VCredist, we need to be installing the current and all future versions of the redist with Python. Hence a time machine is required, and I haven't come up with any good way to simulate a time machine here.

> not when even MS itself recommends against doing this.

I have separate advice (also from MS, from the same people who have been quoted previously, but in private conversations so I can't link to it) that if we want any chance of our plugin architecture being VC version independent, this is what we have to do. I'm emailing again to get more specific advice, but the official guidance has always been biased by wanting people to get the latest tools (which is why VC9 disappeared until my team made the case that sometimes people can't upgrade). We're still pushing hard to make this an acknowledged use case, and don't be surprised if at some point in the future official advice says "if you allow plugins, do what CPython did to help your users and developers".


The "/MT" == "statically linked" equivalence is an oversimplification in the presence of link-time code generation ("/GL" and "/LTCG" options), as we can take .obj or .lib files compiled with /MT and still use dynamic linking. The difference is we have to do it explicitly, which is what the "/nodefaultlib:libucrt.lib ucrt.lib" options do. If we add concrt140, msvcp140 and vccorlib140 to that as well (and probably the rest of the versions redistributables) then all of them will continue to be dynamically linked.

So basically, all the existing static libs could be built with /MT and still have their dependencies dynamically linked if that's what the final linker decides to do. In any case, they probably need to be rebuilt with VC14 unless the authors have very carefully kept a clean API, in which case it may as well be a DLL.

Because we're talking about a plugin architecture here, I think it's actually advantageous to use static linking of the C++ runtime. The main difference from the C runtime is that the C++ runtime does not have to be shared with the host - Python - and the advantage is that state will not be shared with other plugins that also happen to use the same version of C++ (or worse, a different version with the same name, and now we have a conflict).

I appreciate the problems this causes when trying to link in 3rd-party dependencies, but given a choice between making life easier for developers or users I have to side with the users (while doing as much as I possibly can to make developers lives easier). People installing wheels from Christoph's page or PyPI should be able to expect it to work. When pip grows extensions I'll certainly look into writing an extension for specifying, detecting and getting the required VC redistributable, but I don't want core Python to be burdened with shipping the full set of distributables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:56:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 17 Aug 2015 16:56:38 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1439830598.08.0.426918500636.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Yes that should be good to go

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Aug 17 19:17:17 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 17 Aug 2015 17:17:17 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1439831837.09.0.760216919288.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I am admittedly not a fan of skinnable user interfaces, especially for non-entertainment applications. It doesn't add anything to the usability, and makes support harder. It always says to me "hello, 2002 called and wants it's user interface back". I think the actual changing themes part of ttk is the least useful piece.

However, I've no grand objection to adding a setting in the general pane for this, perhaps called "User Interface Skin". 

I'm still very fond of "themes" for the syntax coloring tab. The two most commonly used terms seem to be "themes" (e.g. TextMate, Eclipse), and "color schemes" (e.g. Sublime, UltraEdit).

On the matter of changing background color, what I mean is that to modify the background color so that e.g. it's off-white instead of white, you need to change I think it's nine different theme elements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Mon Aug 17 19:19:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 17 Aug 2015 17:19:01 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1439831941.71.0.0226026465725.issue24776@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Agree about the font resizing menu items/shortcuts... your original #17642 remains open for this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Mon Aug 17 19:20:37 2015
From: report at bugs.python.org (shiva prasanth)
Date: Mon, 17 Aug 2015 17:20:37 +0000
Subject: [issue24877] Bad Password for file using zipfile module
In-Reply-To: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>
Message-ID: <1439832037.68.0.648594210013.issue24877@psf.upfronthosting.co.za>


Changes by shiva prasanth <kesavarapu.siva at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Mon Aug 17 19:46:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 17:46:53 +0000
Subject: [issue24776] Improve Fonts/Tabs UX for IDLE
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1439833613.07.0.587516717656.issue24776@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree. Cntl/Cmd +/- font sizing works in turtledemo within sensible limits. The code could be copied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Mon Aug 17 19:59:55 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Mon, 17 Aug 2015 17:59:55 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439834395.46.0.479867898372.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

Hello, 

I'm very interested in tackling this issue but this will be my first contribution to Python and I'm quite nervous. I have gone over the developer guide and FAQ but I would appreciate if you could let me know if I should approach this in a certain way.

----------
nosy: +Can ?bano?lu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Mon Aug 17 20:07:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 18:07:27 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1439834847.03.0.668403806093.issue24781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

So you mean text background as opposed to widget background.  I changed the background of non-user-entered shell, stdout, and stderr text in my personal highlight theme to light versions of the foreground, and like the result so much I have considered proposing changing the defaults. The result in Shell is to separate user entries from prompts and output and the latter three from each other.

This leaves the 6 user-entry text items with white background. This would be helpful since most people would want all 6 backgrounds in the editor the same and it is tedious to get all 6 the same 1 at a time and even worse to experiment with different settings. The explanation might be a bit tricky, but the idea is simple enough once seen.  However, I would not want the individualized colors for non-user text altered.

It seems that you want to be able to collectively define 'background white' to an off-white that would either apply to all user-entered

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Mon Aug 17 20:08:36 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 18:08:36 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <1439834916.27.0.496770027659.issue24878@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40197/ntdoc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Mon Aug 17 20:31:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Aug 2015 18:31:51 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439836311.38.0.542335011221.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Welcome. I was hoping a new contributor would see the 'easy' tag. Nervous is okay as long as it leads to heighten carefulness without paralysis.  I am still nervous hitting the [Commit] button.

1. Important. Sign the contributor agreement.
https://www.python.org/psf/contrib/
https://www.python.org/psf/contrib/contrib-form/
I will not look at a patch until you say you have signed.  I will not commit until the '*' appears on your name (perhaps a week).

2. Once you sign, I will give you at least a week to produce something before I work on this by myself.  Patch needs to apply to 3.4, but StackViewer.py should be identical for 3.4/5/6.

3. Post a patch as soon as you do a complete chunk (any of the numbered items).  Start with either 1. or 2. and switch if you get stuck.

Does above answer your question?

----------
assignee:  -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Mon Aug 17 20:42:30 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 17 Aug 2015 18:42:30 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439828678.57.0.835733327529.issue24872@psf.upfronthosting.co.za>
Message-ID: <55D22AFA.2050801@egenix.com>


Marc-Andre Lemburg added the comment:

On 17.08.2015 18:24, Steve Dower wrote:
> 
> We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but because it looks like the design and not a bug it only comes up when you ask people directly what they'd like to change. (The most common bug is pip failing to install/uninstall, which is what you see on the issue tracker.)

Why not ? People certainly trust the Python installer more than
some script which might want to do this afterwards in order to
get a package working. After all, it's signed by the PSF and
comes with certificate backed verification of authenticity.

> The other benefits are that PYDs compiled with VS 2016+ (or whatever it's called) with these options will work with stock Python 3.5 on a clean machine - so if your extension links to python3.dll you can build once for all Python versions 3.5 and later and know that it will just copy and run. If you're building from source and only have a newer compiler than VC14, you will be able to build successfully. Also, we could decide to build some future Python 3.5.x with a newer compiler as it should not break any existing extensions (after much discussion and testing, obviously, but it is only feasible if we properly hide the VC version now).

This would only work for extensions using the stable Python ABI.
The standard approach is to rebuild extension for every minor
release, since the standard Python ABI is not guaranteed to stay
backwards compatible.

> To achieve these (apart from the last point) with VCredist, we need to be installing the current and all future versions of the redist with Python. Hence a time machine is required, and I haven't come up with any good way to simulate a time machine here.

See above. This is really not a very common use case. If you search
for Py_LIMITED_API (which has to be defined to enable the stable
ABI), you'll hardly find any reference to code using it.

>> not when even MS itself recommends against doing this.
> 
> I have separate advice (also from MS, from the same people who have been quoted previously, but in private conversations so I can't link to it) that if we want any chance of our plugin architecture being VC version independent, this is what we have to do. I'm emailing again to get more specific advice, but the official guidance has always been biased by wanting people to get the latest tools (which is why VC9 disappeared until my team made the case that sometimes people can't upgrade). We're still pushing hard to make this an acknowledged use case, and don't be surprised if at some point in the future official advice says "if you allow plugins, do what CPython did to help your users and developers".

Regardless of marketing strategies, the fact that you have to reinstall
Python and all extensions in case there's some bug in the CRT is really
the main argument against doing static linking.

Static linking of the CRT is normally only used in situations where
you don't want to have single file executables without external
dependencies, e.g. for working on arbitrary Windows systems without
having to install anything. It's a valid use case, but not a general
purpose one.

> The "/MT" == "statically linked" equivalence is an oversimplification in the presence of link-time code generation ("/GL" and "/LTCG" options), as we can take .obj or .lib files compiled with /MT and still use dynamic linking. The difference is we have to do it explicitly, which is what the "/nodefaultlib:libucrt.lib ucrt.lib" options do. If we add concrt140, msvcp140 and vccorlib140 to that as well (and probably the rest of the versions redistributables) then all of them will continue to be dynamically linked.
>
> So basically, all the existing static libs could be built with /MT and still have their dependencies dynamically linked if that's what the final linker decides to do. In any case, they probably need to be rebuilt with VC14 unless the authors have very carefully kept a clean API, in which case it may as well be a DLL.

You lost me there. What's the advantage of using /MT when you then add
all of the CRT libs to the set of libs which are dynamically linked ?

Just to clarify:

If I want to ship a C extension compiled for Python 3.5 which links to an
external DLL on the system, I will have to tell the users of the extension
to first run VCredist in order for them to be able to use extension
on their system, since Python 3.5 will not ship with the necessary
CRT DLLs, correct ?

> Because we're talking about a plugin architecture here, I think it's actually advantageous to use static linking of the C++ runtime. The main difference from the C runtime is that the C++ runtime does not have to be shared with the host - Python - and the advantage is that state will not be shared with other plugins that also happen to use the same version of C++ (or worse, a different version with the same name, and now we have a conflict).

Python C extensions are much more than a plugin architecture. They
allow connecting Python to the world of available C libraries out
there, not just ones which you can statically compile.

> I appreciate the problems this causes when trying to link in 3rd-party dependencies, but given a choice between making life easier for developers or users I have to side with the users (while doing as much as I possibly can to make developers lives easier). People installing wheels from Christoph's page or PyPI should be able to expect it to work. When pip grows extensions I'll certainly look into writing an extension for specifying, detecting and getting the required VC redistributable, but I don't want core Python to be burdened with shipping the full set of distributables.

Same here, and even more so: I would like the users to get a Python
installation they can use out of the box, without having to worry
about DLL hell and this includes making it possible to install
Python C extensions with external DLL dependencies without the
need to run VCredist before being able to do so and it includes
getting CRT bug fixes by means of OS updates rather than complete
reinstalls of Python and all your extensions.

Developers can work around these things, but if we end up requiring them
to redistribute VCredist with every single package that has external
dependencies, just to be able to install a binary package,
because Python itself doesn't ship the necessary DLLs, then something
is clearly broken for Python on Windows.

Users will also likely not grant pip admin privileges to run
VCredist for them (or ask their sys admins to allow pip to do this),
so that idea is not going to work out in practice.

Alternatively, we tell users to install VCredist by hand in case
they plan to use Python with C extensions. Possible, but not
very user friendly either.

With Python 2.7 all this is not an issue, creating yet another road
block to prevent upgrades :-(

I understand that you would like us to get rid off the compiler
version dependency and appreciate your work in that direction,
but chances are high that this will not actually work out in
practice. Backwards compatibility is already hard, forward
compatibility is really really difficult to achieve without
a time machine.

BTW: Do you know whether Python 3.5 will still work as Windows service
without the MSVCR140 DLL available in the system folder ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 20:44:38 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Aug 2015 18:44:38 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439837078.45.0.658935999833.issue24879@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Can this be enabled only for namedtuples?  Otherwise this might be a backwards incompatible change, for example:

  class Foo:
    '''spam'''
    _fields = None

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Mon Aug 17 21:09:43 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Mon, 17 Aug 2015 19:09:43 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439838583.23.0.399312139251.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

It does indeed, thank you very much! I have signed the Contributor Agreement and will start working on this right away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Mon Aug 17 21:17:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Aug 2015 19:17:07 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1439839027.79.0.932494772334.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Why not [require administrative privileges]?

Because some people want to use Python and don't have administrative permissions on their own machine (e.g. students, employees, researchers, etc.)

> The standard approach is to rebuild extension for every minor
> release, since the standard Python ABI is not guaranteed to stay
> backwards compatible.

The last point I posted lets you rebuild extensions *with a different compiler*. So when you upgrade to VC15 you can use that to build your Python 3.5 extensions instead of VC14, and still ship those extensions to users without requiring them to install the VC15 redist. Static linking is part of this

> the fact that you have to reinstall
> Python and all extensions in case there's some bug in the CRT is really
> the main argument against doing static linking.

The same argument applies against app-local copies of the runtime, which is why I'm trying to avoid these dependencies rather than volunteering to redistribute and update them for all extensions.

Also, we already rebuild and release Python due to bugs in OpenSSL, so I see no reason why we wouldn't do the same for bugs in the (small) part of the CRT we statically link.

> Static linking of the CRT is normally only used in situations where
> you don't want to have single file executables without external
> dependencies, e.g. for working on arbitrary Windows systems without
> having to install anything. It's a valid use case, but not a general
> purpose one.

Normally, yes, but we have a new use case now that the majority of the C runtime is preinstalled on machines and versionless.

> What's the advantage of using /MT when you then add
> all of the CRT libs to the set of libs which are dynamically linked ?

The part that is statically linked is only a few functions that are either critical to program initialization or specially optimized by the compiler, and the rest of the CRT is versionless and managed by the operating system.

To be clear, the DLLs I listed are not required by CPython or most pure-C extensions (including, I assume, cffi and Cython). It's only when you start using C++ and especially the Microsoft provided libraries for parallelism that you need these DLLs.

> If I want to ship a C extension compiled for Python 3.5 which links to an
> external DLL on the system, I will have to tell the users of the extension
> to first run VCredist in order for them to be able to use extension
> on their system, since Python 3.5 will not ship with the necessary
> CRT DLLs, correct ?

Correct, just as it's always been. However, if you want to ship a C extension compiled for Python 3.5 which *does not* link to an external DLL, you *do not* have to tell your user to install anything.

> includes getting CRT bug fixes by means of OS updates rather than complete
> reinstalls of Python and all your extensions.

Users of Python 3.5 will get CRT updates from the OS. Only a few trivial functions are statically linked under this scheme.

> Developers can work around these things, but if we end up requiring them
> to redistribute VCredist with every single package that has external
> dependencies, just to be able to install a binary package,
> because Python itself doesn't ship the necessary DLLs, then something
> is clearly broken for Python on Windows.

> Alternatively, we tell users to install VCredist by hand in case
> they plan to use Python with C extensions. Possible, but not
> very user friendly either.

I proposed above making this an option in the installer. Problem is, it doesn't help extensions built with later compilers. Only the extension knows which version of the redist is needed.

> With Python 2.7 all this is not an issue, creating yet another road
> block to prevent upgrades :-(

The issue with Python 2.7 is that you need to use VC9. If you think requiring everyone to use VC14 for Python 3.5 forever is less of an issue than having to recompile static libraries with a new version of the compiler, please say so explicitly, as I have not heard anyone claim that and need to hear it said in complete seriousness before I have any chance of believing it's true.

> chances are high that this will not actually work out in
> practice. Backwards compatibility is already hard, forward
> compatibility is really really difficult to achieve without
> a time machine.

Agreed. However, the forward compatibility problem we're facing right now seems to be external libraries compiled under old compilers - that is, VC10 (to pick one example) failed at forward compatibility, and some work is required to fix that failure. If we concede defeat now, then we will also fail at forward compatibility, and it will take work in the future to correct our failure. I'm trying to do as much work now as I can to offset that work for everyone else later (and thanks for holding me accountable on this - it's more helpful than my apparently frustrated responses probably make it seem :) ).

> BTW: Do you know whether Python 3.5 will still work as Windows service
> without the MSVCR140 DLL available in the system folder ?

Yes, it will. MSVCR140 does not exist - it is called ucrtbase.dll and ships with Python 3.5, Windows 10, and (later this year, I'm told) through normal Windows updates for downlevel operating systems. This is the *only* part of the CRT (it's also the majority of the CRT) that we install, and we do force users to have administrative privileges when installing Python if they don't already have it.

Python does not depend on the C++ runtime. If an extension requires the C++ runtime, users will have to acquire it some other way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 17 21:28:46 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 17 Aug 2015 19:28:46 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439839726.57.0.537368973562.issue24790@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Mon Aug 17 21:43:40 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 17 Aug 2015 19:43:40 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1439840620.17.0.500339398971.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Looking to get some feedback on a large chunk of new code (not yet complete), for the 'new' preferences dialog. Not so much UI things as if I've made any glaring structural errors which aren't obvious to this Python sorta-newbie.

For lack of a better place, I've attached prefs-wip.patch, which just contains code for four entirely new files (querydialog.py, tkextras.py, uifactory.py, and uipreferences.py), no changes to existing files. You should be able to run it standalone just with e.g. "python -m idlelib.uipreferences"

There's some comments at the start of uipreferences.py regarding structural changes from the code in the original configDialog.py.

Thanks!

----------
keywords: +patch
Added file: http://bugs.python.org/file40198/prefs-wip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:01:01 2015
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Mon, 17 Aug 2015 20:01:01 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1439841661.65.0.0706707315688.issue24383@psf.upfronthosting.co.za>


Changes by A. Jesse Jiryu Davis <jesse at emptysquare.net>:


----------
nosy: +emptysquare

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24383>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:03:25 2015
From: report at bugs.python.org (Matt Spitz)
Date: Mon, 17 Aug 2015 20:03:25 +0000
Subject: [issue24882] ThreadPoolExecutor doesn't reuse threads until #threads
 == max_workers
In-Reply-To: <1439823540.4.0.657998470812.issue24882@psf.upfronthosting.co.za>
Message-ID: <1439841805.69.0.551147131409.issue24882@psf.upfronthosting.co.za>


Changes by Matt Spitz <mattspitz at gmail.com>:


----------
title: ThreadPoolExceutor doesn't reuse threads until #threads == max_workers -> ThreadPoolExecutor doesn't reuse threads until #threads == max_workers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24882>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:09:44 2015
From: report at bugs.python.org (Matt Spitz)
Date: Mon, 17 Aug 2015 20:09:44 +0000
Subject: [issue24882] ThreadPoolExecutor doesn't reuse threads until #threads
 == max_workers
In-Reply-To: <1439823540.4.0.657998470812.issue24882@psf.upfronthosting.co.za>
Message-ID: <1439842184.65.0.75503955254.issue24882@psf.upfronthosting.co.za>


Matt Spitz added the comment:

On further investigation, it appears that we can't just check against the queue length, as it doesn't indicate whether threads are doing work or idle.

A change here will need a counter/semaphore to keep track of the number of idle/working threads, which may have negative performance implications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24882>
_______________________________________

From report at bugs.python.org  Tue Aug 18 03:05:11 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 Aug 2015 01:05:11 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439859911.57.0.469167920932.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a new version of the patch with Nathaniel's and and Berker's comments addressed.

----------
Added file: http://bugs.python.org/file40199/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 18 03:59:54 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Aug 2015 01:59:54 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439863194.54.0.160654393367.issue24879@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Named tuples are not a type, they are a protocol.  Guido has agreed that checking for _fields is an acceptable and preferred way of finding out whether something is a namedtuple.    I can add a check to at least check the value of _fields is an iterable of strings.  If it still aliases with some random use of _fields, the only consequence is that the matching field names will appear in a different order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 04:17:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 02:17:03 +0000
Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to
 the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <20150818021644.36745.32430@psf.io>


Roundup Robot added the comment:

New changeset d3cda8cf4d42 by Ned Deily in branch '2.7':
Issue #24079: Improve description of the text and tail attributes for
https://hg.python.org/cpython/rev/d3cda8cf4d42

New changeset ad0491f85050 by Ned Deily in branch '3.4':
Issue #24079: Improve description of the text and tail attributes for
https://hg.python.org/cpython/rev/ad0491f85050

New changeset 17ce3486fd8f by Ned Deily in branch '3.5':
Issue #24079: merge from 3.4
https://hg.python.org/cpython/rev/17ce3486fd8f

New changeset 3c94ece57c43 by Ned Deily in branch 'default':
Issue #24079: merge from 3.5
https://hg.python.org/cpython/rev/3c94ece57c43

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24079>
_______________________________________

From report at bugs.python.org  Tue Aug 18 04:20:53 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Aug 2015 02:20:53 +0000
Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to
 the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1439864453.59.0.237804812584.issue24079@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for all of your contributions on this.  I've committed a version along the lines I suggested along with Martin's example.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24079>
_______________________________________

From report at bugs.python.org  Tue Aug 18 04:30:49 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 18 Aug 2015 02:30:49 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439865049.78.0.439683420261.issue24769@psf.upfronthosting.co.za>


Robert Collins added the comment:

Patch looks good to me too. I think this needs to be put forward as a PR to bitbucket right? It looks Release Critical to me.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 18 04:33:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 18 Aug 2015 02:33:42 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439865222.14.0.251981713216.issue24847@psf.upfronthosting.co.za>


Robert Collins added the comment:

Looks good to me. I think you should commit (or perhaps you are pending PR approval on the rc branch or something?)

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 18 05:29:41 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 03:29:41 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439868581.44.0.29461308449.issue24879@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Named tuples are not a type, they are a protocol.  Guido has agreed that checking for _fields is an acceptable and preferred way of finding out whether something is a namedtuple.

They are, but for protocols we usually use dunder names.  "_fields" is a common enough attribute name for all kinds of objects, not necessarily namedtuples.

Can we at least check if the class is a tuple subclass and then use its '_fields' for sorting?

> I can add a check to at least check the value of _fields is an iterable of strings.  If it still aliases with some random use of _fields, the only consequence is that the matching field names will appear in a different order.

+1 for checking if it's an iterable of strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:04:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 05:04:54 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <20150818050451.4925.92360@psf.io>


Roundup Robot added the comment:

New changeset 40f2bbb922e6 by Raymond Hettinger in branch 'default':
Issue #24878:  Add docstrings to selected namedtuples
https://hg.python.org/cpython/rev/40f2bbb922e6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:05:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Aug 2015 05:05:16 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <1439874316.1.0.167688628023.issue24878@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:13:22 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Tue, 18 Aug 2015 05:13:22 +0000
Subject: [issue24883] Typo in c-api/buffer documentation
Message-ID: <1439874802.02.0.402789203299.issue24883@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

https://docs.python.org/3/c-api/buffer.html

Some links to the members of Py_buffer are not available.
"~Py_Buffer" should be "~Py_buffer".
The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: bufferdoc.patch
keywords: patch
messages: 248758
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Typo in c-api/buffer documentation
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40200/bufferdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24883>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:36:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Aug 2015 05:36:42 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439876202.22.0.491471985655.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'll withdraw my current pull request and make a new one tomorrow. I prefer to check into 3.5.1 immediately, and especially since this one will be covered by the buildbots, so I'll do that first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 18 08:20:17 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 18 Aug 2015 06:20:17 +0000
Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to
 the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1439878817.31.0.604403376224.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The "can store arbitrary objects" sentence is now duplicated, and still way too visible. I have to read three sentences until it tells me what I need to know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24079>
_______________________________________

From report at bugs.python.org  Tue Aug 18 08:20:57 2015
From: report at bugs.python.org (Alex Budovski)
Date: Tue, 18 Aug 2015 06:20:57 +0000
Subject: [issue1635741] Interpreter seems to leak references after finalization
Message-ID: <1439878857.64.0.0889074474583.issue1635741@psf.upfronthosting.co.za>


Alex Budovski added the comment:

Interestingly enough, some of the leaked memory came from the finalize routine itself! Here's one example:

0:004> !heap -p -a 0x000000DB144346F0
    address 000000db144346f0 found in
    _HEAP @ db0cae0000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        000000db14434690 030a 0000  [00]   000000db144346c0    03074 - (busy)
        7ffc55628b04 ntdll!RtlpCallInterceptRoutine+0x0000000000000040
        7ffc555f9f36 ntdll!RtlAllocateHeap+0x0000000000079836
        7ffc2a60c4da ucrtbased!calloc_base+0x000000000000123a
        7ffc2a60c27d ucrtbased!calloc_base+0x0000000000000fdd
        7ffc2a60f34f ucrtbased!malloc_dbg+0x000000000000002f
        7ffc2a60fdde ucrtbased!malloc+0x000000000000001e
        5a5e6ef9 python36_d!_PyMem_RawMalloc+0x0000000000000029
        5a5e78c7 python36_d!_PyMem_DebugAlloc+0x0000000000000087
        5a5e5e6f python36_d!_PyMem_DebugMalloc+0x000000000000001f
        5a5e7230 python36_d!PyMem_Malloc+0x0000000000000030
        5a582047 python36_d!new_keys_object+0x0000000000000077
        5a57f7c5 python36_d!dictresize+0x0000000000000085
        5a57a4b2 python36_d!PyDict_Merge+0x0000000000000112
        5a57bf33 python36_d!PyDict_Update+0x0000000000000023
        5a75fb1d python36_d!PyImport_Cleanup+0x000000000000045d
        5a778f9e python36_d!Py_Finalize+0x000000000000005e

----------
nosy: +Alex Budovski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Aug 18 08:29:21 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 18 Aug 2015 06:29:21 +0000
Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to
 the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1439879361.65.0.697372211376.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I think the first two sentences can simply be removed to fix this, without loss of readability or information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24079>
_______________________________________

From report at bugs.python.org  Tue Aug 18 08:39:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 06:39:23 +0000
Subject: [issue24883] Typo in c-api/buffer documentation
In-Reply-To: <1439874802.02.0.402789203299.issue24883@psf.upfronthosting.co.za>
Message-ID: <20150818063920.13734.26866@psf.io>


Roundup Robot added the comment:

New changeset 0c5af3e398f0 by Benjamin Peterson in branch '3.4':
'Py_Buffer' should be 'Py_buffer' (closes #24883)
https://hg.python.org/cpython/rev/0c5af3e398f0

New changeset 76892906253c by Benjamin Peterson in branch '3.5':
merge 3.4 (#24883)
https://hg.python.org/cpython/rev/76892906253c

New changeset c1e6bc6a9d69 by Benjamin Peterson in branch 'default':
Merge 3.5 (#24883)
https://hg.python.org/cpython/rev/c1e6bc6a9d69

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24883>
_______________________________________

From report at bugs.python.org  Tue Aug 18 11:30:10 2015
From: report at bugs.python.org (REIX Tony)
Date: Tue, 18 Aug 2015 09:30:10 +0000
Subject: [issue24046] Incomplete build on AIX
In-Reply-To: <1429844081.77.0.468875149896.issue24046@psf.upfronthosting.co.za>
Message-ID: <1439890210.71.0.0864675224228.issue24046@psf.upfronthosting.co.za>


REIX Tony added the comment:

Fresh openssl versions are now available for AIX: 1.0.1p and 1.0.2d .
See: http://www.bullfreeware.com/search.php?package=openssl

----------
nosy: +trex58

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24046>
_______________________________________

From report at bugs.python.org  Tue Aug 18 11:36:54 2015
From: report at bugs.python.org (Marian Horban)
Date: Tue, 18 Aug 2015 09:36:54 +0000
Subject: [issue24884] Add method reopenFile() in WatchedFileHandler class
Message-ID: <1439890614.7.0.380949664782.issue24884@psf.upfronthosting.co.za>


New submission from Marian Horban:

Method WatchedFileHandler::emit() makes 2 things:
1. reopens log file,
2. emits record.
Sometimes user wants to reopen file immediately after some action without emitting.
Code that reopens file must be moved to separate method to avoid copy-pasting code in programs that use this functionality.
Patch is provided.

----------
files: add_reopen_file.patch
keywords: patch
messages: 248765
nosy: Marian Horban
priority: normal
severity: normal
status: open
title: Add method reopenFile() in WatchedFileHandler class
type: enhancement
Added file: http://bugs.python.org/file40201/add_reopen_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24884>
_______________________________________

From report at bugs.python.org  Tue Aug 18 11:46:27 2015
From: report at bugs.python.org (REIX Tony)
Date: Tue, 18 Aug 2015 09:46:27 +0000
Subject: [issue20600] test_create_server_ssl_verify_failed() failure on "PPC64
 AIX 3.x" buildbot
In-Reply-To: <1392136781.96.0.859159765022.issue20600@psf.upfronthosting.co.za>
Message-ID: <1439891187.52.0.600600621995.issue20600@psf.upfronthosting.co.za>


REIX Tony added the comment:

I'm now working about the port of Python 3.4.3 on AIX.
So, I'm interesting with issues dealing with AIX.
I'm now building a view of the issues on AIX 6.1 .

----------
nosy: +trex58

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20600>
_______________________________________

From report at bugs.python.org  Tue Aug 18 11:48:30 2015
From: report at bugs.python.org (Aymeric Augustin)
Date: Tue, 18 Aug 2015 09:48:30 +0000
Subject: [issue24885] StreamReaderProtocol docs recommend using private API
Message-ID: <1439891310.64.0.826592232629.issue24885@psf.upfronthosting.co.za>


New submission from Aymeric Augustin:

https://docs.python.org/3/library/asyncio-stream.html?highlight=streamreaderprotocol#stream-functions says:

> (If you want to customize the StreamReader and/or StreamReaderProtocol classes, just copy the code ? there?s really nothing special here except some convenience.)

StreamReaderProtocol inherits from streams.FlowControlMixin which isn't documented. Applying this advice means, instead of inheriting from StreamReaderProtocol, inheriting from streams.FlowControlMixin -- in order to obtain the _drain_helper method, which StreamWriter.drain must wait for.

At this point inheriting StreamReaderProtocol appears to be the lesser evil.

I suggest to remove this paragraph from the documentation.

----------
components: asyncio
messages: 248767
nosy: aymeric.augustin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: StreamReaderProtocol docs recommend using private API
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24885>
_______________________________________

From report at bugs.python.org  Tue Aug 18 12:17:36 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 18 Aug 2015 10:17:36 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <1439893056.52.0.0412191613658.issue24878@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

I see some typos in aifc.py:
+_aifc_params.sampwidth.__doc__ = 'Ample width in bytes'
+_aifc_params.compname.__doc__ = ("""A human-readable version ofcompression type

Should that be "Sample width" and "of compression"?

----------
nosy: +encukou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Tue Aug 18 13:24:52 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 18 Aug 2015 11:24:52 +0000
Subject: [issue24886] open fails randomly on AIX
Message-ID: <1439897092.19.0.462319646512.issue24886@psf.upfronthosting.co.za>


New submission from Arnon Yaari:

We are using Python 2.7.8 on AIX 7.1 TL 3.
On rare occasions, calls to open files with mode "w" fail with: IOError: File exists.

      File "/root/jenkins/workspace/powertools/eggs/infi.credentials_store-0.1-py2.7.egg/infi/credentials_store/base.py", line 175, in set_credentials
        with open(self.get_file_path(), 'w') as f:
    IOError: [Errno 17] File exists: '/root/.infinidat/infinihost'

This happens randomly on multiple systems and different files (including e.g. "/dev/null").
This is very strange because "File exists" should only be raised if we open the file with the 'x' flag (os.O_EXCL) and we don't.
After debugging, we discovered that this happens due to a bug in AIX. On AIX, fopen checks for mode[2] (where 'mode' is the second argument passed to it - in our case, "w") regardless of its length. fopen checks this byte against 'x' to decide if O_EXCL should be used. In the case of passing "w" as 'mode', mode[2] will contain undefined data -- and in rare cases it will contain the byte 'x'.
This was reported to IBM and APARs exist for this issue:
http://www.ibm.com/support/docview.wss?uid=isg1IV64453 (see related APARs for various AIX versions in this page)

Python can and should work around this because the code in fileobject.c is also partly to blame:
Python 2.7.x contains the following lines:

    /* probably need to replace 'U' by 'rb' */
    newmode = PyMem_MALLOC(strlen(mode) + 3);

For the 'mode' parameter, Python allocates 3 additional bytes that are not always used, and these bytes contain uninitialized data. The byte 'x' that causes the problem comes from this allocation. Python should set the bytes to zero to avoid this issue.
I'm attaching a patch. Note that this applies only to the 2.x branch.

----------
files: aix_fopen_fix.diff
keywords: patch
messages: 248769
nosy: wiggin15
priority: normal
severity: normal
status: open
title: open fails randomly on AIX
versions: Python 2.7
Added file: http://bugs.python.org/file40202/aix_fopen_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24886>
_______________________________________

From report at bugs.python.org  Tue Aug 18 13:42:06 2015
From: report at bugs.python.org (Cal Leeming)
Date: Tue, 18 Aug 2015 11:42:06 +0000
Subject: [issue24887] Sqlite3 has no option to provide open flags
Message-ID: <1439898126.92.0.460778309784.issue24887@psf.upfronthosting.co.za>


New submission from Cal Leeming:

There are several flags which can be provided to Sqlite3 during connection [1]. Alternative libraries such as apsw provide the ability to use these flags [2], however it would be nice if `sqlite3` supported this out of the box.

Is there any reason why the wrapper for `sqlite3` does not allow flags to be passed in? If not, can we add it?

[1]: https://www.sqlite.org/c3ref/open.html
[2]: https://github.com/rogerbinns/apsw/blob/master/example-code.py#L466

----------
components: Library (Lib)
messages: 248770
nosy: sleepycal
priority: normal
severity: normal
status: open
title: Sqlite3 has no option to provide open flags
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24887>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:11:31 2015
From: report at bugs.python.org (John Lehmann)
Date: Tue, 18 Aug 2015 12:11:31 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1439899891.84.0.941451357627.issue23972@psf.upfronthosting.co.za>


Changes by John Lehmann <j1o1h1n at gmail.com>:


----------
nosy: +j1o1h1n

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23972>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:36:28 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Tue, 18 Aug 2015 12:36:28 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439901388.8.0.562991735321.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

Hello again,

I have spent some time going over the code and how the PyShell brings all of this together and have formed some loose opinions on how to solve these issues but I wanted to get a much more informed opinion.

I will provide a patch for the first one first, so right now, all my questions are related to that one.

Basically, I have come up with three different places I could patch in StackViewer.py to remove "idlelib.run.runcode" from the stack viewer. 

First option is to patch the constructor of "StackTreeItem" so that if "idlelib.run.runcode" is in the traceback, it never gets pushed to the stack list. I don't like this approach very much because I would essentially be removing data from the stack. 

Second option is to patch the "GetSubList" method so that the iterated variable "info" is checked before constructing a new "FrameTreeItem". If "idlelib.run.runcode" is matched, we would just continue to the next value in the list. I think this would lead to repetitive code though. We would rewrite some of the "GetText" method of "FrameTreeItem" and then make a string comparison to identify the entry to be removed.

Third option is to call the "GetText" method after each created "FrameTreeItem" and make the string comparison then. This would add a lot of method calls if the stack is long. On the other hand, this approach doesn't repeat any code. 

It is highly possible that I have missed something very simple and elegant :) I would very much appreciate your input. I can make upload a patch once I get your approval. Which approach would be better here?

Something else that I would like to ask is the preparation of the patch file. Should switch to the 3.4 branch and then create the patch or can I do it at the dev branch? How would I check if the patch applies to 3.4/3.5/3.6 (apart from applying them manually and testing if it has the desired outcome)?

I'm sorry for the wall of text, I'm nervous and I don't want to mess something up. :)

Thanks a lot for your assistance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 18 15:20:28 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 18 Aug 2015 13:20:28 +0000
Subject: [issue24884] Add method reopenFile() in WatchedFileHandler class
In-Reply-To: <1439890614.7.0.380949664782.issue24884@psf.upfronthosting.co.za>
Message-ID: <1439904028.3.0.643410140934.issue24884@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24884>
_______________________________________

From report at bugs.python.org  Tue Aug 18 15:40:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2015 13:40:55 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439905255.05.0.477579312915.issue24879@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, protocols and duck typing do not always use dunder names.  In fact checking for dunder names explicitly is probably the less common of the two cases.  (We are talking about "protocol" here in a generic sense, not the restricted set of those that include dunder methods.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:00:24 2015
From: report at bugs.python.org (Anton Barkovsky)
Date: Tue, 18 Aug 2015 14:00:24 +0000
Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual
In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za>
Message-ID: <1439906424.26.0.372404957037.issue22452@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <anton at swarmer.me>:


----------
nosy: +anton.barkovsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22452>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:33:44 2015
From: report at bugs.python.org (Stephen Shirley)
Date: Tue, 18 Aug 2015 14:33:44 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1439908424.95.0.104770224016.issue23078@psf.upfronthosting.co.za>


Changes by Stephen Shirley <kormat at gmail.com>:


----------
nosy: +kormat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:36:31 2015
From: report at bugs.python.org (Geoffrey Royer)
Date: Tue, 18 Aug 2015 14:36:31 +0000
Subject: [issue24888] FileNotFoundException raised by subprocess.call
Message-ID: <1439908591.24.0.224694175166.issue24888@psf.upfronthosting.co.za>


New submission from Geoffrey Royer:

According to the documentation of the subprocess.check_call function: https://docs.python.org/3/library/subprocess.html#subprocess.check_call

It would be nice to notify the reader that this function can raise FileNotFoundException. It is raised in case when the binary one wants to call does not exist.

Example:

Python 3.4.0 (default, Jun 19 2015, 14:20:21) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_call(["foo", "bar"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/subprocess.py", line 552, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python3.4/subprocess.py", line 533, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.4/subprocess.py", line 848, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.4/subprocess.py", line 1446, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'foo'

----------
assignee: docs at python
components: Documentation
messages: 248773
nosy: Geoffrey Royer, docs at python
priority: normal
severity: normal
status: open
title: FileNotFoundException raised by subprocess.call

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24888>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:43:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2015 14:43:45 +0000
Subject: [issue24888] FileNotFoundException raised by subprocess.call
In-Reply-To: <1439908591.24.0.224694175166.issue24888@psf.upfronthosting.co.za>
Message-ID: <1439909025.33.0.988937657056.issue24888@psf.upfronthosting.co.za>


R. David Murray added the comment:

We don't in general document all the exceptions that can be raised by a piece of code.  This could be an edge case, though.  Let's see what others thing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24888>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:44:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2015 14:44:02 +0000
Subject: [issue24888] FileNotFoundException raised by subprocess.call
In-Reply-To: <1439908591.24.0.224694175166.issue24888@psf.upfronthosting.co.za>
Message-ID: <1439909042.47.0.717122141345.issue24888@psf.upfronthosting.co.za>


R. David Murray added the comment:

think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24888>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:47:06 2015
From: report at bugs.python.org (Geoffrey Royer)
Date: Tue, 18 Aug 2015 14:47:06 +0000
Subject: [issue24888] FileNotFoundException raised by subprocess.call
In-Reply-To: <1439908591.24.0.224694175166.issue24888@psf.upfronthosting.co.za>
Message-ID: <1439909226.74.0.577925634933.issue24888@psf.upfronthosting.co.za>


Changes by Geoffrey Royer <geoffrey.royer at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24888>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:53:32 2015
From: report at bugs.python.org (Geoffrey Royer)
Date: Tue, 18 Aug 2015 14:53:32 +0000
Subject: [issue24888] FileNotFoundException raised by subprocess.call
In-Reply-To: <1439908591.24.0.224694175166.issue24888@psf.upfronthosting.co.za>
Message-ID: <1439909612.99.0.916546371677.issue24888@psf.upfronthosting.co.za>


Changes by Geoffrey Royer <geoffrey.royer at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24888>
_______________________________________

From report at bugs.python.org  Tue Aug 18 18:13:18 2015
From: report at bugs.python.org (shiva prasanth)
Date: Tue, 18 Aug 2015 16:13:18 +0000
Subject: [issue24877] Bad Password for file using zipfile module
In-Reply-To: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>
Message-ID: <1439914398.08.0.535952760357.issue24877@psf.upfronthosting.co.za>


Changes by shiva prasanth <kesavarapu.siva at gmail.com>:


----------
status: closed -> open
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Tue Aug 18 18:15:16 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 Aug 2015 16:15:16 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1439914516.66.0.0140573686798.issue24769@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It's ultimately Larry's call, but I think it should go into 3.5.0.

----------
assignee:  -> larry
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:10:43 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Aug 2015 17:10:43 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439917843.22.0.545538804814.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

StackViewer.py seem to be identical in 3.4, 3.5, and 3.6, so a patch against any applies to all.  The diff with 2.7 is

F:\Python\dev\36>hg diff -r 4884af6d3e30 f:/python/dev/36/Lib/idlelib/StackViewer.py
@@ -2,7 +2,7 @@
 import sys
 import linecache
 import re
-import Tkinter as tk
+import tkinter as tk

 from idlelib.TreeWidget import TreeNode, TreeItem, ScrolledCanvas
 from idlelib.ObjectBrowser import ObjectTreeItem, make_objecttreeitem
@@ -10,7 +10,7 @@

 def StackBrowser(root, flist=None, tb=None, top=None):
     if top is None:
-        from Tkinter import Toplevel
+        from tkinter import Toplevel
         top = Toplevel(root)
     sc = ScrolledCanvas(top, bg="white", highlightthickness=0)
     sc.frame.pack(expand=1, fill="both")
@@ -109,7 +109,7 @@
         return len(self.object) > 0

     def keys(self):
-        return self.object.keys()
+        return list(self.object.keys())

     def GetSubList(self):
         sublist = []

The second and third differences are due to unneeded code; I will remove them after I submit this message, so update your repository after I do that and then patch.

---
Your research is very helpful.  The purpose of 1. *is* to remove data ;-) -- data that is only present because of Idle.  The purpose of  StackTreeItem.get_stack is to removed unneeded data while converting a linked list to a regular list.  Note that the loop drops 2 of 4 fields. I do not know if
        if tb and tb.tb_frame is None:
            tb = tb.tb_next
actually removes anything, but after this, I believe that the idlelib.run.runcode node (or idlelib.PyShell.runcode node, when Idle is started with -n) is at the top of the linked list.  So I believe adding
        tb = tb.tb_next
after the above will do what we want.  Try it, and if it works, move on.

---
6 (modeled after 3). Modules only have +Globals.  Remove +Globals under each module and instead display globals when expanding. (There will only be a module other than __main__ when there is an error in another module being imported.  We should then improve the lines to read
  + Globals for module __main__ ...
  + Locals for function xyz...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:24:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 17:24:39 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <20150818172436.15619.21618@psf.io>


Roundup Robot added the comment:

New changeset 11e9f34169d1 by Victor Stinner in branch '3.4':
cgi.FieldStorage.read_multi ignores Content-Length
https://hg.python.org/cpython/rev/11e9f34169d1

New changeset 5b9209e4c3e4 by Victor Stinner in branch '3.5':
(Merge 3.4) cgi.FieldStorage.read_multi ignores Content-Length
https://hg.python.org/cpython/rev/5b9209e4c3e4

New changeset 0ff1acc89cf0 by Victor Stinner in branch 'default':
(Merge 3.5) cgi.FieldStorage.read_multi ignores Content-Length
https://hg.python.org/cpython/rev/0ff1acc89cf0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:26:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Aug 2015 17:26:58 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1439918818.67.0.0230719061398.issue24764@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I applied the fix, thanks Peter for the report and the fix, thanks Pierre for the review.

> https://bugs.launchpad.net/barbican/+bug/1485452, 
> is problem mentioned in the bug is same with mentioned bug?

I don't know, but you can try to apply the patch locally if you want, or download the Python 3.4 using Mercurial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:28:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 17:28:19 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <20150818172816.15629.87872@psf.io>


Roundup Robot added the comment:

New changeset 9ad330a9d785 by Terry Jan Reedy in branch '2.7':
Issue #24790: Remove extraneous code (which also create 2 & 3 conflicts).
https://hg.python.org/cpython/rev/9ad330a9d785

New changeset 010264c9ceae by Terry Jan Reedy in branch '3.4':
Issue #24790: Remove extraneous code (which also create 2 & 3 conflicts).
https://hg.python.org/cpython/rev/010264c9ceae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:45:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Aug 2015 17:45:31 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1439919931.74.0.305674496894.issue24764@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24764>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:45:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Aug 2015 17:45:33 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439919933.89.0.183082094608.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

7. Sorts global and local names (as with dir()).

8. Don't expand values with their class attributes, at least not for builtins.  Example

+ <dir icon> __doc__  = None

Clicking + gives all the attributes of type(None), each with its own +.  It does not do this for ints and strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:23:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 18:23:23 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <20150818182319.6308.9239@psf.io>


Roundup Robot added the comment:

New changeset 73984e665bf5 by Yury Selivanov in branch '3.5':
Issue #23572: Fixed functools.singledispatch on classes with falsy metaclasses.
https://hg.python.org/cpython/rev/73984e665bf5

New changeset 94d0c219d46f by Yury Selivanov in branch 'default':
Merge 3.5 (issue #23572)
https://hg.python.org/cpython/rev/94d0c219d46f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23572>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:24:22 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 18:24:22 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <1439922262.05.0.908226117217.issue23572@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I was also bitten by this via Enum. Is there any chance this will be fixed in Python 3.5?

It will be fixed in 3.5.1.

Thanks for the patch, Ethan!

----------
nosy: +yselivanov
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23572>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:28:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Aug 2015 18:28:29 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439922509.24.0.0871425596255.issue24879@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40203/pydoc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:38:46 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 18:38:46 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <1439923126.16.0.44808644406.issue23572@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23572>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:41:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 18:41:00 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <20150818183242.6792.37657@psf.io>


Roundup Robot added the comment:

New changeset 586195685aaf by Yury Selivanov in branch '3.4':
Issue #23572: Fixed functools.singledispatch on classes with falsy metaclasses.
https://hg.python.org/cpython/rev/586195685aaf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23572>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:42:06 2015
From: report at bugs.python.org (Chris Hogan)
Date: Tue, 18 Aug 2015 18:42:06 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1439923326.72.0.590937229773.issue8987@psf.upfronthosting.co.za>


Chris Hogan added the comment:

At Intel, we've run into problems with external modules giving paths to _nt_quote_args that contain trailing backslashes, which escapes the final quote and breaks the command.  This fix takes care of special characters, trailing backslashes, and embedded quotes as in Matt's example.  I've also added unit tests for these cases, as well as a high level test that builds an extension and defines some macros that contain quotes and special characters. 

setup.py - Includes a library directory with a trailing backslash. I compiled a simple library, test_module.lib, and put it in that directory to test the linking.  This fails without my fix.  The macro definitions also fail without this fix.

testmodule.c - A simple C extension.  It just makes sure everything worked and returns the string "Success!"

As for current workarounds in setup scripts, I know numpy uses their own distutils.  They wrote a quote_args() function that they use instead of _nt_quote_args(). It checks for spaces, but only if the argument isn't already quoted.  It doesn't account for other special characters or trailing backslashes.

----------
nosy: +christopher.hogan
Added file: http://bugs.python.org/file40204/quote-args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:42:41 2015
From: report at bugs.python.org (Chris Hogan)
Date: Tue, 18 Aug 2015 18:42:41 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1439923361.31.0.627961233894.issue8987@psf.upfronthosting.co.za>


Changes by Chris Hogan <christopher.hogan at Intel.com>:


Added file: http://bugs.python.org/file40205/quote-args-ext.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:50:17 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 18:50:17 +0000
Subject: [issue24692] types.coroutines() idempotence documentation
In-Reply-To: <1437650502.32.0.0288592289227.issue24692@psf.upfronthosting.co.za>
Message-ID: <1439923817.23.0.403237731294.issue24692@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Is this still something that we need to address? I think that the current types.coroutine docs are pretty accurate and don't see where the proposed patch really improves them.

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24692>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:53:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Aug 2015 18:53:36 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439924016.77.0.746727613768.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Posting the actual changes made to Tcl and Tk, mainly so I can link them from the upstream issue I'm filing.

----------
Added file: http://bugs.python.org/file40206/tcltk_ucrt_option.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:55:09 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 18:55:09 +0000
Subject: [issue24710] Class name hardcoded in
 TracebackException.from_exception()
In-Reply-To: <1437778625.24.0.630527994303.issue24710@psf.upfronthosting.co.za>
Message-ID: <1439924109.86.0.997342006451.issue24710@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

LGTM.

FWIW, using 'self.from_exception(..)' is better because this way it's easier to override the method.  Another way would be to write 'type(self).from_exception(..)', but I think using 'self' is good enough.

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24710>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:59:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Aug 2015 18:59:10 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1439924350.13.0.985482629175.issue4356@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Tue Aug 18 21:16:50 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 18 Aug 2015 19:16:50 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1439925410.38.0.878396107341.issue8987@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Tue Aug 18 21:59:09 2015
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 18 Aug 2015 19:59:09 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1439927949.54.0.0700592703189.issue24294@psf.upfronthosting.co.za>


Jim Jewett added the comment:

I've changed the stage to "test needed". 

At a minimum, an interactive test should be written and added to the documentation.  Better would be an automated test (perhaps via subprocess).

The documentation should also be updated; at a minimum, there should be a versionchanged to say when the default changed. Ideally, also some clarification on the intended differences between DeprecationWarning and PendingDeprecationWarning, and whether there are any behavioral differences.

----------
nosy: +Jim.Jewett
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:03:11 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Aug 2015 20:03:11 +0000
Subject: [issue24889] Idle: always start with focus
Message-ID: <1439928191.61.0.630343371617.issue24889@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

On Windows, starting Idle with an icon or at console brings up shell or editor window with focus, ready to receive input. Starting Idle from a built python_d in interactive console mode with '>>> import idlelib.idle' brings up an Idle shell with a cursor blinking at the '>>> ' prompt, but leaves the input focus with the console until one clicks on the Shell window.  This is quite annoying and I want to fix it.

I have the impression that this may be a Windows-only problem.  True?

PyShell.main calls PyShellFileList.open_shell, which calls PyShell.begin. I believe this is the only place .begin is called, and it is only called when there is no existing Shell.

Calling text.focus_force() works for me.  .focus_set does not as the issue is application focus rather than widget focus within Idle.  Does this or might this cause any problems with Linux or Mac?

--
Side note: any comment on this line in the context?
         tkinter._default_root = None # 03Jan04 KBK What's this?

----------
assignee: terry.reedy
components: IDLE
files: idle-focus-fix.diff
keywords: patch
messages: 248790
nosy: markroseman, serhiy.storchaka, terry.reedy
priority: high
severity: normal
stage: commit review
status: open
title: Idle: always start with focus
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40207/idle-focus-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24889>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:11:25 2015
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 18 Aug 2015 20:11:25 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439928685.03.0.305218043858.issue24790@psf.upfronthosting.co.za>


Jim Jewett added the comment:

Terry:  Was removing the public attribute keys OK?

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:38:58 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 18 Aug 2015 20:38:58 +0000
Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box
In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za>
Message-ID: <1439930338.45.0.754778295826.issue20523@psf.upfronthosting.co.za>


Changes by Arnon Yaari <wiggin15 at gmail.com>:


----------
nosy: +wiggin15

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20523>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:44:42 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 18 Aug 2015 20:44:42 +0000
Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work
In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za>
Message-ID: <1439930682.91.0.754131104707.issue24801@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached macpopup-revised.patch, incorporating Serhiy's very helpful suggestions. Unless there are any other thoughts, this one is probably ready to go.

----------
Added file: http://bugs.python.org/file40208/macpopup-revised.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24801>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:51:04 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 18 Aug 2015 20:51:04 +0000
Subject: [issue24750] IDLE: Cosmetic improvements for main window
In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za>
Message-ID: <1439931064.57.0.351114103765.issue24750@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Sounds like this one should be ready to review and incorporate.  

As a reminder, mainwin3.patch, which should work on Tk 8.4+, gets rid of the highlightthickness around the text widget in the editor, the sunken line/column effect in the status bar, and adds a thin separator below the text widget in the editor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24750>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:54:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 18 Aug 2015 20:54:01 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1439931241.91.0.0848952670879.issue24570@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Alessandro, would you have a chance to test this one line patch, which makes calltips work again on OS X?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

From report at bugs.python.org  Tue Aug 18 23:01:05 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 18 Aug 2015 21:01:05 +0000
Subject: [issue24760] IDLE settings dialog shouldn't be modal
In-Reply-To: <1438297628.71.0.179622085434.issue24760@psf.upfronthosting.co.za>
Message-ID: <1439931665.3.0.795116144738.issue24760@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Terry, when you get a chance, it would be great if you could have a look at demodalize.patch (or if you can suggest someone else who would be good to take a peek at it).

This is sort of the baseline for the uifactory, and touches a lot of things in small ways to decouple some of the inter-module dependencies. 

Other things (the new query dialogs, ttk versions of configuration and search dialogs, etc.) depend on this patch to wire the uifactory into the infrastructure.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24760>
_______________________________________

From report at bugs.python.org  Tue Aug 18 23:14:26 2015
From: report at bugs.python.org (Brendan Barnwell)
Date: Tue, 18 Aug 2015 21:14:26 +0000
Subject: [issue24890] Windows launcher docs don't fully explain shebang
 semantics
Message-ID: <1439932466.21.0.43365988759.issue24890@psf.upfronthosting.co.za>


New submission from Brendan Barnwell:

With the fix of issue #17903 in place, the behavior of the Windows launcher for a shebang of "#!/usr/bin/env python" is now different from the behavior for the other "virtual commands" in that the PATH is searched for this particular virtual command but not the others.  But this difference is not explained in the docs (see https://docs.python.org/3/using/windows.html#shebang-lines).  The docs should be updated to make the difference clear.

In addition, as noted in bug #24625, the launcher parses and executes shebang lines "normally" if the shebang is not one of the virtual commands.  However, this is not actually stated on the documentation page; the only examples on the page either use the virtual commands or use a bare command like "python".  Given that shebang lines don't normally work at all on Windows, and given that the shebang handling is already different on Windows because of the virtual commands, the docs shouldn't assume that it's clear what "works like a normal shebang" means.  A note should be added to the docs to make this explicit.  Something like "If the shebang line is not one of these virtual commands, it is executed as a normal program and the script filename is passed to it as a command-line argument."

----------
components: Windows
messages: 248796
nosy: BrenBarn, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows launcher docs don't fully explain shebang semantics
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24890>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:18:48 2015
From: report at bugs.python.org (Yi Ding)
Date: Tue, 18 Aug 2015 22:18:48 +0000
Subject: [issue24891] python aborts running under nohup
Message-ID: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>


New submission from Yi Ding:

Looks like this bug https://bugs.python.org/issue7111 has resurfaced in python3 (python 2.6 works as far as I can tell) at least on Macs.

I've attached a simple test script.

Steps:
1. SSH to remote server.
2. Run nohup ./test.sh &
3. exit SSH.
4. SSH back in and see that there are a bunch of errors in your nohup.out file.

----------
files: test.py
messages: 248797
nosy: Yi Ding
priority: normal
severity: normal
status: open
title: python aborts running under nohup
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file40209/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:19:03 2015
From: report at bugs.python.org (Yi Ding)
Date: Tue, 18 Aug 2015 22:19:03 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439936343.77.0.622630962745.issue24891@psf.upfronthosting.co.za>


Yi Ding added the comment:

test.sh attached

----------
Added file: http://bugs.python.org/file40210/test.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:37:47 2015
From: report at bugs.python.org (Timothy Geiser)
Date: Tue, 18 Aug 2015 22:37:47 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
Message-ID: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>


New submission from Timothy Geiser:

You can't join bytes on another bytes object. (Everything below applies to bytearray, as well)


>>> x = b'foo'
>>> y = b'barbaz'
>>> x.join(y)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    x.join(y)
TypeError: sequence item 0: expected a bytes-like object, int found


But this is fine for strings, and gives you exactly what you'd expect


>>> x = 'foo'
>>> y = 'barbaz'
>>> x.join(y)
'bfooafoorfoobfooafooz'
>>> y.join(x)
'fbarbazobarbazo'


The best work-around I could think of was


>>> x = b'foo'
>>> y = b'barbaz'
>>> x.join(y[i:i+1] for i in range(len(y)))
b'bfooafoorfoobfooafooz'
>>> y.join(x[i:i+1] for i in range(len(x)))
b'fbarbazobarbazo'


That just doesn't feel nearly pythonic enough, considering that the string version works as expected. I'm not even sure what the right solution here is, since the problem is that the iterator for a bytes object returns ints, not length-one bytes objects. Do we need another signature for the bytes.join method that takes byte-like objects and does what I'm describing here?

----------
components: Interpreter Core
messages: 248799
nosy: geitda
priority: normal
severity: normal
status: open
title: bytes.join() won't take it's own type as the argument
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:53:14 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 18 Aug 2015 22:53:14 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439938394.47.0.574902476248.issue24891@psf.upfronthosting.co.za>


Robert Collins added the comment:

What sort of errors?

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:00:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Aug 2015 23:00:50 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439938850.39.0.903950889544.issue24891@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm unable to reproduce the issue on Linux with Python 3.4.2.

----------
components: +Macintosh
nosy: +haypo, ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:02:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Aug 2015 23:02:21 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <20150818230218.21672.64155@psf.io>


Roundup Robot added the comment:

New changeset 19ac02a522ba by Steve Dower in branch '3.5':
Issue #24847: Removes vcruntime140.dll dependency from Tcl/Tk.
https://hg.python.org/cpython/rev/19ac02a522ba

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:24:34 2015
From: report at bugs.python.org (Yi Ding)
Date: Tue, 18 Aug 2015 23:24:34 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439940274.91.0.153103827671.issue24891@psf.upfronthosting.co.za>


Yi Ding added the comment:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor
./test.sh: line 4: 49632 Abort trap: 6           python3 test.py -o hello.txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:26:32 2015
From: report at bugs.python.org (Yi Ding)
Date: Tue, 18 Aug 2015 23:26:32 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439940392.09.0.35728170999.issue24891@psf.upfronthosting.co.za>


Yi Ding added the comment:

That's from my nohup.out. It might be a Mac OS specific thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:41:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Aug 2015 23:41:14 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439941274.48.0.252719091799.issue24891@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I can reproduce the bug with gdb if the file descriptor 0 is closed before calling:
    std = create_stdio(iomod, fd, 0, "<stdin>", encoding, errors);
and after the following lines were called:
    fd = fileno(stdin);
    if (!is_valid_fd(fd)) {

In initstdio () at Python/pylifecycle.c:1156.

create_stdio() fails in FileIO constructor, on the line:
   if (_Py_fstat(self->fd, &fdfstat) < 0)
of _io_FileIO___init___impl() at Modules/_io/fileio.c:480

It's a corner case of the issue #7111, I would call it a race condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:46:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Aug 2015 23:46:48 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439941608.97.0.415754381478.issue24891@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 2 is not affected, PyFile_FromFile() doesn't check if the file descriptor is valid. On Python 3, we call fstat() to check the block size of the file descriptor to optimize buffering.

----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:20:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Aug 2015 00:20:51 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <20150819002046.6314.28916@psf.io>


Roundup Robot added the comment:

New changeset fc56a0300cd4 by Robert Collins in branch 'default':
Issue #24054: decouple linecache tests from inspect tests
https://hg.python.org/cpython/rev/fc56a0300cd4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:21:48 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 00:21:48 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1439943708.75.0.804726717487.issue24054@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thank you for the patch; sorry it took me so long to get to it - been working on a backlog of patch review.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:39:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 00:39:42 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
In-Reply-To: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>
Message-ID: <1439944782.48.0.0345734761846.issue24892@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think there's enough motivation for making a special case here.

I think this should be rejected; it's working as designed, even if not everyone agrees with the design.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:50:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Aug 2015 00:50:15 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439945415.74.0.794014553459.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A fair question. The API is a private implementation for Idle (see PEP 434), though I am generally avoiding breaking any public uses thereof.  I actually checked that the method is not defined on the base class.  But on the microchance that someone uses it, I will restore the methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 03:06:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2015 01:06:14 +0000
Subject: [issue24893] Idle occasionally gets mouse position wrong for
 selections
Message-ID: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Something has been wrong with the underlying Tkinter for several years. A mouse click to select text will mistarget by several lines.

I've held-off reporting this because I couldn't narrow it down to a reproduceable case.  That said, I've seen it on fresh installs of Python on multiple machines with different users.

But now, we have it on video.  It happened to Guido during a keynote.  See https://www.youtube.com/watch?v=0Ef9GudbxXY at about 7:00 to 7:30.

----------
components: IDLE
messages: 248811
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Idle occasionally gets mouse position wrong for selections
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Wed Aug 19 03:33:10 2015
From: report at bugs.python.org (Timothy Geiser)
Date: Wed, 19 Aug 2015 01:33:10 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
In-Reply-To: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>
Message-ID: <1439947990.94.0.325099849735.issue24892@psf.upfronthosting.co.za>


Timothy Geiser added the comment:

I believe the special case has already been made: iterating over bytes-like objects returns ints. Natually, join() should take the same thing. Also, constructor bytearray(iterable_of_ints), the mutable-sequence expression ba[i:j:k] = t, and the function ba.extend(t) with t as an iterable of ints. It's the s.join(t) that's different than all these others.

Again:

>>> ba = bytearray(b'barbaz')
>>> ba[0:4:2] = b'ft'
>>> ba
bytearray(b'fatbaz')
>>> ba.extend(b'foo')
>>> ba
bytearray(b'fatbazfoo')
>>> ba.join(b'not_this_though')
Traceback (most recent call last):
  File "<pyshell#32>", line 1, in <module>
    ba.join(b'not_this_though')
TypeError: sequence item 0: expected a bytes-like object, int found


I'll go ahead argue that it's exactly backwards as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 03:34:58 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 19 Aug 2015 01:34:58 +0000
Subject: [issue24890] Windows launcher docs don't fully explain shebang
 semantics
In-Reply-To: <1439932466.21.0.43365988759.issue24890@psf.upfronthosting.co.za>
Message-ID: <1439948098.04.0.0222199705474.issue24890@psf.upfronthosting.co.za>


eryksun added the comment:

The patch for issue 23465 (PEP 486) updated the docs to explain the behavior of #!/usr/bin/env as follows:

    The /usr/bin/env form of shebang line has one further special
    property. Before looking for installed Python interpreters, 
    this form will search the executable PATH for a Python 
    executable. This corresponds to the behaviour of the Unix 
    env program, which performs a PATH search. 

This paragraph needs to be added to the 3.4 docs.

Another undocumented feature is adding custom commands in the [commands] section of py.ini. The read_commands function handles this. 

Speaking of which, a side effect of defining SEARCH_PATH in PC/launcher.c is that PATH is searched in find_command if the command isn't found in the global "commands" array. This can lead to unexpected behavior when combined with SKIP_PREFIX (i.e. the skip_prefix function skips past any of the builtin_prefixes in the shebang). For example, #!/usr/bin/perl will search the current directory and PATH for "perl.COM" "perl.EXE", "perl.BAT", etc (i.e. trying each extension listed in PATHEXT). This behavior should be documented. Preferably I think it should also be constrained to only search when the prefix is /usr/bin/env, such as by adding a "search" boolean parameter to the find_command function.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eryksun
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24890>
_______________________________________

From report at bugs.python.org  Wed Aug 19 04:22:16 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Aug 2015 02:22:16 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1439950936.17.0.586867751377.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is an approach that somewhat merges Nathaniel's proposed solution and mine.

----------
Added file: http://bugs.python.org/file40211/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Wed Aug 19 04:31:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Aug 2015 02:31:25 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <20150819023101.33438.44969@psf.io>


Roundup Robot added the comment:

New changeset 0e2620831f17 by Steve Dower in branch '3.5':
Issue #24847: Fixes Tix revision number and reverts fix for the wrong revision.
https://hg.python.org/cpython/rev/0e2620831f17

New changeset 9cc3f2f2d810 by Steve Dower in branch 'default':
Issue #24847: Fixes Tix revision number and reverts fix for the wrong revision.
https://hg.python.org/cpython/rev/9cc3f2f2d810

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:22:28 2015
From: report at bugs.python.org (Aymeric Augustin)
Date: Wed, 19 Aug 2015 05:22:28 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1439961748.82.0.0128738542394.issue10740@psf.upfronthosting.co.za>


Aymeric Augustin added the comment:

This bug appears to be fixed upstream: https://github.com/ghaering/pysqlite/commit/f254c534948c41c0ceb8cbabf0d4a2f547754739

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:25:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Aug 2015 05:25:31 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <20150819052528.15613.65855@psf.io>


Roundup Robot added the comment:

New changeset f5c40ab9e233 by Raymond Hettinger in branch 'default':
Issue #24879:  Teach pydoc to display named tuple fields in the order they were defined.
https://hg.python.org/cpython/rev/f5c40ab9e233

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:26:24 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2015 05:26:24 +0000
Subject: [issue24879] Pydoc to list data descriptors in _fields order if it
 exists
In-Reply-To: <1439789590.43.0.926064650189.issue24879@psf.upfronthosting.co.za>
Message-ID: <1439961984.8.0.594408338681.issue24879@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24879>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:28:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 05:28:12 +0000
Subject: [issue24891] python aborts running under nohup
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439962092.5.0.711394214561.issue24891@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:28:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 05:28:29 +0000
Subject: [issue24891] race condition in initstdio() (python aborts running
 under nohup)
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439962109.75.0.963072392866.issue24891@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: python aborts running under nohup -> race condition in initstdio() (python aborts running under nohup)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:28:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 05:28:49 +0000
Subject: [issue24891] race condition in initstdio() (python aborts running
 under nohup)
In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za>
Message-ID: <1439962129.06.0.346965660214.issue24891@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Interpreter Core -Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24891>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:31:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 05:31:22 +0000
Subject: [issue24732] 3.5.0b3 Windows accept() on unready non-blocking socket
 raises PermissionError [now need unit test]
In-Reply-To: <1437963228.18.0.486881534673.issue24732@psf.upfronthosting.co.za>
Message-ID: <1439962282.42.0.492974005231.issue24732@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: 3.5.0b3 Windows accept() on unready non-blocking socket raises PermissionError -> 3.5.0b3 Windows accept() on unready non-blocking socket raises PermissionError [now need unit test]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24732>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:34:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 05:34:06 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>
Message-ID: <1439962446.74.0.74020532795.issue24707@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMHO the best to do with this issue is to document that Python doesn't ensure that the clock is monotonic, but only exposes what the OS provides, and then remove the assertion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24707>
_______________________________________

From report at bugs.python.org  Wed Aug 19 08:10:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Aug 2015 06:10:25 +0000
Subject: [issue24894] iso-8859-11 missing from codecs table
Message-ID: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

In https://docs.python.org/3/library/codecs.html#standard-encodings
iso8859_11 appears to be missing.  'thai' seems a valid alias for this encoding, but there might be others.
cp874 also covers the thai alphabet, but it's a different encoding.

Note that iso8859_12 is also missing, but that is expected.

See also https://en.wikipedia.org/wiki/ISO/IEC_8859#The_Parts_of_ISO.2FIEC_8859

----------
assignee: docs at python
components: Documentation, Unicode
keywords: easy
messages: 248819
nosy: docs at python, ezio.melotti, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: iso-8859-11 missing from codecs table
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24894>
_______________________________________

From report at bugs.python.org  Wed Aug 19 09:56:38 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 19 Aug 2015 07:56:38 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1439970998.65.0.00238967692065.issue23606@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Wed Aug 19 10:12:26 2015
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 19 Aug 2015 08:12:26 +0000
Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass
 error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439971946.13.0.865557814401.issue24870@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> Why are bytes being escaped in a binary blob? The reason to use surrogateescape is when you have data that is mostly text, should be processed as text, but can have occasional binary data.  That wouldn't seem to apply to a database binary blob.

Since SQL may contain binary data.

data = bytes(range(256))
cursor.execute(u"INSERT INTO t (blob_col) values (%(data)s)", {"data": data})

DB driver should escape properly for SQL syntax, then decode with surrogateescape for % operator.

bytes in Python 3.5 supports % operator so I can use it instead of unicode %.
But I'll continue to support Python 3.4 for some years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:26:18 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:26:18 +0000
Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance
In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za>
Message-ID: <1439976378.73.0.487887426991.issue9303@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

The externally maintained version of the sqlite3 module has now been switched to the v2 statement API. pysqlite is for Python 2.7 only. I'd suggest to revisit this for Python 3.6 and then try to port most fixes from pysqlite to the sqlite3 module.

----------
resolution:  -> postponed
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9303>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:34:17 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:34:17 +0000
Subject: [issue16958] The sqlite3 context manager does not work with
 isolation_level=None
In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za>
Message-ID: <1439976857.88.0.0776788449734.issue16958@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I'm +1 on deprecating the connection manager

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16958>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:40:17 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:40:17 +0000
Subject: [issue20463] sqlite dumpiter dumps invalid script when virtual tables
 are used
In-Reply-To: <1391198256.46.0.541752876278.issue20463@psf.upfronthosting.co.za>
Message-ID: <1439977217.07.0.302687102865.issue20463@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

apsw contains code that handles the issues with dumping SQLite databases very well. I plan to integrate this code into pysqlite. We can then later port the fix to the sqlite3 module.

See https://github.com/ghaering/pysqlite/issues/10 for the tasks and
https://github.com/rogerbinns/apsw/blob/master/tools/shell.py#L1012 for the apsw code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20463>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:43:30 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:43:30 +0000
Subject: [issue11691] sqlite3 Cursor.description doesn't set type_code
In-Reply-To: <1301199375.2.0.455501522423.issue11691@psf.upfronthosting.co.za>
Message-ID: <1439977410.01.0.988432014823.issue11691@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

There is no guarantee that all any column in a SQlite resultset always has the same type. That's why I decided to err on the side of setting the type code to "undefined".

Closing as wontfix.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11691>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:50:43 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:50:43 +0000
Subject: [issue24887] Sqlite3 has no option to provide open flags
In-Reply-To: <1439898126.92.0.460778309784.issue24887@psf.upfronthosting.co.za>
Message-ID: <1439977843.41.0.0761057900522.issue24887@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

It requires switch to the v2 open function of the SQLite C API. While we're at it, we can also enable URI filenames.

----------
assignee:  -> ghaering
nosy: +ghaering
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24887>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:53:37 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:53:37 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1439978017.27.0.639380799271.issue19065@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I'm -1 on adding timezone to the adapters.

----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:54:12 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:54:12 +0000
Subject: [issue16379] SQLite error code not exposed to python
In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>
Message-ID: <1439978052.85.0.946704722559.issue16379@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16379>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:56:01 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:56:01 +0000
Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing
 a SQL REPLACE statement
In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za>
Message-ID: <1439978161.05.0.901345015825.issue16864@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16864>
_______________________________________

From report at bugs.python.org  Wed Aug 19 11:56:18 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 09:56:18 +0000
Subject: [issue21250] sqlite3 doesn't have unit tests for 'insert or
 [algorithm]' functionality.
In-Reply-To: <1397634761.6.0.834429340049.issue21250@psf.upfronthosting.co.za>
Message-ID: <1439978178.9.0.724641967938.issue21250@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21250>
_______________________________________

From report at bugs.python.org  Wed Aug 19 12:01:44 2015
From: report at bugs.python.org (Laurent Coustet)
Date: Wed, 19 Aug 2015 10:01:44 +0000
Subject: [issue24895] indentation fix in ceval.c
Message-ID: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>


New submission from Laurent Coustet:

https://hg.python.org/cpython/rev/17d3bbde60d2

introduced a patch using tabs for indentation in ceval.c.

Attached patch just make the code more consistent by using spaces instead of tabs for indentation.


Related to: http://bugs.python.org/issue4753

----------
components: Interpreter Core
files: cpython2.7_indentfix_ceval.diff
keywords: patch
messages: 248827
nosy: Laurent Coustet
priority: normal
severity: normal
status: open
title: indentation fix in ceval.c
versions: Python 2.7
Added file: http://bugs.python.org/file40212/cpython2.7_indentfix_ceval.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:35:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 12:35:41 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
In-Reply-To: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>
Message-ID: <1439987741.09.0.635152594333.issue24892@psf.upfronthosting.co.za>


R. David Murray added the comment:

I said *enough* motivation.  doing b'x'.join(b'anything') is a very uncommon operation (as is the equivalent string case).

There is no parallel to the bytearray constructor, since that constructor does not take an iterable of byte-like objects as its input, it takes an iterable of ints, as you point out.  There is no parallel to slice assignment, since a slice is by definition a bytes like object (that's why using the slice notation in the comprehension to the argument of join works).

The inconsistency is entirely a consequence of the fact that if you iterate a bytes-like object you get integers.  So, join's behavior is consistent with that, and as I said, *I* don't see enough motivation to make a special case exception here.  Others may disagree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:38:11 2015
From: report at bugs.python.org (Leif Arne Storset)
Date: Wed, 19 Aug 2015 12:38:11 +0000
Subject: [issue24896] It is undocumented that re.UNICODE affects re.IGNORECASE
Message-ID: <1439987891.31.0.547960058443.issue24896@psf.upfronthosting.co.za>


New submission from Leif Arne Storset:

A non-ASCII string does not match a regular expression case-insensitively
unless the UNICODE flag is set. This seems reasonable, but the documentation
seems to imply that this is not the case.

The example:

    import re
    # Does not match
    re.compile(u"???????????????", re.IGNORECASE) \
            .findall(u"???????????????") 
    # Matches
    re.compile(u"???????????????", re.IGNORECASE | re.UNICODE) \
            .findall(u"???????????????")

(In Python 3, it does not match if re.ASCII is given.)

The documentation (2.7) says:

    re.UNICODE
    
    Make \w, \W, \b, \B, \d, \D, \s and \S dependent on the Unicode character
    properties database.

(https://docs.python.org/2/library/re.html#re.UNICODE)

My regex does not use any of those escapes, yet the regex changes behavior with
the UNICODE flag. This leads to confusion when the regex doesn't match. The documentation is very specific about the behavior that changes with the flag,
implying that behavior not mentioned is unaffected.

Of course, it's easy to guess the correct (hopefully) solution.

Still, I suggest changing the documentation to mention that re.IGNORECASE is
affected. Looking at the source code, there seems to be further consequences
(it mentions "Unicode locale") which may also warrant a mention. If you do want
to avoid specifics, however, even a hand-wavy reference to something like "match
according to Unicode" would help, because it implies that not only the escapes
change behavior.



In Python 3, there is a counterpart to the 2.7 problem: re.ASCII makes our
Cyrillic string not match. Again, this behavior makes intuitive sense, but the
documentation seems to indicate something different:

    re.ASCII
    Make \w, \W, \b, \B, \d, \D, \s and \S perform ASCII-only matching instead
    of full Unicode matching. This is only meaningful for Unicode patterns, and
    is ignored for byte patterns.

    ?

    re.IGNORECASE
    Perform case-insensitive matching; expressions like [A-Z] will match
    lowercase letters, too. This is not affected by the current locale and
    works for Unicode characters as expected.

re.ASCII does appear to affect re.IGNORECASE. Since this is the non-default
case, however, I'm not sure it's worth calling it out. I'd be happy even if
only the 2.7 docs change.

----------
assignee: docs at python
components: Documentation
messages: 248829
nosy: Leif Arne Storset, docs at python
priority: normal
severity: normal
status: open
title: It is undocumented that re.UNICODE affects re.IGNORECASE
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24896>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:40:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 12:40:27 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1439988027.28.0.635921628852.issue10740@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's not a backward compatible change, so we'll need a migration strategy if we want to apply this (and I'd certainly like to).

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:45:44 2015
From: report at bugs.python.org (Alexandre Badez)
Date: Wed, 19 Aug 2015 12:45:44 +0000
Subject: [issue24736] argparse add_mutually_exclusive_group do not print help
In-Reply-To: <1438001526.73.0.776043102355.issue24736@psf.upfronthosting.co.za>
Message-ID: <1439988344.55.0.651356152642.issue24736@psf.upfronthosting.co.za>


Alexandre Badez added the comment:

@paul: thanks, I'm very surprised because the parsing work well.
It's just the display that do not.

Moreover it's not said in the documentation that you cannot nest groups.

So maybe we should update the documentation and/or improve the module ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24736>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:55:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 12:55:09 +0000
Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass
 error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1439988909.74.0.57326978425.issue24870@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since you already have to rewrite the string to do the escaping, I would judge it worth the extra effort to piece string together as binary, but I can understand wanting to use % notation.  The performance issue seems to prevent that, though, and there's no guarantee the proposed optimization will get applied to 3.4, or even 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:59:50 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 12:59:50 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1439989190.3.0.376289533297.issue10740@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

Please note that after the mentioned commit, I restored backwards compatibility with commit https://github.com/ghaering/pysqlite/commit/796b3afe38cfdac5d7d5ec260826b0a596554631

Now the only difference is that the implicit commits *before* DDL statements are gone. I consider these a bug anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:03:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 13:03:46 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1439989426.85.0.159485443383.issue19065@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you expand on why you are -1, Gerhard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:06:06 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 13:06:06 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1439989566.29.0.853202014564.issue3783@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

This wiki page is out of date. It appears that SQlite is now threadsafe by default: http://www.sqlite.org/threadsafe.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:09:34 2015
From: report at bugs.python.org (shiva prasanth)
Date: Wed, 19 Aug 2015 13:09:34 +0000
Subject: [issue24877] Bad Password for file using zipfile module
In-Reply-To: <1439772722.91.0.760434586154.issue24877@psf.upfronthosting.co.za>
Message-ID: <1439989774.43.0.29073237442.issue24877@psf.upfronthosting.co.za>


Changes by shiva prasanth <kesavarapu.siva at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24877>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:09:37 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 19 Aug 2015 13:09:37 +0000
Subject: [issue16885] SQLite3 iterdump ordering
In-Reply-To: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za>
Message-ID: <1439989777.02.0.590807101371.issue16885@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

http://bugs.python.org/issue20463 is related.

----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16885>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:12:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 13:12:34 +0000
Subject: [issue24896] It is undocumented that re.UNICODE affects re.IGNORECASE
In-Reply-To: <1439987891.31.0.547960058443.issue24896@psf.upfronthosting.co.za>
Message-ID: <1439989954.06.0.497096163147.issue24896@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it would be reasonable to add re.IGNORECASE to the list of things affected, since it obviously does switch between using the unicode database and not doing so.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24896>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:12:49 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 19 Aug 2015 13:12:49 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1439989969.11.0.849480469232.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've been ignoring this because I wasn't assigned...

Here's the options. If we make it load ucrtbase.dll directly (which does still have named exports, and also uses the API schema on Windows 10):
* some code that uses it will need updating (due to API changes since VC9/VC10)
* code may need to change depending on OS updated (which could change the ucrtbase exports)
* much existing code using this will probably work

If we leave it as is:
* all existing uses will obviously fail, nothing subtle
* users will either substitute the name themselves, find an equivalent stdlib function, or use a supported Windows API

Having just written that out, I still think not supporting it is best, but I do need to write it up in the porting info still. Any other thoughts?

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:14:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 13:14:08 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1439990048.95.0.701639804815.issue10740@psf.upfronthosting.co.za>


R. David Murray added the comment:

Excellent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:29:21 2015
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 19 Aug 2015 13:29:21 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1439990961.1.0.631715629041.issue24054@psf.upfronthosting.co.za>


David Edelsohn added the comment:

This patch causes a new failure on many of the buildbots.

----------
nosy: +David Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:35:37 2015
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 19 Aug 2015 13:35:37 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1439991337.75.0.10927896876.issue24054@psf.upfronthosting.co.za>


Changes by David Edelsohn <dje.gcc at gmail.com>:


----------
nosy: +David.Edelsohn -David Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:40:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 13:40:39 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1439991639.82.0.273263012778.issue24054@psf.upfronthosting.co.za>


R. David Murray added the comment:

Example:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/10098/steps/test/logs/stdio

----------
nosy: +r.david.murray
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:44:21 2015
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 19 Aug 2015 13:44:21 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1439991861.96.0.780808516367.issue24054@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Also

http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/2/steps/test/logs/stdio

http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/2

Comments

Issue #24054: decouple linecache tests from inspect tests

Patch from David D. Riddle

Changed files

Lib/test/test_linecache.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:45:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 13:45:56 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
In-Reply-To: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>
Message-ID: <1439991956.41.0.349389357022.issue24892@psf.upfronthosting.co.za>


R. David Murray added the comment:

In case I wasn't clear: bytes-like object join's argument is *an iterable of bytes-like objects*, not an iterable of ints.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 16:46:16 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Wed, 19 Aug 2015 14:46:16 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1439995576.83.0.465436200157.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

Thank you very much for your thorough input, it is very much appreciated!

Actually one of the first things that I tried was to return stack[1:] to remove the target but your suggestion is much better. I did try it and it does work and I will provide a patch as soon as I get home. 

I'll start probing the second one then. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 17:48:08 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 19 Aug 2015 15:48:08 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1439999288.81.0.0162467371002.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

Larry - PR for you at https://bitbucket.org/larry/cpython350/pull-requests/6/issue-24847-removes-vcruntime140dll/diff

The buildbots are happy with this change, and so am I. Zach also had a look at the Tcl and Tk patches, and I've already heard back from upstream that they like the change but need it expanded before they'll take it (that won't affect what we need for our builds though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:04:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Aug 2015 16:04:57 +0000
Subject: [issue24895] indentation fix in ceval.c
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <1440000297.06.0.282482064695.issue24895@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Laurent.

Can any other core devs remembered if we explicitly untabbed the C source in 2.7? I know we did in Python 3, but I can't remember if we did it in Python 2 to make patches easier.

----------
nosy: +brett.cannon
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:09:14 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Aug 2015 16:09:14 +0000
Subject: [issue24892] bytes.join() won't take it's own type as the argument
In-Reply-To: <1439937467.69.0.387516366168.issue24892@psf.upfronthosting.co.za>
Message-ID: <1440000554.17.0.631742810536.issue24892@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I agree with David. Concatenating ints to a bytes object doesn't work when you directly work with ints and bytes, and so I don't think bytes.join should special case it (Zen of Python: "Special cases aren't special enough to break the rules").

Thanks for the idea anyway, Timothy.

----------
nosy: +brett.cannon
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24892>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:18:45 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Wed, 19 Aug 2015 16:18:45 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440001125.51.0.994791667073.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

Alright, here goes my first patch. I just did what you have pointed out :)

----------
keywords: +patch
Added file: http://bugs.python.org/file40213/issue24790.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:29:52 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Wed, 19 Aug 2015 16:29:52 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440001792.8.0.513425038697.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

I have also prepared a patch for the second item but I don't know if I should regenerate the patch after you have committed the first patch so I'm sitting on it now. 

I also didn't update the ACKS and NEWS files, should I?

Here's what I did for the second item, just in case you spot something I shouldn't be doing:

         sublist = []
         if frame.f_globals is not frame.f_locals:
             item = VariablesTreeItem("<locals>", frame.f_locals, self.flist)
-            sublist.append(item)
-        item = VariablesTreeItem("<globals>", frame.f_globals, self.flist)
+        else:
+            item = VariablesTreeItem("<globals>", frame.f_globals, self.flist)
         sublist.append(item)
         return sublist

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:38:32 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Wed, 19 Aug 2015 16:38:32 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440002312.72.0.492851594978.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

Come to think of it, maybe I should send both the second and third items in one patch? I could just call the GetSubList method if the VariablesTreeItem is being created for locals. Is that a bad approach to take?

Sorry for the sheer number of questions :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:42:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 16:42:38 +0000
Subject: [issue24895] indentation fix in ceval.c
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <1440002558.71.0.985856111325.issue24895@psf.upfronthosting.co.za>


R. David Murray added the comment:

I couldn't remember either.  Antoine should know, he did the work/commit.

----------
nosy: +pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:43:44 2015
From: report at bugs.python.org (Laurent Coustet)
Date: Wed, 19 Aug 2015 16:43:44 +0000
Subject: [issue24895] indentation fix in ceval.c
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <1440002624.28.0.183090577046.issue24895@psf.upfronthosting.co.za>


Laurent Coustet added the comment:

by the way, the rest of the code did not contain any tab in ceval.c. They were added by 17d3bbde60d2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:53:10 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Aug 2015 16:53:10 +0000
Subject: [issue24895] indentation fix in ceval.c
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <1440003190.77.0.158359975902.issue24895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The Python 3 code doesn't have tabs. I'm assuming Benjamin took the original patch instead of trying to backport the Python 3 commit.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 19:09:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2015 17:09:17 +0000
Subject: [issue24895] indentation fix in ceval.c in python 2.7
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <1440004157.59.0.514991385838.issue24895@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: indentation fix in ceval.c -> indentation fix in ceval.c in python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Wed Aug 19 21:23:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Aug 2015 19:23:25 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440012205.58.0.0611172378469.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

NEWS patches should be omitted from submitted .diff or .patch files because a) NEWS is so volatile that merge conflicts applying the .diff are likely; b) NEWS is different between versions, so that forward merge conflicts are possible (usual for Idle items, so I apply them separately) and b) committers tend to rewrite then anyway.  I will later prepare and separately commit one entry for this issue.

ACKS is more stable within and between versions, so including a acks patch is ok.  But then the patch must be prepared for 3.4 and 2.7 specifically, and I want to know ahead of time if there will be a 3.4 to 3.5 or 3.5 to 3.6 merge conflict.  You can include it or leave it out (easier).

I tested both the .patch and diff in msg248849.  When putting code or diffs in messages, please include function/class/method names or lineno.  With this patch, SubList always return a list of one item.  Note that we can always use frame.f_locals, whether it is or is not f_globals.

I am not exactly sure what you meant by your your last question, but it lead me to the answer.  When a tree item with + is clicked, the corresponding GetSubList method is called. What we want FrameTreeItem.GetSubList to do, instead of returning a list of (now 1) VariablesTreeItem, is to return what VariablesTreeItem.GetSubList would (when clicked subequently).  Replace most of the body of the former (FrameTI.GSL) with the body of the latter (VarTI.GSL), with 'self.object' replaced by 'frame.f_locals'.  Class VariablesTreeItem will then be obsolete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:15:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 20:15:46 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440015346.25.0.998874128542.issue8987@psf.upfronthosting.co.za>


R. David Murray added the comment:

So I think the only objection to committing this as a bug fix would be the unfortunately real possibility that doing so will break someone's workaround.  My *guess* is that such a workaround would most likely take the form of replacing _nt_quote_args as the one example we have in had did.  So I'm in favor of fixing this.

I've added some people to nosy who might have an opinion and even perhaps some way to look for other examples of people coping with this (in open source code bases that also target windows).

I haven't reviewed the patch yet but I will.

----------
nosy: +barry, dstufft, ncoghlan, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Wed Aug 19 23:45:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2015 21:45:34 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440020734.41.0.757891059151.issue8987@psf.upfronthosting.co.za>


R. David Murray added the comment:

There are two features of this I have questions about.  If I'm understanding correctly, if passed a quoted string you are not re-quoting it, but you are always stripping a trailing slash even if it is inside quotes.

For the first, that seems wrong.  Either we should be quoting the quotes, or we should assume that if passed a string that starts and ends with quotes, that it is already fully quoted, and not change it.

For the second, doesn't that potentially change the semantics of the string passed in?  You can't actually know that the backslash is part of a path, nor can you be sure that a trailing backslash is not significant even if it is a path.  And in fact if there is a backslash before a double quote, arguably that is supposed to be a double quote that doesn't end the string (see point one above).

I tried list2cmdline, and what it does is to backslash escape appropriately, including preserving blackslashes that are in front of double quotes, and does not add surrounding quotes if there are no internal blanks.  I think list2cmdline is correct here (and it has certainly seen a lot of use), and I think we should either replicate its logic or just use it.

Now, subprocess calls CreateProcess, while distutils calls os.spawnv, but my understanding is that the quoting rules are the same (that is, that the CRT's _spawnv ultimately calls CreateProcess with the arguments joined by blanks).  

Since issue 8972 has been resolved by fixing the broken behavior, I think we should just use list2cmdline.  We could leave _nt_quote_args alone and replace the call to it in _spawn_nt with:

  cmd = [list2cmdline([arg]) for arg in cmd]

or we could put the fix in _nt_quote_args.  The backward compatibility calculus is...not obvious :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:09:47 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 19 Aug 2015 22:09:47 +0000
Subject: [issue24889] Idle: always start with focus
In-Reply-To: <1439928191.61.0.630343371617.issue24889@psf.upfronthosting.co.za>
Message-ID: <1440022187.75.0.265644158636.issue24889@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I reproduced your problem on Windows, and verified that it wasn't an issue on either Mac or Linux.

Your fix however, didn't change anything for me (on a Windows 7 VM). I tried a few other things (raising the window, playing with various wm attributes, etc.) with no luck.

The fact that it works ok when run directly from the command prompt got me thinking, and I eventually tracked down what is preventing IDLE from becoming the front application.

It's actually an internal Windows feature, that's designed to prevent background applications from all of a sudden putting up windows that interfere with what you're doing in the foreground, instead putting a notification in the task bar and making you click that or the window itself.

The mechanism used is to prevent applications from coming to the front on their own if they don't do so very shortly after they're first launched. So when you launch a Python shell (e.g. from a command prompt), the "delay" it takes you to type "import idlelib.idle" plus the launch time exceeds this timeout, and Windows decides it won't allow it to put the window in the foreground.

You can change the timeout (or set it to 0 to disable the feature) via the registry key HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout
(you need to restart after). With that change, your fix worked for me.

You can Google around for "ForegroundLockTimeout" for additional info.

There's not realistically an easy way to get around it in IDLE itself (for obvious reasons, given the purpose of the feature).

I'm guessing this will affect few people as much as it does you, constantly starting and stopping IDLE from within Python. If the fix works on your system, especially without mucking with that registry key, that should cover it. The fix doesn't cause any harm on Mac or Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24889>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:23:27 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 19 Aug 2015 22:23:27 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440023007.38.0.797380593838.issue8987@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As far as I'm concerned distutils on Windows is a farce so do what you like with it.  It usually can't pick up the version of VS that you know is correct and is installed, the error messages are less than useless, so the only damage that I see is something that is even more broken than it all ready is.  Alternatively it gets slightly further before bombing with yet another useless message.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:35:21 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 22:35:21 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1440023721.05.0.286814906127.issue24054@psf.upfronthosting.co.za>


Robert Collins added the comment:

I can't see how the patch could have caused the 
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_symbol.py", line 44, in test_real_grammar_and_symbol_file
    os.stat(TEST_PY_FILE)))
AssertionError: False is not true : symbol stat: os.stat_result(st_mode=33206, st_ino=108649341010373284, st_dev=1222264288, st_nlink=1, st_uid=0, st_gid=0, st_size=2095, st_atime=1438992962, st_mtime=1438992962, st_ctime=1438992962)
test_py stat: os.stat_result(st_mode=33206, st_ino=71213169107987373, st_dev=1222264288, st_nlink=1, st_uid=0, st_gid=0, st_size=2209, st_atime=1439969830, st_mtime=1439969831, st_ctime=1439969830)


failure, so I'm going to ignore that - its a size change in the output file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:36:49 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 22:36:49 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1440023809.1.0.563152185509.issue24054@psf.upfronthosting.co.za>


Robert Collins added the comment:

So it looks like one failure is:
FAIL: test_getline (test.test_linecache.GoodUnicode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_linecache.py", line 63, in test_getline
    self.assertEqual(line, cached_line)
AssertionError: '?\n' != '?\n'
- ?
+ ?

and the other is:


======================================================================
ERROR: test_getline (test.test_linecache.GoodUnicode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_linecache.py", line 58, in test_getline
    for index, line in enumerate(fp):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)

We need to figure out if the failure is spurious/local capabilities (e.g. we should skip the test here) or a bug in the test. Where can I find out more about the config of the buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:01:07 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 23:01:07 +0000
Subject: [issue24710] Class name hardcoded in
 TracebackException.from_exception()
In-Reply-To: <1437778625.24.0.630527994303.issue24710@psf.upfronthosting.co.za>
Message-ID: <1440025267.57.0.914376814463.issue24710@psf.upfronthosting.co.za>


Robert Collins added the comment:

So I'm still ambivalent at best about this - this interface hasn't been designed for subclassing - I'm sure there is a bunch more stuff that would be needed. What /is/ needed feature wise here is a sideways extension mechanism for doing filtering and transformation of frames.

I'd be much happier about looking at subclassability after we had that in place.

Anyhow, since I did apply the change this issue was specifically about (the third hunk in the patches), I'm going to close this now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24710>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:03:41 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 23:03:41 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1440025421.81.0.958244488168.issue20362@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20362>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:14:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Aug 2015 23:14:02 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <20150819231359.4929.24472@psf.io>


Roundup Robot added the comment:

New changeset 738de9a9a3ea by Robert Collins in branch '3.5':
Issue #20362: Honour TestCase.longMessage correctly in assertRegex.
https://hg.python.org/cpython/rev/738de9a9a3ea

New changeset 977e60f597de by Robert Collins in branch 'default':
Issue #20362: Honour TestCase.longMessage correctly in assertRegex.
https://hg.python.org/cpython/rev/977e60f597de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20362>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:19:20 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 19 Aug 2015 23:19:20 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440026360.86.0.256945903441.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

Switching distutils.spawn to simply use subprocess.Popen (probably keeping the explicit path search) looks good to me.

Quoting rules are different when you call with shell=True (aka "cmd.exe /c"), since then you also need to escape ^, | and > (with a ^), but if it's being passed directly to the process (via CreateProcess) you don't need to do this. Popen doesn't appear to handle this correctly either.

Because of the backwards compatibility concerns, realistically I think we can only fix this in 3.6 at this stage. The issue has existed for too long to convince Larry to take it for 3.5.0, and changing the behaviour of either distutils or subprocess between .0 and .1 feels risky to me.

(Adding Brett in case he's motivated to take the opportunity to definitively learn and implement Windows's quoting rules and becoming the first person in the world to achieve it. Sounds like his kind of thing :) )

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:20:06 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2015 23:20:06 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <1440026406.74.0.943896178145.issue21192@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I've found this to be a serious usability regression and think it should be reverted right-away.  It makes IDLE unsuitable for evening showing turtle demos to kids.  For adults in my classes, it was also confusing because unlike the old restart-bar it fails to make a clean distinction between sessions and making it clear that old variable definitions have be forgotten.  The issue is even more acute because cmd-p can cycle through statements in previous sessions.

----------
nosy: +rhettinger
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21192>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:21:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2015 23:21:40 +0000
Subject: [issue24893] Idle occasionally gets mouse position wrong for
 selections
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440026500.56.0.601829565842.issue24893@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> terry.reedy
nosy: +ned.deily, ronaldoussoren, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:24:52 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 23:24:52 +0000
Subject: [issue20362] longMessage attribute is ignored in
 unittest.TestCase.assertRegexpMatches etc
In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>
Message-ID: <1440026692.03.0.406998425226.issue20362@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch, applied to 3.5 and 3.6.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20362>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:25:20 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 23:25:20 +0000
Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za>
Message-ID: <1440026720.2.0.248983737788.issue24054@psf.upfronthosting.co.za>


Robert Collins added the comment:

Debian is green again and I think windows will do so to.

----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24054>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:40:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 19 Aug 2015 23:40:38 +0000
Subject: [issue24893] Idle occasionally gets mouse position wrong for
 selections
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440027638.31.0.420990337432.issue24893@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:58:50 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 19 Aug 2015 23:58:50 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1440028730.19.0.415693705903.issue22680@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22680>
_______________________________________

From report at bugs.python.org  Thu Aug 20 02:33:02 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 20 Aug 2015 00:33:02 +0000
Subject: [issue24893] Idle occasionally gets mouse position wrong for
 selections
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440030782.12.0.943291135096.issue24893@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Watched that video clip - yikes, that is bad.

I tried playing around to reproduce it, but haven't had any success yet, though did find another weird thing. If you have a bunch of short lines without any blanks, sometimes when you click well to the right of all of them, the cursor will end up at the beginning of one of the lines, rather than at the end of them. This wasn't consistent but did happen maybe 1/10th of the time.

Guido was running on a Mac. Were the other examples where you saw this missing by several lines also all on Mac?  (Not to say that means it's a Mac only bug, but...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 02:41:41 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Aug 2015 00:41:41 +0000
Subject: [issue24893] Idle occasionally gets mouse position wrong for
 selections
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440031301.87.0.679638203394.issue24893@psf.upfronthosting.co.za>


Ned Deily added the comment:

A wild guess: could it be dependent on the screen resolution, in particular if a Mac Retina display is in use? It also could depend on the version of Tk; from the screenshot it is clear that Guido was not using a python.org version of 3.4 so the out-of-date Apple-supplied Tk *might* be in use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 03:16:09 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 20 Aug 2015 01:16:09 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
Message-ID: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

This is an issue that came up quite often when creating code where you want the class' namespace to hold the instance attributes. I've often seen (and written) code like this:

class Foo:
  def __init__(self):
    self._x = 42
  @property
  def x(self):
    return self._x

As an attempt to populate the class namespace with what should normally be available on the instance. In all my projects now I use my own custom decorator to get around that.

class attribute:
  def __init__(self, func):
    self.func = func
  def __get__(self, instance, owner):
    if instance is None:
      return self
    return self.func.__get__(instance, owner)

This permits instances to override attributes set as such, like this:

class Bar:
  def __init__(self):
    self.x = 42
  @attribute
  def x(self):
    pass # placeholder

I figured I might as well suggest the idea. I'm not attached to the name, and it's more for completion's sake rather than hard necessity.

----------
messages: 248869
nosy: ebarry
priority: normal
severity: normal
status: open
title: Add new attribute decorator (akin to property)?
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 03:31:13 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 20 Aug 2015 01:31:13 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440034273.26.0.421322608866.issue24897@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Could you give an actual use-case demo, and how it's different from @property?  Could just be that I'm tired, but I'm not seeing the advantages of @attribute.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 03:41:59 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 20 Aug 2015 01:41:59 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440034919.77.0.149653408635.issue24897@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The only significant difference is that it lets the instance overwrite the attribute (it doesn't have __set__ or __delete__). For example (using fractions.Fraction to demonstrate), the following:

    def __new__(cls, numerator=0, denominator=None, _normalize=True):
        # ...
        self._numerator = numerator
        self._denominator = denominator

    @property
    def numerator(a):
        return a._numerator

    @property
    def denominator(a):
        return a._denominator

would become:

    def __new__(cls, numerator=0, denominator=None, _normalize=True):
        # ...
        self.numerator = numerator
        self.denominator = denominator

    @attribute
    def numerator(a):
        pass

    @attribute
    def denominator(a):
        pass

This is more of an aesthetic enhancement rather than a functional one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 04:34:48 2015
From: report at bugs.python.org (Ted Lemon)
Date: Thu, 20 Aug 2015 02:34:48 +0000
Subject: [issue24898] Documentation for str.find() is confusing
Message-ID: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za>


New submission from Ted Lemon:

The documentation for str.find() on python.org, for all current versions, says:

Return the lowest index in the string where substring sub is found, such that sub is contained in the slice s[start:end]. Optional arguments start and end are interpreted as in slice notation. Return -1 if sub is not found.

I think that what is meant here is this:

Return the lowest index in a string s where substring sub is found, such that if a is the returned index, and b == a + len(sub), sub is contained in the slice s[a:b]. Optional arguments start and end are interpreted as in slice notation. Return -1 if sub is not found.

----------
assignee: docs at python
components: Documentation
messages: 248872
nosy: Ted Lemon, docs at python
priority: normal
severity: normal
status: open
title: Documentation for str.find() is confusing
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24898>
_______________________________________

From report at bugs.python.org  Thu Aug 20 05:39:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Aug 2015 03:39:00 +0000
Subject: [issue24895] indentation fix in ceval.c in python 2.7
In-Reply-To: <1439978504.01.0.932660866928.issue24895@psf.upfronthosting.co.za>
Message-ID: <20150820033856.21676.35145@psf.io>


Roundup Robot added the comment:

New changeset ea2f6fd04307 by Benjamin Peterson in branch '2.7':
remove tabs from ceval.c (closes #24895)
https://hg.python.org/cpython/rev/ea2f6fd04307

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24895>
_______________________________________

From report at bugs.python.org  Thu Aug 20 07:46:11 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 20 Aug 2015 05:46:11 +0000
Subject: [issue24893] Tk occasionally mispositions Text() insert cursor on
 mouse click.
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440049571.33.0.73099347139.issue24893@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Guido, we are looking at the PyCon 2014 keynote video where the text cursor was misplaced relative to the mouseclick, trying to guess the reason. Do you still have the Mac laptop you used? If so, have you upgraded its python?

The hideous moment is at 7:10. Guido clicked after '.split' to position the blinking insert cursor there, to add 'lines' to the method name. There was no reason to select anything. The cursor appeared instead on the blank line 4 lines above. Guido was able to move the text cursor with arrow keys, as normal, to the desired position.

Serhiy or Kevin, have either of you seen or heard of this problem?

Earlier in the video, there are Display boxes offering resolution choices of 800x600, 1024x768, and 1280x1024. I presume that this indicates 'not Retina'.

I suspect the OS or tk they jointly control the text cursor. Minimal code for experiments is:

import tkinter as tk
root = tk.Tk()
text = tk.Text()
text.pack()
root.mainloop()

Running the above on Win7, I tried Mark's experiment. Clicking near the end of a line consistently put the cursor at the end of the line.  Clicking near the right edge of the box, at least 50 columns away, consistently put the cursor at the beginning of *some* line, but not necessarily the one 'clicked' on.

I looked at idlelib.EditorWindow for anything that might possibly affect tk processing of left button clicks. I only found 2 items.

        if macosxSupport.isAquaTk():
            text.bind("<Control-Button-1>",self.right_menu_event)
If the problem were Mac-specific, this might warrant a look.

        self.text.event_add("<<set-line-and-column>>",
                            "<KeyRelease>", "<ButtonRelease>")
The cursor is positioned on buttom press, before release.

----------
assignee: terry.reedy -> 
components: +Tkinter
nosy: +gvanrossum, serhiy.storchaka, wordtech
stage:  -> test needed
title: Idle occasionally gets mouse position wrong for selections -> Tk  occasionally mispositions Text() insert cursor on mouse click.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 07:49:23 2015
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 20 Aug 2015 05:49:23 +0000
Subject: [issue24898] Documentation for str.find() is confusing
In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za>
Message-ID: <1440049763.46.0.0421925165752.issue24898@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The "slice" clause is talking about the additional arguments. A clearer version could be 


Return the lowest index in the string where substring sub is found within the slice s[start:end].  Optional arguments start and end are interpreted as in slice notation. Return -1 if sub is not found.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24898>
_______________________________________

From report at bugs.python.org  Thu Aug 20 07:59:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 20 Aug 2015 05:59:21 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <1440050361.25.0.854833002855.issue21192@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

How about 'RESTART: Shell' and 'RESTART: <name of file>' to make it clear that old definitions are forgotten in both cases while new definitions are added in the second case.

I do not understand the comment about turtledemo as it runs separately from Idle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21192>
_______________________________________

From report at bugs.python.org  Thu Aug 20 08:03:37 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Aug 2015 06:03:37 +0000
Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib
 docs
Message-ID: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

I think it would be useful to add to the pathlib documentation a table listing os/os.path operations and their pathlib equivalent.
This will be useful both for people porting their code to pathlib and for people that already know os/os.path and want to get familiar with pathlib.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 248877
nosy: docs at python, ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an os.path <=> pathlib equivalence table in pathlib docs
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24899>
_______________________________________

From report at bugs.python.org  Thu Aug 20 09:21:50 2015
From: report at bugs.python.org (Benedikt Sauer)
Date: Thu, 20 Aug 2015 07:21:50 +0000
Subject: [issue24900] Raising an exception that is unable to be unpickled
 causes hang in ProcessPoolExecutor
Message-ID: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za>


New submission from Benedikt Sauer:

When raising an exception that is unpicklable in a worker process. This used to be the case for all exceptions that have a non-trivial constructor but this was fixed by http://bugs.python.org/issue1692335.

I now have the concrete problem with cx_Oracle in which the error type cx_Oracle._Error doesn't define tp_new which results in a

    UnpicklingError: NEWOBJ class argument has NULL tp_new

I have already reported this fact at https://bitbucket.org/anthony_tuininga/cx_oracle/issues/23.

However, I think that the worker thread should either be able to recover from this (which should be quite easy) or, at the very least, fail cleanly. Currently, when this condition is triggered the worker processes are not killed alongside the parent.

There is an existing report and a patch in the backports project: https://github.com/agronholm/pythonfutures/issues/30#issuecomment-132576545

----------
messages: 248878
nosy: filmor
priority: normal
severity: normal
status: open
title: Raising an exception that is unable to be unpickled causes hang in ProcessPoolExecutor
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24900>
_______________________________________

From report at bugs.python.org  Thu Aug 20 09:34:55 2015
From: report at bugs.python.org (Benedikt Sauer)
Date: Thu, 20 Aug 2015 07:34:55 +0000
Subject: [issue24900] Raising an exception that cannot be unpickled causes
 hang in ProcessPoolExecutor
In-Reply-To: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za>
Message-ID: <1440056095.17.0.558046469373.issue24900@psf.upfronthosting.co.za>


Benedikt Sauer added the comment:

Actually I think that this may consist of multiple issues:

1. http://bugs.python.org/issue8323 (closed as wont-fix): multiprocessing.Queue should throw a sensible error if a Queue element can't be unpickled, however the user managed to create that
2. The worker process should prevent unpicklable ResultItems to be put on the Queue
3. The parent thread in ProcessPoolExecutor should handle the exceptions by setting its broken flag and at least trying to cleanly shut down

----------
title: Raising an exception that is unable to be unpickled causes hang in ProcessPoolExecutor -> Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24900>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:42:09 2015
From: report at bugs.python.org (shiva prasanth)
Date: Thu, 20 Aug 2015 10:42:09 +0000
Subject: [issue24901] single element tuple 's ending comma is different that
 without comma
Message-ID: <1440067329.01.0.494145077826.issue24901@psf.upfronthosting.co.za>


New submission from shiva prasanth:

Python 2.7.9 (default, Apr  2 2015, 15:33:21) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (2,)==(2)
False
>>> (2,3,)==(2,3)
True
>>> (2,3)==(2,3,)
True
>>> s=(2,)
>>> s2=(2)
>>> s==s2
False
>>>

----------
messages: 248880
nosy: shivaprasanth
priority: normal
severity: normal
status: open
title: single element tuple 's ending comma is different that without comma
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24901>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:47:00 2015
From: report at bugs.python.org (shiva prasanth)
Date: Thu, 20 Aug 2015 10:47:00 +0000
Subject: [issue24901] (2, )!=(2) and (2, 3)==(2, 3,
 ) why ??? tested in each version
In-Reply-To: <1440067329.01.0.494145077826.issue24901@psf.upfronthosting.co.za>
Message-ID: <1440067620.97.0.776031626278.issue24901@psf.upfronthosting.co.za>


Changes by shiva prasanth <kesavarapu.siva at gmail.com>:


----------
nosy:  -shivaprasanth
title: single element tuple 's ending comma is different that without comma -> (2,)!=(2) and (2,3)==(2,3,) why ??? tested in each version
type:  -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24901>
_______________________________________

From report at bugs.python.org  Thu Aug 20 13:03:16 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 20 Aug 2015 11:03:16 +0000
Subject: [issue24901] (2, )!=(2) and (2, 3)==(2, 3,
 ) why ??? tested in each version
In-Reply-To: <1440067329.01.0.494145077826.issue24901@psf.upfronthosting.co.za>
Message-ID: <1440068596.0.0.758275995415.issue24901@psf.upfronthosting.co.za>


eryksun added the comment:

Refer to section 6.2.3, parenthesized forms:

https://docs.python.org/3/reference/expressions.html#parenthesized-forms

    if the list contains at least one comma, it yields a tuple;
    otherwise, it yields the single expression that makes up the
    expression list.

So (2) is an int, while (2,) is a tuple that contains an int.

    The exception is the empty tuple, for which parentheses are
    required ? allowing unparenthesized ?nothing? in 
    expressions would cause ambiguities and allow common typos
    to pass uncaught.

Thus () is an empty tuple. Note also that section 6.13 states the following regarding a trailing comma:

    The trailing comma is required only to create a single 
    tuple (a.k.a. a singleton); it is optional in all other 
    cases.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24901>
_______________________________________

From report at bugs.python.org  Thu Aug 20 14:43:34 2015
From: report at bugs.python.org (Felix Kaiser)
Date: Thu, 20 Aug 2015 12:43:34 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
Message-ID: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>


New submission from Felix Kaiser:

http.server: on startup, show host/port as URL

Old:

% python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 ...

New:

% ./python -m http.server  
Serving http://0.0.0.0:8000/ ...

This is useful because (modern) terminals will auto-detect URLs and make them clickable, so printing an URL makes it easier to navigate the browser there.

----------
components: Library (Lib)
files: http_server__on_startup_show_host_and_port_as_url.patch
keywords: patch
messages: 248882
nosy: fxkr
priority: normal
severity: normal
status: open
title: http.server: on startup, show host/port as URL
type: enhancement
Added file: http://bugs.python.org/file40214/http_server__on_startup_show_host_and_port_as_url.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Thu Aug 20 15:51:31 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 Aug 2015 13:51:31 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440078691.65.0.16696624649.issue24897@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

I'm missing the point too, I think. I don't see class attributes in your initial Foo class, then your second one as a __new__ method, but references self. I'm quite confused at this point.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:02:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 14:02:09 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440079329.36.0.890065945892.issue8987@psf.upfronthosting.co.za>


R. David Murray added the comment:

*I'm* not suggesting using Popen.  That would be a more significant change to the code, and I don't see a motivation for it.  I'm just suggesting using list2cmdline for the quoting.  (If we were rewriting distutils it would be a different story, but we're not.)

And no, Popen with shell=True does *not* handle quoting.  If you use shell=True, *you* are responsible for doing correct quoting (and is what makes using shell=True so dangerous).  That applies to both unix and windows, and the confusion about that fact was what led to the need for the "fix" backout in issue 8972.

If a fix can't go in as a bug fix (whether or not it gets into 3.5.0), then we should perhaps instead consider the rewrite for 3.6: provide a *new* distutils function that does use Popen and does things "right" (based on everything we've learned since distutils was written), leaving the old function in place, deprecated, for backward compatibility.

That doesn't solve the problem for people running in to this bug trying to build extensions for 2.7, 3.4, and 3.5, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:28:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 14:28:40 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440080920.35.0.0978874272983.issue24897@psf.upfronthosting.co.za>


R. David Murray added the comment:

So you are basically wanting to be able to create read only attributes that don't have a _ in front of them even internally.

I don't think that's something Python core should add.  Read only attributes should be an exceptional case in most python programs.  Fraction uses them because Fraction is an immutable type and those properties are involved in the hash calculation.

I've written an immutable class with a number of attributes (email.policy), and my solution involved a custom __setattr__, which really makes more sense for my use case.  So I think this should be left to the application/library to decide. That is, the solution isn't universal enough to go in the stdlib, IMO.

So, long story short, I'm -1 :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:38:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 14:38:09 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1440081489.73.0.434934487561.issue24902@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a nice idea, but I think it would be better to add it to the message rather than change the message (and we'd still break some people's programs, I'm sure):

  Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000) ...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:54:13 2015
From: report at bugs.python.org (Ted Lemon)
Date: Thu, 20 Aug 2015 14:54:13 +0000
Subject: [issue24898] Documentation for str.find() is confusing
In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za>
Message-ID: <1440082453.68.0.0405684939943.issue24898@psf.upfronthosting.co.za>


Ted Lemon added the comment:

Hm, okay, that explains it.   I was previously mystified.  How about this as a refinement on your proposal, though:

Return the lowest index in the string where substring sub is found within the string.  Optional arguments start and end restrict the search to the slice of the string, s[start:end].  Returned index is relative to the beginning of the string, not the beginning of the slice. Return -1 if sub is not found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24898>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:10:03 2015
From: report at bugs.python.org (Felix Kaiser)
Date: Thu, 20 Aug 2015 15:10:03 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1440083403.53.0.919624566377.issue24902@psf.upfronthosting.co.za>


Felix Kaiser added the comment:

I'm not sure - that'd be redundant, and I find it harder to read. It also breaks for badly configured terminals where "("/")" are part of the select-by-word character set (but thats a very minor issue -- users with parentheses in the set will probably be used to broken links). Here's a new patch though. Your choice :-)

As for breaking programs: that message is clearly intended for human consumption. My opinion is that if someone parses that, they deserve the opportunity to fix their code. However, out of curiosity, I did search for code containing "Serving HTTP on" before opening the issue and couldn't find anything that's parsing that message.

----------
Added file: http://bugs.python.org/file40215/http_server__on_startup_show_host_and_port_as_url.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:24:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 15:24:13 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1440084253.03.0.827762245971.issue24902@psf.upfronthosting.co.za>


R. David Murray added the comment:

I do it in a number of test suites (you pass in localhost and port 0, then parse the output to find out what port got used).  I'm sure other people do it as well.  The parens could be dropped.  I don't think it is really redundant, as the two ways of presenting the info hit different parts of my brain: one is the part that looks at things from a networking perspective (ports and IPs) and the other that looks at it from a web perspective (urls).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:28:50 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Aug 2015 15:28:50 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1440084530.81.0.816703784914.issue24847@psf.upfronthosting.co.za>


Steve Dower added the comment:

FYI - the Tcl and Tk changes have been committed upstream: http://core.tcl.tk/tcl/tktview/00189c4afcb9e2586301d711f71383e48817a72d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:29:02 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Aug 2015 15:29:02 +0000
Subject: [issue24893] Tk occasionally mispositions Text() insert cursor on
 mouse click.
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440084542.46.0.288205218854.issue24893@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Ned]
> the out-of-date Apple-supplied Tk *might* be in use.

It also happens to me and my students periodically.  Our Tk is up-to-date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:50:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Aug 2015 15:50:01 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440085801.13.0.568640042396.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

Maybe a better starting point is to monkey-patch via setuptools? I know it's nasty, but it'll give us a chance to actually iterate on this before committing to a distutils change. (IMO the biggest problem with distutils is that it gets basically no testing before a final release, other than people who have already worked around its issues.) CCompiler.spawn is fairly easy to patch too.

Adding Jason in case he's still so upset from last time I did this (finding VC compiler for 2.7) he wants to shut the suggestion down immediately :)

As an aside, escaping quotes by doubling them (as in the OP) works fine for MSVC, but is not necessarily standard across all applications. Escaping with a backslash is probably more common, but (e.g.) batch files don't need them escaped if they aren't followed by a space and can't escape them at all if they are followed by a space (then again, we all agree that cmd.exe is fundamentally broken here, so using https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391.aspx (CommandLineToArgvW API) as the benchmark is reasonable).

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:56:07 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 20 Aug 2015 15:56:07 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440086167.13.0.64860118138.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Hum, working on the automated test. It is slightly annoying as with subprocess python is not in a tty, so there will be no change in behavior. I'm not sure how to proceed. 

> At a minimum, an interactive test should be written and added to the documentation

Where would that be ? In the warnings docs, or is there a specific place for "Manual tests" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:05:19 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 20 Aug 2015 16:05:19 +0000
Subject: [issue24893] Tk occasionally mispositions Text() insert cursor on
 mouse click.
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440086719.7.0.0230983148658.issue24893@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't have that laptop any more. It's likely that the screen resolution change caused Tcl/Tk to be confused. That's probably a Tcl/Tk bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:05:31 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 20 Aug 2015 16:05:31 +0000
Subject: [issue24893] Tk occasionally mispositions Text() insert cursor on
 mouse click.
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1440086731.89.0.330258376659.issue24893@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24893>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:09:02 2015
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 20 Aug 2015 16:09:02 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440086942.46.0.875676058108.issue24294@psf.upfronthosting.co.za>


Jim Jewett added the comment:

Instead of using python directly in a subprocess, try calling a shell command that in turns calls python.  (Admittedly, this may look like the pipe scenario...)

In theory, you could even drive another python interactively, using a GUI runner, but I'm not sure how much new infrastructure that would add to the test suite, so it might not be worth it.

I'm not aware of a list of manual tests (though perhaps there *should* be one...); I would put it under the DeprecationWarning docs, sort of like an example.  Others may have better ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:30:52 2015
From: report at bugs.python.org (Chris Hogan)
Date: Thu, 20 Aug 2015 16:30:52 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440088252.43.0.185614038766.issue8987@psf.upfronthosting.co.za>


Chris Hogan added the comment:

> Since issue 8972 has been resolved by fixing the broken behavior, I think we should just use list2cmdline.  
> We could leave _nt_quote_args alone and replace the call to it in _spawn_nt with:

>  cmd = [list2cmdline([arg]) for arg in cmd]

I verified that this passes the high-level test I wrote.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:42:41 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Aug 2015 16:42:41 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440088961.17.0.0796746378588.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

The problem is I can easily find plenty of cases where it won't work.

My biggest concern is that list2cmdline will require already-quoted arguments, which is going to break anyone who's already worked around distutils failing to do so (which makes it really difficult to justify fixing 2.7 and 3.4, and soon 3.5 unless we get it into 3.5.0). The escaping it applies for '\"' also does not take into account someone who has correctly escaped their own argument.

Particularly for distutils, we look up tools by simple name and use PATHEXT, so we may find someone's "link.bat", which then needs very different quoting from the actual "link.exe" (this one is probably unsolvable, unfortunately).

The solution isn't as simple as calling an existing function. It's probably actually as complicated as requiring callers to specify whether strings are quoted or not, and then switching between quoting modes based on what type of program (ie. EXE vs BAT) is being launched. list2cmdline is false hope here, IMO, as it just makes it harder for people to work around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:45:00 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Aug 2015 16:45:00 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440089100.19.0.608353009936.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

FWIW, the problem in the original post is that '-DMODULE_VERSION="1.0.5"' is not quoted by distutils and the quotes are eaten.

This can be fixed by specifying '-DMODULE_VERSION=\"1.0.5\"'. There are no spaces in the argument, so the problem is that cl.exe eats unescaped quotes, not that we aren't automatically changing users arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:59:13 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 20 Aug 2015 16:59:13 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440089953.67.0.198695750746.issue24294@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

I don't see how any of those suggestions help for writing an automated test. Spawning a shell is irrelevant; the problem is to get a tty, which is much harder. There only way I can see that might work for an automated test is to use
  https://docs.python.org/3/library/pty.html
which is Linux only, but I suppose that's better than nothing.

(isatty(sys.stdin) does do something sensible on Windows, right? I hope?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:05:40 2015
From: report at bugs.python.org (Jake Garver)
Date: Thu, 20 Aug 2015 17:05:40 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
Message-ID: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>


New submission from Jake Garver:

In compileall.py's main, we verify that the provided destdir (-d) exists at build time.  But destdir will commonly be used to override the build time path with a runtime path.  That runtime path will usually not exist at build time.

Note that this logic was changed when compileall.py was migrated to argparse.  I think the old logic accidentally avoided the isdir() check at build time.
https://github.com/python/cpython/commit/11e99b06bda2a23478fcec40df8c18edc8a06668

With the attached patch, behavior is made consistent with python 2.7, intended or otherwise.

----------
components: Library (Lib)
files: python34_compileall_ddir.diff
keywords: patch
messages: 248900
nosy: jgarver
priority: normal
severity: normal
status: open
title: Do not verify destdir argument to compileall
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40216/python34_compileall_ddir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:21:11 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 20 Aug 2015 17:21:11 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440091271.82.0.676859580884.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Would `pty` even work on CI where the terminal itself might not be a TTY ?

    >>> subprocess.Popen(['bash', '-c', '''./python.exe -c "import sys; print(sys.stdin.isatty())"'''], stdin=subprocess.PIPE, stderr=subprocess.STDOUT)

    False

Otherwise, I can also (try to) implement  a debug flag "--FakeTTYYesIMReallySure" that make `.isatty()` lie.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:31:38 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 20 Aug 2015 17:31:38 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440091898.52.0.580241416294.issue24294@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

If pty is going to work at all then it should work regardless of whether the tests themselves are being run under a tty, yes.

I personally would not want to merge a test based on making isatty lie, because the point of tests is to increase confidence that things work, and that test sounds more complicated and error prone than the original code being tested. I'm not a cpython committer though...

I am more concerned that isatty might actually just not work on windows, since it is actually strictly speaking true that you never have a "try" on Windows, even if you might have a gui console window open. It would be a good idea to check this quickly...

The other option would be to just remove the isatty check from the patch entirely -- it wasn't something that had strong consensus in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:36:58 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 20 Aug 2015 17:36:58 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440092218.35.0.467067914958.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Astonishingly isatty appear to work on windows:

http://bugs.python.org/issue18553

Up to core python for istty().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:42:17 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 17:42:17 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440092537.28.0.231160815503.issue8987@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it sounds like there may be no way around the fact that people may already be doing the extra needed quoting escaping internal quotes) and therefore that this change would break those use cases.  (I note that any such code must be conditional on windows vs unix, since escaping the quotes will break the same command executed on unix).  

Unless...what if we conditionalize it on whether or not '\"' and/or '\\' appears in the argument?

And yes, the fundamental problem is that Windows provides no way to call a program with a list of not-to-be-modified strings.  The problem with a .bat parsing its argument string differently from how everything else parses its argument string is not a new problem, and is faced by anyone using subprocess.  distutils is trying to be (relatively) platform agnostic, to my understanding, so again we'd have to actually parse the input, this time looking for '.bat' and quoting accordingly.

If we solve the .bat problem (as opposed to ignoring it like we currently do in subprocess) we should fix it in subprocess too.

This is certainly getting non-trivial :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:44:35 2015
From: report at bugs.python.org (John Taylor)
Date: Thu, 20 Aug 2015 17:44:35 +0000
Subject: [issue21253] unittest assertSequenceEqual can lead to
 Difflib.compare() crashing on mostly different sequences
In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za>
Message-ID: <1440092675.71.0.48861340739.issue21253@psf.upfronthosting.co.za>


John Taylor added the comment:

I am seeing something similar in difflib.HtmlDiff.make_file() under Python 3.4.3 (windows 7).  Do I need to file a separate bug report?


File "H:\test\test.py", line 522, in print_differ
    diff = html.make_file(file1_data,file2_data,"dir 1","dir 2",True)
  File "C:\Python34\lib\difflib.py", line 1713, in make_file
    context=context,numlines=numlines))
  File "C:\Python34\lib\difflib.py", line 1962, in make_table
    fromlist,tolist,flaglist = self._collect_lines(diffs)
  File "C:\Python34\lib\difflib.py", line 1830, in _collect_lines
    for fromdata,todata,flag in diffs:
  File "C:\Python34\lib\difflib.py", line 1806, in _line_wrapper
    self._split_line(fromlist,fromline,fromtext)
  File "C:\Python34\lib\difflib.py", line 1791, in _split_line
    self._split_line(data_list,'>',line2)
  
  (repeated many times)

  File "C:\Python34\lib\difflib.py", line 1791, in _split_line
    self._split_line(data_list,'>',line2)
  File "C:\Python34\lib\difflib.py", line 1755, in _split_line
    if (size <= max) or ((size -(text.count('\0')*3)) <= max):
RuntimeError: maximum recursion depth exceeded in comparison

----------
nosy: +jftuga

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21253>
_______________________________________

From report at bugs.python.org  Thu Aug 20 19:58:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 17:58:05 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440093485.02.0.646968687268.issue24903@psf.upfronthosting.co.za>


R. David Murray added the comment:

That line isn't checking the existence of destdir, but rather of the (single, because we have only one destdir to use) directory to compile.  

What bug are you actually seeing?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:06:55 2015
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 20 Aug 2015 18:06:55 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440094015.23.0.793488229301.issue24294@psf.upfronthosting.co.za>


Jim Jewett added the comment:

On windows, when python is started from the command line without a GUI, os.isatty(sys.stdin) raises an error, but os.isatty(sys.stdin.fileno()) returns true.  

Within IDLE, os.isatty(sys.stdin.fileno()) also raises an error, but os.isatty(0), os.isatty(1), and os.isatty(2) all return true.

I'm not sure exactly when you want which warning to show, let alone whether the above tests are relevant, but I'm happy to run some tests if you can tell me what you're looking for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:08:42 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Aug 2015 18:08:42 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440094122.66.0.692363560622.issue24897@psf.upfronthosting.co.za>


Eric Snow added the comment:

This sort of thread belongs on python-ideas at python.org, not on the tracker.  Please post there (feel free to reference this issue; also add a link to the thread here).  TBH, I think there's a larger discussion to be had regarding the topic of other useful descriptors that we should consider adding to Python.

In the meantime I'm closing this issue.  We can re-open it if the outcome of any python-ideas discussions warrants it.

----------
nosy: +eric.snow, rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:09:24 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Thu, 20 Aug 2015 18:09:24 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1440094164.56.0.137774445122.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

A few questions for Russell:

>What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected.

Does this mean I can safely ignore the segfault?

>Are you using the libffi sources vendored into the Python source tree, or a more recent version? 

By 'vendored in' do you mean 'sources included in python source tree for building?'

>I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in.

Would your recommend downloading and building libffi from sources (on device) and then building python?

I'm asking the above questions because I've hit a fairly significant roadblock; I'm still getting the segfault when test_ctypes is run and I can't seem to get anything useful out of gdb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:09:25 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Aug 2015 18:09:25 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440094165.79.0.966428260565.issue24897@psf.upfronthosting.co.za>


Eric Snow added the comment:

That said...

What's the benefit of it being a decorator?  The docstring?  Access to func.__name__?  It could just as well be:

    class attribute:
        _name = None
        def __get__(self, instance, owner):
            if instance is None:
                return self
            if self._name is None:
                for name, attr in vars(owner).items():
                    if attr is self:
                        self._name = name
                        break
            return instance.__dict__[self._name]

However, note that this is a non-data descriptor since it lacks __set__ and __delete__.  That means it is *not* a read-only wrapper like property.  If that's not a concern then there's no point to using a descriptor at all since you can just use a constant as a place-holder:

    class Bar:
        x = ...
        def __init__(self):
            self.x = 42

If you *are* looking for a read-only wrapping descriptor then you'll need __set__ and __delete__ methods, likely ones that simply raise AttributeError.

FWIW, there are definitely plenty of useful things you can do with descriptors. [1]  Some could be useful enough to make it into the stdlib (or builtins), but I'm not convinced the one you are proposing has enough justification at this point.

[1] https://bitbucket.org/ericsnowcurrently/presentations/src/default/utpy-may2015/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:12:20 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 20 Aug 2015 18:12:20 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440094340.42.0.0211449903009.issue24897@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I figured. I guess it makes more sense to do that on a per-library basis. Eric does have a valid point, and perhaps this addition is not needed :) I realize now that this isn't really needed, backing off and closing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 21:21:41 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Aug 2015 19:21:41 +0000
Subject: [issue24897] Add new attribute decorator (akin to property)?
In-Reply-To: <1440033369.04.0.888403008868.issue24897@psf.upfronthosting.co.za>
Message-ID: <1440098501.38.0.0241600947591.issue24897@psf.upfronthosting.co.za>


Eric Snow added the comment:

No worries, Emanuel.  Thanks for bringing it up.  I'd still be interested to see what sort discussion ensued if you took this to python-ideas.  Starting a thread on the topic has been on my todo list for a while but other matters always end up taking precedence. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24897>
_______________________________________

From report at bugs.python.org  Thu Aug 20 21:36:05 2015
From: report at bugs.python.org (Jake Garver)
Date: Thu, 20 Aug 2015 19:36:05 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440099365.26.0.128621839567.issue24903@psf.upfronthosting.co.za>


Jake Garver added the comment:

Thanks for the response and sorry for the mis-read.

In 2.7, I did something like:
python -m compileall -d /runtime/path foo.py

But in 3.4, I get:
-d destdir requires exactly one directory argument

I'm doing this during a build. Then we package the pyc file into a runtime image.

Let me know if I can further help (or confuse).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:31:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 20:31:20 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440102680.92.0.749350648613.issue24903@psf.upfronthosting.co.za>


R. David Murray added the comment:

So, given that that does something useful, it appears that the error message (which is what is in 2.7 as well) is wrong to refer to 'directory argument', and we should just eliminate the isdir check (and fix the error message).

The patch will need a test.

----------
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:36:22 2015
From: report at bugs.python.org (Jan Hudec)
Date: Thu, 20 Aug 2015 20:36:22 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1440102982.77.0.7021344299.issue10740@psf.upfronthosting.co.za>


Jan Hudec added the comment:

While I agree that the current behaviour is a bug (this bug), and one that renders the package unusable for me (I used apsw or different language instead), I unfortunately have to disagree with Gerhard that the change is not a problem. It can be.

The implicit commit before DDL statements that is gone is not a problem, but the implicit commit *after* them that is *also* gone is. Because if somebody only does DDL statements, and upgrade script might do just that, they will now need a commit.

Scripts that use dbapi2 in a portable way will have the commit, because other databases that support DDL in transactions require it already. But scripts that are only used with current sqlite and possibly mysql (behaviour of which the current version mimics) may not and will break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:37:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Aug 2015 20:37:12 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440103032.79.0.943828609557.issue24903@psf.upfronthosting.co.za>


R. David Murray added the comment:

Actually, it looks like it is a bit more potentially complex than that.  The original code would issue the error only if there were more than one argument and the first one was not a directory.  So it would in fact compile more than one argument as long as the first one was a dir.

It's not clear what purpose that check was supposed to serve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:40:42 2015
From: report at bugs.python.org (Jan Hudec)
Date: Thu, 20 Aug 2015 20:40:42 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1440103242.0.0.298696895327.issue10740@psf.upfronthosting.co.za>


Jan Hudec added the comment:

Oh, I see I misunderstood Gerhard's last commit.

So now the problem should be only if there is a DML statement followed by DDL statement and no commit afterwards. Well, that is indeed probably stupid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:53:43 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Aug 2015 21:53:43 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440107623.57.0.101506907832.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Could someone do a quick code review of my latest patch? If the design looks sane I might be able to steal some time tomorrow to start on the C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:18:08 2015
From: report at bugs.python.org (John Taylor)
Date: Thu, 20 Aug 2015 22:18:08 +0000
Subject: [issue24904] Patch: add timeout to difflib SequenceMatcher ratio()
 and quick_ratio()
Message-ID: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>


New submission from John Taylor:

SequenceMatcher in the difflib module contain ratio() and quick_ratio() methods which can take a long time to run with certain input.  One example is two slightly different versions of jquery.min.js.

I have written a patch against python-350b4 that adds a timeout to these methods.  The new functionality also has the capability to "fall through" to the next quickest comparison method should a timeout occur. If a timeout does occur and using a fall through method is not desired, then -1 is returned for the ratio.

I'd like this to be incorporated into Python 3.5.0 if it is not too late.

----------
components: Library (Lib)
files: difflib-diff.patch
keywords: patch
messages: 248919
nosy: jftuga
priority: normal
severity: normal
status: open
title: Patch: add timeout to difflib SequenceMatcher ratio() and quick_ratio()
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file40217/difflib-diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:39:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Aug 2015 22:39:52 +0000
Subject: [issue24904] Patch: add timeout to difflib SequenceMatcher ratio()
 and quick_ratio()
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1440110392.8.0.454668020916.issue24904@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not sure that it's a good idea to add a timeout to such algorithm. It can be very surprising to have a difference result depending on the system load (CPU usage of _other_ applications) and on the CPU performances.

If you really want this result, I would prefer to design the feature outside the Python stdlib. You might modify the stdlib to allow incremental computation.

About the patch itself, which kind of timer should be used? Monotonic clock? System clock? Process time (CPU time)?

Maybe we can optimize the code?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:47:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Aug 2015 22:47:20 +0000
Subject: [issue24904] Patch: add timeout to difflib SequenceMatcher ratio()
 and quick_ratio()
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1440110840.65.0.395327545111.issue24904@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In general, it isn't good design to incorporate timeout logic in computation logic.  What would be better is a general purpose, reusable, decoupled tool: run_with_time_limit(some_computation, some_args, time_limit).  Such a tool might be based on separate process that can be timed or killed, it might use signals, or may be based on threading.Timer.

I did a quick look around the net.  Timeouts on diff APIs aren't common (i.e GNU diff doesn't have a timeout) but there are a couple of precedents (you aren't the first to have had concerns about the running time for unfavorable inputs).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:47:37 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Aug 2015 22:47:37 +0000
Subject: [issue24904] Patch: add timeout to difflib SequenceMatcher ratio()
 and quick_ratio()
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1440110857.6.0.607461668079.issue24904@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:08:06 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:08:06 +0000
Subject: [issue24904] Patch: add timeout to difflib SequenceMatcher ratio()
 and quick_ratio()
In-Reply-To: <1440109087.94.0.522414876776.issue24904@psf.upfronthosting.co.za>
Message-ID: <1440112086.58.0.49720036557.issue24904@psf.upfronthosting.co.za>


Robert Collins added the comment:

So - I'm with Victor and Raymond here. I think modifying difflib to provide external control over the poor-O components would permit many more benefits than just controlling time: you could wrap them in a timer module to get what this patch does, you could replace them with alternative implementations (e.g. parallel ones).

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24904>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:30:49 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:30:49 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1440113449.6.0.231328202553.issue22680@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for this. I think that a better approach would be the other linked bug - we can kill many birds with one stone.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22680>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:39:00 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:39:00 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not run".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440113940.27.0.184326672816.issue14534@psf.upfronthosting.co.za>


Robert Collins added the comment:

So I've two more cases for this that I think we need to ensure works.

Firstly FunctionTestCase should be blacklistable, and its not abstract.

Secondly we're going to want nose, unittest2 etc to be able to also honour this. I suspect that this is easy and may not require any changes, but having a think about it would be good.

----------
nosy: +rbcollins
title: Add method to mark unittest.TestCases as "do not run". -> Add means to mark unittest.TestCases as "do not run".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:39:51 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:39:51 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not run".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440113991.06.0.586274675954.issue14534@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Removed file: http://bugs.python.org/file36315/01438f18ee18.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:40:00 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:40:00 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not run".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440114000.5.0.212571206665.issue14534@psf.upfronthosting.co.za>


Robert Collins added the comment:

Removed the bogus huge diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:42:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 20 Aug 2015 23:42:02 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not run".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440114122.56.0.37610253488.issue14534@psf.upfronthosting.co.za>


Robert Collins added the comment:

I'm going to review on rietvald - I see a lot of changes needed - sorry - and some are a bit bikesheddy. But, if we do them I'll commit it asap and do any final fixup needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:02:04 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:02:04 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not load".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440115324.64.0.56200287165.issue14534@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
title: Add means to mark unittest.TestCases as "do not run". -> Add means to mark unittest.TestCases as "do not load".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:05:20 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:05:20 +0000
Subject: [issue24758] unittest.mock.Mock's new "unsafe" feature needs a better
 error message
In-Reply-To: <1438283225.26.0.251368779344.issue24758@psf.upfronthosting.co.za>
Message-ID: <1440115520.55.0.172504704858.issue24758@psf.upfronthosting.co.za>


Robert Collins added the comment:

@Randy - ok thanks. So, please do improve the prose in the error message, should be a very straight forward patch.

----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:11:43 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:11:43 +0000
Subject: [issue24263] unittest cannot load module whose name starts with
 Unicode
In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za>
Message-ID: <1440115903.78.0.452588468493.issue24263@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thank you very much for writing your patch in backwards compatible style - it will make backporting to unittest2 much easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24263>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:13:50 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 21 Aug 2015 00:13:50 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1440116030.09.0.254102265128.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Regarding the setting background for the multiple elements.. one possibility is that the first time in a session they change the background of an element that was same as the background, we ask if they'd like to apply that change to the other program elements that have the same background.

I hope that wouldn't be too "You seem to be writing a letter..." :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:16:58 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:16:58 +0000
Subject: [issue24263] unittest cannot load module whose name starts with
 Unicode
In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za>
Message-ID: <1440116218.06.0.756256992381.issue24263@psf.upfronthosting.co.za>


Robert Collins added the comment:

I'm torn on whether this needs a test or not. It would be hard to regress, but testing this properly really wants hypothesis with a valid-python-identifier-strategy.

I think on balance we do need one.

So - we need a test in test_discover that mocks the presence of a file with a name containing e.g. \u2603.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24263>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:23:36 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:23:36 +0000
Subject: [issue24352] Provide a way for assertLogs to optionally not hide the
 logging output
In-Reply-To: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za>
Message-ID: <1440116616.73.0.970051259399.issue24352@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok so, design thoughts here.

assertLogs really does two things. Firstly it takes a copy of the logs so it can do its assertion.

Secondly it disables all other logging, cleaning up noisy tests.

Your specific need only conflicts with the second case.

The way I handle this in 'fixtures' is to automatically attach the logs to the test output, which means failures show the logs. (Successes have them too, but they are not shown by default).

Ignoring the mismatch between stock unittest and fixtures supporting unittests, does this sound like it would meet your needs? e.g. you'd use your global to make attachments be shown on success as well as failure, and then you'd have nearly identical behaviour. But not exactly:  it would still disable the during-execution output (which makes parallel and CI runs a lot nicer - the report at the end is the key).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24352>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:43:42 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 21 Aug 2015 00:43:42 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1440117822.71.0.451815448361.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

I've implemented my background-calling code in my framework via run_in_executor() now, so this has become a non-issue for me. I have no more interest in this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24383>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:45:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Aug 2015 00:45:32 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440117932.06.0.712670365624.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I just realized that there is a slight but in the patch so far.  When a non-empty program runs, it necessarily executes at least one statement in the main module.  It will only execute anything else when there is a call. Therefore, the stack trace always begins in the main module and that line can be used to display globals, making the globals item under functions redundant.

However, if there is a call to a function in another module, there need not be a module level statement.  By removing the globals items for functions in other modules, the current patch as is will not allow viewing of globals in other modules. A possible solution is to add an expandable module item every time the module changes.

Mark and I would like to combine the StackViewer and Debugger UIs.  Essentially, a revised stackviewer pane would eventually become part of the debugger.  The Debugger avoids the intermediate +locals and +globals items of StackViewer by expanding both when an item is clicked.  However, the expansion is not added to the tree, but to the one locals box and the one (optional) globals box, both separate from and below the tree.

An alternate solution to the globals problem is to expand locals under a function when clicked on, as currently done with stackviewer, and expand globals to a globals box below the tree, as currently done with stackviewer.  I do not see much need to see the globals of different functions simultaneously (one can switch, as one must do not with Debugger).  I see more reason to see multiple locals of at the same time, and it also make sense to put locals right under each function.

Debugger already does item 8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:49:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Aug 2015 00:49:48 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440118188.45.0.858070597601.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

We should take a look as the stackviewer part of the debugger ui.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:57:17 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:57:17 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1440118637.57.0.583268972361.issue23882@psf.upfronthosting.co.za>


Robert Collins added the comment:

reviewed in rietvald, but here too just in case.

The hunk that saves/restores _top_level_dir feels wrong to me - and not part of this bug, please remove it.

The rest of the patch is fine today.

But it also needs to add two specifically namespace tests: concretely we need the following cases covered:


a) namespace subdir/namespace subdir/test_foo.py gets loaded
b) namespace subdir/test_foo.py with another instance of the namespace subdir on sys.path also containing e.g. test_bar.py, test_bar.py is not loaded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:57:46 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 00:57:46 +0000
Subject: [issue23882] unittest discovery doesn't detect namespace packages
 when given no parameters
In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za>
Message-ID: <1440118666.91.0.210811837207.issue23882@psf.upfronthosting.co.za>


Robert Collins added the comment:

(for the trivial case of CLI discover without a parameter - so translate that to the lower level API and then test that)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23882>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:58:52 2015
From: report at bugs.python.org (Eric Snow)
Date: Fri, 21 Aug 2015 00:58:52 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440118732.9.0.55133639914.issue24305@psf.upfronthosting.co.za>


Eric Snow added the comment:

"Hybrid Nathaniel/Brett approach" LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:03:13 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 21 Aug 2015 01:03:13 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1440118993.08.0.684107165281.issue23496@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

>>What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected.

> Does this mean I can safely ignore the segfault?

Well, "safely" in the sense that everything except a very recent version of libffi is known to not work on ARM64 - so if it doesn't work, it's not because of something Python is doing wrong, it's a problem with a dependency.

>>Are you using the libffi sources vendored into the Python source tree, or a more recent version? 

>By 'vendored in' do you mean 'sources included in python source tree for building?'

Correct. The libffi source code that is in the Python source tree is quite old, and *definitely* doesn't work on ARM64. I'm not even sure that it works on ARMv7.

>>I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in.

> Would your recommend downloading and building libffi from sources (on device) and then building python?

Well, for starters - as I've said before, I'd recommend not compiling on device at all, but that's a separate issue. 

However, regardless of where you're compiling, you can either use an external libffi, or you can do what I've done in the iOS patch - update the Python source tree to include a newer version of libffi. If you update the source in the Python tree, you need to use 2 versions (or a merged version); you need v3.2 sources for ARMv7, and trunk sources for ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk doesn't even compile for ARMv7. See the iOS patch for details.

> I'm asking the above questions because I've hit a fairly significant roadblock; I'm still getting the segfault when test_ctypes is run and I can't seem to get anything useful out of gdb.

Personally, I've pretty much given up on CPython on Android. Even when I got it working, the performance of the JNI layer is *abysmal*, and severely crippled. If you're planning to actually interact with the device in any way (like, say, put a button on the screen), that's a big problem. 

I'm working on an approach that uses Java natively - think "Jython for Android". I'm still a way off having anything working, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:10:09 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 21 Aug 2015 01:10:09 +0000
Subject: [issue24900] Raising an exception that cannot be unpickled causes
 hang in ProcessPoolExecutor
In-Reply-To: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za>
Message-ID: <1440119409.7.0.16057385425.issue24900@psf.upfronthosting.co.za>


Changes by Alex Gr?nholm <alex.gronholm+python at nextday.fi>:


----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24900>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:32:34 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 01:32:34 +0000
Subject: [issue22197] Allow better verbosity / output control in test cases
In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za>
Message-ID: <1440120754.4.0.940578724741.issue22197@psf.upfronthosting.co.za>


Robert Collins added the comment:

There's a few interacting things here. If I can suggest some design thoughts.

buffering within a test is I think really something we should offer a test servicing API for. There are many thirdparty ones (e.g. I have one in fixtures) - but it should be a dedicated API, even if the implementation happens to be shared with the buffer runner feature.

I think it is reasonable in some cases to change TestCase behaviour based on how much debugging is desired - even in CI environments, some outputs are much more expensive than others to generate (e.g. taking a full dump of a database). To enable that we do need a CLI -> runtime environment communication mechanism.

There are many related APIs which we could look at for doing this.
* TestCase's load API (__init__) - we'd get at this via TestLoader
* TestCase's execution API (run, debug) - we'd get at this through TestRunner (for more parameters) or perhaps TestResult (by adding some attribute/query method).
* TestCase's test servicing API (assert*) - we could add a query method or a well known attribute to abstract out where the info is actually coming from
* TestCase's user supplied API (setUp, test methods)
* TestResult - constructed by the runner, it is in some ways the natural means for passing stuff like this around - its how result does its buffering today: but IMO the implementation is in the wrong spot there [it precludes parallelisation vs a test service API that uses a mutex only when needed], so I'd like to not repeat that here.

TestCases support being run multiple times, so to me that rules out using the load API.

I very much want to take TestResult in the direction of being forward-only: feed-backwards APIs on it are much more complex to reason about in the case of Y joins in the result chain. So I think its time we introduced a runner -> test API.

Something like

def run(self, result=None, runner=None):
   ...
   dunder_set(self, '__unittest__runner__', runner)
   try:
   ...
   finally:
       dunder_set(self, '__unittest__runner__', None)
   
def debug(self, runner=None):
   ... same ...

with a helper to pull that out without folk's own code triggering name mangling.

And runner would then be the home for things like aborting a test run, providing configuration like verbosity, arbitrary end user options and so on.
Something like:
runner.config = {}
runner.config['verbosity'] = ...
runner.config['user'] = {... marshalled from CLI ... }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22197>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:41:34 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 01:41:34 +0000
Subject: [issue24247] "unittest discover" modifies sys.path
In-Reply-To: <1432145504.49.0.0792649435806.issue24247@psf.upfronthosting.co.za>
Message-ID: <1440121294.05.0.137322228835.issue24247@psf.upfronthosting.co.za>


Robert Collins added the comment:

It did that because you did not specify a top level directory. Without that, the cwd is not on the path and that breaks many environments.

We should probably document it better. The workaround for your needs is to either just run 'unittest discover', or run 'unittest discover tests -t .', not 'unittest discover tests'.

The behaviour is however something I believe to be correct and essential to most user experiences.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
title: "unittest discover" does modify sys.path -> "unittest discover" modifies sys.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24247>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:41:59 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 21 Aug 2015 01:41:59 +0000
Subject: [issue24355] Provide a unittest api for controlling verbosity in tests
In-Reply-To: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za>
Message-ID: <1440121319.73.0.887831410895.issue24355@psf.upfronthosting.co.za>


Robert Collins added the comment:

I've put a fairly comprehensive comment into issue22197.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24355>
_______________________________________

From report at bugs.python.org  Fri Aug 21 04:07:49 2015
From: report at bugs.python.org (Shiming He)
Date: Fri, 21 Aug 2015 02:07:49 +0000
Subject: [issue21423]
 concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an
 initializer argument
In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za>
Message-ID: <1440122869.33.0.334783600536.issue21423@psf.upfronthosting.co.za>


Changes by Shiming He <heshiming at gmail.com>:


----------
nosy: +Shiming He

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21423>
_______________________________________

From report at bugs.python.org  Fri Aug 21 04:14:48 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Aug 2015 02:14:48 +0000
Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440123288.56.0.707573606269.issue23517@psf.upfronthosting.co.za>


Tim Peters added the comment:

It is really bad that roundtripping current microsecond datetimes doesn't work.  About half of all microsecond-resolution datetimes fail to roundtrip correctly now.  While the limited precision of a C double guarantees roundtripping of microsecond datetimes "far enough" in the future will necessarily fail, that point is about 200 years from now.

Rather than argue endlessly about rounding, it's possible instead to make the tiniest possible change to the timestamp _produced_ at the start.  Here's code explaining it:

    ts = d.timestamp()
    # Will microseconds roundtrip correctly?  For times far
    # enough in the future, there aren't enough bits in a C
    # double for that to always work.  But for years through
    # about 2241, there are enough bits.  How does it fail
    # before then?  Very few microsecond datetimes are exactly
    # representable as a binary float.  About half the time, the
    # closest representable binary float is a tiny bit less than
    # the decimal value, and that causes truncating 1e6 times
    # the fraction to be 1 less than the original microsecond
    # value.
    if int((ts - int(ts)) * 1e6) != d.microsecond:
        # Roundtripping fails.  Add 1 ulp to the timestamp (the
        # tiniest possible change) and see whether that repairs
        # it.  It's enough of a change until doubles just plain
        # run out of enough bits.
        mant, exp = math.frexp(ts)
        ulp = math.ldexp(0.5, exp - 52)
        ts2 = ts + ulp
        if int((ts2 - int(ts2)) * 1e6) == d.microsecond:
            ts = ts2
        else:
            # The date is so late in time that a C double's 53
            # bits of precision aren't sufficient to represent
            # microseconds faithfully.  Leave the original
            # timestamp alone.
            pass
    # Now ts exactly reproduces the original datetime,
    # if that's at all possible.

This assumes timestamps are >= 0, and that C doubles have 53 bits of precision.  Note that because a change of 1 ulp is the smallest possible change for a C double, this cannot make closest-possible unequal datetimes produce out-of-order after-adjustment timestamps.

And, yes, this sucks ;-)  But it's far better than having half of timestamps fail to convert back for the next two centuries.  Alas, it does nothing to get the intended datetime from a microsecond-resolution timestamp produced _outside_ of Python.  That requires rounding timestamps on input - which would be a better approach.

Whatever theoretical problems may exist with rounding, the change to use truncation here is causing real problems now.  Practicality beats purity.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Fri Aug 21 07:45:11 2015
From: report at bugs.python.org (Jan Wagner)
Date: Fri, 21 Aug 2015 05:45:11 +0000
Subject: [issue24880] ctypeslib patch for regular expression for symbols to
 include
In-Reply-To: <1439796006.75.0.0781056689434.issue24880@psf.upfronthosting.co.za>
Message-ID: <1440135911.96.0.0127310856637.issue24880@psf.upfronthosting.co.za>


Jan Wagner added the comment:

Yes, hosted at svn.python.org, but without any means of "externally" filing a bug report or patch for it other than here on bugs.python.org. Maybe theller you could include this patch?   Change status to closed + third party...?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24880>
_______________________________________

From report at bugs.python.org  Fri Aug 21 07:47:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Aug 2015 05:47:18 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1440136038.78.0.0338173044631.issue24902@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I like Felix's original suggestion.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Fri Aug 21 10:05:22 2015
From: report at bugs.python.org (Jim Minter)
Date: Fri, 21 Aug 2015 08:05:22 +0000
Subject: [issue24905] Allow incremental I/O to blobs in sqlite3
Message-ID: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za>


New submission from Jim Minter:

SQLite supports incremental I/O to blobs, i.e. the capability to stream reads and writes to blobs without having to load the entire blob into memory first.  See https://www.sqlite.org/c3ref/blob_open.html for more details on the C API.

It'd be nice if it were possible to do this in Python using sqlite3 (it is already possible with apsw).

----------
messages: 248945
nosy: jim_minter
priority: normal
severity: normal
status: open
title: Allow incremental I/O to blobs in sqlite3
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24905>
_______________________________________

From report at bugs.python.org  Fri Aug 21 11:32:59 2015
From: report at bugs.python.org (Michele Comitini)
Date: Fri, 21 Aug 2015 09:32:59 +0000
Subject: [issue24906] asyncore asynchat hanging on ssl
Message-ID: <1440149579.35.0.0331898658282.issue24906@psf.upfronthosting.co.za>


New submission from Michele Comitini:

When sending a message larger than 4096 bytes with smtpd on a ssl socket, everything hangs.

This is due to polling before synchronizing the SSL channel with the underlying socket.

The issue can be solved by properly modifying the poll function and handling the SSLWantRead exception.

I provide 2 (Debug)SMTPServer implementations and one client to show the error and the workaround all using ssl.

The workaround is not correct semantically but fixes the poll function behavior correctly.

----------
components: Library (Lib)
files: async-ssl-bug.zip
messages: 248946
nosy: Michele Comitini
priority: normal
severity: normal
status: open
title: asyncore asynchat hanging on ssl
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40218/async-ssl-bug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24906>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:01:09 2015
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 21 Aug 2015 10:01:09 +0000
Subject: [issue1384175] random module - Provider DLL failed to initialize
 correctly
Message-ID: <1440151269.8.0.700775461854.issue1384175@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Note that there are still people who get this error in some strange cases, me included.

E.g.:
http://stackoverflow.com/questions/27904936/python-exe-file-crashes-while-launching-on-windows-xp/32137554#32137554

This happened at a call to `os.urandom` for me.
This was in a subprocess.

The bug for me was that I called `_subprocess.CreateProcess` with an `env_mapper = {'foo': 'bar'}`. The fix:

    env_mapper = os.environ.copy()
    env_mapper.update({'foo': 'bar'})

There is another related question [here](http://stackoverflow.com/questions/21791005/windows-error-provider-dll-failed-to-initialize-correctly-on-import-of-cgi-mo).
And some discussion on [this GitHub issue](https://github.com/aws/aws-cli/issues/1226).
All those seem to be related to `crypt32.dll` in a frozen Python app, or via py2app.

----------
nosy: +Albert.Zeyer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1384175>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:18:53 2015
From: report at bugs.python.org (Vadim Kantorov)
Date: Fri, 21 Aug 2015 10:18:53 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
Message-ID: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>


New submission from Vadim Kantorov:

If module's __init__.py contains "__import__('pkg_resources').declare_namespace(__name__)", the module is not loaded, even though it's located in the current directory and should mask other modules.

Originally I stumbled upon this issue while installing a new version of Google Protobuf. But here's a simpler repro:

$ python -c 'import json; print json.__file__'
/usr/lib/python2.7/json/__init__.pyc

$ mkdir json; echo "print 'test'" > json/__init__.py
$ python -c 'import json; print json.__file__'
test
json/__init__.py

$ echo "__import__('pkg_resources').declare_namespace(__name__); print 'test'" > json/__init__.py
$ python -c 'import json; print json.__file__'
test
/usr/lib/python2.7/json/__init__.pyc

For Protobuf, if you build Python bindings from sources, the google/__init__.py will contain exactly "__import__('pkg_resources').declare_namespace(__name__)" and it prevents the freshly-built module from being loaded, even if the module egg is at the first place in sys.path. So an older version gets loaded and it screws things up.

Ubuntu 14.10, Python 2.7.8

----------
components: Extension Modules
messages: 248948
nosy: Vadim Kantorov
priority: normal
severity: normal
status: open
title: Module location load order is not respected if pkg_resources is imported and a namespace is declared
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:20:19 2015
From: report at bugs.python.org (Hartmut Niemann)
Date: Fri, 21 Aug 2015 11:20:19 +0000
Subject: [issue24908] sysconfig.py and distutils.sysconfig.py disagree on
 directory spelling on Windows
Message-ID: <1440156019.56.0.0846148968613.issue24908@psf.upfronthosting.co.za>


New submission from Hartmut Niemann:

Lib\sysconfig.py uses '{installed_base}/Include'
as the include directory on Windows, 

Lib\distutils\sysconfig.py uses 
elif os.name == "nt":
        return os.path.join(prefix, "include")

which is normally harmless because windows file systems
are case-preserving, but case-ignoring, but it leads to
a warning from pyinstaller:
https://github.com/pyinstaller/pyinstaller/issues/783

The directory referred to has a lowercase i (on my machine).

In my opinion both modules should use the spelling
that the installer uses when creating the directories.

----------
messages: 248949
nosy: htnieman
priority: normal
severity: normal
status: open
title: sysconfig.py and distutils.sysconfig.py disagree on directory spelling on Windows
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24908>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:58:42 2015
From: report at bugs.python.org (Jake Garver)
Date: Fri, 21 Aug 2015 12:58:42 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440161922.34.0.278764789275.issue24903@psf.upfronthosting.co.za>


Jake Garver added the comment:

I agree.  I couldn't find a use for the check, so I removed it entirely in the provided patch.  I'm running that way now with success, but of course I'm covering just one use case.

Digging back a bit further, the isdir() check came in here:
https://github.com/python/cpython/commit/dc6a4c158f8a6175c7d0d5d1a61c24c06767ef22

And even further, near the beginning of time, we find the original check:
https://github.com/python/cpython/commit/995d45ede2432306a2a0306ce29cea4013bc2850

Speculation: In the context of the original code, "directory" in the error message makes more sense and that word should have been dropped when single file support was added.  However, given that we loop over the args, I don't see how -d was limited to a single arg.

With my patch in place, I tested compileall.py with multiple args and the -d.  It works as expected and contains the -d path.
python -m compileall -d /runtime/path foo.py bar.py foobar.py

I'm happy to craft a new patch.  How would you like it?

----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Fri Aug 21 15:55:08 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 21 Aug 2015 13:55:08 +0000
Subject: [issue1384175] random module - Provider DLL failed to initialize
 correctly
Message-ID: <1440165308.26.0.984942782257.issue1384175@psf.upfronthosting.co.za>


eryksun added the comment:

Albert, this issue was opened for Python 2.4 and was closed over 6 years ago. Open a new issue if you believe there's a bug or room for improvement in a currently supported Python version. 

FYI, on Windows _PyOS_URandom first initializes the Crypto API by calling [CryptAcquireContext][1]. As shown in the debug session below, this function requires the SystemRoot environment variable to be correctly defined. 

    C:\>cdb -g "C:\Program Files\Python27\python.exe"

    Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    ...

    >>> import os
    >>> from ctypes import *
    ...
    >>> PROV_RSA_FULL = 1
    >>> CRYPT_VERIFYCONTEXT = 0xf0000000
    >>> CryptAcquireContextA = WinDLL('advapi32').CryptAcquireContextA 
    >>> hcrypt = c_void_p()

    >>> del os.environ['SystemRoot']
    >>> CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)
    ModLoad: 000007fe`fc480000 000007fe`fc498000   C:\Windows\system32\CRYPTSP.dll
    CryptAcquireContext:  CheckSignatureInFile failed at cryptapi.c line 5198
    CryptAcquireContext:  Failed to read registry signature value at cryptapi.c line 873
    0

    >>> os.environ['SystemRoot'] = 'C:\\Windows'
    >>> CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)
    ModLoad: 000007fe`fc180000 000007fe`fc1c7000   C:\Windows\system32\rsaenh.dll
    ModLoad: 000007fe`fcae0000 000007fe`fcaef000   C:\Windows\system32\CRYPTBASE.dll
    1
    >>> hcrypt
    c_void_p(4407952L)

It has always struck me as odd that this API uses the environment variable instead of the object manager's secured \SystemRoot object symbolic link. C'est la vie. 

Anyway, I don't think Python's os and subprocess modules should prevent you from shooting yourself in the foot here. When creating an environment block for a child process, excluding SystemRoot is generally a bad idea, but the language shouldn't get in the way. 

I think it's prudent to include at least all of the system-defined variables. Here's a function that calls [CreateEnvironmentBlock][2] and returns the system variables in a dict. It excludes user variables and doesn't inherit from the current process.

    import ctypes

    userenv = ctypes.WinDLL('userenv', use_last_error=True)

    def errcheck_bool(result, func, args):
        if not result:
            raise ctypes.WinError(ctypes.get_last_error())
        return args

    userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
                                               ctypes.c_void_p,
                                               ctypes.c_int)
    userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)

    def get_system_environ():
        WCHAR_SIZE = ctypes.sizeof(ctypes.c_wchar)
        environ = {}
        cenv = ctypes.c_void_p()
        userenv.CreateEnvironmentBlock(ctypes.byref(cenv), None, 0)
        addr = cenv.value    
        try:
            while True:
                s = ctypes.c_wchar_p(addr).value
                if not s:
                    break
                i = s.find('=', 1)
                if i != -1:
                    environ[s[:i]] = s[i+1:]
                addr += (len(s) + 1) * WCHAR_SIZE
        finally:
            userenv.DestroyEnvironmentBlock(cenv)
        return environ

[1]: https://msdn.microsoft.com/en-us/library/aa379886
[2]: https://msdn.microsoft.com/en-us/library/bb762270

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1384175>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:00:06 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 21 Aug 2015 14:00:06 +0000
Subject: [issue1384175] random module - Provider DLL failed to initialize
 correctly
Message-ID: <1440165606.08.0.574810285286.issue1384175@psf.upfronthosting.co.za>


eryksun added the comment:

I forgot to set errcheck:

    import ctypes

    userenv = ctypes.WinDLL('userenv', use_last_error=True)

    def errcheck_bool(result, func, args):
        if not result:
            raise ctypes.WinError(ctypes.get_last_error())
        return args

    userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
                                               ctypes.c_void_p,
                                               ctypes.c_int)
    userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)

    userenv.CreateEnvironmentBlock.errcheck = errcheck_bool
    userenv.DestroyEnvironmentBlock.errcheck = errcheck_bool

    # ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1384175>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:05:31 2015
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 21 Aug 2015 14:05:31 +0000
Subject: [issue1384175] random module - Provider DLL failed to initialize
 correctly
Message-ID: <1440165931.24.0.0383975477602.issue1384175@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Ah thanks, that explains why it failed for me, and why it works after my fix, which was anyway what I intended.

I mostly posted my comment here in case someone else hits this, so he has another thing to check/debug.

I don't think that there is a bug on Python's side. Maybe a nice thing would be a small check in _PyOS_URandom for os.environ['SystemRoot'] and print a more helpful error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1384175>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:25:10 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Fri, 21 Aug 2015 14:25:10 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1440118993.08.0.684107165281.issue23496@psf.upfronthosting.co.za>
Message-ID: <8E2C2129-A0A3-4453-9480-E6C58736B6D2@gmail.com>


Cyd Haselton added the comment:

Question for Ryan Gonzalez:
Given this information...

On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee <report at bugs.python.org> wrote:
>
>Russell Keith-Magee added the comment:
>
>>>What hardware architecture are you compiling for? If it's ARM64, and
>you're not using a trunk version of libffi, that segfault in
>test_ctypes is to be expected.
>
>> Does this mean I can safely ignore the segfault?
>
>Well, "safely" in the sense that everything except a very recent
>version of libffi is known to not work on ARM64 - so if it doesn't
>work, it's not because of something Python is doing wrong, it's a
>problem with a dependency.
>

...do you know of a way to run all tests except _ctypes, so that Imcan verify everything else?

And to answer Russell's questions:

>>>Are you using the libffi sources vendored into the Python source
>tree, or a more recent version? 
>
>>By 'vendored in' do you mean 'sources included in python source tree
>for building?'
>
>Correct. The libffi source code that is in the Python source tree is
>quite old, and *definitely* doesn't work on ARM64. I'm not even sure
>that it works on ARMv7.
>
Definitely using the vendored in sources.

>
>> Would your recommend downloading and building libffi from sources (on
>device) and then building python?
>
>Well, for starters - as I've said before, I'd recommend not compiling
>on device at all, but that's a separate issue. 
>
Any particular reason why? The device I'm working with has a port of GCC which I've used to build other utilities that work well...given that I'm working on a tablet.

>However, regardless of where you're compiling, you can either use an
>external libffi, or you can do what I've done in the iOS patch - update
>the Python source tree to include a newer version of libffi. If you
>update the source in the Python tree, you need to use 2 versions (or a
>merged version); you need v3.2 sources for ARMv7, and trunk sources for
>ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk
>doesn't even compile for ARMv7. See the iOS patch for details.
>
Since I'm not compiling for ARM64...and have zero experience with hacking configure.ac files...would it be okay to include just the 3.2 sources if I note somewhere that this fork does not include ARM64 support?

>> I'm asking the above questions because I've hit a fairly significant
>roadblock; I'm still getting the segfault when test_ctypes is run and I
>can't seem to get anything useful out of gdb.
>
>Personally, I've pretty much given up on CPython on Android. Even when
>I got it working, the performance of the JNI layer is *abysmal*, and
>severely crippled. If you're planning to actually interact with the
>device in any way (like, say, put a button on the screen), that's a big
>problem. 
>
My goal is to build a port that operates on Android in a Linux-like environment; I'm currently using KBOX3.  I've no experience with the Python language so JNI interop is Greek to me.  For what i'm using the port for it functions fairly well.

>I'm working on an approach that uses Java natively - think "Jython for
>Android". I'm still a way off having anything working, though.
>
I'll keep an eye out for it once I've got Python basics under my belt.
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:38:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Aug 2015 14:38:32 +0000
Subject: [issue24352] Provide a way for assertLogs to optionally not hide the
 logging output
In-Reply-To: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za>
Message-ID: <1440167912.24.0.228399221607.issue24352@psf.upfronthosting.co.za>


R. David Murray added the comment:

My test harness already dumps the logging buffer on test failure.

What I need this for is debugging.  My test harness verbose = 2 flag turns on logging globally, and I need to see the logging from the code under test correctly interspersed with the other logging (some of which comes from *other processes*...there are integration tests as well as unit tests).

Here's what I'm currently using:

    @contextmanager
    def assertLogs(self, logger=None, level=None):
        cm = super().assertLogs(logger, level)
        watcher = cm.__enter__()
        if verbose > 1:
            capture_handler = cm.logger.handlers
            cm.logger.propagate = cm.old_propagate
            cm.logger.handlers = cm.old_handlers + cm.logger.handlers
        try:
            yield watcher
        finally:
            if verbose > 1:
                # Restore before exit to avoid a race.  Otherwise debug output
                # sometimes gets written to the console during non-v.
                cm.logger.propagate = False
                cm.logger.handlers = capture_handler
            cm.__exit__(None, None, None)

So, I have a solution, and if my use case is too specialized I can just continue to use that solution, though I am forced to poke at the internals to make it work :)

I am also, by the way, depending on the fact that when the logging is being done by another thread I can "watch" cm.output until specific logging that I am expecting appears in the buffer.  I'm sure that's going to make some people throw up their hands in disgust, considering among other things the fact that it involves a busy-wait, but while it may be a somewhat ugly hack, it is a hack that works well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24352>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:40:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 21 Aug 2015 14:40:38 +0000
Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate
 Text
In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>
Message-ID: <1440168038.54.0.341386259265.issue17945@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Just came across this one (Terry I'm sure can figure out why).

I'm sympathetic with Guilherme's wish that Tk had done this one differently, as an option to specify an existing text widget peer when creating a text widget, rather than having the original spawn a new widget. It probably has something to do with specifying a "-peer" option that you couldn't later change via "configure".

As Gregory's peerfix.diff indicated, the original Python API for this command is wrong, or at least at odds with all the rest of Tkinter. The one required argument should indeed be the parent (master) for the new peer, and not it's widget path name. The call should return the new Text widget object.

Given that nobody can be using the (unpatched) call as it is not functional, I suggest this be changed, without regard to backward compatibility concerns.

The other issue that Gregory raises is the peer being an instance of a Text subclass, e.g. _textpeer, rather than Text itself. While I'm not certain, I suspect this could likely be an issue in practice.

If it's somehow possible to create it as an instance of Text, that would definitely be preferable. I haven't closely examined BaseWidget et al., but I wonder if a hack along these lines might be possible:

 1. Create a new Text widget under the parent (call it 'dummy')
 2. Generate a new widget name (or used a passed in 'name' cnf parameter as usual)  to be used for the peer text widget
 3. Call the underlying 'peer create' with our generated name to create a new text widget on the Tcl side
 4. Modify dummy._w to use the generated name
 5. Replace the original parent.children[dummy._name] entry with one for the newly generated name
 6. Call into Tcl to destroy the dummy Text widget

It didn't look to me like there would be more housekeeping that needed doing to effectively point a widget object at a different widget.

The overhead of temporarily creating the extra Text widget should be negligible in practice.

If this seems like a feasible approach I can try to code it up.

----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17945>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:48:32 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 21 Aug 2015 14:48:32 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <8E2C2129-A0A3-4453-9480-E6C58736B6D2@gmail.com>
Message-ID: <F1D2431C-CDAB-4F13-BC0A-057067FF7EB2@gmail.com>


Ryan Gonzalez added the comment:

On August 21, 2015 9:25:10 AM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>Question for Ryan Gonzalez:
>Given this information...
>
>On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee
><report at bugs.python.org> wrote:
>>
>>Russell Keith-Magee added the comment:
>>
>>>>What hardware architecture are you compiling for? If it's ARM64, and
>>you're not using a trunk version of libffi, that segfault in
>>test_ctypes is to be expected.
>>
>>> Does this mean I can safely ignore the segfault?
>>
>>Well, "safely" in the sense that everything except a very recent
>>version of libffi is known to not work on ARM64 - so if it doesn't
>>work, it's not because of something Python is doing wrong, it's a
>>problem with a dependency.
>>
>
>...do you know of a way to run all tests except _ctypes, so that Imcan
>verify everything else?
>

You can temporarily change the last line of Lib/ctypes/test/__init__.py to:

return args[1]

>And to answer Russell's questions:
>
>>>>Are you using the libffi sources vendored into the Python source
>>tree, or a more recent version? 
>>
>>>By 'vendored in' do you mean 'sources included in python source tree
>>for building?'
>>
>>Correct. The libffi source code that is in the Python source tree is
>>quite old, and *definitely* doesn't work on ARM64. I'm not even sure
>>that it works on ARMv7.
>>
>Definitely using the vendored in sources.
>
>>
>>> Would your recommend downloading and building libffi from sources
>(on
>>device) and then building python?
>>
>>Well, for starters - as I've said before, I'd recommend not compiling
>>on device at all, but that's a separate issue. 
>>
>Any particular reason why? The device I'm working with has a port of
>GCC which I've used to build other utilities that work well...given
>that I'm working on a tablet.
>
>>However, regardless of where you're compiling, you can either use an
>>external libffi, or you can do what I've done in the iOS patch -
>update
>>the Python source tree to include a newer version of libffi. If you
>>update the source in the Python tree, you need to use 2 versions (or a
>>merged version); you need v3.2 sources for ARMv7, and trunk sources
>for
>>ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk
>>doesn't even compile for ARMv7. See the iOS patch for details.
>>
>Since I'm not compiling for ARM64...and have zero experience with
>hacking configure.ac files...would it be okay to include just the 3.2
>sources if I note somewhere that this fork does not include ARM64
>support?
>
>>> I'm asking the above questions because I've hit a fairly significant
>>roadblock; I'm still getting the segfault when test_ctypes is run and
>I
>>can't seem to get anything useful out of gdb.
>>
>>Personally, I've pretty much given up on CPython on Android. Even when
>>I got it working, the performance of the JNI layer is *abysmal*, and
>>severely crippled. If you're planning to actually interact with the
>>device in any way (like, say, put a button on the screen), that's a
>big
>>problem. 
>>
>My goal is to build a port that operates on Android in a Linux-like
>environment; I'm currently using KBOX3.  I've no experience with the
>Python language so JNI interop is Greek to me.  For what i'm using the
>port for it functions fairly well.
>
>>I'm working on an approach that uses Java natively - think "Jython for
>>Android". I'm still a way off having anything working, though.
>>
>I'll keep an eye out for it once I've got Python basics under my belt.
>>----------
>>
>>_______________________________________
>>Python tracker <report at bugs.python.org>
>><http://bugs.python.org/issue23496>
>>_______________________________________
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:55:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Aug 2015 14:55:50 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
In-Reply-To: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>
Message-ID: <1440168950.46.0.746251995939.issue24907@psf.upfronthosting.co.za>


R. David Murray added the comment:

pkg_resources is 3rd party code (from the point of view of this tracker).  If you are saying its code is revealing a bug in python, can you expand on what exactly the bug is?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:00:48 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 21 Aug 2015 15:00:48 +0000
Subject: [issue24908] sysconfig.py and distutils.sysconfig.py disagree on
 directory spelling on Windows
In-Reply-To: <1440156019.56.0.0846148968613.issue24908@psf.upfronthosting.co.za>
Message-ID: <1440169248.52.0.183225892302.issue24908@psf.upfronthosting.co.za>


eryksun added the comment:

Within the standard library, I think only the site module uses the top-level sysconfig module, which IIRC it uses to set up sys.path. 

Note that WINDOWS_SCHEME in distutils.command.install uses "Include". Also for virtual environments, venv.EnvBuilder.ensure_directories hard codes "Include".

----------
components: +Distutils, Windows
nosy: +dstufft, eric.araujo, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal -> low
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24908>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:03:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Aug 2015 15:03:51 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440169431.2.0.540637751436.issue24903@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, so I think the goal was to prevent more than one *directory* from being specified, since as I said earlier that wouldn't make sense given we have only a single destdir path.

However, for backward compatibility reasons we should probably not restrict it, but rather invoke the python "consenting adults" rule and let you shoot yourself in the foot that way if you want to.  It only affects error messages, after all.

So yeah, if you can build a new patch including some tests that would be great.  Best way is to check out the repository, switch to the 3.4 branch, edit the files, and use 'hg diff' to generate the patch.  Doing it that way makes it easy to test your changes.  But whatever method of coming up with a context diff that you care to use is also fine.

More detailed information about the normal workflow is in docs.python.org/devguide.  Note that in addition to the central repository at hg.python.org, there are also bitbucket and github mirrors, which should both be mentioned in the devguide (if they aren't, that's a bug in the devguide :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:04:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Aug 2015 15:04:02 +0000
Subject: [issue24903] Do not verify destdir argument to compileall
In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za>
Message-ID: <1440169442.61.0.110233113187.issue24903@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24903>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:17:30 2015
From: report at bugs.python.org (Nicolas Jouanin)
Date: Fri, 21 Aug 2015 15:17:30 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1440170250.95.0.673153910781.issue19084@psf.upfronthosting.co.za>


Changes by Nicolas Jouanin <nico at beerfactory.org>:


----------
nosy: +njouanin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:18:48 2015
From: report at bugs.python.org (Nicolas Jouanin)
Date: Fri, 21 Aug 2015 15:18:48 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
 and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1440170328.41.0.11168752264.issue11943@psf.upfronthosting.co.za>


Changes by Nicolas Jouanin <nico at beerfactory.org>:


----------
nosy: +njouanin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11943>
_______________________________________

From report at bugs.python.org  Fri Aug 21 18:51:55 2015
From: report at bugs.python.org (Adam Meily)
Date: Fri, 21 Aug 2015 16:51:55 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
Message-ID: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>


New submission from Adam Meily:

** This issue and attached patch only affect Windows **

Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time.


Example
=======

A pipe is created using the os.pipe() function. Then, two threads are started, T1 and T2. T1 calls Popen, setting stdout to the write-end of the pipe. T2 calls Popen, setting stdin to the read-end of the pipe. Stock CPython would make T1.stdout and T2.stdin inheritable. T1's Popen will create a subprocess, which correctly inherits T1.stdout, but it will also inherit the T2.stdin handle. Likewise, T2's Popen will create a subprocess, which correctly inherits T2.stdin, but it will also inherit the T1.stdout handle. Thus, in this situation where both ends of the pipe were accidentally inherited, the pipe will not properly close and T2's subprocess will have to be forcefully killed (assuming it is reading from stdin).

The patch simply enforces that the lifetime of an inheritable handle is limited to a single call to Popen.


Why this should be in CPython
=============================

I believe this change should be in CPython. Tracking down this bug into the Python core took a substantial amount of time and work. Can I do this in my Python application and achieve the same effect? Absolutely, but I would argue that I shouldn't have to. The fix in CPython is very minimal:

 - It won't break existing code. Even if my project already has a lock around calls to Popen, my code will continue to work. Sure, it's a duplicate lock, but nothing will break or deadlock.

 - The performance impact is negligible. The lock is only instantiated for Windows platforms and acquiring/releasing a lock appears to have very low overhead.

 - Because the patch is very small, it can be easily backported to other Python versions. As far as I can tell, Python 3.5, 3.4, 3.3, and 2.7 will work with the attached patch. The one difference between the Python versions is that subprocess.mswindows was renamed to subprocess._mswindows at some point, which is very minor.

 - Python 3.4's  new OS-specific inheritable functions [os.get_inheritable(), os.set_inheritable(), etc] will continue to work as expected. So, nothing is broken or changed there.

Old code won't break, new code will benefit immediately, and existing code will work better.


Similar Issues
==============

 - #19809: subprocess should warn uses on race conditions when multiple threads spawn child processes

 - #2320: Race condition in subprocess using stdin

 - #12739: read stuck with multithreading and simultaneous subprocess.Popen

----------
components: Library (Lib)
files: win32-popen-lock.patch
keywords: patch
messages: 248961
nosy: Adam Meily
priority: normal
severity: normal
status: open
title: Windows: subprocess.Popen: race condition for leaking inheritable handles
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40219/win32-popen-lock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 18:57:28 2015
From: report at bugs.python.org (Adam Meily)
Date: Fri, 21 Aug 2015 16:57:28 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440176248.84.0.611662646456.issue24909@psf.upfronthosting.co.za>


Adam Meily added the comment:

Attached is a test Python script that you can run to see the race condition in action. There are two Python scripts: pipe.py and reader.py.

 - pipe.py: make two subprocess.Popen() calls from two different threads.

 - reader.py: (its content is in the bottom comments of pipe.py, so move it to a separate file): reads lines from stdin and exits

Basically, pipe.py creates a pipe between "echo Hello World!" and "python reader.py".

You'll see that pipe.py will hang until ctrl+c is entered, even though the first subprocess in the pipe, reader.py, exits. Uncommenting the time.sleep() call will cause the first subprocess.Popen() time to properly close the inheritable handles before the second subprocess.Popen() call is made in the other thread, thus the inheritable handles are leaked.

----------
Added file: http://bugs.python.org/file40220/pipe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:01:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Aug 2015 17:01:13 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440176473.8.0.59814010519.issue24909@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is it possible to construct a test for this?

----------
components: +Windows
nosy: +gregory.p.smith, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
stage:  -> patch review
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:03:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Aug 2015 17:03:40 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440176620.21.0.141633990228.issue24909@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yeah, when stdin, stdout or stderr is a pipe, subprocess.Popen() calls CreateProcess() with the STARTF_USESTDHANDLES flag and bInheritHandles=TRUE.

This issue was fixed on UNIX for file descriptor inheritance. The fix is a major change: Python 3.4 now only creates non-inheritable file descriptors by default. See the PEP 446, especially the "Only Inherit Some Handles on Windows" section:
https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

This part is out of the scope of the PEP.

For me, the real fix would be to create non-inheritable

I guess that this issue is a duplicate of the issue #19575.

I'm again the idea of adding a lock inside the subprocess module. I may add deadlocks. You can already put this lock in your application, before calling subprocess.Popen (directly or indirectly).

> Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time.

This is a race condition specific to the subprocess module. Usually, handles are created non-inhertable, so calling CreateProcess() with bInheritHandles=TRUE is not an issue.

The real fix is *not* make duplicated handles inheritable, but use the new PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure. Again, see the issue #19575.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:04:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Aug 2015 17:04:47 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440176686.99.0.316224849291.issue24909@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
Removed message: http://bugs.python.org/msg248964

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:10:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Aug 2015 17:10:09 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440177009.26.0.21575919078.issue24909@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yeah, when stdin, stdout or stderr is a pipe, subprocess.Popen() calls CreateProcess() with the STARTF_USESTDHANDLES flag and bInheritHandles=TRUE.

This issue was fixed on UNIX for file descriptor inheritance. The fix is a major change: Python 3.4 now only creates non-inheritable file descriptors by default. See the PEP 446.

For your issue, see the "Only Inherit Some Handles on Windows" section:
https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

But this section is not fixed by the PEP. I was decided to fix inheritance of file descriptors and inheritance of handles separatly.

I guess that this issue is a duplicate of the issue #19575.

I'm against the idea of adding a lock inside the subprocess module. I may introduce deadlock issues. You can already put such lock in your application, to call subprocess.Popen (directly or indirectly).

> Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time.

This is a race condition really specific to the subprocess module. Usually, handles are created non-inhertable on Windows, so calling CreateProcess() with bInheritHandles=TRUE is not an issue in the common case. Here the problem is that subprocess makes duplicated handles inheritable. There is a short window where a second thread can spawn a process and inherit these handles too.

The real fix is to never make duplicated handles inheritable, but instead to use the new PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure. Another option to fix the issue is to use a wrapper application and send handles from the parent to the child, but this option introduces a lot of complexity since the parent has to handle two processes, not only one! Again, see the issue #19575.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:38:01 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Aug 2015 17:38:01 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
In-Reply-To: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>
Message-ID: <1440178681.51.0.545905238075.issue24907@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:51:06 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 21 Aug 2015 17:51:06 +0000
Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate
 Text
In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>
Message-ID: <1440179466.74.0.912283021966.issue17945@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Did a quick check... this approach seems to work. Only change was in step 4 should set both ._w and ._name for the widget object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17945>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:54:26 2015
From: report at bugs.python.org (Chris Hogan)
Date: Fri, 21 Aug 2015 17:54:26 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440179666.98.0.956422465857.issue8987@psf.upfronthosting.co.za>


Chris Hogan added the comment:

Here's a change that might fix the trailing backslash problem for now without breaking anything.  libpath-fix.patch only affects arguments that we know are paths.  This happens before anything is quoted.

This avoids the problem when something like 'C:\path with space\trailing backslash\' is passed to _nt_quote_args() and becomes '"C:\path with space\trailing backslash\"'.  The " is escaped which mangles the string.

I'm not sure if it's the responsibility of the user to not pass in such arguments, or of cpython to sanitize these things.  Is this change harmless, or can you think of situations where it will break something?

----------
Added file: http://bugs.python.org/file40221/libpath-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:16:14 2015
From: report at bugs.python.org (Chris Hogan)
Date: Fri, 21 Aug 2015 18:16:14 +0000
Subject: [issue993766] bdist_dumb and --relative on Windows fails
Message-ID: <1440180974.59.0.501947164152.issue993766@psf.upfronthosting.co.za>


Chris Hogan added the comment:

I think ensure_relative is incorrect. The comment in the function states:

 "Take the full path 'path', and make it a relative path. This is useful to make 'path' the second argument to os.path.join()."

However, according to the docs for os.path.join, if a component contains a drive letter, all previous components are thrown away and the drive letter is reset.  This makes the result from ensure_relative a poor candidate as a "second argument to os.path.join" on Windows because it will always contain a drive letter which will always wipe out the first argument.

>>> os.path.join('bar', 'c:foo')
'c:foo'

This is what happens when I try to build a simple distro with the command python setup.py bdist_dumb --relative. In Lib/distutils/command/bdist_dumb.py:bdist_dumb.run:

archive_root = os.path.join(self.bdist_dir, ensure_relative(install.install_base))

the call is

>>> os.path.join('build\\bdist.win-amd64\\dumb', 'C:path\\to\\python')
'C:path\\to\\python'

It seems to me that the intention is to return

'build\\bdist.win-amd64\\dumb\\path\\to\\python27'

Later in distutils.archive_util.make_archive, it tries to os.chdir into 'C:path\\to\\python', which it can't do because that's not an absolute path (it's missing a '\' after 'C:').
As far as I can tell, the only thing the --relative flag does is to append the python install path onto the build location and build the archive there. However, this build location is temporary and gets deleted at the end of the process, so I don't really see the point.

I think there are two options here: 
1) Get rid of ensure_relative and do it like this:

archive_root = os.path.join(self.bdist_dir, os.path.splitdrive(install.install_base)[1].lstrip(os.sep))

This is the only place ensure_relative is ever used anyway.

2) Keep ensure_relative and do it like this:

archive_root = os.path.join(self.bdist_dir, os.path.splitdrive(ensure_relative(install.install_base))[1])

----------
nosy: +christopher.hogan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue993766>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:29:44 2015
From: report at bugs.python.org (Carl Meyer)
Date: Fri, 21 Aug 2015 18:29:44 +0000
Subject: [issue19469] Duplicate namespace package portions (but not on Windows)
In-Reply-To: <1383285932.19.0.495289288555.issue19469@psf.upfronthosting.co.za>
Message-ID: <1440181784.54.0.204668004267.issue19469@psf.upfronthosting.co.za>


Carl Meyer added the comment:

FWIW, this bug has bitten Django; see https://code.djangoproject.com/ticket/25246

We can easily work around it for future versions, but we have code in released versions that assumed that `__path__` wouldn't contain dupes; it causes us to raise an error in a situation that shouldn't be an error (because we need a Django "app" module to have exactly one filesystem location).

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19469>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:31:51 2015
From: report at bugs.python.org (Adam Meily)
Date: Fri, 21 Aug 2015 18:31:51 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440181911.67.0.240494405492.issue24909@psf.upfronthosting.co.za>


Adam Meily added the comment:

@r.david.murray: Yes I could make a test.

@haypo:

I did not know about the PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure, thanks for the heads up. You pointed me in the right direction, and I see now that you've been following this, and similar, subprocessing issues on Windows for some time.

I understand the hesitancy for adding a Lock to the standard library. Unless I am mistaken, I don't think my patch could cause a deadlock. I am releasing the lock in a `finally` block. So, the way I see it, the only way a deadlock can occur is if the thread crashes while in C code, which will cause the `finally` block to not execute. The lock will stay acquired, and then another thread will deadlock trying to acquire the lock. However, if that is the case and the thread crashed in C, the whole interpreter instance would have crashed, not just the Thread, which would make the deadlock impossible.

It looks like the structure you reference to, PROC_THREAD_ATTRIBUTE_HANDLE_LIST (STARTUPINFOEX), is only available in Windows Vista and after. Which means that Windows XP/Server 2003 would still have this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:38:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Aug 2015 18:38:17 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440182297.79.0.601161149225.issue24909@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It looks like the structure you reference to, PROC_THREAD_ATTRIBUTE_HANDLE_LIST (STARTUPINFOEX), is only available in Windows Vista and after. Which means that Windows XP/Server 2003 would still have this issue.

Windows XP is no more supported in Python 3.5:
https://docs.python.org/dev/whatsnew/3.5.html#unsupported-operating-systems

For Windows Server 2003, yes, we will have to keep the current code which has the race condition. We did the same in the PEP 446 to clear the inherit flag. It's atomic or not depending on the function, on the operating system and even depending on the operating system version. So the PEP 446 doesn't fix all race conditions on old operating systems.

https://www.python.org/dev/peps/pep-0446/#atomic-creation-of-non-inheritable-file-descriptors

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:49:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Aug 2015 18:49:53 +0000
Subject: [issue24910] Windows MSIs don't have unique display names
Message-ID: <1440182992.59.0.13997851785.issue24910@psf.upfronthosting.co.za>


New submission from Steve Dower:

The MSIs for debug symbols and binaries have the same descriptions as the main installers, so you can't distinguish between the packages in lists like (get-package python).Name (in Powershell):

Python 3.5.0rc1 Development Libraries (64-bit)
Python 3.5.0rc1 Core Interpreter (64-bit)
Python 3.5.0rc1 Standard Library (32-bit)
Python 3.5.0rc1 Executables (64-bit)
Python 3.5.0rc1 Executables (32-bit)
Python 3.5.0rc1 Tcl/Tk Support (32-bit)
Python 3.5.0rc1 Tcl/Tk Support (64-bit)
Python 3.5.0rc1 Executables (32-bit)
Python 3.5.0rc1 Tcl/Tk Support (32-bit)
Python 3.5.0rc1 Tcl/Tk Support (64-bit)
Python 3.5.0rc1 Standard Library (32-bit)
Python 3.5.0rc1 Tcl/Tk Support (32-bit)
Python 3.5.0rc1 Core Interpreter (32-bit)
Python 3.5.0rc1 Core Interpreter (64-bit)

We (I) should fix up the descriptions so they can be told apart. (Note that these are not generally user-visible, so it isn't a huge deal.)

----------
assignee: steve.dower
components: Installation, Windows
messages: 248972
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows MSIs don't have unique display names
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24910>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:54:06 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 21 Aug 2015 18:54:06 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440182297.79.0.601161149225.issue24909@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-NquQ-TQUqQ9GKFAQvnTcinQFkV2Q6UE3nhCBjfv08rhQ@mail.gmail.com>


Zachary Ware added the comment:

STINNER Victor added the comment:
> For Windows Server 2003, yes, we will have to keep the current code which has the race condition.

Server 2003 is also unsupported in 3.5+ (MS extended support ended in July).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:04:40 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Fri, 21 Aug 2015 19:04:40 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1440183880.23.0.552694728704.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Thanks Ryan.

Running ./python -m test (with the edit to the __init__.py for ctypes) produces the following error:

[151/390/18] test_hash
Fatal Python error: Bus error

Current thread 0xb6f72ec8 (most recent call first):
  File "/bld/pyt/cpython-android/Lib/test/test_hash.py", line 89 in test_unaligned_buffers
  File "/bld/pyt/cpython-android/Lib/unittest/case.py", line 577 in run
  File "/bld/pyt/cpython-android/Lib/unittest/case.py", line 625 in __call__
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in __call__
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in __call__
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
  File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in __call__
  File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1668 in run
  File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1769 in _run_suite
  File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1803 in run_unittest
  File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1279 in test_runner
  File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1280 in runtest_inner
  File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 978 in runtest
  File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 763 in main
  File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd  File "/bld/pyt/cpython-android/Lib/test/__main__.py", line 3 in <module>
  File "/bld/pyt/cpython-android/Lib/runpy.py", line 85 in _run_code
  File "/bld/pyt/cpython-android/Lib/runpy.py", line 170 in _run_module_as_main
Bus error

Not sure what a bus error is...off to Google

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:15:55 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 21 Aug 2015 19:15:55 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1440183880.23.0.552694728704.issue23496@psf.upfronthosting.co.za>
Message-ID: <CAO41-mOPJEjuSiA9uhmaxLfBzaUVwvQdextAm33SeBFdh8aXvw@mail.gmail.com>


Ryan Gonzalez added the comment:

Bus error is basically unaligned memory access.

...

...do you feel like trying to get a backtrace from GDB again? :) (The last
time likely didn't end well because the machine stack got somehow
corrupted.)

On Fri, Aug 21, 2015 at 2:04 PM, Cyd Haselton <report at bugs.python.org>
wrote:

>
> Cyd Haselton added the comment:
>
> Thanks Ryan.
>
> Running ./python -m test (with the edit to the __init__.py for ctypes)
> produces the following error:
>
> [151/390/18] test_hash
> Fatal Python error: Bus error
>
> Current thread 0xb6f72ec8 (most recent call first):
>   File "/bld/pyt/cpython-android/Lib/test/test_hash.py", line 89 in
> test_unaligned_buffers
>   File "/bld/pyt/cpython-android/Lib/unittest/case.py", line 577 in run
>   File "/bld/pyt/cpython-android/Lib/unittest/case.py", line 625 in
> __call__
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in
> __call__
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in
> __call__
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 122 in run
>   File "/bld/pyt/cpython-android/Lib/unittest/suite.py", line 84 in
> __call__
>   File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1668
> in run
>   File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1769
> in _run_suite
>   File "/bld/pyt/cpython-android/Lib/test/support/__init__.py", line 1803
> in run_unittest
>   File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1279 in
> test_runner
>   File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1280 in
> runtest_inner
>   File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 978 in runtest
>   File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 763 in main
>   File "/bld/pyt/cpython-android/Lib/test/regrtest.py", line 1564 in
> main_in_temp_cwd  File "/bld/pyt/cpython-android/Lib/test/__main__.py",
> line 3 in <module>
>   File "/bld/pyt/cpython-android/Lib/runpy.py", line 85 in _run_code
>   File "/bld/pyt/cpython-android/Lib/runpy.py", line 170 in
> _run_module_as_main
> Bus error
>
> Not sure what a bus error is...off to Google
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23496>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:33:08 2015
From: report at bugs.python.org (Adam Meily)
Date: Fri, 21 Aug 2015 19:33:08 +0000
Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking
 inheritable handles
In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za>
Message-ID: <1440185588.19.0.679369012065.issue24909@psf.upfronthosting.co.za>


Adam Meily added the comment:

Ok, I can re-implement the patch to meet what you all are looking for. I just want to double check that I'm on the same page:

I'll get rid of the lock, because the fix should really be done in the call to CreateProcessW. I imagine that I'll be editing Modules/_winapi.c:824. Essentially, the fix will include switching _winapi.c to use a STARTUPINFOEX structure, and manually passing in the three handles for stdin, stdout, and stderr to PROC_THREAD_ATTRIBUTE_HANDLE_LIST.

The one potential problem that I see is that it looks like specifying PROC_THREAD_ATTRIBUTE_HANDLE_LIST means that no other handles are inherited, even if they are inheritable. Doesn't this break applications that are explicitly creating inheritable handles and expecting them to be accessible within the subprocess? I could add Windows support for pass_fds, but then existing applications would have to be updated to use the argument on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:53:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Aug 2015 19:53:42 +0000
Subject: [issue19469] Duplicate namespace package portions (but not on Windows)
In-Reply-To: <1383285932.19.0.495289288555.issue19469@psf.upfronthosting.co.za>
Message-ID: <1440186822.72.0.175304068884.issue19469@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I can't reproduce under Python 3.4.3, the 3.4 branch, 3.5 branch, or default with a plain namespace package. Can anyone come up with a test case that can reproduce this problem? Otherwise I'll assume it was a bug that got fixed in 3.4.2.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19469>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:18:40 2015
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Aug 2015 20:18:40 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1440188320.69.0.429679248205.issue24881@psf.upfronthosting.co.za>


Akira Li added the comment:

To make _pyio correspond to the C version I've added 

  sys.platform in {'win32', 'cygwin'} 

condition. See the attached pyio_setmode.diff 

It is not clear why the absence of _setmode(fd, os.O_BINARY) is not detected by tests.

(a) a corresponding test should be added
(b) OR _setmode() call should be removed from both Python and C io versions

----------
keywords: +patch
nosy: +akira
Added file: http://bugs.python.org/file40222/pyio_setmode.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:34:06 2015
From: report at bugs.python.org (zodalahtathi)
Date: Fri, 21 Aug 2015 20:34:06 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
Message-ID: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>


New submission from zodalahtathi:

socket.socket has a context manager to automatically close the socket with the `with` statement: https://hg.python.org/cpython/file/d1bf181afa82/Lib/socket.py#l138

However it is not documented, unlike socket.create_connection.

----------
assignee: docs at python
components: Documentation
messages: 248979
nosy: docs at python, zodalahtathi
priority: normal
severity: normal
status: open
title: Context manager of socket.socket is not documented
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:40:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Aug 2015 20:40:45 +0000
Subject: [issue17945] tkinter: change API of non-functioning peer_create,
 does not instantiate Text
In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>
Message-ID: <1440189642.93.0.647587621262.issue17945@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka
title: tkinter/Python 3.3.0: peer_create doesn't instantiate Text -> tkinter: change API of non-functioning peer_create, does not instantiate Text
type: behavior -> enhancement
versions: +Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17945>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:52:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Aug 2015 20:52:40 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1440190360.57.0.213725071437.issue24848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a reason for behavior in case 2. This is likely a truncated data and it is safer to raise an exception than silently produce lone surrogate. Current UTF-7 encoder always adds '-' after ending shift sequence. I suppose this is not a bug.

However there are yet three bugs.

4. Decoder can emit lone low surrogate before replacement character in case of error.

>>> b'+2DTdI-'.decode('utf-7', 'replace')
'\ud834?'

A low surrogate is a part of incomplete astral character and shouldn't emitted in case of error in encoded astral character.

5. According to RFC 2152: "A "+" character followed immediately by any character other than members of set B or "-" is an ill-formed sequence." But this is accepted by current decoder as empty shift sequence that is decoded to empty string.

>>> b'a+,b'.decode('utf-7')
'a,b'
>>> b'a+'.decode('utf-7')
'a'

6. Replacement character '\ufffd' can be replaced with character '?' ('\xfd'):

>>> b'\xff'.decode('utf-7', 'replace')
'?'
>>> b'a\xff'.decode('utf-7', 'replace')
'a?'
>>> b'a\xffb'.decode('utf-7', 'replace')
'a?b'
>>> b'\xffb'.decode('utf-7', 'replace')
'?b'

This bug is reproduced only in 3.4+.

Following patch fixes bugs 1 and 4 and adds more tests.

Corner cases 2 and 3 are likely not bugs.

I doubt about fixing bug 5. iconv accepts such ill-formed sequences. In any case I think the fix of this bug can be applied only for default branch.

I have no idea how to fix bug 6. I afraid it can be a bug in _PyUnicodeWriter and therefore can affect other decoders.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40223/utf7_error_handling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24848>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:55:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Aug 2015 20:55:51 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1440190551.57.0.603214202968.issue24881@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Sat Aug 22 00:02:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Aug 2015 22:02:51 +0000
Subject: [issue24912] The type of cached objects is mutable
Message-ID: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The type of non-heap types can be changed in 3.5. This means that the type of cached immutable objects such as small ints, empty or 1-character strings, etc can be changed.

>>> class I(int):
...     __slots__ = ()
...     def __repr__(self):
...         return 'Answer to The Ultimate Question of Life, the Universe, and Everything'
...     def __add__(self, other):
...         return self * other
... 
>>> (42).__class__ = I
>>> ord('*')
Answer to The Ultimate Question of Life, the Universe, and Everything
>>> x = 42; x + 2
84
>>> class S(str):
...     __slots__ = ()
...     def __len__(self):
...         return 123
... 
>>> 'a'.__class__ = S
>>> i = 1; len('abc'[:i])
123

----------
components: Interpreter Core
messages: 248981
nosy: pitrou, serhiy.storchaka
priority: high
severity: normal
status: open
title: The type of cached objects is mutable
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sat Aug 22 00:12:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Aug 2015 22:12:08 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440195128.25.0.170470074866.issue24912@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Isn't there already an issue open for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sat Aug 22 00:15:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Aug 2015 22:15:39 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440195339.43.0.713720429422.issue24912@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't remember. I noticed this once in comments on Rietveld, but don't remember the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sat Aug 22 00:30:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Aug 2015 22:30:53 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440196252.96.0.18912203065.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

That would break paths like "\" or "D:\" ("D:" != "D:\" - the backslash is meaningful here), but I'm fairly sure _nt_quote_args could add '\\"' to the end if it ends in a backslash already (to escape the trailing slash):

     for i, arg in enumerate(args):
         if ' ' in arg:
-            args[i] = '"%s"' % arg
+            args[i] = '"%s%s"' % (arg, '\\' if arg.endswith('\\') else '')
     return args

For distutils, that's probably an okay fix since we're already quoting everything, and it doesn't try to make things too smart. But it would break people who are already escaping their own trailing backslash, and doesn't provide a workaround that will work both before and after this change. Especially for something like distutils, where people often have one setup.py for all Python versions, this is pretty important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sat Aug 22 01:09:07 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 21 Aug 2015 23:09:07 +0000
Subject: [issue24913] newblock() Uninitialized Variable
Message-ID: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.5 suffers from a vulnerability caused by the behavior of the newblock() function used by the collections.deque module. When called, newblock() allocates memory using PyMem_Malloc() and does not initialize it:

static block *
newblock(Py_ssize_t len) {
    block *b;
    if (len >= MAX_DEQUE_LEN) {
        PyErr_SetString(PyExc_OverflowError,
                        "cannot add more blocks to the deque");
        return NULL;
    }
    if (numfreeblocks) {
        numfreeblocks--;
        return freeblocks[numfreeblocks];
    }
    b = PyMem_Malloc(sizeof(block)); <<<< Memory allocation.
    if (b != NULL) {
        return b; <<<< Buffer returned without initialization.
    }
    PyErr_NoMemory();
    return NULL;
}

Because PyMem_Malloc does not initialize the memory, the block may contain garbage data. In some cases, this can lead to memory corruption which could be exploitable to achieve code execution. The following exception analysis is an example of EIP corruption:

 *******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** The OS name list needs to be updated! Unknown Windows version: 10.0 ***

FAULTING_IP:
python35!PyUnicode_Type+0
696f60d8 a800            test    al,0

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 696f60d8 (python35!PyUnicode_Type)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000008
   Parameter[1]: 696f60d8
Attempt to execute non-executable address 696f60d8

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=696f60d8 ebx=00000002 ecx=00d9492c edx=00000002 esi=019b4e58 edi=0337b970
eip=696f60d8 esp=00bcf7dc ebp=00bcf7fc iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
python35!PyUnicode_Type:
696f60d8 a800            test    al,0

PROCESS_NAME:  pythonw.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000008

EXCEPTION_PARAMETER2:  696f60d8

WRITE_ADDRESS:  696f60d8

FOLLOWUP_IP:
python35!PyUnicode_Type+0
696f60d8 a800            test    al,0

FAILED_INSTRUCTION_ADDRESS:
python35!PyUnicode_Type+0
696f60d8 a800            test    al,0

APP:  pythonw.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

FAULTING_THREAD:  000009dc

DEFAULT_BUCKET_ID:  SOFTWARE_NX_FAULT_CODE

PRIMARY_PROBLEM_CLASS:  SOFTWARE_NX_FAULT_CODE

BUGCHECK_STR:  APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_SOFTWARE_NX_FAULT_FALSE_POSITIVE

LAST_CONTROL_TRANSFER:  from 69505ad3 to 696f60d8

STACK_TEXT:
00bcf7fc 69505ad3 00000002 00bcf840 694253fc python35!PyUnicode_Type
00bcf808 694253fc 0337b970 019b4e58 00000002 python35!PyObject_RichCompare+0x53
00bcf840 695031c3 03a1a8f0 03a21878 00f83340 python35!deque_index+0xac
00bcf85c 69564433 03a21120 03a21878 00000000 python35!PyCFunction_Call+0x113
00bcf890 695618d8 00e23a08 00000000 00000040 python35!call_function+0x303
00bcf908 6956339f 00e23a08 00000000 00f83000 python35!PyEval_EvalFrameEx+0x2318
00bcf954 6959a142 00e40f58 00000000 00000000 python35!_PyEval_EvalCodeWithName+0x82f
00bcf990 69599fd5 00e40f58 00e40f58 00bcfa5c python35!run_mod+0x42
00bcf9bc 6959904a 00f801f0 00e366f0 00000101 python35!PyRun_FileExFlags+0x85
00bcfa00 6946f037 00f801f0 00e366f0 00000001 python35!PyRun_SimpleFileExFlags+0x20a
00bcfa2c 6946f973 00bcfa5c 00000000 6ecb2100 python35!run_file+0xe7
00bcfad4 1ce31279 00000002 00f79eb0 1ce3c588 python35!Py_Main+0x913
00bcfae4 1ce3145f 1ce30000 00000000 00f71c68 pythonw!wWinMain+0x19
00bcfb30 74ed3744 7f174000 74ed3720 5c8b59d2 pythonw!__scrt_common_main_seh+0xfd
00bcfb44 775aa064 7f174000 a81800d2 00000000 kernel32!BaseThreadInitThunk+0x24
00bcfb8c 775aa02f ffffffff 775cd7c3 00000000 ntdll!__RtlUserThreadStart+0x2f
00bcfb9c 00000000 1ce3150a 7f174000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python35!PyUnicode_Type+0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python35

IMAGE_NAME:  python35.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  5598ccc2

FAILURE_BUCKET_ID:  SOFTWARE_NX_FAULT_CODE_c0000005_python35.dll!PyUnicode_Type

BUCKET_ID:  APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_SOFTWARE_NX_FAULT_FALSE_POSITIVE_BAD_IP_python35!PyUnicode_Type+0

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:software_nx_fault_code_c0000005_python35.dll!pyunicode_type

FAILURE_ID_HASH:  {aa94d074-8f9b-b618-df4f-eaad15f84370}

Followup: MachineOwner
---------

To fix the issue, it is recommended that newblock use PyMem_Calloc instead of PyMem_Malloc. A proposed patch has been attached.

Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com)

----------
files: newblock_Uninitialized_variable.patch
keywords: patch
messages: 248985
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: newblock() Uninitialized Variable
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file40224/newblock_Uninitialized_variable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Sat Aug 22 01:10:29 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 21 Aug 2015 23:10:29 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440198629.58.0.00683718556753.issue24913@psf.upfronthosting.co.za>


Changes by John Leitch <john.leitch5 at gmail.com>:


Added file: http://bugs.python.org/file40225/newblock_Uninitialized_variable.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Sat Aug 22 02:45:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Aug 2015 00:45:06 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440204306.9.0.161347691761.issue24913@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Sat Aug 22 04:45:44 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 22 Aug 2015 02:45:44 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440211544.59.0.601475682863.issue24305@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sat Aug 22 05:01:07 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 22 Aug 2015 03:01:07 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1440212467.1.0.336759619419.issue24881@psf.upfronthosting.co.za>


eryksun added the comment:

> It is not clear why the absence of _setmode(fd, os.O_BINARY)
> is not detected by tests.

It's only a problem when an existing text-mode file descriptor is passed in. For example, in text mode the CRT handles b'\x1a' as an EOF marker:

    Python 3.5.0b4 (v3.5.0b4:c0d641054635, Jul 26 2015, 07:11:12)
    [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os, _pyio
    >>> _ = open('testfile', 'wb').write(b'abc\x1adef')

    >>> fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
    >>> f = _pyio.open(fd, 'rb')
    >>> f.read()
    b'abc'
    >>> f.close()

    >>> f = _pyio.open('testfile', 'rb')
    >>> f.read()
    b'abc\x1adef'

The setmode call ensures a file descriptor is in the expected binary mode:

    >>> import msvcrt
    >>> fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
    >>> old_mode = msvcrt.setmode(fd, os.O_BINARY)
    >>> old_mode == os.O_TEXT
    True
    >>> f = _pyio.open(fd, 'rb')
    >>> f.read()
    b'abc\x1adef'

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Sat Aug 22 08:45:10 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Sat, 22 Aug 2015 06:45:10 +0000
Subject: [issue24914] Python: Not just OO style but this is not mentioned on
 python.org or in FAQ
Message-ID: <1440225910.92.0.539487452884.issue24914@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

Just read http://www.ibmsystemsmag.com/ibmi/developer/general/different-world-python/?utm_campaign=ibm-enews&utm_medium=email&utm_source=ibmi-jul22-2015?&utm_content=exclusive1-headline

It states that they could have had an officially supported version of Python on that IBM platform much earlier but for this:

> "The second was that everything we read on Python, and all the examples we encountered, led us to believe that it was a completely object oriented (OO) language"

They may have used it earlier had they known then that Python can be written in a procedural style they having no love of Java's OO, but being able to use PHP and access PHP's OO bits.

Looking again on python.org, the examples are not OO, but when you delve down, say to the FAQ - it gives the mistaken impression that OO is the _only_ style of programming supported: https://docs.python.org/2/faq/general.html#what-is-python

Somehow we need to explain that OO is an implementation style, but the language allows code to be written in just as much - or as little, of proceedural/OO/functional styles as the programmer is comfortable with.

----------
assignee: docs at python
components: Documentation
messages: 248987
nosy: Paddy McCarthy, docs at python
priority: normal
severity: normal
status: open
title: Python: Not just OO style but this is not mentioned on python.org or in FAQ
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24914>
_______________________________________

From report at bugs.python.org  Sat Aug 22 16:41:42 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 22 Aug 2015 14:41:42 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
Message-ID: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>


New submission from Alecsandru Patrascu:

Hi All,

This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation.

I would like to submit a request to turn-on Profile Guided Optimization or PGO as the default build option for Python (both 2.7 and 3.6), given its performance benefits on a wide variety of workloads and hardware.  For instance, as shown from attached sample performance results from the Grand Unified Python Benchmark, >20% speed up was observed.  In addition, we are seeing 2-9% performance boost from OpenStack/Swift where more than 60% of the codes are in Python 2.7. Our analysis indicates the performance gain was mainly due to reduction of icache misses and CPU front-end stalls.

Attached is the Makefile patches that modify the all build target and adds a new one called "disable-profile-opt". We built and tested this patch for Python 2.7 and 3.6 on our Linux machines (CentOS 7/Ubuntu Server 14.04, Intel Xeon Haswell/Broadwell with 18/8 cores).  We use "regrtest" suite for training as it provides the best performance improvement.  Some of the test programs in the suite may fail which leads to build fail.  One solution is to disable the specific failed test using the "-x " flag (as shown in the patch)

Steps to apply the patch: 
1.  hg clone https://hg.python.org/cpython cpython 
2.  cd cpython 
3.  hg update 2.7 (needed for 2.7 only) 
4.  Copy *.patch to the current directory 
5.  patch < python2.7-pgo.patch (or patch < python3.6-pgo.patch)
6.  ./configure 
7.  make

To disable PGO
7b. make disable-profile-opt

In the following, please find our sample performance results from latest XEON machine, XEON Broadwell EP.  
Hardware (HW):      Intel XEON (Broadwell) 8 Cores

BIOS settings:      Intel Turbo Boost Technology: false
                    Hyper-Threading: false
                
Operating System:   Ubuntu 14.04.3 LTS trusty

OS configuration:   CPU freq set at fixed: 2.6GHz by
                        echo 2600000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
                        echo 2600000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
                    Address Space Layout Randomization (ASLR) disabled (to reduce run to run variation) by
                        echo 0 > /proc/sys/kernel/randomize_va_space
                
GCC version:        gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

Benchmark:          Grand Unified Python Benchmark (GUPB)
                    GUPB Source: https://hg.python.org/benchmarks/                    

Python2.7 results:
    Python source: hg clone https://hg.python.org/cpython cpython
    Python Source: hg update 2.7
    hg id: 0511b1165bb6 (2.7)
    hg id -r 'ancestors(.) and tag()': 15c95b7d81dc (2.7) v2.7.10
    hg --debug id -i: 0511b1165bb6cf40ada0768a7efc7ba89316f6a5
                
        Benchmarks          Speedup(%)
        simple_logging      20
        raytrace            20
        silent_logging      19
        richards            19
        chaos               16
        formatted_logging   16
        json_dump           15
        hexiom2             13
        pidigits            12
        slowunpickle        12
        django_v2           12
        unpack_sequence     11
        float               11
        mako                11
        slowpickle          11
        fastpickle          11
        django              11
        go                  10
        json_dump_v2        10
        pathlib             10
        regex_compile       10
        pybench             9.9
        etree_process       9
        regex_v8            8
        bzr_startup         8
        2to3                8
        slowspitfire        8
        telco               8
        pickle_list         8
        fannkuch            8
        etree_iterparse     8
        nqueens             8
        mako_v2             8
        etree_generate      8
        call_method_slots   7
        html5lib_warmup     7
        html5lib            7
        nbody               7
        spectral_norm       7
        spambayes           7
        fastunpickle        6
        meteor_contest      6
        chameleon           6
        rietveld            6
        tornado_http        5
        unpickle_list       5
        pickle_dict         4
        regex_effbot        3
        normal_startup      3
        startup_nosite      3
        etree_parse         2
        call_method_unknown 2
        call_simple         1
        json_load           1
        call_method         1

Python3.6 results
    Python source: hg clone https://hg.python.org/cpython cpython    
    hg id: 96d016f78726 tip
    hg id -r 'ancestors(.) and tag()': 1a58b1227501 (3.5) v3.5.0rc1
    hg --debug id -i: 96d016f78726afbf66d396f084b291ea43792af1

                        
        Benchmark           Speedup(%)
        fastunpickle        22.94
        fastpickle          21.67
        json_load           17.64
        simple_logging      17.49
        meteor_contest      16.67
        formatted_logging   15.33
        etree_process       14.61
        raytrace            13.57
        etree_generate      13.56
        chaos               12.09
        hexiom2             12
        nbody               11.88
        json_dump_v2        11.24
        richards            11.02
        nqueens             10.96
        fannkuch            10.79
        go                  10.77
        float               10.26
        regex_compile       9.8
        silent_logging      9.63
        pidigits            9.58
        etree_iterparse     9.48
        2to3                8.44
        regex_v8            8.09
        regex_effbot        7.88
        call_simple         7.63
        tornado_http        7.38
        etree_parse         4.92
        spectral_norm       4.72
        normal_startup      4.39
        telco               3.88
        startup_nosite      3.7
        call_method         3.63
        unpack_sequence     3.6
        call_method_slots   2.91
        call_method_unknown 2.59
        iterative_count     0.45
        threaded_count      -2.79


Thank you,
Alecsandru

----------
components: Build
files: python2.7-3.6-pgo.zip
messages: 248988
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: Profile Guided Optimization active by-default
type: performance
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40226/python2.7-3.6-pgo.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:52:34 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 22 Aug 2015 17:52:34 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
Message-ID: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

sysconfig currently calculates various formats of the Python version number by chopping up the sys.version string. This has a FIXME by it in the code, because the the format of sys.version is not guaranteed.

With this patch, the config variables 'py_version', 'py_version_short' and 'py_version_nodot' are instead generated from sys.version_info, which has a specified structure:
https://docs.python.org/3/library/sys.html#sys.version_info

One piece of information is lost by this change: after a pre-release, a + is added to the version string - e.g. '3.5.0b4+' means an unreleased version somewhere after 3.5.0b4. I can't find any structured representation of this information, so 'py_version' no longer contains it. I'm not sure whether it matters: I can't find anything using the 'py_version' config variable.

----------
components: Library (Lib)
files: sysconfig-version-fixme.patch
keywords: patch
messages: 248989
nosy: takluyver
priority: normal
severity: normal
status: open
title: In sysconfig, don't rely on sys.version format
Added file: http://bugs.python.org/file40227/sysconfig-version-fixme.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:06:40 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sat, 22 Aug 2015 18:06:40 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1440266800.86.0.0721953869192.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Update: 
I found this bug report (https://bugs.python.org/issue23786) and re-compiled python with -mno-unaligned-access as mentioned. test_hash still throws a bus error.

Back to drawing board....suggestions welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:56:21 2015
From: report at bugs.python.org (Konstantin Molchanov)
Date: Sat, 22 Aug 2015 18:56:21 +0000
Subject: [issue24754] argparse add_argument with action="store_true",
 type=bool should not crash
In-Reply-To: <1438250218.94.0.699008040775.issue24754@psf.upfronthosting.co.za>
Message-ID: <1440269781.21.0.0253431154956.issue24754@psf.upfronthosting.co.za>


Konstantin Molchanov added the comment:

Although I agree that specifying type with store_true or store_false is unnecessary, this shouldn't really be an error like this. Why not just ignore type if it can't be utilized?

The error message implies the usage of add_argument is erroneous, however it is fully compatible with the spec give in the docs.

Alternatively, the docs should be updated.

----------
nosy: +moigagoo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24754>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:26:48 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 22 Aug 2015 19:26:48 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440271608.03.0.803945245397.issue24915@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Please upload your patches as separate, uncompressed files for review.

PGO was already proposed here, but nothing came out of it:

https://bugs.python.org/issue17781

I suggest rejecting that old ticket and sticking with this one since it has an actual patch.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:27:53 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 22 Aug 2015 19:27:53 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440271673.36.0.792844011102.issue17781@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Issue 24915 suggests PGO and comes with an actual patch. I suggest rejecting this ticket as too broad.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:29:52 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Aug 2015 19:29:52 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440271792.34.0.690328825235.issue17781@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

LTO (Link-Time Optimization) is not the same as PGO, though I guess it can take advantage of PGO for its heuristics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:47:42 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sat, 22 Aug 2015 19:47:42 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1440266800.86.0.0721953869192.issue23496@psf.upfronthosting.co.za>
Message-ID: <0E401C0A-486A-436C-9DC8-5E01C8D137CA@gmail.com>


Ryan Gonzalez added the comment:

I'm assuming gdb still doesn't work?

On August 22, 2015 1:06:41 PM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>Update: 
>I found this bug report (https://bugs.python.org/issue23786) and
>re-compiled python with -mno-unaligned-access as mentioned. test_hash
>still throws a bus error.
>
>Back to drawing board....suggestions welcome.
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:06:53 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sat, 22 Aug 2015 20:06:53 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <0E401C0A-486A-436C-9DC8-5E01C8D137CA@gmail.com>
Message-ID: <A8014005-E0A6-43C9-B9B5-A1A208173058@gmail.com>


Cyd Haselton added the comment:

On August 22, 2015 2:47:42 PM CDT, Ryan Gonzalez <report at bugs.python.org> wrote:
>
>Ryan Gonzalez added the comment:
>
>I'm assuming gdb still doesn't work?

It does. I just don't know it well enough to know if the errors are something I'm doing wrong or something the program is doing wrong.

Basically I'm running
gdb
file ./python
set args -m test
set sysroot /path/to/sysroot
run

and examining/posting the results.  Which are confusing to me because, again, don't know it well enough.
>
>On August 22, 2015 1:06:41 PM CDT, Cyd Haselton
><report at bugs.python.org> wrote:
>>
>>Cyd Haselton added the comment:
>>
>>Update: 
>>I found this bug report (https://bugs.python.org/issue23786) and
>>re-compiled python with -mno-unaligned-access as mentioned. test_hash
>>still throws a bus error.
>>
>>Back to drawing board....suggestions welcome.
>>
>>----------
>>
>>_______________________________________
>>Python tracker <report at bugs.python.org>
>><http://bugs.python.org/issue23496>
>>_______________________________________
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:28:17 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sat, 22 Aug 2015 20:28:17 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <A8014005-E0A6-43C9-B9B5-A1A208173058@gmail.com>
Message-ID: <CAO41-mPN9YRMkW91-aG+KQ3B03n5SZvSivnfzU=-ETLF7pEy=A@mail.gmail.com>


Ryan Gonzalez added the comment:

After typing 'run', enter 'bt' and post the results.

On Sat, Aug 22, 2015 at 3:06 PM, Cyd Haselton <report at bugs.python.org>
wrote:

>
> Cyd Haselton added the comment:
>
> On August 22, 2015 2:47:42 PM CDT, Ryan Gonzalez <report at bugs.python.org>
> wrote:
> >
> >Ryan Gonzalez added the comment:
> >
> >I'm assuming gdb still doesn't work?
>
> It does. I just don't know it well enough to know if the errors are
> something I'm doing wrong or something the program is doing wrong.
>
> Basically I'm running
> gdb
> file ./python
> set args -m test
> set sysroot /path/to/sysroot
> run
>
> and examining/posting the results.  Which are confusing to me because,
> again, don't know it well enough.
> >
> >On August 22, 2015 1:06:41 PM CDT, Cyd Haselton
> ><report at bugs.python.org> wrote:
> >>
> >>Cyd Haselton added the comment:
> >>
> >>Update:
> >>I found this bug report (https://bugs.python.org/issue23786) and
> >>re-compiled python with -mno-unaligned-access as mentioned. test_hash
> >>still throws a bus error.
> >>
> >>Back to drawing board....suggestions welcome.
> >>
> >>----------
> >>
> >>_______________________________________
> >>Python tracker <report at bugs.python.org>
> >><http://bugs.python.org/issue23496>
> >>_______________________________________
> >
> >----------
> >
> >_______________________________________
> >Python tracker <report at bugs.python.org>
> ><http://bugs.python.org/issue23496>
> >_______________________________________
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23496>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:38:03 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Aug 2015 20:38:03 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1440275883.19.0.232238967748.issue4709@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Sun Aug 23 01:39:20 2015
From: report at bugs.python.org (John Leitch)
Date: Sat, 22 Aug 2015 23:39:20 +0000
Subject: [issue24917] time_strftime() Buffer Over-read
Message-ID: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.5 suffers from a vulnerability caused by the behavior of the time_strftime() function. When called, the function loops over the format string provided, using strchr to search for each instance of '%'. After finding a '%', it continues to search two characters ahead, assuming that each instance is the beginning of a well formed format string token.

However, if a string ends with '%', this logic will result in a call to strchr that reads off the end of the format string buffer:

    /* check that the format string contains only valid directives */
    for(outbuf = strchr(fmt, '%'); <<<< Assuming fmt ends with a '%', this will return a pointer to the end of the string.
        outbuf != NULL;
        outbuf = strchr(outbuf+2, '%')) <<<< Once outbuf is pointing to the end of the string, outbuf+2 skips
    {                                        past the null terimnator, leading to a buffer over-read.
        if (outbuf[1]=='#')
            ++outbuf; /* not documented by python, */
        if ((outbuf[1] == 'y') && buf.tm_year < 0)
        {
            PyErr_SetString(PyExc_ValueError,
                        "format %y requires year >= 1900 on Windows");
            Py_DECREF(format);
            return NULL;
        }
    }

In some applications, it may be possible to exploit this behavior to disclose the contents of adjacent memory. The buffer over-read can be observed by running the following script:

from time import *
strftime("AA%"*0x10000)

Which, depending on the arrangement of memory, may produce an exception such as this:

0:000> g
(20b8.18d4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=ffffffff ebx=52c1a6a0 ecx=00000000 edx=08ef3000 esi=08ec2fe8 edi=08ec2ff8
eip=52d254f3 esp=004cf9d4 ebp=004cfa58 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
python35!strchr+0x33:
52d254f3 f30f6f0a        movdqu  xmm1,xmmword ptr [edx] ds:002b:08ef3000=????????????????????????????????
0:000> db edx-0x10
08ef2ff0  41 25 41 41 25 41 41 25-00 d0 d0 d0 d0 d0 d0 d0  A%AA%AA%........
08ef3000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08ef3060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> k5
ChildEBP RetAddr  
004cf9d0 52c1a7f6 python35!strchr+0x33 [f:\dd\vctools\crt\vcruntime\src\string\i386\strchr_sse.inc @ 75]
004cfa58 52c832d3 python35!time_strftime+0x156 [c:\build\cpython\modules\timemodule.c @ 615]
004cfa74 52ce442f python35!PyCFunction_Call+0x113 [c:\build\cpython\objects\methodobject.c @ 109]
004cfaa8 52ce18ec python35!call_function+0x2ff [c:\build\cpython\python\ceval.c @ 4651]
004cfb20 52ce339f python35!PyEval_EvalFrameEx+0x232c [c:\build\cpython\python\ceval.c @ 3184]

To fix this issue, it is recommended that time_strftime() be updated to check outputbuf[1] for null in the body of the format string directive validation loop. A proposed patch is attached.

Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com)

----------
files: time_strftime_Buffer_Over-read.patch
keywords: patch
messages: 248998
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: time_strftime() Buffer Over-read
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file40228/time_strftime_Buffer_Over-read.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24917>
_______________________________________

From report at bugs.python.org  Sun Aug 23 01:40:44 2015
From: report at bugs.python.org (John Leitch)
Date: Sat, 22 Aug 2015 23:40:44 +0000
Subject: [issue24917] time_strftime() Buffer Over-read
In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za>
Message-ID: <1440286844.31.0.907206257295.issue24917@psf.upfronthosting.co.za>


Changes by John Leitch <john.leitch5 at gmail.com>:


Added file: http://bugs.python.org/file40229/time_strftime_Buffer_Over-read.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24917>
_______________________________________

From report at bugs.python.org  Sun Aug 23 03:45:49 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Aug 2015 01:45:49 +0000
Subject: [issue24914] Python: Not just OO style but this is not mentioned on
 python.org or in FAQ
In-Reply-To: <1440225910.92.0.539487452884.issue24914@psf.upfronthosting.co.za>
Message-ID: <1440294349.1.0.602377094732.issue24914@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The problem is that technically Python is an object-oriented language as everything is a language (which is what makes Python more OO than Java). Having said that, you can use other programming styles. I'm fine with clarifying the entry in the FAQ that Python can be written in other programming styles such as procedural or functional. If you have suggested wording, Paddy, please feel free to propose a patch.

----------
nosy: +brett.cannon
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24914>
_______________________________________

From report at bugs.python.org  Sun Aug 23 03:47:49 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Aug 2015 01:47:49 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440294469.48.0.178876193673.issue24915@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 07:36:29 2015
From: report at bugs.python.org (chris laws)
Date: Sun, 23 Aug 2015 05:36:29 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1440308189.58.0.580907434724.issue23972@psf.upfronthosting.co.za>


chris laws added the comment:

I have updated the patch to address comments raised by haypo. 

An exception is now raised if reuse_port is explicitly used and the platform does not support SOREUSEPORT. The docs have also been updated to make it more explicit that this feature is not supported on Windows.

----------
Added file: http://bugs.python.org/file40230/23972_cjl_v002.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23972>
_______________________________________

From report at bugs.python.org  Sun Aug 23 08:52:07 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Sun, 23 Aug 2015 06:52:07 +0000
Subject: [issue24914] Python: Not just OO style but this is not mentioned on
 python.org or in FAQ
In-Reply-To: <1440225910.92.0.539487452884.issue24914@psf.upfronthosting.co.za>
Message-ID: <1440312727.77.0.353824948397.issue24914@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

OK, here's a suggested re-wording:

"Python is an interpreted, interactive, object-oriented programming language that also supports programming in procedural and functional styles. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes; but statements are not required to be contained in class definitions and functions are first class - being able to be composed, returned from other functions and be a member of other container types such as dicts, sets, and lists."

If that is too long,an alternative would be to delete my addition to the last sentence from "; but classes are not ..." Leaving it to the reader to research just how procedural and functional Python can be. (Where should a programmer, but newbie-to-Python look)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24914>
_______________________________________

From report at bugs.python.org  Sun Aug 23 08:52:09 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 06:52:09 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440312729.91.0.90171581429.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40231/python2.7-pgo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 08:52:39 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 06:52:39 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440312759.55.0.347020177564.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40232/python3.6-pgo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 08:54:09 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 06:54:09 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440312849.63.0.411668355917.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Removed file: http://bugs.python.org/file40226/python2.7-3.6-pgo.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 08:56:55 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 06:56:55 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440313015.11.0.77284055997.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I added the patches as individual files and removed the zip file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 11:41:05 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sun, 23 Aug 2015 09:41:05 +0000
Subject: [issue22140] "python-config --includes" returns a wrong path (double
 prefix)
In-Reply-To: <1407245312.64.0.904100539745.issue22140@psf.upfronthosting.co.za>
Message-ID: <1440322865.63.0.0602303688357.issue22140@psf.upfronthosting.co.za>


Alexey Gorshkov added the comment:

I don't understand: Why python-config needs to seek "realpath"? Why python-config is trying to be smarter than one who starts ./configure script?

As so, the right thing to this, is remove "smart" parts from python-config. But as for fast hack in to this is replace line 'prefix_real=$(installed_prefix "$0")' with 'prefix_real=$prefix_build'.

----------
nosy: +animus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22140>
_______________________________________

From report at bugs.python.org  Sun Aug 23 15:19:50 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 23 Aug 2015 13:19:50 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440335990.48.0.306475278141.issue24915@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

Is this supposed to work on Macs using Apple's version of gcc? I've got the latest version of Yosemite and XCode, and am getting these warnings when trying to build 2.7:

clang: warning: argument unused during compilation: '-fprofile-generate'

Should this be enabled using a configure check? Perhaps gcc/clang supports this but spells the feature differently. gcc --help tells me:

% gcc --help | egrep profile
  -fprofile-instr-generate
  -fprofile-instr-use=<value>
                          Use instrumentation data for profile-guided optimization
  -fprofile-sample-use=<value>
                          Enable sample-based profile guided optimizations

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 16:03:58 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 23 Aug 2015 14:03:58 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440338638.43.0.255290065452.issue8987@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I'm not upset by the idea of monkey patching in Setuptools for vetting certain techniques. I've even considered having Setuptools adopt distutils entirely. Today I filed https://bitbucket.org/pypa/setuptools/issues/417/adopt-distutils to seed the discussion on that possibility. For the sake of this discussion, I would happily accept a pull request to supply the forward-compatible version of _nt_quote_args (or similar), allowing a window for other libraries to make the switch against versions of Python supported by Setuptools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sun Aug 23 17:00:42 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 15:00:42 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440342042.14.0.0581059942758.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

The patches are tested on Linux machines, with GNU GCC >4.8.3. From your output I see that you are using the CLANG compiler. CLANG uses a different set of flags for PGO that are not compatible with GCC's, therefore the compilation will fail. Can you please use the GNU GCC compiler to test the patches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 17:02:58 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Aug 2015 15:02:58 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1440342177.99.0.809063685946.issue8987@psf.upfronthosting.co.za>


Steve Dower added the comment:

I notice you say "adopt" rather than "vendor" - effectively removing distutils from the stdlib?

It could work, but to really be able to move distutils forward we need some sort of side-by-side versioning, such that a package can declare which version of distutils is required, preferably without needing to download old versions on the fly when building. I'm sure it's possible but haven't got a complete vision yet.

Maybe it's as simple as having flags that setup scripts enable before they build?

import distutils
distutils.enable(distutils.flags.smart_quote_args)

That way we can actually change things without breaking old build scripts. Should be just as feasible if setuptools adopts distutils, but there'll probably be opposition from elsewhere along the lines of including "core" functionality in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sun Aug 23 17:03:36 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 23 Aug 2015 15:03:36 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440342216.77.0.55962388055.issue24915@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

It is executed using the gcc command:

% gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -fprofile-generate -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c
clang: warning: argument unused during compilation: '-fprofile-generate'
% type gcc
gcc is /usr/bin/gcc

I have no idea if you can even use something other than clang on Macs now. In any case, the default compiler should work to build Python out of the box, if necessary, by checking things during configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 18:10:51 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 23 Aug 2015 16:10:51 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1440346251.91.0.286168562183.issue19065@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I'm -1 because I believe that ultimately, adapters and converters were a mistake to add to pysqlite. That's why I deprecated them in pysqlite 2.8.0.

Do you know what would be the correct step to propose a deprecation in the sqlite3 module of Python proper? Is a PEP necessary?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Sun Aug 23 18:16:33 2015
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 23 Aug 2015 16:16:33 +0000
Subject: [issue16379] SQLite error code not exposed to python
In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>
Message-ID: <1440346593.11.0.554108565538.issue16379@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I propose to also set the SQLite extended error code if this is implemented.

What's the reasoning behind offering a error code to name mapping? This seem problematic to me. In case a newer SQLite version introduces a new error code, this error code cannot be found in the mapping. I propose to leave this out in order to not have this problem.

Otherwise we will have people depending on any error code being able to be found in this mapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16379>
_______________________________________

From report at bugs.python.org  Sun Aug 23 19:01:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Aug 2015 17:01:35 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440349295.37.0.579743186018.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a patch that adds the C version of the frame skipping. Unfortunately it fails under test_threading, test_subprocess, test_multiprocessing_spawn. It's due to is_internal_frame() somehow although setting a breakpoint in gdb in that function never triggers. The return value is -11 from the interpreter and I don't remember what that represents.

----------
Added file: http://bugs.python.org/file40233/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sun Aug 23 19:09:47 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 23 Aug 2015 17:09:47 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1440349787.11.0.810558039604.issue9262@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I've put together a standalone tabs widget (mostly done) based on Tk canvas widget, that emulates the behaviour of TextMate's tabs. I was able to modify Roger's extension to use this widget. See attached screenshot newtabs.png (tabs area is fully functioning, bottom debug area is just UI).

----------
Added file: http://bugs.python.org/file40234/newtabs.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Sun Aug 23 19:34:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Aug 2015 17:34:36 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440351275.99.0.431760604812.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I did an initial code review on the 3.6 patch.

What would it take to add clang support for PGO? Is it simply using different flags that configure can set in the generated Makefile? Or is it more involved and would require maintaining two separate compile lines in the Makefile?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 20:23:53 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 23 Aug 2015 18:23:53 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440354233.89.0.196675595046.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I received the review and will post new patch versions as soon as I update them. 

Regarding PGO on clang, I will need a bit more time to edit the Makefile and will post it just for clang, to be easier for us to see the differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 23 20:28:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Aug 2015 18:28:10 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <20150823182807.67848.22866@psf.io>


Roundup Robot added the comment:

New changeset 4432c441b639 by Raymond Hettinger in branch 'default':
Issue #24878: Fix typos and line wrap
https://hg.python.org/cpython/rev/4432c441b639

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Sun Aug 23 20:28:24 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Aug 2015 18:28:24 +0000
Subject: [issue24878] Add docstrings to selected named tuples
In-Reply-To: <1439785738.06.0.883729285767.issue24878@psf.upfronthosting.co.za>
Message-ID: <1440354504.96.0.475444784317.issue24878@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Petr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24878>
_______________________________________

From report at bugs.python.org  Sun Aug 23 21:44:17 2015
From: report at bugs.python.org (Ilya Kulakov)
Date: Sun, 23 Aug 2015 19:44:17 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1440359057.4.0.278990621622.issue17797@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Steve,

What's going to be the required msvc compiler for 3.5 on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Sun Aug 23 22:20:07 2015
From: report at bugs.python.org (asldkjfn)
Date: Sun, 23 Aug 2015 20:20:07 +0000
Subject: [issue24918] Docs layout bug
Message-ID: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>


New submission from asldkjfn:

Green bars cover yellow text box. 
https://docs.python.org/2/faq/windows.html

----------
assignee: docs at python
components: Documentation
messages: 249018
nosy: docs at python, reag
priority: normal
severity: normal
status: open
title: Docs layout bug
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24918>
_______________________________________

From report at bugs.python.org  Sun Aug 23 22:26:43 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 23 Aug 2015 20:26:43 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440361603.92.0.980188726022.issue24912@psf.upfronthosting.co.za>


Mark Shannon added the comment:

If there is another issue for this, then it doesn't seem to be a release blocker. I think it should be.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 23 22:59:59 2015
From: report at bugs.python.org (Carol Willing)
Date: Sun, 23 Aug 2015 20:59:59 +0000
Subject: [issue24918] Docs layout bug
In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>
Message-ID: <1440363599.59.0.786459956611.issue24918@psf.upfronthosting.co.za>


Carol Willing added the comment:

The highlighting of code box extends beyond the bounds of the box to the far right of the page. A screenshot is attached as an example. The behavior occurs on all versions (3.2+, 2.7.x) except 2.6.

Thanks for reporting this issue.

----------
nosy: +willingc
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40235/Screenshot 2015-08-23 16.55.34.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24918>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:16:39 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 23 Aug 2015 21:16:39 +0000
Subject: [issue20851] Update devguide to cover testing from a tarball
In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za>
Message-ID: <1440364599.88.0.205971953444.issue20851@psf.upfronthosting.co.za>


Robert Collins added the comment:

Possibly silly q: how does one /make/ a Python release tarball? 'make dist' which is the autoconf standard complains that it has no such target...

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20851>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:42:55 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 23 Aug 2015 21:42:55 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1440366175.94.0.97460957352.issue17797@psf.upfronthosting.co.za>


eryksun added the comment:

The 3.5 build uses MSVC 14 (VS 2015):

https://docs.python.org/3.5/using/windows.html#compiling-python-on-windows
https://hg.python.org/cpython/file/3.5/PCbuild/readme.txt

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:47:42 2015
From: report at bugs.python.org (=?utf-8?q?Jan_Studen=C3=BD?=)
Date: Sun, 23 Aug 2015 21:47:42 +0000
Subject: [issue24919] Use user shell in subprocess
Message-ID: <1440366462.7.0.365898747019.issue24919@psf.upfronthosting.co.za>


New submission from Jan Studen?:

According to POSIX specification the pathname of user shell is stored in SHELL (environmental variable, see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08) so I think that is good idea to use that pathname instead of hardcoded one.
Change is only in one line of subprocess package to use SHELL environmental variable and use hardcoded shell pathname as fallback.

lines 1431-1433
```
            if shell:
                args = ["/bin/sh", "-c"] + args
                if executable:
```

to

```
            if shell:
                args = [os.environ.get("SHELL","/bin/sh"), "-c"] + args
                if executable:
```

----------
components: Library (Lib)
messages: 249023
nosy: Jan Studen?
priority: normal
severity: normal
status: open
title: Use user shell in subprocess
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24919>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:21:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2015 22:21:38 +0000
Subject: [issue20851] Update devguide to cover testing from a tarball
In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za>
Message-ID: <1440368498.32.0.644017462988.issue20851@psf.upfronthosting.co.za>


R. David Murray added the comment:

How to do it is part of PEP 101 (https://www.python.org/dev/peps/pep-0101/).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20851>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:30:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2015 22:30:27 +0000
Subject: [issue24919] Use user shell in subprocess
In-Reply-To: <1440366462.7.0.365898747019.issue24919@psf.upfronthosting.co.za>
Message-ID: <1440369027.45.0.342167660161.issue24919@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the suggestion, but that would make programs using subprocess non-portable.  There is an open issue to use the *default* shell instead of hard coding it (because the sh-alike is not at /bin/sh on, eg, Android), but using the user shell would break lots of programs.  Your suggestion was brought up by a core dev (and rejected) in that issue (issue 16255)

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> subrocess.Popen needs /bin/sh but Android only has /system/bin/sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24919>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:47:49 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 23 Aug 2015 22:47:49 +0000
Subject: [issue20851] Update devguide to cover testing from a tarball
In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za>
Message-ID: <1440370069.67.0.4923967662.issue20851@psf.upfronthosting.co.za>


Larry Hastings added the comment:

To make the tarballs, I use the "release.py" script from here:

https://hg.python.org/release

and run "release.py --export <versionnumber>".  I haven't peeked inside the black box to see how the sausage is made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20851>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:52:36 2015
From: report at bugs.python.org (Bryce Darling)
Date: Sun, 23 Aug 2015 22:52:36 +0000
Subject: [issue24917] time_strftime() Buffer Over-read
In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za>
Message-ID: <1440370356.88.0.13149494161.issue24917@psf.upfronthosting.co.za>


Changes by Bryce Darling <darlingbryce at gmail.com>:


----------
nosy: +brycedarling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24917>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:52:46 2015
From: report at bugs.python.org (Bryce Darling)
Date: Sun, 23 Aug 2015 22:52:46 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440370366.18.0.42413559642.issue24913@psf.upfronthosting.co.za>


Changes by Bryce Darling <darlingbryce at gmail.com>:


----------
nosy: +brycedarling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:03:32 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 23 Aug 2015 23:03:32 +0000
Subject: [issue24919] Use user shell in subprocess
In-Reply-To: <1440366462.7.0.365898747019.issue24919@psf.upfronthosting.co.za>
Message-ID: <1440371012.48.0.795195403533.issue24919@psf.upfronthosting.co.za>


eryksun added the comment:

I expect Popen's shell=True option to use the same shell as os.system.  The POSIX spec for the [system function][1] requires running sh, as follows:

    execl(<shell path>, "sh", "-c", command, (char *)0);

glibc uses "/bin/sh" for the shell path. Modifying the SHELL environment variable doesn't affect the behavior of os.system. I would be surprised if Popen's shell=True had been designed like that. Thankfully it's too late to change this since it could break existing code. ;-)

The story is different on Windows. The CRT's system() prefers the shell that's set in the ComSpec environment variable. So on Windows Popen uses os.environ.get("COMSPEC", "cmd.exe").

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24919>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:16:41 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 23 Aug 2015 23:16:41 +0000
Subject: [issue24919] Use user shell in subprocess
In-Reply-To: <1440366462.7.0.365898747019.issue24919@psf.upfronthosting.co.za>
Message-ID: <1440371801.14.0.399813832756.issue24919@psf.upfronthosting.co.za>


eryksun added the comment:

Here's the rationale given for ignoring SHELL in POSIX system():

    One reviewer suggested that an implementation of system() might
    want to use an environment variable such as SHELL to determine
    which command interpreter to use. The supposed implementation
    would use the default command interpreter if the one specified
    by the environment variable was not available. This would allow
    a user, when using an application that prompts for command lines
    to be processed using system(), to specify a different command
    interpreter. Such an implementation is discouraged. If the
    alternate command interpreter did not follow the command line
    syntax specified in the Shell and Utilities volume of
    POSIX.1-2008, then changing SHELL would render system()
    non-conforming. This would affect applications that expected the
    specified behavior from system(), and since the Shell and
    Utilities volume of POSIX.1-2008 does not mention that SHELL
    affects system(), the application would not know that it needed
    to unset SHELL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24919>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:47:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Aug 2015 23:47:16 +0000
Subject: [issue24633] README file installed into site-packages conflicts with
 package named "readme"
In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za>
Message-ID: <20150823234713.29069.66777@psf.io>


Roundup Robot added the comment:

New changeset d90a65014c42 by Robert Collins in branch 'default':
Issue #24633: site-packages/README -> README.txt.
https://hg.python.org/cpython/rev/d90a65014c42

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24633>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:48:46 2015
From: report at bugs.python.org (Caio Ariede)
Date: Sun, 23 Aug 2015 23:48:46 +0000
Subject: [issue19469] Duplicate namespace package portions (but not on Windows)
In-Reply-To: <1383285932.19.0.495289288555.issue19469@psf.upfronthosting.co.za>
Message-ID: <1440373726.59.0.132799537908.issue19469@psf.upfronthosting.co.za>


Caio Ariede added the comment:

I tried to reproduce it using Python 3.4.3 and 3.4.2. No luck.

----------
nosy: +Caio Ariede
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19469>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:50:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 23 Aug 2015 23:50:03 +0000
Subject: [issue24633] README file installed into site-packages conflicts with
 package named "readme"
In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za>
Message-ID: <1440373803.47.0.858615631568.issue24633@psf.upfronthosting.co.za>


Robert Collins added the comment:

Applied to 3.6 only (since I don't want to disrupt the 3.5 release train, and think that making packagers adjust on a point release would be mean).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24633>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:50:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 23 Aug 2015 23:50:44 +0000
Subject: [issue24168] Unittest discover fails with namespace package if the
 path contains the string same as the module name
In-Reply-To: <1431393278.14.0.705809016524.issue24168@psf.upfronthosting.co.za>
Message-ID: <1440373844.46.0.887096596283.issue24168@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24168>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:51:50 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 23 Aug 2015 23:51:50 +0000
Subject: [issue24193] Make LOGGING_FORMAT of assertLogs configurable
In-Reply-To: <1431605029.99.0.444835301939.issue24193@psf.upfronthosting.co.za>
Message-ID: <1440373910.43.0.719787208898.issue24193@psf.upfronthosting.co.za>


Robert Collins added the comment:

Parameters please, TestCase has nothing to do with this - it really shouldn't even have the method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24193>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:59:33 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 23 Aug 2015 23:59:33 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1440374373.7.0.140516844014.issue17908@psf.upfronthosting.co.za>


Robert Collins added the comment:

"say, something to run a test until failure, or to
watch for reference leaks, or to run tests in multiple processes :-))"

I think a few complimentary things.

unittest extensability currently requires a new CLI entry point for each thing. I'd like to fix that.

The actual plumbing is fairly extensible, though its not always obvious. I'd like to fix that too - without any global state getting involved.

Of the things you mention, running a given command line until failure and checking for reference leaks are both straight forward, very common requests (as is the gc check) and I'd like to see those implemented as extensions shipped in the stdlib.

Running in parallel becomes important when one is doing slow (e.g. functional) tests with unittest, and I think thats important to support. It is however much harder to do well: some of the current idioms that have snuck in (like the handling of stdout/stderr capturing without the buffer flag) are not well matched to the needs of reporting on concurrent tests to users. I'm not in any way opposed to a good implementation, but it would need to be good I think - there's not much point having a poor implementation, given the rich set of parallel test runners that are out there that already build on the unittest core (green, nose, testrepository just for starters). The only unique audience for stdlib test facilities is the stdlib itself and I think a better way to solve that is to enable the use of alternative runners for our own tests (moving them to be a little cleaner should enable that) - and then the point where it matters is really 'when buildbots would be enough faster to make a difference'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17908>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:01:46 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 00:01:46 +0000
Subject: [issue24055] unittest package-level set up & tear down module
In-Reply-To: <1429907156.24.0.517799178005.issue24055@psf.upfronthosting.co.za>
Message-ID: <1440374506.22.0.337015701535.issue24055@psf.upfronthosting.co.za>


Robert Collins added the comment:

Personally I'm very skeptical of all the multi-test setup facilties because of the very poor interactions with parallel testing that this basic approach has. But - we haven't yet brought in something sensible to let us deprecate setUpModule and setUpClass, so I could not reject it on that basis.

I'd have to see a patch or a prototype to comment on the maintainability etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24055>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:11:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Aug 2015 00:11:04 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <20150824001057.79919.69113@psf.io>


Roundup Robot added the comment:

New changeset 3256764fadae by Robert Collins in branch '2.7':
Issue #22812: Fix unittest discovery examples.
https://hg.python.org/cpython/rev/3256764fadae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22812>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:16:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Aug 2015 00:16:28 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <20150824001618.27305.8936@psf.io>


Roundup Robot added the comment:

New changeset e285606efb82 by Robert Collins in branch '3.4':
Issue #22812: Fix unittest discovery examples.
https://hg.python.org/cpython/rev/e285606efb82

New changeset 875a851b9d5a by Robert Collins in branch '3.5':
Issue #22812: Fix unittest discovery examples.
https://hg.python.org/cpython/rev/875a851b9d5a

New changeset d9ec88a1e5d6 by Robert Collins in branch 'default':
Issue #22812: Fix unittest discovery examples.
https://hg.python.org/cpython/rev/d9ec88a1e5d6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22812>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:17:41 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 00:17:41 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1440375461.35.0.373684202171.issue22812@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22812>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:19:08 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 00:19:08 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440375548.84.0.739973774826.issue2786@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Mon Aug 24 02:20:53 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 00:20:53 +0000
Subject: [issue23839] Clear caches after every test
In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za>
Message-ID: <1440375653.14.0.958272392734.issue23839@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, so this is still in the noise space - it might be useful, it might not. Do we have reports of machines failing to run the test suite (that are also usefully big enough to compile Python and use it)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23839>
_______________________________________

From report at bugs.python.org  Mon Aug 24 05:35:14 2015
From: report at bugs.python.org (Isaac Levy)
Date: Mon, 24 Aug 2015 03:35:14 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
Message-ID: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>


New submission from Isaac Levy:

OS: windows 7, python 3.4.3, tk version 8.6.1

os.get_terminal_size also fails.


>>> shutil.get_terminal_size()
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    shutil.get_terminal_size()
  File "C:\Python34\lib\shutil.py", line 1058, in get_terminal_size
    size = os.get_terminal_size(sys.__stdout__.fileno())
AttributeError: 'NoneType' object has no attribute 'fileno'
>>> os.get_terminal_size()
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    os.get_terminal_size()
ValueError: bad file descriptor

----------
components: IDLE
messages: 249039
nosy: Isaac Levy
priority: normal
severity: normal
status: open
title: shutil.get_terminal_size throws AttributeError
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Mon Aug 24 07:20:32 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 24 Aug 2015 05:20:32 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1440393632.17.0.281731302504.issue24920@psf.upfronthosting.co.za>


eryksun added the comment:

FYI, the size of the terminal associated with the C's stdout isn't related to the IDLE shell. For example, in Linux when I run IDLE from the GUI, the associated terminal size is 0x0. 

On Windows, os.get_terminal_size uses the console API GetConsoleScreenBufferInfo. This can't work given IDLE has no attached console. Also, for a GUI app the Windows C runtime leaves the standard FILE streams uninitialized to an invalid file descriptor (-1), so Python's sys.__stdout__ is None. That's why you get an AttributeError complaining that NoneType (i.e. type(None)) has no attribute 'fileno'.

Currently shutil.get_terminal_size returns the fallback size when os.get_terminal_size(sys.__stdout__.fileno()) raises NameError or OSError. I think AttributeError and ValueError should be added to this list.

----------
components: +Windows -IDLE
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Mon Aug 24 08:37:02 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 24 Aug 2015 06:37:02 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1440398222.28.0.210522834361.issue24872@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Two findings regarding the new "semi-static linking" options:

Distutils now creates libraries (.lib) that "may not be readable by subsequent versions of Visual C++" <https://msdn.microsoft.com/en-us/library/0zza0de8.aspx>.

Build times and static library sizes significantly increase to a point where it becomes impractical in some cases. For example, on my system, the zeromq package builds in 90 s on Python 3.4.3, while on Python 3.5rc1 it takes 470 s. Building HDF5 static libs with the new options takes 30 minutes (close to 100% CPU usage on 8 logical processors) compared to less than 5 minutes for the default options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:54:59 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 24 Aug 2015 08:54:59 +0000
Subject: [issue24193] Make LOGGING_FORMAT of assertLogs configurable
In-Reply-To: <1431605029.99.0.444835301939.issue24193@psf.upfronthosting.co.za>
Message-ID: <1440406499.13.0.150871294211.issue24193@psf.upfronthosting.co.za>


Michael Foord added the comment:

assertLogs is on a Python test suite helper, not TestCase itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24193>
_______________________________________

From report at bugs.python.org  Mon Aug 24 11:09:43 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 09:09:43 +0000
Subject: [issue24193] Make LOGGING_FORMAT of assertLogs configurable
In-Reply-To: <1431605029.99.0.444835301939.issue24193@psf.upfronthosting.co.za>
Message-ID: <1440407383.15.0.357241642206.issue24193@psf.upfronthosting.co.za>


Robert Collins added the comment:

I don't know if or when it was moved, but right now:

./python -m pydoc unittest.case.TestCase.assertLogs
... the docs for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24193>
_______________________________________

From report at bugs.python.org  Mon Aug 24 12:49:22 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Mon, 24 Aug 2015 10:49:22 +0000
Subject: [issue16379] SQLite error code not exposed to python
In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>
Message-ID: <1440413362.29.0.335526734336.issue16379@psf.upfronthosting.co.za>


Daniel Shahaf added the comment:

> What's the reasoning behind offering a error code to name mapping?

Allowing code that runs into an error to print the error name rather than its
numeric value.  This saves whoever reads the error message having to look it up
himself.

> his seem problematic to me. In case a newer SQLite version introduces a new
> error code, this error code cannot be found in the mapping. I propose to
> leave this out in order to not have this problem.
> 
> Otherwise we will have people depending on any error code being able to be
> found in this mapping.

Then people shouldn't depend on the mapping being complete.  Let's keep the
mapping and document that people should only use it as
`sqlite3.errorcode.get(...)`, never as `sqlite3.errorcode[...]`.

Or if that's not a good API, we could encapsulate the incompleteness of the
mapping into a small wrapper function:

   def something(errorcode):
       return sqlite3.errorcode.get(errorcode,
                                    "<sqlite3 error {!d}>".format(errorcode))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16379>
_______________________________________

From report at bugs.python.org  Mon Aug 24 13:46:32 2015
From: report at bugs.python.org (Torgil Svensson)
Date: Mon, 24 Aug 2015 11:46:32 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1440416792.19.0.0418995763347.issue16123@psf.upfronthosting.co.za>


Torgil Svensson added the comment:

I frequently use IDLE as an interactive shell to Python with the Editor attached. It's very nice for this purpose as it's lightweight and embedded in Python delivery. This is only possible with -n flag as without it each press on F5 will restart the interpreter and I lose all variables, graphs etc.

Under 2.7 (not related to this thread) I'm also unable to use interactive graphs [ ion()] in matplotlib without the -n flag.

Is there another way to run the module without restarting interpreter without the -n option?

Will 2.7 be affected by this change in the future?

----------
nosy: +Torgil Svensson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Mon Aug 24 15:08:32 2015
From: report at bugs.python.org (Joseph Schachner)
Date: Mon, 24 Aug 2015 13:08:32 +0000
Subject: [issue24921] Operator precedence table in 5.15 should be highest to
 lowest precedence
Message-ID: <1440421712.73.0.607673856693.issue24921@psf.upfronthosting.co.za>


New submission from Joseph Schachner:

We should not make people who need to read Python documentation do an extra transformation in their heads to correctly understand that in section 5.15 higher precedence is at the bottom of the table and lower precedence is at the top. Because the documentation has this table inverted from the way it is usually presented in other references, one of the top hits in a Google search shows an instructor felt the need to make a version in the usual "high to low precedence" order to show students, see:
http://www.mathcs.emory.edu/~valerie/courses/fall10/155/resources/op_precedence.html
That version is so much more comfortable for me to read, it seems almost strange, but it is true. Please consider changing section 5.15 so it would not need the top paragraph explaining that the table order is not what the reader probably expects, instead just present the table as at the link above - in the order the reader does expect - higher precedence on top, lower on the bottom. That only needs two short sentences of explanation that don't make the reader think "wait ... what?"

----------
assignee: docs at python
components: Documentation
messages: 249046
nosy: Joseph Schachner, docs at python
priority: normal
severity: normal
status: open
title: Operator precedence table in 5.15 should be highest to lowest precedence
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24921>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:09:26 2015
From: report at bugs.python.org (Vadim Kantorov)
Date: Mon, 24 Aug 2015 14:09:26 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
In-Reply-To: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>
Message-ID: <1440425366.56.0.456450879715.issue24907@psf.upfronthosting.co.za>


Vadim Kantorov added the comment:

>From my (novice) standpoint, it's very weird that importing pkg_resources in a module's __init__.py causes Python to deviate from its core module import rules / sequence.

Would you consider reporting this issue to pkg_resources's authors more appropriate?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:15:48 2015
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 24 Aug 2015 14:15:48 +0000
Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages
Message-ID: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za>


New submission from Cal Leeming:

There was a discussion/patch in #9754 [1].

This allows for multiple warning types as a tuple, e.g.;

    self.assertWarnsRegex((DeprecationWarning, RuntimeWarning), "^E1000:")

However, it does not allow testing for multiple warning messages, e.g.;

    expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001"))
    self.assertWarnsRegex(*expect)

This is slightly unexpected, as `test.support.check_warnings` allows this behaviour, e.g.

    expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001"))
    check_warnings(*expect)

Therefore I am proposing that `assertWarnsRegex` and `assertWarns` are modified to reflect the behaviour of `check_warnings`, whilst ensuring backwards compatibility. (e.g. if arg[0] is tuple, use new approach, otherwise use old approach).

[1]: http://bugs.python.org/issue9754

----------
components: Interpreter Core
messages: 249048
nosy: sleepycal
priority: normal
severity: normal
status: open
title: assertWarnsRegex doesn't allow multiple warning messages
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24922>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:36:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 14:36:24 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
In-Reply-To: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>
Message-ID: <1440426984.39.0.797503578047.issue24907@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, unless you can identify a python bug yourself.  I believe pkg_resources does a bunch of imports when it is imported, so I'm not really surprised that it has an effect on the order in which things are imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:38:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 14:38:46 +0000
Subject: [issue24907] Module location load order is not respected if
 pkg_resources is imported and a namespace is declared
In-Reply-To: <1440152333.17.0.123323582496.issue24907@psf.upfronthosting.co.za>
Message-ID: <1440427126.95.0.552706919583.issue24907@psf.upfronthosting.co.za>


R. David Murray added the comment:

To be clear: I believe it imports things that are not in the standard library, based on scanning sys.path.  But I haven't studied the code in depth, so I could be wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24907>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:43:00 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 24 Aug 2015 14:43:00 +0000
Subject: [issue24921] Operator precedence table in 5.15 should be highest to
 lowest precedence
In-Reply-To: <1440421712.73.0.607673856693.issue24921@psf.upfronthosting.co.za>
Message-ID: <1440427380.16.0.758780932555.issue24921@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yacc uses low to high.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24921>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:45:43 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 24 Aug 2015 14:45:43 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427543.04.0.446161248486.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I modified the patches after the review made by Brett (python2.7-pgo-v02.patch and python3.6-pgo-v02.patch):
- removed the call to pybench
- left the PGO steps as optional. To use it we run "make profile-opt"
- in the initial patches, I left out test_hashlib  because in our benchmarks we did not see any gain by applying PGO to the hash functions. It is not harmful and we can let it there or skip it. Nevertheless, in order not to create confusions about it, I removed that parameter from the patch.


I also added the patches for Mac exclusively (python2.7-pgo-v02-mac.patch and python3.6-pgo-v02-mac.patch). You must have llvm-profdata installed and in your path (in /Library/Developer/CommandLineTools/usr/bin/) to use it. I tested on Yosemite and it compiles fine with clang. I am working on a generic version (configure and Makefile patches) to merge all these platforms and will post them as soon as it is done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:45:52 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 24 Aug 2015 14:45:52 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427552.67.0.262982820326.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40236/python2.7-pgo-v02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:45:59 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 24 Aug 2015 14:45:59 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427559.89.0.187622919766.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40237/python3.6-pgo-v02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:46:11 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 24 Aug 2015 14:46:11 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427571.13.0.162524458438.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40238/python2.7-pgo-v02-mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:46:21 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 24 Aug 2015 14:46:21 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427581.23.0.541991123232.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40239/python3.6-pgo-v02-mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:53:01 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 24 Aug 2015 14:53:01 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440427981.59.0.250810690052.issue24915@psf.upfronthosting.co.za>


Stefan Krah added the comment:

My initial reaction is that the default should be optimized for
short build times. I would not want to type "disable-profile-opt"
every time I'm running the tests.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:55:21 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 24 Aug 2015 14:55:21 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
Message-ID: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>


New submission from Chris Hogan:

Setup.py evaluates what's given in LDFLAGS and CPPFLAGS and CFLAGS. These variables are the usual mechanism to communicate custom paths/libs/defs to a build process. However, setup.py puts system paths in front of custom paths which makes it impossible to use these variables for providing search paths to overwrite system settings.

This patch puts system paths at the end of the list to avoid this problem.  Is there a rationale for prepending system paths?

----------
components: Build
files: append-sys-paths.patch
keywords: patch
messages: 249054
nosy: christopher.hogan
priority: normal
severity: normal
status: open
title: Append system paths in setup.py instead of prepending
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file40240/append-sys-paths.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24923>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:55:43 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 24 Aug 2015 14:55:43 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440428143.66.0.588970086246.issue24915@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I see that your latest patch leaves PGO as an option, so
please ignore my previous comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:12:05 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 24 Aug 2015 15:12:05 +0000
Subject: [issue24921] Operator precedence table in 5.15 should be highest to
 lowest precedence
In-Reply-To: <1440421712.73.0.607673856693.issue24921@psf.upfronthosting.co.za>
Message-ID: <1440429125.8.0.953099730861.issue24921@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

YACC might be an outlier as well. In any case, it's probably better to use other common programming languages as a gauge of what's typical. A quick check of C, C#, C++, Java, Perl, Ruby, and Haskell shows they all list operator precedence in order from highest to lowest.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24921>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:23:09 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 24 Aug 2015 15:23:09 +0000
Subject: [issue24921] Operator precedence table in 5.15 should be highest to
 lowest precedence
In-Reply-To: <1440421712.73.0.607673856693.issue24921@psf.upfronthosting.co.za>
Message-ID: <1440429789.28.0.697251081652.issue24921@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Agreed.  I'm not sure though what the reason for this convention is:
The flow in Grammar/Grammar (low to high) feels quite natural to me.

That said, I'm +-0 on the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24921>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:25:11 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 24 Aug 2015 15:25:11 +0000
Subject: [issue24924] _posixsubprocess.c: sysconf() might not be
 async-signal-safe
Message-ID: <1440429911.87.0.822286157872.issue24924@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

The safe_get_max_fd() (in Modules/_posixsubprocess.c) is documented to be async-signal-safe.

However, this function calls sysconf().
sysconf() was guaranteed to be async-singal-safe in SUSv3, but it's no longer in SUSv4.

I don't think it's going to be a problem in practice, but it's probably worth adding a clarification comment.

----------
components: Extension Modules
messages: 249058
nosy: jwilk
priority: normal
severity: normal
status: open
title: _posixsubprocess.c: sysconf() might not be async-signal-safe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24924>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:26:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Aug 2015 15:26:07 +0000
Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za>
Message-ID: <1440429967.79.0.566647919492.issue24872@psf.upfronthosting.co.za>


Steve Dower added the comment:

Do you know where that time is being spent?

I'd guess it's in link.exe (or lib.exe) while it displays a "generating code" message. You should be able to omit the "/LTCG" option from lib.exe when building a static library, though I suspect that will push the delay into the final link step when building the DLL/PYD.

And while it takes longer, it's almost certainly doing a better job of optimizing everything (I'd guess it's probably O(N**2) with the number of obj files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24872>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:20:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:20:04 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
Message-ID: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>


New submission from R. David Murray:

Attached is a patch that enhances doctest discovery so that it can correctly report the line number for doctest errors in tests that are string values of the __test__ dictionary.  It only works if the strings are formatted as triple quoted strings, but since that is the most common case I think it is worth doing.

I don't have a test for this...I think it will require a unit test rather than adding to the doctests, since it needs to check the reported line number and other changes to test_doctest.py would change the line numbers.

----------
files: doctest_find__test__.patch
keywords: easy, patch
messages: 249060
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: Allow doctest to find line number of __test__ strings if formatted as a triple quoted string.
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40241/doctest_find__test__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:24:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:24:01 +0000
Subject: [issue24924] _posixsubprocess.c: sysconf() might not be
 async-signal-safe
In-Reply-To: <1440429911.87.0.822286157872.issue24924@psf.upfronthosting.co.za>
Message-ID: <1440433441.87.0.938647791161.issue24924@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24924>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:25:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:25:50 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1440433550.79.0.736816433317.issue24925@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file40241/doctest_find__test__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:26:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:26:01 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1440433561.77.0.298510759782.issue24925@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file40242/doctest_find__test__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:27:11 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Aug 2015 16:27:11 +0000
Subject: [issue24915] Profile Guided Optimization active by-default
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440433631.8.0.762883986221.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

the v02 patches LGTM. I'm fine with seeing those committed as-is knowing Alecsandru is actively working towards Clang support.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:28:40 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Aug 2015 16:28:40 +0000
Subject: [issue19469] Duplicate namespace package portions (but not on Windows)
In-Reply-To: <1383285932.19.0.495289288555.issue19469@psf.upfronthosting.co.za>
Message-ID: <1440433720.95.0.89763337327.issue19469@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, if someone finds a way to reproduce the bug in the next week then we will keep this open as active, else I'm closing it as out-of-date.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19469>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:42:46 2015
From: report at bugs.python.org (Vineet Kumar Doshi)
Date: Mon, 24 Aug 2015 16:42:46 +0000
Subject: [issue24926] Incorrect Example in HTMLParser.handle_comment(data)
Message-ID: <1440434566.8.0.727706131725.issue24926@psf.upfronthosting.co.za>


New submission from Vineet Kumar Doshi:

Hi,

link : https://docs.python.org/2/library/htmlparser.html#HTMLParser.HTMLParser.handle_comment

Incorrect Line : 

The content of Internet Explorer conditional comments (condcoms) will also be sent to this method, so, for <!--[if IE 9]>IE9-specific content<![endif]-->, this method will receive '[if IE 9]>IE-specific content<![endif]'.

Corrected Line :
The content of Internet Explorer conditional comments (condcoms) will also be sent to this method, so, for <!--[if IE 9]>IE9-specific content<![endif]-->, this method will receive '[if IE 9]>IE9-specific content<![endif]'.

Please correct this mistake in the docs.

Let me know, if it helps.

Thanks

Best Regards

----------
assignee: docs at python
components: Documentation
messages: 249063
nosy: docs at python, vineetkumardoshi
priority: normal
severity: normal
status: open
title: Incorrect Example in HTMLParser.handle_comment(data)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24926>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:51:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Aug 2015 16:51:41 +0000
Subject: [issue24926] Incorrect Example in HTMLParser.handle_comment(data)
In-Reply-To: <1440434566.8.0.727706131725.issue24926@psf.upfronthosting.co.za>
Message-ID: <20150824165131.76209.59825@psf.io>


Roundup Robot added the comment:

New changeset ff53dbcdc85f by R David Murray in branch '2.7':
#24926: Fix typo in example.
https://hg.python.org/cpython/rev/ff53dbcdc85f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24926>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:52:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:52:38 +0000
Subject: [issue24926] Incorrect Example in HTMLParser.handle_comment(data)
In-Reply-To: <1440434566.8.0.727706131725.issue24926@psf.upfronthosting.co.za>
Message-ID: <1440435158.93.0.82347534405.issue24926@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the report.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24926>
_______________________________________

From report at bugs.python.org  Mon Aug 24 18:56:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Aug 2015 16:56:57 +0000
Subject: [issue24926] Incorrect Example in HTMLParser.handle_comment(data)
In-Reply-To: <1440434566.8.0.727706131725.issue24926@psf.upfronthosting.co.za>
Message-ID: <20150824165654.12145.11482@psf.io>


Roundup Robot added the comment:

New changeset 6eb5e59886e1 by R David Murray in branch '3.4':
#24926: Fix typo in example.
https://hg.python.org/cpython/rev/6eb5e59886e1

New changeset ae9a9f201870 by R David Murray in branch '3.5':
Merge: #24926: Fix typo in example.
https://hg.python.org/cpython/rev/ae9a9f201870

New changeset ccde4da4d0de by R David Murray in branch 'default':
Merge: #24926: Fix typo in example.
https://hg.python.org/cpython/rev/ccde4da4d0de

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24926>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:04:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Aug 2015 17:04:49 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1440435889.53.0.330095102408.issue16123@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Torgil, thank you for the interesting feedback. I will respond to your four paragraphs slightly out of order.

1. Starting Idle with '-n', I verified that running 'print(a)' from the editor works after entering 'a=1' in the shell. The intended purpose of the editor is to edit files that run as is.  From this viewpoint, the carryover behavior is a bug.  Idle's original single process mode, now accessed with -n, only remains because communicating with a subprocess via sockets turns out to be a bit unreliable.

3. Using an editor as a extension of the shell is an alternate use.  It does not have to be tied to -n.  I have been thinking about alternate run modes and added 'run as input' to my list.  A useful version might be this: don't require a name for the editor buffer; don't restart; enter each statement at a prompt and run as if typed.  The latter would make all the code run in Shell visible and add each statement to the history list.

2. I am a bit puzzled by your matlab comment. When tkinter code is run from editor in a separate process, it successfully grabs keyboard and mouse input.  (One of the reasons for the shift from 1 to 2 processes was to disentangle user tkinter guis from the Idle tkinter gui.) On the other hand, running
  import msvcrt; k = msvcrt.kbhit()
on Windows does not work with either 1 or 2 processes because the Idle gui retains input focus.

If you want to pursue this, please open a new issue on the tracker or post to the idle-sig list or its news.gmane.org mirror gmane.comp.python.idle. In either case, say more about what 'not work' means.

4.This issue was opened before PEP 434 and before 2.7 maintenance was extended from 5 years (expiring now as 3.5 is released) to 10 years.  Hence the deprecation notice was not added to 2.7. I do not expect this to change.

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:05:17 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:05:17 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
Message-ID: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>


New submission from Jonas Obrist:

When using multiprocessing.Pool, if the function run in the pool segfaults, the program will simply hang forever. However when using multiprocessing.Process directly, it runs fine, setting the exitcode to -11 as expected.

I would expect the Pool to behave similar to Process, or at the very least an exception to be raised instead of just silently hanging forever.

I was able to reproduce this issue both on Linux (Ubuntu 15.04) and Mac OS X.

----------
files: pool_segfault.py
messages: 249068
nosy: Jonas Obrist, jnoller, sbt
priority: normal
severity: normal
status: open
title: multiprocessing.Pool hangs forever on segfault
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40243/pool_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:05:56 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:05:56 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440435956.76.0.0420628457101.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Added file: http://bugs.python.org/file40244/segfault.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:06:22 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:06:22 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440435982.92.0.389438530652.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Added file: http://bugs.python.org/file40245/setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:06:39 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:06:39 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440435999.52.0.218042106321.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Added file: http://bugs.python.org/file40246/process_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:59:57 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:59:57 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439197.31.0.269496075949.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Removed file: http://bugs.python.org/file40244/segfault.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:00:01 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 18:00:01 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439201.79.0.41355561409.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Removed file: http://bugs.python.org/file40245/setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:00:06 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 18:00:06 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439206.47.0.311345391498.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Removed file: http://bugs.python.org/file40243/pool_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:00:09 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 18:00:09 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439209.75.0.84195182615.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Removed file: http://bugs.python.org/file40246/process_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:00:30 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 18:00:30 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439230.03.0.959470964939.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Added file: http://bugs.python.org/file40247/pool_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:00:55 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 18:00:55 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440439255.69.0.181439807966.issue24927@psf.upfronthosting.co.za>


Changes by Jonas Obrist <ojiidotch at gmail.com>:


Added file: http://bugs.python.org/file40248/process_segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:19:55 2015
From: report at bugs.python.org (Alexander Oblovatniy)
Date: Mon, 24 Aug 2015 19:19:55 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
Message-ID: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>


New submission from Alexander Oblovatniy:

Hi!

Current implementation of `patch.dict` spoils order of items in `collections.OrderedDict`, because it explicitly converts passed `values` to `dict` (https://github.com/python/cpython/blob/923527f560acd43d4cc11293060900e56c7cb39b/Lib/unittest/mock.py#L1559-L1560):

```python

# support any argument supported by dict(...) constructor
self.values = dict(values)
```

Most obvious way is to check if `values` is an instance of `dict`. If it's not, then we need to convert it to dict:

```python

if not isinstance(values, dict):
    values = dict(values)

self.values = values
```

This will work for `OrderedDict`, because it's a subclass of `dict`. But this will not work for `UserDict.UserDict`, `UserDict.DictMixin`, `collections.MutableMapping`, etc., because they do not subclass `dict`. So, better way is to less strict check and look if `values` implements `dict`-like interface, e.g.:

```python

if not hasattr(values, 'update'):
    values = dict(values)

self.values = values
```

Here is a question existence of what attrs to check.

Any ideas?

Thanks!

----------
components: Library (Lib)
messages: 249069
nosy: Alexander Oblovatniy
priority: normal
severity: normal
status: open
title: mock.patch.dict spoils order of items in collections.OrderedDict
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:21:03 2015
From: report at bugs.python.org (Alexander Oblovatniy)
Date: Mon, 24 Aug 2015 19:21:03 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1440444063.69.0.238274532479.issue24928@psf.upfronthosting.co.za>


Alexander Oblovatniy added the comment:

Hi!

Current implementation of `patch.dict` spoils order of items in `collections.OrderedDict`, because it explicitly converts passed `values` to `dict` (https://github.com/python/cpython/blob/923527f560acd43d4cc11293060900e56c7cb39b/Lib/unittest/mock.py#L1559-L1560):

    # support any argument supported by dict(...) constructor
    self.values = dict(values)


Most obvious way is to check if `values` is an instance of `dict`. If it's not, then we need to convert it to dict:

    if not isinstance(values, dict):
        values = dict(values)

    self.values = values


This will work for `OrderedDict`, because it's a subclass of `dict`. But this will not work for `UserDict.UserDict`, `UserDict.DictMixin`, `collections.MutableMapping`, etc., because they do not subclass `dict`. So, better way is to less strict check and look if `values` implements `dict`-like interface, e.g.:

    if not hasattr(values, 'update'):
        values = dict(values)

    self.values = values


Here is a question existence of what attrs to check.

Any ideas?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:01:06 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Aug 2015 20:01:06 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440446466.57.0.673729241746.issue24915@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

i'm updating the title to be more accurate.

turning it on by default is likely not desirable as the makefile is primarily used by developers who are iterating on changes.

but having it use a good workload (regrtest) and work with llvm and os x are good. :)

----------
nosy: +gregory.p.smith
title: Profile Guided Optimization active by-default -> Profile Guided Optimization improvements (better training, llvm support, etc)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:01:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Aug 2015 20:01:24 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <20150824200112.19644.17630@psf.io>


Roundup Robot added the comment:

New changeset 5a9ac801f9b4 by larry in branch '3.5':
Merged in brettcannon/cpython350/3.5 (pull request #2)
https://hg.python.org/cpython/rev/5a9ac801f9b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24492>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:02:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 20:02:24 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1440446544.92.0.827544436791.issue24928@psf.upfronthosting.co.za>


R. David Murray added the comment:

Based on reading the patch.dict doct, I'm guessing that that dict call is making a copy in order to do a restore later.  Perhaps replacing the dict call with a copy call would be sufficient? (I haven't looked at the dict.patch code).

----------
nosy: +r.david.murray, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:39:09 2015
From: report at bugs.python.org (Steve Yeung)
Date: Mon, 24 Aug 2015 21:39:09 +0000
Subject: [issue24929] _strptime.TimeRE should not enforce range in regex
Message-ID: <1440452349.29.0.876134082373.issue24929@psf.upfronthosting.co.za>


New submission from Steve Yeung:

Currently, the regex in TimeRE enforces the numeric ranges. For example:
    'm': r"(?P<m>1[0-2]|0[1-9]|[1-9])",

As a result, an invalid month will cause an generic regex error:
    ValueError: time data '2015/16/5' does not match format '%Y/%m/%d'

However, if we relax the regex to not check the range and allow datetime to handle it:
    'm': r"(?P<m>\d{1,2})"

The error will be handle in datetime instead and the error will be much more helpful:
    ValueError: month must be in 1..12

Please consider relaxing the regex for numeric ranges in _strptime.TimeRE.

----------
components: Library (Lib)
messages: 249074
nosy: Steve Yeung
priority: normal
severity: normal
status: open
title: _strptime.TimeRE should not enforce range in regex
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24929>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:44:20 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 21:44:20 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440452660.07.0.302266063835.issue24294@psf.upfronthosting.co.za>


Robert Collins added the comment:

Hi, just to say - I'm happy to help steer this through. I think its an important ecosystem fixup.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:51:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 21:51:44 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440453104.98.0.660769484541.issue24294@psf.upfronthosting.co.za>


Robert Collins added the comment:

On testing this - I don't think subprocess tests are necessarily needed.

The scenarios are these (from Nick's comment):
Test frameworks.
 - there are two in the standard library. unittest and doctest.
 - unittest's code paths end up going through 'TestProgram'.
 - doctest via 'testmod'.
 - so alter the warning configuration in those APIs to enable both DeprecationWarning and PendingDeprecationWarning. I don't think (right now anyhow :)) that we need a 'do not do this' flag in them..

Interactive REPL. This includes IDLE in my opinion.
 - there are three here IIRC - IDLE and the cPython and a helper module (which may or may not be the REPL for ./python - I haven't climbed through that code in ---ages---).
 - Again here I'd just enable DW in those code paths. Don't worry about whether its a tty or not: thats irrelevant. If the REPL enters, its the REPL and we should treat it like a user. If someone is driving the REPL programattically its likely one of: a remote session - so they should see it - or its a test harness - so they should see it.


Everything else.
Don't change anything here.

On docs: yes, we should update the docs for:
 - each changed module
 - the warnings module itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:56:57 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 21:56:57 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440453417.53.0.719490146876.issue24927@psf.upfronthosting.co.za>


Jonas Obrist added the comment:

So the reason this is happening is very simple:

When using Pool.apply, the task (function) is sent to the task queue, which is consumed by the worker. At this point the task is "in progress". However, the worker dies without being able to finish the task or in any other way tell the Pool that it can't finish the task. The actual process is then ended by the Pool but the task is still in limbo, so any attempt at getting a result will hang forever.

I'm not sure there's a straight forward way to solve this (the ways I can think of from the top of my head involve adding quite a bit of overhead to the Pool so it keeps track of which process/worker is handling which task at a given time, so if it exits prematurely this task can be finished), but at the very least this case should be documented I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:18:03 2015
From: report at bugs.python.org (marcos paulo)
Date: Mon, 24 Aug 2015 23:18:03 +0000
Subject: [issue24930] fix
Message-ID: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>


New submission from marcos paulo:

Hello to everyone!!!

This test https://hg.python.org/cpython/file/2.7/Lib/test/test_ssl.py on method
ContextTests.test_options, is broker becouse has a error between lines 717 ~ 719;

On 717 line, has a comment about # OP_ALL | OP_NO_SSLv2 is the default value, but
it's not true, becouse this method is fail when i run it => 
py.test Lib/test/test_ssl.py -k ContextTests 
results ===>
https://hg.python.org/cpython/file/2.7/Lib/test/test_ssl.py#l717
*** AssertionError: 2164261887 != 2197816319L

I fixed this method and i wrote new cases about test_options using a lot of options 
from ssl.PROTOCOL, for example:
ssl.PROTOCOL_TLSv1                 
ssl.PROTOCOL_TLSv1_1                
ssl.PROTOCOL_TLSv1_2
ssl.PROTOCOL_SSLv2                
ssl.PROTOCOL_SSLv23
ssl.PROTOCOL_SSLv3  


on this test_options.patch, is the test fixed!

thanks
Att

:-)
marcosptf

----------
components: Library (Lib)
files: test_options.patch
keywords: patch
messages: 249078
nosy: marcosptf
priority: normal
severity: normal
status: open
title: fix
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40249/test_options.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24930>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:20:39 2015
From: report at bugs.python.org (marcos paulo)
Date: Mon, 24 Aug 2015 23:20:39 +0000
Subject: [issue24930] test_ssl broker was fixed
In-Reply-To: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>
Message-ID: <1440458439.09.0.397479447876.issue24930@psf.upfronthosting.co.za>


Changes by marcos paulo <marcosptf at yahoo.com.br>:


----------
title: fix -> test_ssl broker was fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24930>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:47:28 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 24 Aug 2015 23:47:28 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1440460048.36.0.733410590284.issue21167@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Pull request accepted and merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:48:35 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 24 Aug 2015 23:48:35 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1440460115.16.0.844823141877.issue24847@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Pull request accepted and merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:49:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 23:49:02 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440460142.92.0.67634591792.issue2786@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, so this is an API and ABI change. I'm going to do a variant without that downside.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:49:48 2015
From: report at bugs.python.org (Samuel Isaacson)
Date: Mon, 24 Aug 2015 23:49:48 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
Message-ID: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>


New submission from Samuel Isaacson:

When inheriting from namedtuples, _asdict and __dict__ return empty dictionaries:

    from collections import namedtuple

    class Point(namedtuple('_Point', ['x', 'y'])):
        pass

    a = Point(3, 4)
    print(a._asdict() == {})

gives False; it is True on Python 2.7.6

----------
components: Library (Lib)
messages: 249082
nosy: Samuel Isaacson
priority: normal
severity: normal
status: open
title: _asdict breaks when inheriting from a namedtuple
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:59:12 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 24 Aug 2015 23:59:12 +0000
Subject: [issue24867] Asyncio Task.get_stack fails with native coroutines
In-Reply-To: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>
Message-ID: <1440460752.63.0.0532307087471.issue24867@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Pull request accepted and merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:59:48 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 24 Aug 2015 23:59:48 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440460788.19.0.13605363584.issue2786@psf.upfronthosting.co.za>


Robert Collins added the comment:

And herewith.

----------
Added file: http://bugs.python.org/file40250/issue-2786-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:09:52 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:09:52 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440461392.31.0.836693999081.issue24769@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yes, I'll accept this into 3.5.0, please send a pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:10:43 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:10:43 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1440461443.08.0.722746923598.issue24844@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Please either mark as wontfix or send me a pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24844>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:12:52 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Aug 2015 00:12:52 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440461572.28.0.203037185351.issue24931@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:13:45 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Aug 2015 00:13:45 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440461625.91.0.81701537584.issue2786@psf.upfronthosting.co.za>


Robert Collins added the comment:

Forgot docs - I'll do before committing, but not worried about review of them so much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:23:37 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:23:37 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440462217.86.0.628758406041.issue24305@psf.upfronthosting.co.za>


Larry Hastings added the comment:

The C implementation is making me nervous.  My gut feeling is the Python implementation would be easier to get right.

I still don't quite understand: what is the user-perceived result of this change?  Module authors issuing a DeprecationWarning can now use stacklevel=2 instead of stacklevel=10?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:32:07 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:32:07 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440462727.25.0.0935518967849.issue24305@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Is it really *impossible* to "correctly issue a deprecation warning for a module", as the title asserts?  Or does the new import system simply make it *tiresome*?

if sys.version_info.major == 3 and sys.version_info.minor == 4:
  stacklevel = 8
elif  sys.version_info.major == 3 and sys.version_info.minor == 4:
  stacklevel = 10
else:
  stacklevel = 2 # I bet they fixed it in 3.6!

warnings.warn("{} is deprecated".format(__name__), DeprecationWarning,
              stacklevel=stacklevel)


That's Python for you, doing six "impossible" things before breakfast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:36:20 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 25 Aug 2015 00:36:20 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440462980.18.0.39748135899.issue24305@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

> I still don't quite understand: what is the user-perceived result of this change?  Module authors issuing a DeprecationWarning can now use stacklevel=2 instead of stacklevel=10?

Exactly. There are a lot of deprecated modules in the wild, and the correct way to mark a module as deprecated is by writing

warnings.warn("This module is deprecated!", stacklevel=2)

at the top-level of your module. Except that in Python 3.3 you have to use stacklevel=10, and in Python 3.4 you have to use stacklevel=8, and I haven't checked what you need in Python 3.5 but it may well be different again, because it depends on internal implementation details of the import system. Fortunately AFAICT from some code searches no-one is actually depending on this though; instead everyone just writes stacklevel=2 and gets the wrong result.

(This is made more urgent b/c people are increasingly relying on the stacklevel information to filter whether they even see the DeprecationWarning. E.g. I've seen multiple test suites which register a warnings filter that displays DeprecationWarnings iff they are attributed to the package-under-test, and IPython now shows deprecation warnings by default if the warning is attributed to interactive code -- see issue 24294. So there's a good chance that users will only find out that the module they are using is deprecated if the stacklevel= is set correctly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:39:55 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:39:55 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440463195.44.0.00167569911604.issue24305@psf.upfronthosting.co.za>


Larry Hastings added the comment:

If this has been broken since 3.3, I don't think it's a release blocker for 3.5.  I'm willing to consider it a "bug" and accept a fix, but I'd prefer it to be as low-risk as possible (aka the Python version).  Can someone fix the regressions?

And, if the C fix is better somehow, let's definitely get that into 3.6.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:40:43 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 25 Aug 2015 00:40:43 +0000
Subject: [issue24305] The new import system makes it impossible to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440463243.08.0.334357745685.issue24305@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

You're right, "impossible" is a slight exaggeration :-). As an alternative, every package could indeed carry around a table containing the details of importlib's call stack in every version of Python.

(I also haven't checked whether it's consistent within a single stable release series. I guess we could add a rule that 3.5.x -> 3.5.(x+1) cannot change the number of function calls inside the importlib callstack, because that is part of the public API, but I have less than perfect confidence that this rule has been enforced strictly in the past, and I don't think I'd want to be the one in charge of enforcing it in the future.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:43:23 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 00:43:23 +0000
Subject: [issue24305] The new import system makes it inconvenient to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440463403.09.0.846736718966.issue24305@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
title: The new import system makes it impossible to correctly issue a deprecation warning for a module -> The new import system makes it inconvenient to correctly issue a deprecation warning for a module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:56:30 2015
From: report at bugs.python.org (Samuel Isaacson)
Date: Tue, 25 Aug 2015 00:56:30 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440464190.12.0.7249278618.issue24931@psf.upfronthosting.co.za>


Samuel Isaacson added the comment:

Sorry; it returns True on Python 3.4, False on Python 2.7.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:14:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 01:14:40 +0000
Subject: [issue24930] test_ssl broker was fixed
In-Reply-To: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>
Message-ID: <1440465280.09.0.127724121337.issue24930@psf.upfronthosting.co.za>


R. David Murray added the comment:

Most likely you ran the test using a different version of python from the one the test is from.  All the tests in that file pass on our buildbots when run by the python version they are for.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24930>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:15:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 01:15:40 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <1440465340.45.0.438451673862.issue21167@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:23:31 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 25 Aug 2015 01:23:31 +0000
Subject: [issue24844] Python 3.5rc1 compilation error with Apple clang 4.2
 included with Xcode 4
In-Reply-To: <1439312804.21.0.961990235071.issue24844@psf.upfronthosting.co.za>
Message-ID: <1440465811.1.0.936900266507.issue24844@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't think we should hold 3.5.0 for a patch for this.  I recommend lowering the priority and targeting a patch for 3.5.1.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24844>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:29:19 2015
From: report at bugs.python.org (marcos paulo)
Date: Tue, 25 Aug 2015 01:29:19 +0000
Subject: [issue24930] test_ssl broker was fixed
In-Reply-To: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>
Message-ID: <1440466159.0.0.545597405028.issue24930@psf.upfronthosting.co.za>


marcos paulo added the comment:

the version that i ran the test, is python 2.7.10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24930>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:38:20 2015
From: report at bugs.python.org (marcos paulo)
Date: Tue, 25 Aug 2015 01:38:20 +0000
Subject: [issue24930] test_ssl broker was fixed
In-Reply-To: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>
Message-ID: <1440466700.02.0.955203700833.issue24930@psf.upfronthosting.co.za>


marcos paulo added the comment:

anyway, this changes that i did, make this test more resilent!
this test now is more complete than before!

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24930>
_______________________________________

From report at bugs.python.org  Tue Aug 25 03:56:33 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 01:56:33 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <1440467793.79.0.652397392457.issue24847@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:18:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Aug 2015 02:18:46 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1440469126.94.0.702752416195.issue24911@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:19:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 02:19:53 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440469193.79.0.669392190305.issue24931@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:26:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 02:26:41 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440469601.4.0.970005748431.issue24829@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Gnu Readline uses standard output for echoing input, prompts, controlling the cursor, etc. You can already see this by redirecting to a separate terminal. In Linux:

$ python > /dev/pts/2

So I think your assumption is not valid. Perhaps you can redirect standard error instead? (python -i . . . 2> output.txt, at least in Linux.) Or maybe use some terminal logging program, like the ?script? Unix command. But I?m not sure there is a good use case for enabling Readline without a terminal to output to.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:46:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 02:46:54 +0000
Subject: [issue24850] syslog.syslog() does not return error when unable to
 send the log
In-Reply-To: <1439398885.55.0.81268943259.issue24850@psf.upfronthosting.co.za>
Message-ID: <1440470814.69.0.960358104192.issue24850@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?ve never used syslog() in Python, but I thought I should point out that the standard Posix API does not do any error reporting either. See <http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html>: ?The . . . functions shall not return a value. / No errors are defined.?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24850>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:54:32 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 02:54:32 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440471272.88.0.197023135588.issue24931@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

For __dict__, I'm not sure what the right behavior should by for subclasses that don't define __slots__.  In Python 3, the __dict__ is returning the dict for the subclass.  This might be the correct and most desirable behavior:

    >>> class Point(namedtuple('_Point', ['x', 'y'])):
            pass
    >>> a = Point(3, 4)
    >>> a.w = 5
    >>> a.__dict__
    {'w': 5}

If we leave the __dict__ behavior as is in Py3, then we still need to get _asdict() back to its documented behavior.  For that, we would need to disconnect it from __dict__ by restoring the Py2.7 code for _asdict():

    def _asdict(self):
        'Return a new OrderedDict which maps field names to their values'
        return OrderedDict(zip(self._fields, self))

All this needs to be thought-out carefully.  Putting in __dict__ support originally looked like a bugfix to get vars() working correctly, but it caused problems with pickling which then led to the addition of __getnewargs__.  It seems that defining __dict__ leads to problems no matter how you do it.

My inclination is to remove __dict__ and __getewargs__ from the namedtuple definition entirely and return to a simpler state of affairs that is easier to reason about and less likely to lead to unexpected behaviors like the one in this bug report.

One note:  using the Py2.7 namedtuple code in Python3 still doesn't restore the old behavior.  Something else in the language appears to have changed (causing the subclasses' __dict__ to take precedence over the inherited __dict__ property).

----------
priority: normal -> high
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:55:23 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 02:55:23 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440471323.42.0.762263692848.issue24769@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I wanted to get this in to Python 3.5.0rc2, so I checked it in myself.  Petr, I gave you credit in the checkin comment and Misc/NEWS.  Hope that's okay!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 04:56:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 02:56:18 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1440471378.92.0.938305946023.issue24928@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Perhaps replacing the dict call with a copy call would be sufficient?

I think that would do it.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Tue Aug 25 05:00:19 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 03:00:19 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440471619.9.0.538887005763.issue17781@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would like the see LTO enabled.  The intermodule calls to code in abstract.c would become less expensive.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Tue Aug 25 06:19:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 04:19:10 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <20150825041907.19636.42327@psf.io>


Roundup Robot added the comment:

New changeset 5b43ee3df43e by Berker Peksag in branch '3.5':
Issue #10708: Add a link to devguide in Misc/Porting.
https://hg.python.org/cpython/rev/5b43ee3df43e

New changeset 23f4d8bf4f83 by Berker Peksag in branch 'default':
Issue #10708: Add a link to devguide in Misc/Porting.
https://hg.python.org/cpython/rev/23f4d8bf4f83

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10708>
_______________________________________

From report at bugs.python.org  Tue Aug 25 06:20:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 04:20:51 +0000
Subject: [issue24808] PyTypeObject fields have incorrectly documented types
In-Reply-To: <1438857358.96.0.0472075361686.issue24808@psf.upfronthosting.co.za>
Message-ID: <1440476451.98.0.138536529473.issue24808@psf.upfronthosting.co.za>


Martin Panter added the comment:

Most of this looks good. For the record, tp_flags was changed to unsigned in 3.4 (Issue 16086). The const and Py_ssize_t changes were done before 3.0.

The only bits I would hesitate about are adding back the two comments saying ?Assigned meaning in release 2?. These comments seem to have been removed from the Python 3 documentation in r67578, and I don?t see much point adding them back.

I will have a go at committing the rest of the patch. (This is my first time making a commit.)

----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag, martin.panter
stage:  -> commit review
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24808>
_______________________________________

From report at bugs.python.org  Tue Aug 25 06:26:23 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Aug 2015 04:26:23 +0000
Subject: [issue24789] ctypes doc string
In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za>
Message-ID: <1440476783.05.0.832156931151.issue24789@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24789>
_______________________________________

From report at bugs.python.org  Tue Aug 25 06:50:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 04:50:26 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440478226.12.0.30398252891.issue24931@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40251/nt_fix1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Tue Aug 25 07:51:28 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Aug 2015 05:51:28 +0000
Subject: [issue24932] Migrate _testembed to a C unit testing library
Message-ID: <1440481888.38.0.825081560944.issue24932@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Programs/_testembed (invoked by test_capi to test CPython's embedding support) is currently a very simple application with only two different embedding tests: https://hg.python.org/cpython/file/tip/Programs/_testembed.c

In light of proposals like PEP 432 to change the interpreter startup sequence and make it more configurable, it seems desirable to be better able to test more configuration options directly, without relying on the abstraction layer provided by the main CPython executable.

The specific unit testing library that prompted this idea was cmocka, which is used by libssh, sssd and cwrap: https://cmocka.org/

cwrap in turn is used by the Samba team to mock out network interfaces and other operations using LD_PRELOAD: https://cwrap.org/

We don't necessarily have to use those particular libraries, I'm just filing this issue to capture the idea of improving our C level unit testing capabilities, and then updating regrtest to better capture and report those results (currently there are just a couple of tests in test_capi that call the _testembed executable)

----------
components: Tests
messages: 249106
nosy: encukou, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Migrate _testembed to a C unit testing library
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24932>
_______________________________________

From report at bugs.python.org  Tue Aug 25 07:53:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 05:53:24 +0000
Subject: [issue24808] PyTypeObject fields have incorrectly documented types
In-Reply-To: <1438857358.96.0.0472075361686.issue24808@psf.upfronthosting.co.za>
Message-ID: <20150825055320.76207.71650@psf.io>


Roundup Robot added the comment:

New changeset 54a9c649281d by Martin Panter <vadmium> in branch '3.4':
Issue #24808: Update the documentation of some PyTypeObject fields
https://hg.python.org/cpython/rev/54a9c649281d

New changeset e81d692a00b1 by Martin Panter <vadmium> in branch '3.5':
Issue #24808: Merge 3.4 into 3.5; adjust new tp_as_async field
https://hg.python.org/cpython/rev/e81d692a00b1

New changeset 2637e2593f01 by Martin Panter <vadmium> in branch 'default':
Issue #24808: Merge 3.5 into 3.6
https://hg.python.org/cpython/rev/2637e2593f01

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24808>
_______________________________________

From report at bugs.python.org  Tue Aug 25 08:03:04 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Aug 2015 06:03:04 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440482584.38.0.610351551052.issue24294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As Robert suggests, I think it's OK to issue the deprecation warnings for code run via "python < script.py" or "cat script.py | python". Reverting to the current behaviour if folks actually want that would just be a matter of passing the file in directly, rather than piping it via stdin: "python script.py".

That eliminates any need to care about whether the input is a tty or not, and we can just focus on the code paths. If you grep the CPython code base for "ps1" you're likely to find most of the relevant places ("sys.ps1" hold the interactive prompt, while "sys.ps2" holds the continuation prompt)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Tue Aug 25 08:08:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Aug 2015 06:08:37 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440482917.74.0.319648321658.issue24769@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Larry! Sorry I didn't get to this as soon as I got back from the US.

Will you add it to 3.5.1 and 3.6.0, or would you prefer I take care of that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 08:15:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 06:15:42 +0000
Subject: [issue24808] PyTypeObject fields have incorrectly documented types
In-Reply-To: <1438857358.96.0.0472075361686.issue24808@psf.upfronthosting.co.za>
Message-ID: <1440483342.19.0.932197038062.issue24808@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I think that worked smoothly (let me know if I missed something). Thanks for the patch Joseph.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24808>
_______________________________________

From report at bugs.python.org  Tue Aug 25 09:07:56 2015
From: report at bugs.python.org (Aymeric Augustin)
Date: Tue, 25 Aug 2015 07:07:56 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1440486476.33.0.701494198432.issue10740@psf.upfronthosting.co.za>


Aymeric Augustin added the comment:

Since a better solution seems to be around the corner, I'm withdrawing my proposal.

I'm attaching the current state of my patch. It isn't functional. Mostly it proves that my API proposal is very inconvenient to implement in C. That's why I kept it around for over a year without completing it.

----------
Added file: http://bugs.python.org/file40252/issue10740-aaugustin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Tue Aug 25 09:09:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 07:09:11 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1440486551.02.0.693433628559.issue24902@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Tue Aug 25 09:35:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 07:35:07 +0000
Subject: [issue14534] Add means to mark unittest.TestCases as "do not load".
In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>
Message-ID: <1440488107.39.0.139580854266.issue14534@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 22680, about blacklisting FunctionTestCase, was closed as a duplicate of this. However the patch there has a useful test case for FunctionTestCase that could be merged with any future work here.

----------
stage: patch review -> needs patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14534>
_______________________________________

From report at bugs.python.org  Tue Aug 25 09:37:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 07:37:04 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1440488224.33.0.219469526282.issue22680@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +Add means to mark unittest.TestCases as "do not load".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22680>
_______________________________________

From report at bugs.python.org  Tue Aug 25 09:43:36 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 25 Aug 2015 07:43:36 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440488616.91.0.298680569713.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

ok, thanks. I'll remove the is tty ans push docs changes on a new patch. 
I'll see if I can figure out how to enable DW by default in unittest and doctest. 

Thanks !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:28:15 2015
From: report at bugs.python.org (Andrey Wagin)
Date: Tue, 25 Aug 2015 11:28:15 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
Message-ID: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>


New submission from Andrey Wagin:

In [1]: import socket

In [2]: sks = socket.socketpair(socket.AF_UNIX, socket.SOCK_DGRAM)

In [3]: sks[1].send("asdfasdfsadfasdfsdfsadfsdfasdfsdfasdfsadfa")
Out[3]: 42

In [4]: sks[0].recv(1, socket.MSG_PEEK | socket.MSG_TRUNC)
Out[4]: 'a\x00\x00\x00\xc0\xbf8\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

recv() returns a buffer. The size of this buffer is equal to the size of transferred data, but only the first symbol was initialized. What is the idea of this behavior.

Usually recv(sk, NULL, 0, socket.MSG_PEEK | socket.MSG_TRUNC) is used to get a message size. What is the right way to get a message size in Python?

----------
components: Library (Lib)
messages: 249114
nosy: Andrey Wagin
priority: normal
severity: normal
status: open
title: socket.recv(size, MSG_TRUNC) returns more than size bytes
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:39:25 2015
From: report at bugs.python.org (=?utf-8?b?Q2FuIMSwYmFub8SfbHU=?=)
Date: Tue, 25 Aug 2015 11:39:25 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440502765.41.0.451252672204.issue24790@psf.upfronthosting.co.za>


Can ?bano?lu added the comment:

First of all, sorry for the late reply.

I did try the solution you have proposed which removes the need to click to expand the items under globals/locals but as I understand it, you have something more in mind for the whole stackviewer UI. Should I still submit a patch for this?

As far as the bug is concerned I will look into that next.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:37:35 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 12:37:35 +0000
Subject: [issue24850] syslog.syslog() does not return error when unable to
 send the log
In-Reply-To: <1439398885.55.0.81268943259.issue24850@psf.upfronthosting.co.za>
Message-ID: <1440506255.69.0.719253777911.issue24850@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, in that case there aren't any errors for us to return, so this is moot.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24850>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:39:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 12:39:32 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1440506372.22.0.587121518589.issue24928@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:53:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 12:53:46 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440507226.32.0.86219824465.issue24294@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not sure that is acceptable.  "Just changing it to a file" could break an application's structure that is depending on being able to use stdin to run scripts.  As one example, vim scripts can embed python code...now, what VIM does behind the scenes with that I don't know, and it might be able to write it out to a file or put somewhere in memory for the embedded interpreter to run, but the point is that here is a an application whose API is embedded scripts that get fed into python, not independent files that python gets called on.  I'm guessing there are other applications out there that *would* be affected by this, even if vim itself isn't (and I don't know if it is or not).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:59:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 12:59:27 +0000
Subject: [issue24808] PyTypeObject fields have incorrectly documented types
In-Reply-To: <1438857358.96.0.0472075361686.issue24808@psf.upfronthosting.co.za>
Message-ID: <1440507567.16.0.7618675484.issue24808@psf.upfronthosting.co.za>


R. David Murray added the comment:

Congratulation on your first commit, Martin :)

Dropping the python2 reference was the right call: the python3 docs are supposed to be a "fresh start" and there are very few places where they mention python2.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24808>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:09:39 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 25 Aug 2015 13:09:39 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
Message-ID: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi All,

My name is Florin Papa and I work in the Server Languages Optimizations Team at Intel Corporation.

I would like to submit a patch that solves compatibility issues of the django_v2 benchmark in the Grand Unified Python Benchmark. The django_v2 benchmark uses inspect.getargspec(), which is deprecated and was removed in Python 3.6. Therefore, it crashes with the message "ImportError: cannot import name 'getargspec'" when using the latest version of Python on the default branch.

The patch modifies the benchmark to use inspect.signature() when Python version is 3.6 or above and keep using inspect.getargspec() otherwise.
 

Regards,
Florin

----------
components: Benchmarks
files: django_v2_compat_3_6.patch
keywords: patch
messages: 249119
nosy: florin.papa
priority: normal
severity: normal
status: open
title: django_v2 benchmark not working in Python 3.6
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file40253/django_v2_compat_3_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:15:50 2015
From: report at bugs.python.org (Gabi Davar)
Date: Tue, 25 Aug 2015 13:15:50 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
 (getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1440508550.99.0.203078707341.issue10466@psf.upfronthosting.co.za>


Changes by Gabi Davar <grizzly.nyo at gmail.com>:


----------
nosy: +Gabi.Davar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:20:14 2015
From: report at bugs.python.org (Matheus Vieira Portela)
Date: Tue, 25 Aug 2015 13:20:14 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440508814.12.0.253918865993.issue3548@psf.upfronthosting.co.za>


Matheus Vieira Portela added the comment:

I just found this open issue and I can work on it. What is left to do before closing it?

----------
nosy: +matheus.v.portela

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:21:46 2015
From: report at bugs.python.org (Andrey Wagin)
Date: Tue, 25 Aug 2015 13:21:46 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1440508906.31.0.303296966959.issue24933@psf.upfronthosting.co.za>


Andrey Wagin added the comment:

sendto(4, "asdfasdfsadfasdfsdfsadfsdfasdfsd"..., 42, 0, NULL, 0) = 42
recvfrom(3, "a\0n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\0\0\0\0\2\0\0\0"..., 1, MSG_TRUNC, NULL, NULL) = 42

I think the exit code is interpreted incorrectly. In this case it isn't equal to the number of bytes received. Then python copies this number of bytes from the buffer with smaller size, so it may access memory which are not allocated or allocated by someone else.

valgrind detects this type of errors:
[avagin at localhost ~]$ cat sock.py 
import socket, os, sys

sks = socket.socketpair(socket.AF_UNIX, socket.SOCK_DGRAM)
pid = os.fork()
if pid == 0:
	sks[1].send("\0" * 4096)
	sys.exit(0)
sk = sks[0]
print sk.recv(1, socket.MSG_TRUNC )

[avagin at localhost ~]$ valgrind python sock.py
==25511== Memcheck, a memory error detector
==25511== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==25511== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==25511== Command: python sock.py
==25511== 
==25511== Syscall param write(buf) points to uninitialised byte(s)
==25511==    at 0x320B4F0940: __write_nocancel (in /usr/lib64/libc-2.20.so)
==25511==    by 0x320B478D2C: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.20.so)
==25511==    by 0x320B4794EE: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib64/libc-2.20.so)
==25511==    by 0x320B46EE68: fwrite (in /usr/lib64/libc-2.20.so)
==25511==    by 0x369CC90210: ??? (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CC85EAE: ??? (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CC681AB: PyFile_WriteObject (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CCE08F9: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CCE340F: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CCE3508: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CCFC91E: ??? (in /usr/lib64/libpython2.7.so.1.0)
==25511==    by 0x369CCFDB41: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:31:29 2015
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 25 Aug 2015 13:31:29 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440509489.2.0.8445556952.issue24769@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

I pulled the 3.5 branch a few minutes ago, and the patch isn't present.  Has it not been pushed to hg.python.org?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:51:23 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 13:51:23 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440510683.93.0.962428881562.issue24769@psf.upfronthosting.co.za>


Larry Hastings added the comment:

That's correct, it's just in 3.5.0 at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 16:03:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 14:03:53 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440511433.21.0.315958060184.issue3548@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for being willing to work on it.

If what is wanted is a way to pipeline shell commands, Python already has that functionality in the pipes module.

So the interesting thing here would be pipelining *non* shell commands, to avoid the shell exploits that using a shell pipeline invites.

The pipes module already has a worked out API, so perhaps it would be useful to see about re-implementing pipe's command execution using subprocess, and expand the API to allow for argv style command specification that would be fed to subprocess using the default shell=False.  This would also presumably allow pipes to be used when there's no bash shell available.

The downside is that we might break current uses of pipes if we replace the shell version of the pipelining with subprocess shell=True, while using subprocess only if the command specifications are argv lists would result in code with a split personality.  But if I were working on it I'd experiment with that approach to see if it made sense.

Other core devs may have other opinions on this :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 25 16:25:41 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 25 Aug 2015 14:25:41 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440512741.94.0.0839567024098.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

# unittest 

(Pending)DeprecationWarning are already enabled if no -W flags are given. 

# doctest

We enable the DW in REPL only if originate from `__main__`, this seem to be painful to do in doctest, as each doctest execute in a module that have the name of the file it is executed in. Should I enable globally regardless of where the DW comes from, or explore more ?

Should the doctest fail if such a warning is raised, or actually just print it to the output, letting the doctest pass ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:05:21 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 15:05:21 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440515121.35.0.302248394741.issue24913@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:12:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Aug 2015 15:12:08 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440515528.11.0.752312693321.issue24913@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm find the "exception analysis" to be unreadable.  Have you found any place in the deque code where the uninitialized memory actually gets accessed?

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:22:18 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Aug 2015 15:22:18 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1440516138.6.0.352928984794.issue24933@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Evidently, the recv code doesn't know anything about MSG_TRUNC, which causes it to do incorrect things when the output length is greater than the buffer length.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:43:41 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 25 Aug 2015 15:43:41 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440517421.65.0.110740490607.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I modified the patches to be compatible with both environments. The new versions modify the configure.ac file also, therefore you will need to run "autoconf" by hand. Also, in case of MaOS you will need to have llvm-profdata installed and in your path.

I kept the expanded form of regrtest (/Lib/test/regrtest.py) because this way it is clearer to the user what is the main file that runs the training workload. 

Also, the "|| true" is necessary also, due to the nature of regrtest. This test suite is designed to return a fail code if a test is not ok, even for tests that do not comply with certain dependencies (meaning users that didn't installed any other libraries).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:43:53 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 25 Aug 2015 15:43:53 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440517433.28.0.996823082339.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40254/python2.7-pgo-v03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:44:00 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 25 Aug 2015 15:44:00 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440517440.25.0.270902506825.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40255/python3.5-pgo-v03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:47:24 2015
From: report at bugs.python.org (yunlian)
Date: Tue, 25 Aug 2015 15:47:24 +0000
Subject: [issue24935] LDSHARED is not set according when CC is set.
Message-ID: <1440517644.33.0.785597906757.issue24935@psf.upfronthosting.co.za>


New submission from yunlian:

On linux, when CC is set, we expect that the LDSHARED is set accordingly.
Currently, only on OS X, the LDSHARED is set properly.

Below is the proposed patch

--- a/Lib/distutils/sysconfig.py        2015-08-24 11:58:37.265683872 -0700
+++ b/Lib/distutils/sysconfig.py        2015-08-24 11:57:29.673945173 -0700
@@ -180,9 +180,9 @@
             if _USE_CLANG:
                 newcc = 'clang'
         if newcc:
-            # On OS X and linux, if CC is overridden, use that as the default
+            # On OS X, if CC is overridden, use that as the default
             #       command for LDSHARED as well
-            if ((sys.platform == 'darwin' or sys.platform.startswith('linux'))
+            if (sys.platform == 'darwin'
                     and 'LDSHARED' not in os.environ
                     and ldshared.startswith(cc)):
                 ldshared = newcc + ldshared[len(cc):]

----------
components: Distutils
messages: 249129
nosy: dstufft, eric.araujo, yunlian
priority: normal
severity: normal
status: open
title: LDSHARED is not set according when CC is set.
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24935>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:54:54 2015
From: report at bugs.python.org (John Leitch)
Date: Tue, 25 Aug 2015 15:54:54 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440518094.13.0.000811940830533.issue24913@psf.upfronthosting.co.za>


John Leitch added the comment:

The "exception analysis" is output from the WinDbg !analyze command run on a crash where access to the uninitialized memory ultimately corrupted the instruction pointer, leading to a data execution prevention crash. That's why the disassembly is junk--the IP is not pointing to valid instructions. This crash was provided as an example because it demonstrates that the issue is likely exploitable, and can probably be used to achieve code execution.

Here is an example of a crash where execution halts immediately upon attempted to dereference a corrupted pointer. Note that the pointer is 0xC0C0C0C0--a fill pattern indicative of uninitialized memory. 

0:000> r
eax=000002a2 ebx=551160a8 ecx=c0c0c0c0 edx=07e538e0 esi=07e538e0 edi=c0c0c0c0
eip=54f25a55 esp=004cf6e4 ebp=004cf6f4 iopl=0         nv up ei ng nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010287
python35!do_richcompare+0x15:
54f25a55 8b4704          mov     eax,dword ptr [edi+4] ds:002b:c0c0c0c4=????????
0:000> k
ChildEBP RetAddr  
004cf6f4 54f25be3 python35!do_richcompare+0x15 [c:\build\cpython\objects\object.c @ 659]
004cf700 54e453fc python35!PyObject_RichCompare+0x53 [c:\build\cpython\objects\object.c @ 718]
(Inline) -------- python35!PyObject_RichCompareBool+0x14 [c:\build\cpython\objects\object.c @ 739]
004cf738 54f232d3 python35!deque_index+0xac [c:\build\cpython\modules\_collectionsmodule.c @ 933]
004cf754 54f8442f python35!PyCFunction_Call+0x113 [c:\build\cpython\objects\methodobject.c @ 109]
004cf788 54f818ec python35!call_function+0x2ff [c:\build\cpython\python\ceval.c @ 4651]
004cf800 54f8339f python35!PyEval_EvalFrameEx+0x232c [c:\build\cpython\python\ceval.c @ 3184]
004cf84c 54fba0b2 python35!_PyEval_EvalCodeWithName+0x82f [c:\build\cpython\python\ceval.c @ 3962]
(Inline) -------- python35!PyEval_EvalCodeEx+0x21 [c:\build\cpython\python\ceval.c @ 3983]
(Inline) -------- python35!PyEval_EvalCode+0x21 [c:\build\cpython\python\ceval.c @ 777]
004cf888 54fb9f45 python35!run_mod+0x42 [c:\build\cpython\python\pythonrun.c @ 970]
004cf8b4 54fb8fba python35!PyRun_FileExFlags+0x85 [c:\build\cpython\python\pythonrun.c @ 923]
004cf8f8 54e8f1f7 python35!PyRun_SimpleFileExFlags+0x20a [c:\build\cpython\python\pythonrun.c @ 396]
(Inline) -------- python35!PyRun_AnyFileExFlags+0x4e [c:\build\cpython\python\pythonrun.c @ 80]
004cf924 54e8fb33 python35!run_file+0xe7 [c:\build\cpython\modules\main.c @ 318]
004cf9c8 1cd4143f python35!Py_Main+0x913 [c:\build\cpython\modules\main.c @ 768]
(Inline) -------- python!invoke_main+0x1d [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 89]
004cfa14 75463744 python!__scrt_common_main_seh+0xff [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264]
004cfa28 76f0a064 KERNEL32!BaseThreadInitThunk+0x24
004cfa70 76f0a02f ntdll!__RtlUserThreadStart+0x2f
004cfa80 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
python35!do_richcompare+15 [c:\build\cpython\objects\object.c @ 659]
54f25a55 8b4704          mov     eax,dword ptr [edi+4]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 54f25a55 (python35!do_richcompare+0x00000015)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: c0c0c0c4
Attempt to read from address c0c0c0c4

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=000002a2 ebx=551160a8 ecx=c0c0c0c0 edx=07e538e0 esi=07e538e0 edi=c0c0c0c0
eip=54f25a55 esp=004cf6e4 ebp=004cf6f4 iopl=0         nv up ei ng nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010287
python35!do_richcompare+0x15:
54f25a55 8b4704          mov     eax,dword ptr [edi+4] ds:002b:c0c0c0c4=????????

FAULTING_THREAD:  00004a48

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  python.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  c0c0c0c4

READ_ADDRESS:  c0c0c0c4 

FOLLOWUP_IP: 
python35!do_richcompare+15 [c:\build\cpython\objects\object.c @ 659]
54f25a55 8b4704          mov     eax,dword ptr [edi+4]

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  python.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 54f25be3 to 54f25a55

STACK_TEXT:  
004cf6f4 54f25be3 00000002 004cf738 54e453fc python35!do_richcompare+0x15
004cf700 54e453fc c0c0c0c0 07e538e0 00000002 python35!PyObject_RichCompare+0x53
004cf738 54f232d3 07e31d18 07e50e40 08e78b48 python35!deque_index+0xac
004cf754 54f8442f 08e78b48 07e50e40 00000000 python35!PyCFunction_Call+0x113
004cf788 54f818ec 0586eab0 00000000 00000040 python35!call_function+0x2ff
004cf800 54f8339f 0586eab0 00000000 08910ff0 python35!PyEval_EvalFrameEx+0x232c
004cf84c 54fba0b2 0588ff80 00000000 00000000 python35!_PyEval_EvalCodeWithName+0x82f
004cf888 54fb9f45 0588ff80 0588ff80 004cf954 python35!run_mod+0x42
004cf8b4 54fb8fba 06a90fc8 0581bc70 00000101 python35!PyRun_FileExFlags+0x85
004cf8f8 54e8f1f7 06a90fc8 0581bc70 00000001 python35!PyRun_SimpleFileExFlags+0x20a
004cf924 54e8fb33 004cf954 71902100 71902108 python35!run_file+0xe7
004cf9c8 1cd4143f 00000002 05b46f08 05b4cf48 python35!Py_Main+0x913
004cfa14 75463744 7ecee000 75463720 fbb4cf67 python!__scrt_common_main_seh+0xff
004cfa28 76f0a064 7ecee000 949593e0 00000000 KERNEL32!BaseThreadInitThunk+0x24
004cfa70 76f0a02f ffffffff 76f2d7ec 00000000 ntdll!__RtlUserThreadStart+0x2f
004cfa80 00000000 1cd414f7 7ecee000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  c:\build\cpython\objects\object.c

FAULTING_SOURCE_FILE:  c:\build\cpython\objects\object.c

FAULTING_SOURCE_LINE_NUMBER:  659

FAULTING_SOURCE_CODE:  
   655:     PyObject *res;
   656:     int checked_reverse_op = 0;
   657: 
   658:     if (v->ob_type != w->ob_type &&
>  659:         PyType_IsSubtype(w->ob_type, v->ob_type) &&
   660:         (f = w->ob_type->tp_richcompare) != NULL) {
   661:         checked_reverse_op = 1;
   662:         res = (*f)(w, v, _Py_SwappedOp[op]);
   663:         if (res != Py_NotImplemented)
   664:             return res;


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python35!do_richcompare+15

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python35

IMAGE_NAME:  python35.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  55c83105

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_python35.dll!do_richcompare

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_python35!do_richcompare+15

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_python35.dll!do_richcompare

FAILURE_ID_HASH:  {9d923c37-6c51-89af-91c6-b0039172374e}

Followup: MachineOwner
---------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:57:24 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 15:57:24 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440518244.5.0.748961041516.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Any specific reason the v3 patch, Alecsandru, is listed as against 3.5 in the filename? Or is that just a typo?

P.S.: I did another review asking about explicit Clang support and also supporting Greg's request to use `-m test` instead of the explicit file execution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:15:25 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 25 Aug 2015 16:15:25 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440519325.77.0.274507494928.issue24913@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I guess that in the test case the stop parameter is set to 4 in
deque_index(), but it should be clamped to 3.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:22:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 16:22:38 +0000
Subject: [issue24929] _strptime.TimeRE should not enforce range in regex
In-Reply-To: <1440452349.29.0.876134082373.issue24929@psf.upfronthosting.co.za>
Message-ID: <1440519758.72.0.96710810535.issue24929@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Do realize that the strptime code is shared with time.strptime() and so this change would have to make sense in both contexts.

This change can also only happen in Python 3.6 because it is backwards-incompatible due to people potentially already catching the previous exception.

----------
nosy: +brett.cannon
priority: normal -> low
stage:  -> test needed
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24929>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:24:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 16:24:51 +0000
Subject: [issue24932] Migrate _testembed to a C unit testing library
In-Reply-To: <1440481888.38.0.825081560944.issue24932@psf.upfronthosting.co.za>
Message-ID: <1440519891.0.0.164507136367.issue24932@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Someone is going to think of [googletest] (https://github.com/google/googletest) and then realize that it is a C++ test suite and thus won't work unless you explicitly compile Python for C++.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24932>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:25:54 2015
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 25 Aug 2015 16:25:54 +0000
Subject: [issue24935] LDSHARED is not set according when CC is set.
In-Reply-To: <1440517644.33.0.785597906757.issue24935@psf.upfronthosting.co.za>
Message-ID: <1440519954.53.0.781344065711.issue24935@psf.upfronthosting.co.za>


Changes by Mike Frysinger <vapier at users.sourceforge.net>:


----------
nosy: +vapier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24935>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:31:02 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 16:31:02 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440520262.3.0.631716009271.issue24934@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The proposed patch directly modifies the copy of Django in the benchmark suite which isn't acceptable; we purposefully don't modify the project code we pull in for benchmark consistency and ease of maintenance.

It would be better to make sure a newer version of Django is fixed upstream, pull in the newer version to the benchmark suite, and then create a django_v3 benchmark using that newer version while removing the django_v2 benchmark from the default set of benchmarks (if not fully remove it).

And can you sign the contributor agreement, Florin?

----------
nosy: +brett.cannon, pitrou
stage:  -> patch review
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:35:15 2015
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 25 Aug 2015 16:35:15 +0000
Subject: [issue24935] LDSHARED is not set according when CC is set.
In-Reply-To: <1440517644.33.0.785597906757.issue24935@psf.upfronthosting.co.za>
Message-ID: <1440520515.51.0.268839958413.issue24935@psf.upfronthosting.co.za>


Mike Frysinger added the comment:

looks like the patch was reversed, but otherwise should be clear what we're going for

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24935>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:41:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Aug 2015 16:41:24 +0000
Subject: [issue24936] Idle: handle 'raise' properly when running with
 subprocess (2.7)
Message-ID: <1440520884.78.0.336489829691.issue24936@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

With one process (installed 2.7.10, -n option):
>>> raise
Traceback (most recent call last):
  File "<pyshell#0>", line 2, in <module>
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType

With subprocess (default option):
>>> raise

Traceback (most recent call last):
** IDLE Internal Exception: 
  File "C:\Programs\Python27\lib\idlelib\run.py", line 325, in runcode
    exec code in self.locals
  File "C:\Programs\Python27\lib\idlelib\run.py", line 111, in main
    seq, request = rpc.request_queue.get(block=True, timeout=0.05)
  File "C:\Programs\Python27\lib\Queue.py", line 176, in get
    raise Empty
Empty

The 2.7.10 says " If no exception is active in the current scope, a TypeError exception is raised indicating that this is an error (if running under IDLE, a Queue.Empty exception is raised instead)."  The comment is not true with -n.  But adding changing 'IDLE' to 'IDLE without -n' might encourage people to think that they should use '-n'.

A workaround fix might be to add a special check to the internal error handling code to print the TypeError instead. I do not know of any other open issues about Internal Exceptions being printed.

This is a low priority issue, but it is peculiar that this seems to be the only exception so mangled. The only issue issue I found related to this section of the Idle code is #1190163.

This is a 2.7 issue only. In 3.4+, console or Idle in either mode:
>>> raise
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    raise
RuntimeError: No active exception to reraise

----------
messages: 249137
nosy: terry.reedy
priority: low
severity: normal
stage: needs patch
status: open
title: Idle: handle 'raise' properly when running with subprocess (2.7)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24936>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:41:33 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 25 Aug 2015 16:41:33 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
Message-ID: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

In https://docs.python.org/3/howto/cporting.html#cobject-replaced-with-capsule (added in issue13053):

1) __PyCapsule_GetField is defined as::

    #define __PyCapsule_GetField(capsule, field, default_value) ...

but called as::

    __PyCapsule_GetField(capsule, field)


2) __PyCapsule_SetField returns the wrong value (1 for success, 0 for failure).

3) Both the getter and setter don't set the exception on failure, leading to "SystemError: error return without exception set".

Here's a patch.

----------
assignee: docs at python
components: Documentation
files: capsulethunk.patch
keywords: patch
messages: 249138
nosy: docs at python, encukou, larry, ncoghlan
priority: normal
severity: normal
status: open
title: Multiple problems in getters & setters in capsulethunk.h
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40256/capsulethunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:58:50 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 25 Aug 2015 16:58:50 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1440521930.16.0.675868444595.issue24937@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Note:
I'm including a tested (+fixed, now) copy of capsulethunk.h in my set of Python3 C extension porting helpers, http://py3c.readthedocs.org

Unfortunately the tests can't be added to CPython, because they need to run on Python 2.6 to be useful. That makes me think an external project might make a better home for this piece of code.
If you agree, I can take over maintainership of capsulethunk, and make py3c the canonical home for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Tue Aug 25 19:11:50 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 17:11:50 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1440522710.71.0.979512367547.issue24937@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Given that capsulethunk is only needed for 2.6 (and previous), and those versions are no longer maintained by the Python core community, yes I'd be happy for you to take over maintainership and host it externally.  I'm sure we could change the documentation in 2.7, 3.4, and 3.5 to reflect this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Tue Aug 25 19:27:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 17:27:15 +0000
Subject: [issue24929] _strptime.TimeRE should not enforce range in regex
In-Reply-To: <1440452349.29.0.876134082373.issue24929@psf.upfronthosting.co.za>
Message-ID: <1440523635.81.0.690013130271.issue24929@psf.upfronthosting.co.za>


R. David Murray added the comment:

And it does not make sense for time, since time.strptime does no additional validation, it just returns the result returned by _strptime.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24929>
_______________________________________

From report at bugs.python.org  Tue Aug 25 19:30:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 17:30:46 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440523846.66.0.255387544096.issue24934@psf.upfronthosting.co.za>


R. David Murray added the comment:

Florin is covered by the Intel corporate agreement.  I've updated his user record accordingly.

----------
nosy: +r.david.murray
stage: patch review -> 
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Tue Aug 25 19:34:56 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 25 Aug 2015 17:34:56 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440524096.57.0.482692079979.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Sorry, it was a typo. I made a correction to it. I will also modify to -m flag, instead of the explicit file execution. 

Regarding the clang/gcc support, in v03 version of patches, GCC is supported. On Linux is straightforward. On Mac I see that the default development environment also has the "gcc" command, but it is a binary stub that calls clang in backend, so the flags are adjusted for clang-in-gcc-clothing. You say to support clang explicitly as a compiler in 2.7 and 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 19:59:01 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 25 Aug 2015 17:59:01 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440525541.52.0.36324225037.issue24829@psf.upfronthosting.co.za>


Adam Barto? added the comment:

I really don't know how stdio in console in Linux works. In my package https://github.com/Drekin/win-unicode-console I set custom sys.std* streams and a custom readline hook to support Unicode in Python run in Windows console. If I run `py` with my fixes enabled, >>> "?" really yields "?", but when I run `py -i > output.txt`, >>> "?" yields "?" (written to the file of course) same as when my fixes are disabled. From this point of view it seemed wrong that redirection of output affects how a line is read.

Regarding the prompt, I think it should be always written to sys.stdout, so we may hypothetically add a wrapper around GNU readline writing the prompt to sys.stdout and calling the actual readline with empty prompt.

So you are telling me that the characters displayed in console when entering input are actually written to stdout in Linux (I think it's not the case in Windows)? Maybe it woudn't matter if they were written to console even when stdout is redirected.

I'm not saying it is extra useful to redirect stdout while providing interactive input, I was just wondering what should be the right behavior. And from my point of view motivated as explained above, readlinehook should be used even with redirected stdout, at least in Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:08:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 18:08:01 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440526081.17.0.642354342782.issue24829@psf.upfronthosting.co.za>


R. David Murray added the comment:

The behavior of programs definitely differs if stdout is redirected.  For example on linux a program might output color codes to stdout normally, but if it is redirected to a non-tty, no color codes would be output.

Windows console handling of unicode is an entirely separate problem for which there are open issues and some possible solutions being worked on.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:19:14 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:19:14 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440526754.4.0.410911922667.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm asking if that's possible. For instance I set $CC to clang explicitly on OS X as I install the latest version of LLVM through Homebrew to get better compiler warnings for Python. It would be great if we could avoid leaving all clang users out unless they happen to use the stock install on OS X (e.g. cover Clang users on Linux).

Basically it would be nice if this is not exclusive to gcc if Clang also supports PGO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:22:37 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Tue, 25 Aug 2015 18:22:37 +0000
Subject: [issue24927] multiprocessing.Pool hangs forever on segfault
In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za>
Message-ID: <1440526957.13.0.288985096666.issue24927@psf.upfronthosting.co.za>


Jonas Obrist added the comment:

I've added a patch that would simply warn the user if a worker exits prematurely.

----------
keywords: +patch
Added file: http://bugs.python.org/file40257/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24927>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:39:29 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 25 Aug 2015 18:39:29 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440527969.61.0.676263845056.issue24829@psf.upfronthosting.co.za>


Adam Barto? added the comment:

R. David Murray: I understand that the behavior of programs differ if stdout is redirected. I just claim that at least in Windows, stdin and stdout are completely independent, so redirecting *stdout* shouldn't affect how data are read from *stdin*.

I know that Unicode handling in Windows is a completely different issue. I was just explaining how I ran into this issue. During my work on `win-unicode-console` I found out there is some (at least for me) suprising behavior regarding the stdio implementation in Python. So I raised issues (this one, issue17620, issue18597, issue18838).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:44:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 18:44:01 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440528241.31.0.814180880934.issue24829@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, I think we're constrained by the behavior of readline here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:49:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:49:27 +0000
Subject: [issue24938] Measure if _warnings.c is still worth having
Message-ID: <1440528567.54.0.786073455364.issue24938@psf.upfronthosting.co.za>


New submission from Brett Cannon:

_warnings.c was initially created to help with startup performance. It turned out to be a tricky bit of code to get right to continue to support the Python version of the module.

But now that we live in a world where we have startup benchmarks instead of hunches and we freeze code like importlib, maybe it's time to re-evaluate whether warnings.py is such a bad thing to have as part of the startup process? I would be curious to know what the performance impact is if we made _warnings the frozen version of warnings.py instead of the C code and measured the startup performance.

----------
messages: 249150
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Measure if _warnings.c is still worth having
type: performance
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24938>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:49:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:49:38 +0000
Subject: [issue24938] Measure if _warnings.c is still worth having
In-Reply-To: <1440528567.54.0.786073455364.issue24938@psf.upfronthosting.co.za>
Message-ID: <1440528578.84.0.941023767809.issue24938@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24938>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:52:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:52:51 +0000
Subject: [issue24305] The new import system makes it inconvenient to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440528771.76.0.811516212169.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So there are two approaches I see to solving this whole thing. One is for there to be a slight divergence between the C code and the Python code. For _warnings.warn(), nothing changes. For warnings.warn(), though, it does the expected frame skipping. This would mean that _warnings.warn() continues to exist for startup purposes but then user-level code and non-startup code uses the Python version that has the expected semantics. This requires figuring out why not importing _warnings.warn in warnings.py causes test failures.

The other option is someone helps me figure out why the C code is causing its test failures by triggering a -11 return in threaded/subprocess tests and prevent the divergence.

I have opened issue #24938 to actually re-evaluate one of the key points of _warnings.c which was startup performance. This was done about 7 years ago which pre-dates freezing code and providing simple C wrappers as necessary for internal use in Python like we do with importlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:53:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:53:55 +0000
Subject: [issue24938] Measure if _warnings.c is still worth having
In-Reply-To: <1440528567.54.0.786073455364.issue24938@psf.upfronthosting.co.za>
Message-ID: <1440528835.64.0.969437878399.issue24938@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I should also mention the other motivating factor was providing C access to the warnings system, but once again importlib blazed that trail already by providing a C API which simply uses the Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24938>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:55:46 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Aug 2015 18:55:46 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440528946.66.0.97374607131.issue24934@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

According to the docs, getargspec() should be replaced with getfullargspec(), which returns a compatible named tuple. This would probably also minimize the performance impact of the patch (I'm not sure getargspec() is in the critical path, but let's be careful).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Tue Aug 25 20:57:54 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 25 Aug 2015 18:57:54 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440529074.58.0.839971475495.issue24829@psf.upfronthosting.co.za>


Adam Barto? added the comment:

Behavior of which readline? GNU readline? Note that it is only one particular implmentation on one particular platform while Python should be as multiplatform as possible / viable.

And what behavior it is? More precisely, what incorrect behavior in Linux would it bring if the condition in 

    if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout)))
        rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
    else
        rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt);

was replaced by `!isatty (fileno (sys_stdin))`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:15:14 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 25 Aug 2015 19:15:14 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440530114.58.0.106080895152.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Thank you for the clarifications! Your point make sense, we don't want to exclude clang environments. I will analyze this and post some patches once I'm done with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:21:07 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 25 Aug 2015 19:21:07 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1440530467.6.0.262120394809.issue24937@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Thanks! I'll take good care of it :)
Give me a few days to prepare the docs change; this isn't very high priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:21:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2015 19:21:47 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440530507.0.0.906242809878.issue24829@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's the one we started with, and the one in most common use.

I don't even know if there would be a problem.  The thing to do would be to try it and find out (on both linux and windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Tue Aug 25 22:08:47 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 25 Aug 2015 20:08:47 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440533327.19.0.587716219008.issue24934@psf.upfronthosting.co.za>


Florin Papa added the comment:

Thank you all for your feedback on this matter.

According to the docs, starting from version 3.4, getfullargspec() is based on signature(), therefore the performance impact would not differ from the proposed implementation.

I will check if a newer version of django fixes this problem and modify the patch accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:23:58 2015
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 25 Aug 2015 21:23:58 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <1440537838.94.0.565731094063.issue24769@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I have merged it forward into 3.5.1 and 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:30:11 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 25 Aug 2015 21:30:11 +0000
Subject: [issue24939] Remove unicode_fornat.h from stringlib
Message-ID: <1440538211.37.0.431052107009.issue24939@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

Objects/stringlib/unicode_format.h does not belong in stringlib. Back when it was originally written for 2.x, it used stringlib to provide the str and unicode versions of str.format, str.__format__, int.__format__, etc.

However, in 3.x, and especially with PEP 393 (Flexible String Representation), not only is the stringlib functionality no longer needed, it's not used at all.

My suggestion is to just copy the source into Objects/unicodeobject.c, which is the only place it's used. Then delete the stringlib file.

The only downside of including it in unicodeobject.c is that it makes our largest C file about 8% larger:

wc -l says:
1284  Objects/stringlib/unicode_format.h
15414 Objects/unicodeobject.c

There's some argument to be made to separate out the int.__format__, float.__format__ etc. code, and move them to some other library. I don't think they're a huge part of unicode_format.h. And to separate them out would require creating some _Py_* functions to do their work. But it's probably the right thing to do. I'll investigate.

----------
assignee: eric.smith
components: Interpreter Core
messages: 249160
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Remove unicode_fornat.h from stringlib
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24939>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:35:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 21:35:24 +0000
Subject: [issue24769] Interpreter doesn't start when dynamic loading is
 disabled
In-Reply-To: <1438399062.56.0.479680111973.issue24769@psf.upfronthosting.co.za>
Message-ID: <20150825212507.19650.77209@psf.io>


Roundup Robot added the comment:

New changeset 931593401e3e by Larry Hastings in branch '3.5':
Issue #24769: Interpreter now starts properly when dynamic loading
https://hg.python.org/cpython/rev/931593401e3e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24769>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:35:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 21:35:24 +0000
Subject: [issue24867] Asyncio Task.get_stack fails with native coroutines
In-Reply-To: <1439565982.36.0.819644986175.issue24867@psf.upfronthosting.co.za>
Message-ID: <20150825212507.19650.77185@psf.io>


Roundup Robot added the comment:

New changeset 595614c08eeb by Yury Selivanov in branch '3.5':
Issue #24867: Fix asyncio.Task.get_stack() for 'async def' coroutines
https://hg.python.org/cpython/rev/595614c08eeb

New changeset 9b28f41f1353 by Larry Hastings in branch '3.5':
Merged in 1st1/cpython350 (pull request #5)
https://hg.python.org/cpython/rev/9b28f41f1353

New changeset ad48d5a4ef40 by Larry Hastings in branch '3.5':
Add missing Misc/NEWS item for merged pull request for issue #24867.
https://hg.python.org/cpython/rev/ad48d5a4ef40

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24867>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:35:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 21:35:25 +0000
Subject: [issue24847] Can't import tkinter in Python 3.5.0rc1
In-Reply-To: <1439342073.64.0.711373660068.issue24847@psf.upfronthosting.co.za>
Message-ID: <20150825212507.19650.97504@psf.io>


Roundup Robot added the comment:

New changeset dc9bdddca59b by Steve Dower in branch '3.5':
Issue #24847: Removes vcruntime140.dll dependency from Tcl/Tk.
https://hg.python.org/cpython/rev/dc9bdddca59b

New changeset b77ceefc34ff by Larry Hastings in branch '3.5':
Merged in stevedower/cpython350 (pull request #6)
https://hg.python.org/cpython/rev/b77ceefc34ff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24847>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:35:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Aug 2015 21:35:25 +0000
Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc
In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>
Message-ID: <20150825212507.19650.41525@psf.io>


Roundup Robot added the comment:

New changeset d93bb3d636cf by R David Murray in branch '3.5':
#21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/d93bb3d636cf

New changeset c1523d5dee3c by Larry Hastings in branch '3.5':
Merged in bitdancer/cpython350 (pull request #4)
https://hg.python.org/cpython/rev/c1523d5dee3c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21167>
_______________________________________

From report at bugs.python.org  Tue Aug 25 23:53:48 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 25 Aug 2015 21:53:48 +0000
Subject: [issue24939] Remove unicode_format.h from stringlib
In-Reply-To: <1440538211.37.0.431052107009.issue24939@psf.upfronthosting.co.za>
Message-ID: <1440539628.51.0.568066189192.issue24939@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
title: Remove unicode_fornat.h from stringlib -> Remove unicode_format.h from stringlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24939>
_______________________________________

From report at bugs.python.org  Wed Aug 26 00:18:17 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Aug 2015 22:18:17 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1440541097.99.0.535830916527.issue23144@psf.upfronthosting.co.za>


Robert Collins added the comment:

@ezio - you seem busy, so I'll commit this next week if its still pending.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23144>
_______________________________________

From report at bugs.python.org  Wed Aug 26 00:28:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 22:28:30 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440541710.64.0.558012351771.issue24829@psf.upfronthosting.co.za>


Martin Panter added the comment:

In Linux, the original stdin, stdout, stderr file descriptors refer to the same console by default, and you use normal file reads and writes on them. In Linux when Python uses Gnu Readline, the displayed input characters are indeed written to the original stdout file descriptor. For comparison, when Readline is not used, the displayed characters go to the original stdin console, because they are handled at a lower OS level before they are even read by Python and Readline.

By experimentation, the Bash shell seems to work similarly, except it uses stderr rather than stdout. You can freely redirect stdout, but if you redirect stderr it affects the output seen on the terminal. It may be possible to write to stdin to avoid the input and output being split up, but I think writing to an input-only file descriptor is a bad idea.

If you dropped the isatty() check for stdout in Linux, you may end up with the output of Readline in the file (assuming Readline is okay with this). The file would include all the cursor positioning codes, backspaces, etc, that Readline generates. But I haven?t actually tried this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Wed Aug 26 01:20:13 2015
From: report at bugs.python.org (Pastafarianist)
Date: Tue, 25 Aug 2015 23:20:13 +0000
Subject: [issue24788] HTTPException is derived from Exception instead of
 IOError
In-Reply-To: <1438719042.84.0.137488437732.issue24788@psf.upfronthosting.co.za>
Message-ID: <1440544813.58.0.779899421092.issue24788@psf.upfronthosting.co.za>


Pastafarianist added the comment:

I agree that the five exception types you mentioned (UnknownProtocol, UnknownTransferEncoding, IncompleteRead, BadStatusLine, LineTooLong) should be derived from IOError. EOFError is probably not a good choice here. It's not something I would expect to see in networking code. ValueError may be better, but I don't know enough about the library to tell whether it is common to use ValueError in similar contexts.

However, ImproperConnectionState (specifically, CannotSendRequest) may be not a programmer error, and, thus, it might be better to have it derived from IOError. See https://hg.python.org/cpython/file/3.5/Lib/http/client.py#l933. Depending on your point of view, you may consider this to be a programmer error or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24788>
_______________________________________

From report at bugs.python.org  Wed Aug 26 01:59:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 25 Aug 2015 23:59:16 +0000
Subject: [issue24788] HTTPException is derived from Exception instead of
 IOError
In-Reply-To: <1438719042.84.0.137488437732.issue24788@psf.upfronthosting.co.za>
Message-ID: <1440547156.47.0.514658310272.issue24788@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding CannotSendRequest: HTTPConnection will connect again with a new socket if a previous response will close the old connection. See a few lines below where you linked: ?If point (2) is true, then we .?.?. will open a new [socket] when a new request is made.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24788>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:13:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 00:13:03 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1440547983.48.0.90106575689.issue22936@psf.upfronthosting.co.za>


Robert Collins added the comment:

This itself is fixed.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:33:02 2015
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 26 Aug 2015 00:33:02 +0000
Subject: [issue23597] Allow easy display of local variables in log messages?
In-Reply-To: <1425607966.26.0.932937253201.issue23597@psf.upfronthosting.co.za>
Message-ID: <1440549182.73.0.0445552830558.issue23597@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23597>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:40:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Aug 2015 00:40:53 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <20150826004045.67848.36870@psf.io>


Roundup Robot added the comment:

New changeset 2e9cf58c891d by Robert Collins in branch 'default':
Issue #23552: Timeit now warns when there is substantial (4x) variance
https://hg.python.org/cpython/rev/2e9cf58c891d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:41:52 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 00:41:52 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1440549712.86.0.102138333497.issue23552@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:42:15 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 00:42:15 +0000
Subject: [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1440549735.49.0.292956919807.issue23183@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23183>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:45:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 00:45:30 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <1440549930.63.0.514224620634.issue21112@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Wed Aug 26 02:59:06 2015
From: report at bugs.python.org (Isaac Levy)
Date: Wed, 26 Aug 2015 00:59:06 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1440550746.71.0.584011976151.issue24920@psf.upfronthosting.co.za>


Isaac Levy added the comment:

I guess users need to check standard streams for None. There's not many uses of stream attributes in core libs.

Maybe catch should be Exception -- since it's documented to return a fallback on error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Wed Aug 26 03:40:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 26 Aug 2015 01:40:14 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1440553214.33.0.0200467068002.issue24911@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO the change notice for create_connection() should be moved to apply to the ?socket? class, perhaps the ?Socket Objects? section. Issue 9794 looks like context manager support was added specifically for create_connection(), however any socket object, no matter what function is used to create it, should be usable the same way for free.

Also, we should explicitly document that exiting the context manager (?with? statement) invokes close(), since that affects how the underlying socket is closed when makefile() has been used.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:01:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Aug 2015 02:01:27 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <1440554487.73.0.835946417196.issue24790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please post a 'checkpoint' patch with all changes so far, even though it has the 'other globals' problem.

Then look at the UI parts of Debugger.py. It has a Stackviewer class that subclasses ScrolledLIst instead of TreeWidget and a Namespaceviewer class currently used for both locals and globals.

The Namespace class is a frame containing a label (a labeled frame would work as well), a scrollbar, and a canvas containing a frame. The inner frame has a two-column grid: labels with names and entry boxes with values.  Currently, the entry boxes do nothing other than make values look different from names, as editing the entry does nothing. (Ignored entries are a bad UI design.)  Perhaps there was once an intention to propagate changes back to the running program. This would not apply to post-mortem stack viewing.

Starting with the checkpoint patch, I would like to modify Stackviewer to display globals for any item clicked in a separate frame, like Debugger.  This would removing the bug in the checkpoint patch and result in a patch that I might commit.  It would also be a step toward merging (in a new issue).

One possibility is a tree in a new frame.  Another is to import and reuse Debugger.Namespaceviewer.  The issue is whether users should be able to view the attributes of value objects (as in Stackviewer) or not (as in Debugger).  I previously suggested not, because it makes the interface look busy, but I just rediscovered a note based on debugger experience suggesting that it might be a good idea.  Lets start with a second tree.

When waiting for me to respond, you could look at #17942, about improving the command button part of debugger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:07:16 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Aug 2015 02:07:16 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440554836.64.0.17189166534.issue2786@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Moving target version to 3.6 (since we're discussing adding a new public C API).

This is an interesting problem, as seeing an expanding API like this (PyEval_EvalCode -> PyEval_EvalCodeEx -> PyEval_EvalCodeEx2) suggests to me that we actually have a missing abstraction layer trying to get out.

My first reaction was to say "Hey, let's just make the eval loop function aware, and add PyEval_EvalFunction", but that creates a conceptual dependency loop we don't really want. 

So I asked myself a different question: why aren't we storing the qualname as a code object attribute, even though it's a known constant at compile time?

Looking at PEP 3155 (https://www.python.org/dev/peps/pep-3155/ ) it doesn't look like the question came up, and I don't recall it coming up either.

However, looking at https://hg.python.org/cpython/file/default/Python/compile.c I also don't see any reason why we *couldn't* provide a qualname field on code objects, such that f.__code__.co_qualname would give the same answer as f.__qualname__. The compiler already knows the qualname at compile time, we're just currently storing it as a separate constant that gets composed together with the code object at runtime.

My suspicion is that the reason this *wasn't* done is because it's a slightly more intrusive change to the code generation pipeline, but I currently suspect following up with that increase in compiler complexity would be a better option than making the PyEval_* API more complicated.

----------
nosy: +ncoghlan
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:08:54 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Aug 2015 02:08:54 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440554934.23.0.445942108262.issue2786@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Moving this back to patch review while we consider the alternative approach of moving qualname storage into code objects, rather than continuing to transport qualnames separately.

----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:19:27 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 26 Aug 2015 02:19:27 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440555567.77.0.985235785912.issue2786@psf.upfronthosting.co.za>


Ben Longbons added the comment:

Code objects currently have no mutable fields.

So what are you planning to do about things like:

Foo = namedtuple('Foo', 'x y')
def frob(self):
    return self.x + self.y
# probably actually done via a @member(Foo) decorator
# so adding more code here is not a problem.
Foo.frob.__qualname__ = 'Foo.frob'
Foo.frob = frob
del frob

----------
nosy: +o11c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:40:26 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Aug 2015 02:40:26 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440556826.74.0.579734760622.issue24912@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Wed Aug 26 05:18:02 2015
From: report at bugs.python.org (Ilya Kulakov)
Date: Wed, 26 Aug 2015 03:18:02 +0000
Subject: [issue24940] RotatingFileHandler uses tell in non-binary mode to
 determine size of the file in bytes
Message-ID: <1440559082.45.0.784571189082.issue24940@psf.upfronthosting.co.za>


New submission from Ilya Kulakov:

According to the most recent documentation:

    Return the current stream position as an opaque number. The number does not usually represent a number of bytes in the underlying binary storage.

Therefore stream should be opened as 'ab' by using value of the encoding argument or sys.getdefaultencoding if it's None.

----------
messages: 249177
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: RotatingFileHandler uses tell in non-binary mode to determine size of the file in bytes
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24940>
_______________________________________

From report at bugs.python.org  Wed Aug 26 05:42:37 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 26 Aug 2015 03:42:37 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440560557.48.0.611225193253.issue2786@psf.upfronthosting.co.za>


Ben Longbons added the comment:

I made a minimal gist of my motivating code:

https://gist.github.com/o11c/ce0c2ff74b87ea71ad46

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 06:25:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 26 Aug 2015 04:25:55 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1440563155.84.0.378643246124.issue18383@psf.upfronthosting.co.za>


Martin Panter added the comment:

Florent?s manual reproducer is fixed by issue18383_34_2.diff, as is test___all__. And I think the new logic for changing the priority of the filter entries might be sound now. But it does seem like we are adding unnecessary complexity to the implementation just to avoid a quirk of the test suite. Maybe it would be better to save and restore the original filters in the test suite, with a comment explaining why. Or perhaps set a _warnings._options_processed flag to prevent the double initialization?

FTR Alex already hinted at this, but I only now realize issue18383_assert_warns_and_dups_v2.patch contains extra fixes for assertWarns() that are only applicable to 3.5+. They are basically a followup of Issue 16382 and Issue 23027, rather than the original issue here, although the symptom is almost the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Wed Aug 26 07:23:17 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 26 Aug 2015 05:23:17 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440566597.89.0.164874490024.issue24912@psf.upfronthosting.co.za>


Larry Hastings added the comment:

As Python 3.5 Release Manager, my official statement is: Eek!

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Wed Aug 26 08:16:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Aug 2015 06:16:14 +0000
Subject: [issue24913] newblock() Uninitialized Variable
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440569774.78.0.143251278713.issue24913@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40258/fix_deque_overrun.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 08:19:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Aug 2015 06:19:03 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440569943.92.0.214934695737.issue24913@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Larry, this may need to go into 3.5 if there is still an opportunity.

----------
assignee: rhettinger -> larry
nosy: +larry
priority: low -> high
title: newblock() Uninitialized Variable -> deque.index() overruns deque boundary
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:07:03 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 26 Aug 2015 07:07:03 +0000
Subject: [issue24941] classproperty
Message-ID: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

Quoting Guido van Rossum Aug 20 2015. Thread "Properties for classes possible?"

https://mail.python.org/pipermail/python-ideas/2015-August/035354.html

{{{
 think it's reasonable to propose @classproperty as a patch to CPython. It
needs to be C code. Not sure about the writable version. The lazy=True part
is not appropriate for th he stdlib (it's just a memoize pattern).
}}}

The solution I use at the moment:

{{{
# From http://stackoverflow.com/a/5192374/633961
class classproperty(object):
    def __init__(self, f):
        self.f = f
    def __get__(self, obj, owner):
        return self.f(owner)
}}}

According to Terry Jan Reedy the next step is to find
someone to translate this to C.

Sorry, my C knowledge is limited. Can anybody help?

----------
messages: 249182
nosy: guettli
priority: normal
severity: normal
status: open
title: classproperty

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:17:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 26 Aug 2015 07:17:20 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440573440.15.0.404219002454.issue5319@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the hints Robert. I will definitely add that defs entry.

I?m a bit unsure about preserving an existing non-zero exit status. It seems a slightly more complicated and unexpected way of do it to me. But I cannot remember why I was originally interested in this issue. Do you have a use case where keeping the exit status > 1 would be good?

Also need to add some entries to What?s New.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:20:44 2015
From: report at bugs.python.org (Florin Papa)
Date: Wed, 26 Aug 2015 07:20:44 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440573644.67.0.431801352154.issue24934@psf.upfronthosting.co.za>


Florin Papa added the comment:

I have modified the patch to introduce django_v3 to the benchmark suite and deprecate django_v2 for Python 3.6 and up. In order for django_v3 to work, the latest django release must be present in lib/Django-1.8.

Django-1.8 is attached as a zip file because the patch would be too large if it included all these files. In order for the modifications to work, extract the archive to lib/Django-1.8 .

Thank you,
Florin

----------
Added file: http://bugs.python.org/file40259/django_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:21:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Aug 2015 07:21:16 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440573676.11.0.370879448801.issue2786@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The reason I didn't put __qualname__ on code objects is that code objects don't have a __module__ either. That information, up to now, belongs on the module.

Conceptually, a code object could very well be used by multiple functions living in different modules. Now, in practice, I'm not sure that happens (except when constructing function objects on your own, which is not a terribly supported usecase I think).

Also, Ben makes a very point about being able to change a __qualname__. In particular, the user should *still* be able to change a function's __qualname__ even if it's technically stored on the code object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:21:28 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Aug 2015 07:21:28 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440573688.02.0.483671188624.issue2786@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:21:43 2015
From: report at bugs.python.org (Florin Papa)
Date: Wed, 26 Aug 2015 07:21:43 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440573703.15.0.0392143308364.issue24934@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


Added file: http://bugs.python.org/file40260/Django-1.8.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:22:56 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Aug 2015 07:22:56 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440573776.12.0.736951377851.issue2786@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Correcting myself:

> That information, up to now, belongs on the module.

on the function, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:40:51 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 07:40:51 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440574851.91.0.663876737311.issue5319@psf.upfronthosting.co.za>


Robert Collins added the comment:

def main():
   try:
       thing()
   except SomethingChanged:
       exit(1)
   except BinaryDiff:
       exit(2)
   except:
       exit(3)

This is the sort of pattern e.g. 'diff' has. 

Should exit(3) there become exit(1) ? exit(1) means 'succeeded and there were changes'. So no, 3,for this app, means 'broke entirely'.

Exiting with '1' is also poor/confusing for this app. So perhaps we should pick something rarely used - like 255. But anyhow the same logic applies: if an app signals 'error' with a different code, we shouldn't change the apps 'error' signal to be something else when we detect an error.

But OTOH preserving a non-zero not-error code when an error occurs is also wrong.

So I think, on reflection:
 1) pick an unusual code. Not 1. Not 77 (automake test skip code). Maybe 255? https://www.freebsd.org/cgi/man.cgi?query=sysexits&sektion=3&apropos=0&manpath=FreeBSD+10.2-RELEASE defines some codes we should avoid as well.
 2) We document that python itself may cause this exit code to be used and that apps written in python should never use that code
 3) we use your patch as it is - on shutdown error force it to this chosen value.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Wed Aug 26 10:21:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 26 Aug 2015 08:21:10 +0000
Subject: [issue2786] Names in function call exception should have class names, 
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440577270.16.0.520017705118.issue2786@psf.upfronthosting.co.za>


Martin Panter added the comment:

Note to self: this is about changing the name in an exception message, not in the back-trace of call sites that triggered an exception :)

----------
title: Names in traceback should have class names, if they're methods -> Names in function call exception should have class names, if they're methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 10:31:39 2015
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 26 Aug 2015 08:31:39 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440577899.57.0.938906685168.issue24912@psf.upfronthosting.co.za>


Mark Shannon added the comment:

Eek! indeed :)

I intend to track down the cause of this on Monday, and hopefully come up with a fix, unless anyone beats me to it. 

Does anyone know if there is another issue for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Wed Aug 26 10:52:02 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Aug 2015 08:52:02 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440579122.47.0.562839093527.issue24913@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40261/fix_deque_overrun2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 10:54:19 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Aug 2015 08:54:19 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440579259.4.0.477837681355.issue24294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The only way for this change to *break* something is if:

1. They're turning warnings into errors, or are otherwise sensitive to a deprecation warning being emitted
2. They're running code programmatically by way of an interactive REPL path

I think we're far more likely to break something else messing about with TTY detection, than we are keeping things as simple as we can and saying that if folks are running code as if they're a human rather than like a computer, then they're going to get the same deprecation warnings we want a human to see. *If* we get significant bug reports about that during the 3.6 alpha/beta cycle, *then* we can potentially consider limiting it to cases with an actual TTY. I just don't want us to borrow trouble and make this unnecessarily hard to test in the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Wed Aug 26 11:07:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 26 Aug 2015 09:07:42 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440580062.36.0.283759134162.issue5319@psf.upfronthosting.co.za>


Martin Panter added the comment:

I guess I like setting the status to 1 because it matches the status already used by the default exception handling, the value when you raise SystemExit("error message"), and the value used for most internal errors. However I did discover that the exit status is 2 if you give Python wrong CLI arguments or there is an OS error opening a script file.

I?m still rather unsure, only weakly in favour of my original proposal. Maybe see if anyone else has an opinion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Wed Aug 26 11:16:23 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 26 Aug 2015 09:16:23 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440580583.72.0.762481000544.issue5319@psf.upfronthosting.co.za>


Robert Collins added the comment:

Right. So I think one could also propose that the default exception handling should also change to this new number, but it is a different situation - programs don't conflict with that - they allow it to bubble up, but this situation is outside its control.

CLI handling of Python itself is clearly outside both situations and there's no need to reevaluate it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Wed Aug 26 11:59:55 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Aug 2015 09:59:55 +0000
Subject: [issue2786] Names in function call exception should have class names, 
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440583195.42.0.867025916606.issue2786@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

With __qualname__ being mutable, I agree that adding __code__.co_qualname wouldn't be a substitute for that. Instead, similar to the relationship between __name__ and __code__.co_name, they would start out the same, but the function attribute may change later (e.g. through the use of functools.wraps).

However, that also highlights why we need to use the compile time qualname in the traceback, rather than the runtime one: because we currently use the compile time name from the code object rather than the runtime name from the function.

A test case to demonstrate that:

>>> def f():
...     1/0
... 
>>> import functools
>>> @functools.wraps(f)
... def g():
...     return f()
... 
>>> g()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in g
  File "<stdin>", line 2, in f
ZeroDivisionError: division by zero
>>> g.__qualname__
'f'
>>> g.__name__
'f'

Note that "g" still appears in the relevant traceback line, even though both __name__ and __qualname__ have been updated to refer to "f". For a traceback we want to know where the source of the function actually lives, not where it claims to be from for human introspection purposes.

As far as the comparison to __module__ goes, I think that's a different case - we couldn't add that to the code object even if we wanted to, because the compiler doesn't know the module name, it only knows the file name. It's also possible to take an already compiled python file, move it to a different directory, and have the module name change due to the new location in the package hierarchy. __qualname__ is different as, like __name__, it's entirely local to the module and hence available to the compiler at compile time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 12:17:34 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Aug 2015 10:17:34 +0000
Subject: [issue2786] Names in function call exception should have class names, 
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440584254.8.0.912135462756.issue2786@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Hmm, I'd made the same mistake Martin did - I was looking at the tracebacks moreso than at the exception message itself. Looking at the argument unpacking exception message in the context of the test case above, that also uses __code__.co_name rather than the runtime function name:

>>> g(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: g() takes 0 positional arguments but 1 was given

In this case though, I think that's arguably a problem, as we probably want error messages (unlike tracebacks) to include the "intended for human consumption" name, but they currently don't, they expose the name of the wrapper function if it's actually constraining its arguments rather than passing them through for subsequent validation:

>>> def make_wrapper(f):
...     @functools.wraps(f)
...     def wrapper():
...         return f()
...     return wrapper
... 
>>> @make_wrapper
... def g():
...     return f()
... 
>>> g(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: wrapper() takes 0 positional arguments but 1 was given

That makes me more inclined towards a solution like Daniil's patch, but the growing signature of PyEval_Code* still bothers me. Perhaps we could collect the various runtime state arguments up into a "PyEvalScope" struct and make the new API PyEval_EvalCodeInScope(PyObject *code, PyObject *scope)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 13:53:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2015 11:53:58 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1440590038.53.0.833308631765.issue24920@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think checking for None would be better.  Catching Exception might mask other errors that the user would want to know about.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Wed Aug 26 13:56:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2015 11:56:47 +0000
Subject: [issue24940] RotatingFileHandler uses tell in non-binary mode to
 determine size of the file in bytes
In-Reply-To: <1440559082.45.0.784571189082.issue24940@psf.upfronthosting.co.za>
Message-ID: <1440590207.34.0.812194317759.issue24940@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24940>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:03:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2015 12:03:07 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1440590587.35.0.99970346166.issue24294@psf.upfronthosting.co.za>


R. David Murray added the comment:

Matthias: just print it and let the doctest pass.  That's consistent with how unittest works (unless warnings have been turned into errors, in which case it should fail, but I don't think you have to do anything to make that happen).

Nick: OK.  It is true that we aren't going to break anything if we get this wrong, just mildly annoy people :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Wed Aug 26 15:38:46 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 26 Aug 2015 13:38:46 +0000
Subject: [issue24941] classproperty
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440596326.84.0.081469510437.issue24941@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:23:56 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 26 Aug 2015 14:23:56 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440599036.22.0.945024586034.issue24913@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Please create a pull request at your earliest convenience.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:30:44 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 26 Aug 2015 14:30:44 +0000
Subject: [issue24941] classproperty
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440599444.93.0.0596202058961.issue24941@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
components: +Interpreter Core
nosy: +yselivanov
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:34:13 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 26 Aug 2015 14:34:13 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440599653.04.0.991059458396.issue24912@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This exciting new feature was added in checkin c0d25de5919e addressing issue #22986.  Perhaps the core devs who added it would like to chime in.

----------
nosy: +benjamin.peterson, njs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:34:29 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 26 Aug 2015 14:34:29 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1440599669.37.0.696559054674.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

UPDATE:
Still working on the test_hash issue; not making much progress

QUESTION
Does gdb have to be configured with the --with-python switch in order to debug the python binary correctly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:41:39 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 14:41:39 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440600099.94.0.452417462728.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I modified the patches with clang support.

Also, I added an important check for the architecture on which PGO is running. Our proposal targets x86 platforms, since our measurements are made only on x86 hardware.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:41:50 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 14:41:50 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440600110.84.0.533280388744.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40262/python2.7-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 16:41:59 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 14:41:59 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440600119.1.0.18864456437.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40263/python3.6-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:10:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Aug 2015 15:10:18 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <20150826151015.21451.31342@psf.io>


Roundup Robot added the comment:

New changeset ae8ec66adc7f by Raymond Hettinger in branch '3.5':
Issue #24913: Fix overrun error in deque.index().
https://hg.python.org/cpython/rev/ae8ec66adc7f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:12:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Aug 2015 15:12:14 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440601934.12.0.226525745409.issue24913@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Please create a pull request at your earliest convenience.

I'm not sure what that entails.  Can you just apply ae8ec66adc7f and take it from here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:19:01 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 26 Aug 2015 15:19:01 +0000
Subject: [issue24913] deque.index() overruns deque boundary
In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za>
Message-ID: <1440602341.32.0.741587650899.issue24913@psf.upfronthosting.co.za>


Larry Hastings added the comment:

https://docs.python.org/devguide/devcycle.html#release-candidate-rc

https://mail.python.org/pipermail/python-dev/2015-August/141167.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24913>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:38:17 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Aug 2015 15:38:17 +0000
Subject: [issue24941] Add classproperty as builtin class
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440603497.74.0.652373846236.issue24941@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: needs patch -> test needed
title: classproperty -> Add classproperty as builtin class

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:38:29 2015
From: report at bugs.python.org (Ryan Hiebert)
Date: Wed, 26 Aug 2015 15:38:29 +0000
Subject: [issue24941] Add classproperty as builtin class
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440603509.52.0.839313335176.issue24941@psf.upfronthosting.co.za>


Changes by Ryan Hiebert <ryan at ryanhiebert.com>:


----------
nosy: +ryanhiebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:49:32 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 26 Aug 2015 15:49:32 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1440604172.06.0.931372069486.issue9262@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached uitabs.py.  From the header comments:

Standalone 'tabs' widget to switch between multiple different views.

Unlike the Tkinter ttk.Notebook widget, this widget is suitable for
displaying a potentially large number of tabs, as might be found in a
tabbed editor. If there are too many tabs to show based on the available
width, the remainder can be viewed via a popup menu on the last tab.

Tabs can be rearranged by dragging, closed, or new tabs added. Each tab
can have a title which is displayed in the tab, a tooltip for when the
mouse hovers over the tab, and a 'dirty' indicator that can be used to
indicate files needing to be saved.

The appearance and behaviour of the tabs is strongly influenced by the
TextMate editor on Mac OS X.

Implementation is via a single Tkinter canvas.

Unlike many other tabbed widgets, this widget does not take care of
actually switching content being displayed; this is left to the caller.

A UITabsObserver (see below) must be provided to the widget, and is
used to notify the caller when changes are made that must be reflected
in other parts of the user interface.

----------
Added file: http://bugs.python.org/file40264/uitabs.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:51:51 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 26 Aug 2015 15:51:51 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1440604311.26.0.570439249327.issue9262@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached newTabExtension.py, which is Roger's tab extension, hacked to use uitabs.py instead of the UI previously built into that extension.

----------
Added file: http://bugs.python.org/file40265/newTabExtension.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:53:11 2015
From: report at bugs.python.org (Jakub Czaplicki)
Date: Wed, 26 Aug 2015 15:53:11 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1440604391.8.0.961758331866.issue4735@psf.upfronthosting.co.za>


Jakub Czaplicki added the comment:

Such issues are most likely caused by pending windows update that requires machine reboot. This would explain Shereef's comment in msg133158.

----------
nosy: +Jakub Czaplicki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4735>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:56:10 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 26 Aug 2015 15:56:10 +0000
Subject: [issue17942] IDLE Debugger: Improve GUI
In-Reply-To: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za>
Message-ID: <1440604570.33.0.22457990678.issue17942@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached debugpanel.py, implementing a ttk-based mockup of one possible redesign of the debugger UI, as seen in http://bugs.python.org/file40234/newtabs.png

----------
Added file: http://bugs.python.org/file40266/debugpanel.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17942>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:01:12 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Wed, 26 Aug 2015 16:01:12 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1440599669.37.0.696559054674.issue23496@psf.upfronthosting.co.za>
Message-ID: <D91E6E2A-4A8D-4203-BD2E-02B19D1C3D13@gmail.com>


Ryan Gonzalez added the comment:

I don't think so. I believe that switch is just to enable writing gdb extensions in Python.

On August 26, 2015 9:34:29 AM CDT, Cyd Haselton <report at bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>UPDATE:
>Still working on the test_hash issue; not making much progress
>
>QUESTION
>Does gdb have to be configured with the --with-python switch in order
>to debug the python binary correctly?
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:07:23 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 16:07:23 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440605243.94.0.959584568115.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Removed file: http://bugs.python.org/file40262/python2.7-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:07:32 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 16:07:32 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440605252.66.0.639122104086.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Removed file: http://bugs.python.org/file40263/python3.6-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:15:10 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 16:15:10 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440605710.56.0.0310602288519.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40267/python2.7-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:15:15 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 26 Aug 2015 16:15:15 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440605715.97.0.616096058791.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40268/python3.6-pgo-v04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:55:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Aug 2015 16:55:55 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440608155.58.0.964620953726.issue24934@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM on a cursory glance. Hopefully someone will have time to try the patch out and then commit it if everything works out.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:16:18 2015
From: report at bugs.python.org (Erik Bray)
Date: Wed, 26 Aug 2015 17:16:18 +0000
Subject: [issue24941] Add classproperty as builtin class
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440609378.43.0.0148813884653.issue24941@psf.upfronthosting.co.za>


Erik Bray added the comment:

A read-only classproperty is fairly trivial to implement in pure Python and has been done.

A good reason to have a classproperty implementation in CPython would be to support settable/deleteable classproperties.  The problem is that can't be done with the descriptor protocol on its own without a custom metaclass.  classproperty would have to somehow be special-cased, perhaps in type_setattro, say.  I don't know if that can just be done lightly.

Otherwise I don't see the advantage of adding a classproperty type to CPython?

----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:19:15 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Aug 2015 17:19:15 +0000
Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime
 object
In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>
Message-ID: <1440609555.86.0.823797316489.issue22241@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I guess we can change stdlib datetime.timezone.utc's str() to 'UTC'. Make sure to update both the C and the Python version, and the tests, and the docs. It's going to have to go into 3.6.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22241>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:20:36 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 Aug 2015 17:20:36 +0000
Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime
 object
In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>
Message-ID: <1440609636.1.0.269376031461.issue22241@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
assignee:  -> belopolsky
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22241>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:43:03 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 26 Aug 2015 18:43:03 +0000
Subject: [issue24939] Remove unicode_format.h from stringlib
In-Reply-To: <1440538211.37.0.431052107009.issue24939@psf.upfronthosting.co.za>
Message-ID: <1440614583.22.0.409482630625.issue24939@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Actually, int.__format__, etc. are not in this file. So that's good.

The things that are in this file but are unrelated to unicodeobject.c are the support routines for implementing string.Formatter. I think I'll move those elsewhere, as a first step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24939>
_______________________________________

From report at bugs.python.org  Wed Aug 26 21:57:58 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Aug 2015 19:57:58 +0000
Subject: [issue24938] Measure if _warnings.c is still worth having
In-Reply-To: <1440528567.54.0.786073455364.issue24938@psf.upfronthosting.co.za>
Message-ID: <1440619078.19.0.301146644824.issue24938@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here are the benchmark results of freezing warnings.py as _frozen_warnings (very quick hack which doesn't use _frozen_warnings is attached). Basically -S slows down by about 3% and normal startup has no measurable impact. Not sure if that's worth it to simplify the warnings code or not.


INFO:root:Automatically selected timer: perf_counter
INFO:root:Skipping benchmark bzr_startup; not compatible with Python 3.6
INFO:root:Skipping benchmark hg_startup; not compatible with Python 3.6
Running normal_startup...
INFO:root:Running `../cpython/default/python.exe -c ` 1000 times
INFO:root:Running `../cpython/pristine/python.exe -c ` 1000 times
Running startup_nosite...
INFO:root:Running `../cpython/default/python.exe -S -c ` 2000 times
INFO:root:Running `../cpython/pristine/python.exe -S -c ` 2000 times

Report on Darwin Bretts-MacBook-Pro.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64 i386
Total CPU cores: 4

### startup_nosite ###
Min: 0.311247 -> 0.317280: 1.02x slower
Avg: 0.316682 -> 0.325945: 1.03x slower
Significant (t=-17.89)
Stddev: 0.00326 -> 0.00403: 1.2360x larger

The following not significant results are hidden, use -v to show them:
normal_startup.

----------
keywords: +patch
Added file: http://bugs.python.org/file40269/issue24938.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24938>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:22:45 2015
From: report at bugs.python.org (Andrey Wagin)
Date: Wed, 26 Aug 2015 20:22:45 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1440620565.65.0.2881786126.issue24933@psf.upfronthosting.co.za>


Andrey Wagin added the comment:

There is the same behavior for python 3.4
>>> sks[1].send(b"asdfasdfsadfasdfsdfsadfsdfasdfsdfasdfsadfa")
42
>>> sks[0].recv(1, socket.MSG_PEEK | socket.MSG_TRUNC)
b'a\x00Nx\x94\x7f\x00\x00sadfasdfsdfsadfsdfasdfsdfasdfsadfa'
>>>

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:24:33 2015
From: report at bugs.python.org (Andrey Wagin)
Date: Wed, 26 Aug 2015 20:24:33 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1440620673.37.0.691813053831.issue24933@psf.upfronthosting.co.za>


Changes by Andrey Wagin <avagin at gmail.com>:


----------
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:41:53 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Wed, 26 Aug 2015 20:41:53 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440621713.43.0.700107112199.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

Here is a new patch, with modifications according to your review Victor.
Thanks!

----------
Added file: http://bugs.python.org/file40270/multibind2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:47:38 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 26 Aug 2015 20:47:38 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440622058.79.0.255887074657.issue23630@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Here is a new patch, with modifications according to your review Victor.

Could you please generate the patch with 'hg diff', so that code review works with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:51:43 2015
From: report at bugs.python.org (Lee Clemens)
Date: Wed, 26 Aug 2015 20:51:43 +0000
Subject: [issue24942] Remove domain from ipaddress.reverse_pointer property
 and add method
Message-ID: <1440622303.5.0.869445888168.issue24942@psf.upfronthosting.co.za>


New submission from Lee Clemens:

To lookup info from Cymru (https://www.team-cymru.org/IP-ASN-mapping.html#dns) the domain needs to be changed. Although I have not personally seen any, there may also be cases where dropping the domain altogether would be helpful.

So I am wondering if the @property should return the 'bare' reversed address and a new function be added to append the version-appropriate domain as the default or an optional arg as a convenience?

Ref: https://bugs.python.org/issue20480

----------
components: Library (Lib)
messages: 249217
nosy: leeclemens
priority: normal
severity: normal
status: open
title: Remove domain from ipaddress.reverse_pointer property and add method
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24942>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:51:50 2015
From: report at bugs.python.org (Lee Clemens)
Date: Wed, 26 Aug 2015 20:51:50 +0000
Subject: [issue24942] Remove domain from ipaddress.reverse_pointer property
 and add method
In-Reply-To: <1440622303.5.0.869445888168.issue24942@psf.upfronthosting.co.za>
Message-ID: <1440622310.79.0.0386884572691.issue24942@psf.upfronthosting.co.za>


Changes by Lee Clemens <java at leeclemens.net>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24942>
_______________________________________

From report at bugs.python.org  Wed Aug 26 22:58:11 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Wed, 26 Aug 2015 20:58:11 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440622691.87.0.183950609556.issue23630@psf.upfronthosting.co.za>


Changes by Yann Sionneau <ys at m-labs.hk>:


Removed file: http://bugs.python.org/file40270/multibind2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Aug 26 23:02:50 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Wed, 26 Aug 2015 21:02:50 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440622970.6.0.862054465938.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

Ah yes, sorry about that.
Here is a new patch.
However, I worked on these sources: https://github.com/python/asyncio which now I understand was not the correct repository, but I added a tests_require="netifaces" in the setup.py, where can I add this dependency in the CPython repository architecture?
Thanks!

----------
Added file: http://bugs.python.org/file40271/multibind2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Aug 26 23:27:04 2015
From: report at bugs.python.org (Pastafarianist)
Date: Wed, 26 Aug 2015 21:27:04 +0000
Subject: [issue24788] HTTPException is derived from Exception instead of
 IOError
In-Reply-To: <1438719042.84.0.137488437732.issue24788@psf.upfronthosting.co.za>
Message-ID: <1440624424.63.0.124330144315.issue24788@psf.upfronthosting.co.za>


Pastafarianist added the comment:

My bad then.

How do we proceed with introducing a change to the standard library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24788>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:35:46 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 26 Aug 2015 22:35:46 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440628546.64.0.537504497554.issue23630@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Left some feedback in the code review.

I have a question about the api: so we allow to pass a set of hosts to create_server, but why do we have only a single port?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 05:15:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Aug 2015 03:15:09 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <20150827031505.22334.5787@psf.io>


Roundup Robot added the comment:

New changeset 919cee158a89 by Terry Jan Reedy in branch '2.7':
Issue #24782: In Idle extension config dialog, replace tabs with sorted list.
https://hg.python.org/cpython/rev/919cee158a89

New changeset ce13593e378c by Terry Jan Reedy in branch '3.4':
Issue #24782: In Idle extension config dialog, replace tabs with sorted list.
https://hg.python.org/cpython/rev/ce13593e378c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Thu Aug 27 05:23:52 2015
From: report at bugs.python.org (Matheus Vieira Portela)
Date: Thu, 27 Aug 2015 03:23:52 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440645832.76.0.305031902271.issue3548@psf.upfronthosting.co.za>


Matheus Vieira Portela added the comment:

Let me check whether I understood you suggestion...

What you are saying is that it is already possible to pipeline shell commands through subprocess, such as in the following line?

subprocess.call('ls -l | grep Music', shell=True)

However, this requires the command to be executed in a shell environment. Hence, it would be a good idea to extend it to non-shell command execution. Is this right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Thu Aug 27 05:38:29 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Aug 2015 03:38:29 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <20150827033825.19640.133@psf.io>


Roundup Robot added the comment:

New changeset 14ac7deba91f by Terry Jan Reedy in branch '2.7':
Issue #24790: Restore unused function.
https://hg.python.org/cpython/rev/14ac7deba91f

New changeset eec5e81b38d1 by Terry Jan Reedy in branch '3.4':
Issue #24790: Restore unused function.
https://hg.python.org/cpython/rev/eec5e81b38d1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Thu Aug 27 09:18:51 2015
From: report at bugs.python.org (Sworddragon)
Date: Thu, 27 Aug 2015 07:18:51 +0000
Subject: [issue24943] Simplifying os.exec*
Message-ID: <1440659931.7.0.364118068973.issue24943@psf.upfronthosting.co.za>


New submission from Sworddragon:

I'm seeing in the documentation 8 different os.exec* functions that differ only slightly. I think from the way they are differing they could also all be merged into 1 function which could look like this:

os.exec(file, args, env, use_path)

- file is the path to the executable file and if use_path is True the PATH environment variable will be used to look for it (reflects p).
- args will be a dynamic list or tuple of arguments as it can handle a fixed and a variable number of arguments (reflects v).
- env is the mapping of the environment variables which will be used or None if the environment variables of the current process shall be used (reflects e).

env would default to None and use_path either to False or True.

----------
components: Library (Lib)
messages: 249224
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Simplifying os.exec*
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24943>
_______________________________________

From report at bugs.python.org  Thu Aug 27 10:49:12 2015
From: report at bugs.python.org (Florin Papa)
Date: Thu, 27 Aug 2015 08:49:12 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440665352.13.0.588811528327.issue24934@psf.upfronthosting.co.za>


Florin Papa added the comment:

I have modified the Django-1.8.zip archive to extract to Django-1.8 directory.

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy django_v3.patch to the current directory and Django-1.8.zip to the lib/ directory
hg import --no-commit django_v3.patch
cd lib/
unzip Django-1.8.zip

----------
Added file: http://bugs.python.org/file40272/Django-1.8.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Thu Aug 27 10:58:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2015 08:58:08 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440665888.43.0.590095779727.issue24934@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Both the fix and the v3 benchmark sound good to me. Note I haven't tried them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:12:34 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 27 Aug 2015 09:12:34 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440666754.09.0.599700959231.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I fixed the files after the review. Regarding the PROFILE_OPT_OLD line, I think that it is better to keep also the old task used for PGO, until clear evidence and measurements that regrtest is performing better on other architectures exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:12:47 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 27 Aug 2015 09:12:47 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440666767.92.0.727895088626.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40273/python2.7-pgo-v05.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:12:55 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 27 Aug 2015 09:12:55 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440666775.9.0.719956176518.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40274/python3.6-pgo-v05.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:15:35 2015
From: report at bugs.python.org (Hassan El Karouni)
Date: Thu, 27 Aug 2015 09:15:35 +0000
Subject: [issue24944] traceback when using tempfile module on windows
Message-ID: <1440666935.19.0.799788470417.issue24944@psf.upfronthosting.co.za>


New submission from Hassan El Karouni:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.mkstemp()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\tempfile.py", line 308, in mkstemp
    return _mkstemp_inner(dir, prefix, suffix, flags)
  File "C:\Python27\lib\tempfile.py", line 240, in _mkstemp_inner
    _set_cloexec(fd)
  File "C:\Python27\lib\tempfile.py", line 50, in _set_cloexec
    flags = _fcntl.fcntl(fd, _fcntl.F_GETFD, 0)
AttributeError: 'module' object has no attribute 'F_GETFD'


On line 51 in tempfile.py, an AttributeError exception is not caught. The problem is caused by the fact that on Windows, the fcntl module is supposed not to exist, but in my case, a dummy module with the same name was put on the path. This means that line 50 is run thru when making the mkstemp() call.
The fix is to catch the AttributeError exception on line 51.
The bug might also affect Python 3 but this is to be checked.

----------
components: Library (Lib)
messages: 249228
nosy: Hassan El Karouni
priority: normal
severity: normal
status: open
title: traceback when using tempfile module on windows
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24944>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:42:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Aug 2015 09:42:35 +0000
Subject: [issue24944] traceback when using tempfile module on windows
In-Reply-To: <1440666935.19.0.799788470417.issue24944@psf.upfronthosting.co.za>
Message-ID: <1440668555.62.0.145794067296.issue24944@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, do you have a file called fcntl.py in your project?

Try:

>>> import fcntl
>>> fcntl.__file__
'/usr/lib64/python2.7/lib-dynload/fcntlmodule.so'

This module should be available on Windows.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24944>
_______________________________________

From report at bugs.python.org  Thu Aug 27 12:16:06 2015
From: report at bugs.python.org (Hassan El Karouni)
Date: Thu, 27 Aug 2015 10:16:06 +0000
Subject: [issue24944] traceback when using tempfile module on windows
In-Reply-To: <1440666935.19.0.799788470417.issue24944@psf.upfronthosting.co.za>
Message-ID: <1440670566.54.0.897815732998.issue24944@psf.upfronthosting.co.za>


Hassan El Karouni added the comment:

fcntl.__file__  returns  "fcntl.py". The file is located under site-packages.
The contents of the file are:
def fcntl(fd, op, arg=0):
    return 0
        
def ioctl(fd, op, arg=0, mutable_flag=True):
    if mutable_flag:
        return 0
    else:
        return ""
    
def flock(fd, op):
    return
      
def lockf(fd, operation, length=0, start=0, whence=0):
    return

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24944>
_______________________________________

From report at bugs.python.org  Thu Aug 27 13:31:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Aug 2015 11:31:59 +0000
Subject: [issue24944] traceback when using tempfile module on windows
In-Reply-To: <1440666935.19.0.799788470417.issue24944@psf.upfronthosting.co.za>
Message-ID: <1440675119.73.0.30359291745.issue24944@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> fcntl.__file__  returns  "fcntl.py". The file is located under site-packages.

Ok, it's not a bug in Python, but in your local setup. Rename this file to fcntl.py.old, it should fix your issue.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24944>
_______________________________________

From report at bugs.python.org  Thu Aug 27 15:50:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2015 13:50:24 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440683424.38.0.536924904717.issue3548@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, I'm talking about https://docs.python.org/3/library/pipes.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Thu Aug 27 15:50:54 2015
From: report at bugs.python.org (Erik Bray)
Date: Thu, 27 Aug 2015 13:50:54 +0000
Subject: [issue24945] Expose Py_TPFLAGS_ values from Python
Message-ID: <1440683454.06.0.831934129277.issue24945@psf.upfronthosting.co.za>


New submission from Erik Bray:

Although admittedly rare, I've on more than one occasion wanted to inspect the tp_flags of a given class.  It seems silly to me that although tp_flags is exposed to Python via type.__flags__, I then have to go rummaging around in Include/object.h in order to actually interpret the value of that attribute.

It would be nice, then, if the Py_TPFLAGS_* values were exposed as constants somewhere in Python (perhaps in the sys module)?

If it's agreed this is a good idea I'll gladly provide a patch if someone can point me toward where this would best live.

----------
components: Interpreter Core
messages: 249233
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Expose Py_TPFLAGS_ values from Python
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24945>
_______________________________________

From report at bugs.python.org  Thu Aug 27 15:52:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2015 13:52:54 +0000
Subject: [issue24943] Simplifying os.exec*
In-Reply-To: <1440659931.7.0.364118068973.issue24943@psf.upfronthosting.co.za>
Message-ID: <1440683574.87.0.0806299039936.issue24943@psf.upfronthosting.co.za>


R. David Murray added the comment:

The functions in the os module are (for the most part) thin wrappers around OS apis (mostly posix).  The 8 function reflect the posix functions.  If you want a convenience interface, use the subprocess module.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24943>
_______________________________________

From report at bugs.python.org  Thu Aug 27 16:00:36 2015
From: report at bugs.python.org (Erik Bray)
Date: Thu, 27 Aug 2015 14:00:36 +0000
Subject: [issue24945] Expose Py_TPFLAGS_ values from Python
In-Reply-To: <1440683454.06.0.831934129277.issue24945@psf.upfronthosting.co.za>
Message-ID: <1440684036.8.0.78565770156.issue24945@psf.upfronthosting.co.za>


Erik Bray added the comment:

Alternatively (or additionally) it would be nice if type.__flags__ were some PyStructSequence-based type (though as a subtype of int for backwards compat).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24945>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:43:40 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Thu, 27 Aug 2015 16:43:40 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440693820.34.0.958937444827.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

All right, thanks.
I fixed everything but the thing about getaddrinfo being Mock'ed.
How am I supposed to handle the method being called with a Mock'ed getaddrinfo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:44:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 Aug 2015 16:44:16 +0000
Subject: [issue24946] Tkinter tests that fail on linux in tiling window manager
Message-ID: <1440693856.91.0.458235687359.issue24946@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Serhiy, Florian emailed this to me in response to my pydev post on Linux gui tests. I'll let you decide if you think anything needs to be done.

>>>>>>>from Florian
FWIW, those tests seem to fail when using a tiling window manager
(herbstluftwm):

======================================================================
FAIL: test_pack_configure_anchor (tkinter.test.test_tkinter.test_geometry_managers.PackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 48, in test_pack_configure_anchor
    check('n', '30x70+135+20')
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 47, in check
    self.assertEqual(a.winfo_geometry(), geom)
AssertionError: '30x70+210+20' != '30x70+135+20'
- 30x70+210+20
?       - ^
+ 30x70+135+20
?        ^^


======================================================================
FAIL: test_pack_configure_expand (tkinter.test.test_tkinter.test_geometry_managers.PackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 86, in test_pack_configure_expand
    check('20x40+0+80', '50x30+135+0', '80x80+220+75', '40x30+100+170')
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 78, in check
    self.assertEqual(a.winfo_geometry(), geoms[0])
AssertionError: '20x40+0+102' != '20x40+0+80'
- 20x40+0+102
?         ^ -
+ 20x40+0+80
?         ^


======================================================================
FAIL: test_pack_configure_padx_ipadx_fill (tkinter.test.test_tkinter.test_geometry_managers.PackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 125, in test_pack_configure_padx_ipadx_fill
    check('20x40+260+80', '240x200+0+0', side='right', padx=20)
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 123, in check
    self.assertEqual(a.winfo_geometry(), geom1)
AssertionError: '20x40+412+102' != '20x40+260+80'
- 20x40+412+102
+ 20x40+260+80


======================================================================
FAIL: test_pack_configure_pady_ipady_fill (tkinter.test.test_tkinter.test_geometry_managers.PackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 167, in test_pack_configure_pady_ipady_fill
    check('20x40+280+80', '280x200+0+0', side='right', pady=20)
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 165, in check
    self.assertEqual(a.winfo_geometry(), geom1)
AssertionError: '20x40+432+102' != '20x40+280+80'
- 20x40+432+102
+ 20x40+280+80


======================================================================
FAIL: test_pack_configure_side (tkinter.test.test_tkinter.test_geometry_managers.PackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 208, in test_pack_configure_side
    check('top', '20x40+140+0', '300x160+0+40')
  File "/usr/lib/python3.4/tkinter/test/test_tkinter/test_geometry_managers.py", line 206, in check
    self.assertEqual(a.winfo_geometry(), geom1)
AssertionError: '20x40+216+0' != '20x40+140+0'
- 20x40+216+0
?       - ^
+ 20x40+140+0
?        ^^

They however run fine in floating mode, so I'm guessing this is just a
limitation of those tests.

----------
components: Tkinter
messages: 249237
nosy: The-Compiler, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Tkinter tests that fail on linux in tiling window manager
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24946>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:48:41 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Aug 2015 16:48:41 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440694121.73.0.304948279865.issue23630@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> How am I supposed to handle the method being called with a Mock'ed getaddrinfo?

Why would you call it that way?  Are regular asyncio users going to mock it in their production/test code?

If the only case for using mocks there are asyncio unittests -- just don't do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:52:16 2015
From: report at bugs.python.org (Matheus Vieira Portela)
Date: Thu, 27 Aug 2015 16:52:16 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440694336.37.0.688273190147.issue3548@psf.upfronthosting.co.za>


Matheus Vieira Portela added the comment:

Oh, I see... The pipes module uses os.system and os.popen to execute commands under a "/bin/sh" environment. So you are proposing to re-implement it with subprocess in order to execute commands without shell and, also, extend by accepting argv-style parameters. Is this right this time?

How would an argv-style pipe look like?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:56:37 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Thu, 27 Aug 2015 16:56:37 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440694597.24.0.0975729036257.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

All right, here is the new patch then.

----------
Added file: http://bugs.python.org/file40275/multibind3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:58:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2015 16:58:37 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440694717.33.0.967528921675.issue3548@psf.upfronthosting.co.za>


R. David Murray added the comment:

Exactly like the string pipes API, but cmd would be a list of arguments instead of a string.  That would then become the argument list to the subprocess stage.

It is an interesting question whether we'd want to allow mixing stage types.  I'd say no (at least initially, if people complain we can add it as a feature later, but we can't subtract it if we implement it now and decide it is a bad idea after putting it in the field).

Now, keep in mind that you've only got my opinion so far that this is even a good idea :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Thu Aug 27 19:03:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Aug 2015 17:03:38 +0000
Subject: [issue24790] Idle: improve stack viewer
In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za>
Message-ID: <20150827170335.22322.79028@psf.io>


Roundup Robot added the comment:

New changeset 514f5d610175 by Terry Jan Reedy in branch '2.7':
Issue #24790: correct typo noticed by Eric Smith
https://hg.python.org/cpython/rev/514f5d610175

New changeset 213ae5626493 by Terry Jan Reedy in branch '3.4':
Issue #24790: correct typo noticed by Eric Smith
https://hg.python.org/cpython/rev/213ae5626493

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24790>
_______________________________________

From report at bugs.python.org  Thu Aug 27 19:24:06 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Aug 2015 17:24:06 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440696246.75.0.475135503716.issue23630@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks!

The only remaining question is is it OK that we can specify more than one host but only one port?  Guido, Victor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 20:01:21 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Aug 2015 18:01:21 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440698481.1.0.80135668697.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yeah, I think this is fine. I think the use case for multiple hosts is very different than that for multiple ports, so I see no reason to link the two features, and multiple ports hasn't been requested.

The patch has a long line and the new docstring looks a little odd (sentences not starting with capital letters) but otherwise I'm in favor of this going into 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:00:17 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Aug 2015 19:00:17 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440702017.95.0.455121618397.issue23630@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yeah, I think this is fine. I think the use case for multiple hosts is very different than that for multiple ports, so I see no reason to link the two features, and multiple ports hasn't been requested.

OK!

> The patch has a long line and the new docstring looks a little odd (sentences not starting with capital letters) 

Yeah, I've noticed that too, and made a mental note to check line lengths before committing.

> but otherwise I'm in favor of this going into 3.6.

Why only 3.6?  The change is fully backwards compatible, why can't it go in 3.5.1?

Also, what's the protocol for committing something that might take years to be available in github/asyncio?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:00:53 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2015 19:00:53 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440702053.64.0.32093320977.issue24915@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you explain what the profile-merging thing is achieving?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:02:09 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 27 Aug 2015 19:02:09 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1440702129.81.0.920593379073.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Attached uipreferences.py, which is a newer and more complete version of the one in prefs-wip.patch

----------
Added file: http://bugs.python.org/file40276/uipreferences.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24781>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:03:57 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Aug 2015 19:03:57 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440702237.77.0.65600033107.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It can't go into 3.5.1 (a bugfix release) because it is a new feature (however small), and asyncio is not provisional in 3.5 (only in 3.4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:04:30 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Aug 2015 19:04:30 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440702270.34.0.640551385958.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Also, I guess you'll need a branch that tracks what's going into 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:05:48 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Thu, 27 Aug 2015 19:05:48 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440702347.99.0.586588060009.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

About the missing capitalization, I omitted it because it's the argument's name. But I can resubmit with it being capitalized.
I forgot to run flake8, sorry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:06:46 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 19:06:46 +0000
Subject: [issue13812] multiprocessing package doesn't flush stderr on child
 exception
In-Reply-To: <1326849345.92.0.83488691035.issue13812@psf.upfronthosting.co.za>
Message-ID: <1440702406.1.0.711149426976.issue13812@psf.upfronthosting.co.za>


Memeplex added the comment:

I would like to reopen this issue because of the following, very related, behavior. Try this:

```
import multiprocessing as mp
import time


def g():
    time.sleep(100)

def f():
    mp.Process(target=g).start()
    1/0

mp.Process(target=f).start()
```

It won't show the ZeroDivisionError until you keyboard interrupt the g() process or wait for it to end. This is because _exit_function will join every active non-daemon child, which happens before printing and flushing the error. IMO the exception should be shown before joining children, since keeping the error silent is asking for trouble.

----------
nosy: +memeplex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13812>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:07:09 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 19:07:09 +0000
Subject: [issue13812] multiprocessing package doesn't flush stderr on child
 exception
In-Reply-To: <1326849345.92.0.83488691035.issue13812@psf.upfronthosting.co.za>
Message-ID: <1440702429.44.0.0943710572341.issue13812@psf.upfronthosting.co.za>


Changes by Memeplex <carlosjosepita at gmail.com>:


----------
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13812>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:07:10 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Aug 2015 19:07:10 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440702430.84.0.145359514859.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The traditional solution is to rewrite the sentence so the name is not the first word. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:08:50 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2015 19:08:50 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440702530.44.0.315747137039.issue17781@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note this patch is likely wrong, as it doesn't add the optimization options to the linker invocation. According to the gcc does, """To use the link-time optimizer, -flto and optimization options should be specified at compile time and during the final link""".

So probably $OPT should be added to $PY_LDFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:10:49 2015
From: report at bugs.python.org (Matheus Vieira Portela)
Date: Thu, 27 Aug 2015 19:10:49 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1440702649.98.0.171745126586.issue3548@psf.upfronthosting.co.za>


Matheus Vieira Portela added the comment:

Sure. I'll leave this issue for a while before others can emit their opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:20:28 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 27 Aug 2015 19:20:28 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1440703228.69.0.169938430321.issue19904@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:20:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 27 Aug 2015 19:20:48 +0000
Subject: [issue19905] Add 128-bit integer support to ctypes
In-Reply-To: <1386295654.39.0.271762839295.issue19905@psf.upfronthosting.co.za>
Message-ID: <1440703248.1.0.422008567833.issue19905@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
dependencies: +Add 128-bit integer support to struct
stage:  -> needs patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19905>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:47:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2015 19:47:01 +0000
Subject: [issue13812] multiprocessing package doesn't flush stderr on child
 exception
In-Reply-To: <1326849345.92.0.83488691035.issue13812@psf.upfronthosting.co.za>
Message-ID: <1440704821.39.0.521348377504.issue13812@psf.upfronthosting.co.za>


R. David Murray added the comment:

You should open a new issue.  Bonus if you can supply a unit test and patch :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13812>
_______________________________________

From report at bugs.python.org  Thu Aug 27 22:00:06 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 27 Aug 2015 20:00:06 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440705606.28.0.401515800114.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

The profile merging is necessary in case you want to use a pure clang compiler or you use GCC in OSX. For example, a general profiling action using clang will result in at least one binary profile. For our case, when using regrtest, we will have multiple profiles as the test is a multi-process one. The application llvm-profdata has the ability to merge the information collected from multiple processes, thus having a more precise map of what is executed from the profiled application. 

This step is mandatory even if we train on a single threaded or single process workload and have just one profile. More information about the entire process can be found here: http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Thu Aug 27 22:28:19 2015
From: report at bugs.python.org (Alexandre Conrad)
Date: Thu, 27 Aug 2015 20:28:19 +0000
Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440707299.98.0.135118649082.issue23517@psf.upfronthosting.co.za>


Changes by Alexandre Conrad <alexandre.conrad at gmail.com>:


----------
nosy: +aconrad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Thu Aug 27 22:50:01 2015
From: report at bugs.python.org (tagatac)
Date: Thu, 27 Aug 2015 20:50:01 +0000
Subject: [issue24947] asyncio-eventloop documentation grammar (minor)
Message-ID: <1440708601.27.0.541488895387.issue24947@psf.upfronthosting.co.za>


New submission from tagatac:

"amongst which" in the Base Event Loop subsection of the docs does not really describe a list of facilities. "amongst which are" would be better, but "including" conveys the same thing more succinctly.
https://docs.python.org/3/library/asyncio-eventloop.html

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 249257
nosy: docs at python, tagatac
priority: normal
severity: normal
status: open
title: asyncio-eventloop documentation grammar (minor)
Added file: http://bugs.python.org/file40277/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24947>
_______________________________________

From report at bugs.python.org  Thu Aug 27 22:56:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Aug 2015 20:56:17 +0000
Subject: [issue24947] asyncio-eventloop documentation grammar (minor)
In-Reply-To: <1440708601.27.0.541488895387.issue24947@psf.upfronthosting.co.za>
Message-ID: <20150827205614.22338.42345@psf.io>


Roundup Robot added the comment:

New changeset cf15066861fc by Zachary Ware in branch '3.4':
Issue #24947: Fix grammar in asyncio doc
https://hg.python.org/cpython/rev/cf15066861fc

New changeset 563d6f9fecfe by Zachary Ware in branch '3.5':
Issue #24947: Merge 3.4
https://hg.python.org/cpython/rev/563d6f9fecfe

New changeset b76346142b49 by Zachary Ware in branch 'default':
Closes #24947: Merge with 3.5
https://hg.python.org/cpython/rev/b76346142b49

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24947>
_______________________________________

From report at bugs.python.org  Thu Aug 27 22:56:49 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 27 Aug 2015 20:56:49 +0000
Subject: [issue24947] asyncio-eventloop documentation grammar (minor)
In-Reply-To: <1440708601.27.0.541488895387.issue24947@psf.upfronthosting.co.za>
Message-ID: <1440709009.64.0.537062266999.issue24947@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed, thanks for the report and patch!

----------
nosy: +zach.ware
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24947>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:09:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2015 21:09:16 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440709756.57.0.127657460885.issue17781@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, the gain for LTO+PGO (with "-flto -O3") over PGO alone seems to be between 0% and 10% for most benchmarks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:10:10 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2015 21:10:10 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1440709810.26.0.4101884234.issue17781@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You can test for yourself by passing `CFLAGS="-flto -O3" LDFLAGS="-flto -O3"` to ./configure (using gcc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:20:29 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 21:20:29 +0000
Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr
Message-ID: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za>


New submission from Memeplex:

Related to but not the same than https://bugs.python.org/issue13812.

Try this:

```
import multiprocessing as mp
import time


def g():
    time.sleep(100)

def f():
    mp.Process(target=g).start()
    1/0

mp.Process(target=f).start()
```

It won't show the ZeroDivisionError until you keyboard interrupt the g() process or wait for it to end. This is because _exit_function will join every active non-daemon child, which happens before printing and flushing the error. IMO the exception should be shown before joining children, since keeping the error silent is asking for trouble.

----------
components: Library (Lib)
messages: 249262
nosy: memeplex
priority: normal
severity: normal
status: open
title: Multiprocessing not timely flushing stack trace to stderr
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24948>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:31:35 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 Aug 2015 21:31:35 +0000
Subject: [issue21192] Idle: Print filename when running a file from editor
In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>
Message-ID: <1440711095.41.0.632731860782.issue21192@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Now that Larry Hastings has posted directions for handling changes pulled into 3.5.0, I will soon commit the attached, or something close, and add a pull request.

----------
keywords: +patch
Added file: http://bugs.python.org/file40278/@restart.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21192>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:41:59 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 21:41:59 +0000
Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr
In-Reply-To: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za>
Message-ID: <1440711719.46.0.387537258471.issue24948@psf.upfronthosting.co.za>


Memeplex added the comment:

One possible fix to multiprocessing/process.py:

<             try:
<                 self.run()
<                 exitcode = 0
<             finally:
<                 util._exit_function()
---
>             self.run()
>             exitcode = 0
274a272
>             util._exit_function()

This removes the try/finally pair around self.run() and calls _exit_function in the last finally clause. It doesn't honour the original control flow, as this last clause is even executed when the flow is aborted before reaching self.run(). That said, I can't see any particular reason to prefer the original flow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24948>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:42:44 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 21:42:44 +0000
Subject: [issue13812] multiprocessing package doesn't flush stderr on child
 exception
In-Reply-To: <1326849345.92.0.83488691035.issue13812@psf.upfronthosting.co.za>
Message-ID: <1440711764.56.0.881808888951.issue13812@psf.upfronthosting.co.za>


Memeplex added the comment:

http://bugs.python.org/issue24948

I posted a tentative solution there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13812>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:36:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Aug 2015 22:36:36 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <20150827223633.29360.64901@psf.io>


Roundup Robot added the comment:

New changeset a90c6d608b85 by Robert Collins in branch '3.4':
Issue #21112: Fix regression in unittest.expectedFailure on subclasses.
https://hg.python.org/cpython/rev/a90c6d608b85

New changeset ac3f1a6b1de2 by Robert Collins in branch '3.5':
Issue #21112: Fix regression in unittest.expectedFailure on subclasses.
https://hg.python.org/cpython/rev/ac3f1a6b1de2

New changeset bf789ae9bde7 by Robert Collins in branch 'default':
Issue #21112: Fix regression in unittest.expectedFailure on subclasses.
https://hg.python.org/cpython/rev/bf789ae9bde7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:38:26 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 27 Aug 2015 22:38:26 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <1440715106.15.0.804738278816.issue21112@psf.upfronthosting.co.za>


Robert Collins added the comment:

2.7 is sufficiently different that I haven't backported this there - plus the report said it was introduced in 3.4. If someone can show this doesn't work in 2.7 and also supply a patch, we could apply it there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:38:35 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 27 Aug 2015 22:38:35 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <1440715115.46.0.632406494101.issue21112@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:43:21 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 27 Aug 2015 22:43:21 +0000
Subject: [issue2786] Names in function call exception should have class names, 
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440715401.34.0.59674555234.issue2786@psf.upfronthosting.co.za>


Robert Collins added the comment:

Here are some options.

a) Don't make the new thing public - instead export within Python.exe the existing private symbol _...withNames. Pros: no change to public API. Cons: extension modules using the public API cannot make these sorts of errors clearer.

b) Add a new API. Either narrow (add the parameter) or big (add a struct). Pros: everyone treated equally. Cons: More API surface area, and more complex calling convention.

c) use symbol versioning to change the existing API. Cons: more complex build-time detection for users. Pros: API surface area held constant.

d) Don't fix it. :)

I don't have a particular preference, though the struct thing is a wash IMO - it saves adding a serial to the API, at the cost of having a versioned datastructure which needs an embedded serial number. [Except perhaps that you can use symbol versioning to deal with evolutions of the struct - but thats fairly complex to carry off well, and I think this would be the first example w/in Python].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:59:22 2015
From: report at bugs.python.org (Bob Hossley)
Date: Thu, 27 Aug 2015 22:59:22 +0000
Subject: [issue24949] Identifier lookup in a multi-level package is flakey
Message-ID: <1440716362.21.0.0587084904786.issue24949@psf.upfronthosting.co.za>


New submission from Bob Hossley:

This seems like a bug to me, but it may be a recognized limitation even though I couldn't find any documentation suggesting that my tests should not work reliably.  I see no reason why my tests should not work reliably.

I have reliably reproduced the flakeyness under Windows XP with Python 2.6.4 and under Xubuntu 14.04 64-bit with Python 2.7.6 and Python 3.4.0.

Ubuntu 14.04 (trusty)  - XFCE desktop (Xubuntu) 64-bit
Gnome:  3.8.4
Kernel:  3.13.0-62-generic
GCC Version:  4.8 (x86_64-linux-gnu)
Xorg Version:  1.15.1 (12 February 2015  02:49:29PM)

Rebooting doesn't help.

I first encountered the flakeyness in a complicated script which I will describe in outline first.  The very, very simple interactive Python sessions that follow are probably of more interest and use to you.
---
Outline of my complicated script:

import email
    
    # The next line works around a flakeyness in Python    
    from email.mime.nonmultipart import MIMENonMultipart
    
    msg = email.mime.nonmultipart.MIMENonMultipart('text', 'plain', charset='utf-8')

Without the above work around I always get Error:

AttributeError: 'module' object has no attribute 'nonmultipart'

Note "import email" is global.  "from email.mime.nonmultipart import MIMENonMultipart" is local to the function containing the "msg = " line which is the line that fails whenever the workaround is absent.
---
XP Interpreter Session:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Admin>python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> print email.mime.nonmultipart.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> print email.mime.nonmultipart.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> print email.mime.nonmultipart.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> print email.mime.nonmultipart.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> print email.mime.nonmultipart.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> from email.mime import nonmultipart
>>> print email.mime.nonmultipart.__file__
C:\bin\Python26\lib\email\mime\nonmultipart.pyc
>>>

Xubuntu Python 2.7.6 Session

2015-08-25 14:02:46 /home/bob06
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> print(email.mime.nonmultipart.__file__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'nonmultipart'
>>> print(email.mime.nonmultipart.__file__)
/usr/lib/python2.7/email/mime/nonmultipart.pyc


Xubuntu Python 3.4.0 Session

2015-08-27 15:27:39 /home/bob06
$ python3
Python 3.4.0 (default, Jun 19 2015, 14:20:21) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> print(email.mime.nonmultipart.__file__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'mime'
>>> print(email.mime.nonmultipart.__file__)
/usr/lib/python3.4/email/mime/nonmultipart.py

----------
components: Interpreter Core
messages: 249269
nosy: SegundoBob
priority: normal
severity: normal
status: open
title: Identifier lookup in a multi-level package is flakey
type: compile error
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24949>
_______________________________________

From report at bugs.python.org  Fri Aug 28 01:14:25 2015
From: report at bugs.python.org (Jon Brandvein)
Date: Thu, 27 Aug 2015 23:14:25 +0000
Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr
In-Reply-To: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za>
Message-ID: <1440717265.82.0.651817303938.issue24948@psf.upfronthosting.co.za>


Changes by Jon Brandvein <jon.brandvein at gmail.com>:


----------
nosy: +brandjon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24948>
_______________________________________

From report at bugs.python.org  Fri Aug 28 02:06:39 2015
From: report at bugs.python.org (Matheus Vieira Portela)
Date: Fri, 28 Aug 2015 00:06:39 +0000
Subject: [issue24789] ctypes doc string
In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za>
Message-ID: <1440720399.72.0.996129614878.issue24789@psf.upfronthosting.co.za>


Matheus Vieira Portela added the comment:

Updated create_string_buffer docstring to "create_string_buffer(aBytes, anInteger) -> character array".

----------
keywords: +patch
nosy: +matheus.v.portela
Added file: http://bugs.python.org/file40279/issue24789_ctypes_doc_string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24789>
_______________________________________

From report at bugs.python.org  Fri Aug 28 02:28:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Aug 2015 00:28:00 +0000
Subject: [issue24949] Identifier lookup in a multi-level package is flakey
In-Reply-To: <1440716362.21.0.0587084904786.issue24949@psf.upfronthosting.co.za>
Message-ID: <1440721680.46.0.110452989413.issue24949@psf.upfronthosting.co.za>


R. David Murray added the comment:

It should not be the case that email.mime.nonmultipart gets imported unless you import it explicitly.  I can't reproduce your case of trying to access its __file__ attribute and having it succeed the second time.  There must be something unusual about your setup or your linux distribution.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24949>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:11:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Aug 2015 03:11:48 +0000
Subject: [issue24949] Identifier lookup in a multi-level package is flakey
In-Reply-To: <1440716362.21.0.0587084904786.issue24949@psf.upfronthosting.co.za>
Message-ID: <1440731508.19.0.853199071869.issue24949@psf.upfronthosting.co.za>


Martin Panter added the comment:

It sounds like you are trying to do a plain ?import email?, and then expect all the submodules under that package to work, including ?email.mime.nonmultipart?. That is not how it works. I understand the submodules and subpackages are only initialized if you ask for them explicitly. Hence the ?no attribute 'mime' ? error in 3.4.

In your case perhaps you should change or extend the import statement to do

import email.mime.nonmultipart

The reason why your ?from . . . import? works is it also initializes the submodule that you want, and stores it in a chain of attributes of the top-level module as a side effect.

Quickly scanning through <https://docs.python.org/3/tutorial/modules.html#packages>, <https://docs.python.org/3/reference/import.html#packages>, <https://docs.python.org/3/reference/simple_stmts.html#import>, I didn?t see anything obvious pointing out that importing a top-level package doesn?t completely initialize the whole thing. But maybe there is something already there. You might have to read about how the __init__.py internals work to pick it up.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24949>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:28:26 2015
From: report at bugs.python.org (Felix Yan)
Date: Fri, 28 Aug 2015 03:28:26 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
Message-ID: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>


New submission from Felix Yan:

test_expanduser in test.test_posixpath.PosixPathTest fails when the users $HOME being exactly "/", after the patch in issue17809 was introduced.

test test_posixpath failed -- Traceback (most recent call last):
  File "/build/python/src/Python-3.5.0rc2/Lib/test/test_posixpath.py", line 249, in test_expanduser
    self.assertEqual(posixpath.expanduser("~"), home.rstrip("/"))
AssertionError: '/' != ''
- /
+

Would it be appropriate to apply the rstrip() also to the left part of the equation?

----------
components: Tests
messages: 249273
nosy: felixonmars
priority: normal
severity: normal
status: open
title: FAIL: test_expanduser when $HOME=/
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24950>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:30:27 2015
From: report at bugs.python.org (Felix Yan)
Date: Fri, 28 Aug 2015 03:30:27 +0000
Subject: [issue24950] FAIL: test_posixpath when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1440732627.71.0.541116832288.issue24950@psf.upfronthosting.co.za>


Changes by Felix Yan <felixonmars at archlinux.org>:


----------
title: FAIL: test_expanduser when $HOME=/ -> FAIL: test_posixpath when $HOME=/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24950>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:30:50 2015
From: report at bugs.python.org (Felix Yan)
Date: Fri, 28 Aug 2015 03:30:50 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1440732650.94.0.284487154435.issue24950@psf.upfronthosting.co.za>


Changes by Felix Yan <felixonmars at archlinux.org>:


----------
title: FAIL: test_posixpath when $HOME=/ -> FAIL: test_expanduser when $HOME=/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24950>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:37:27 2015
From: report at bugs.python.org (Felix Yan)
Date: Fri, 28 Aug 2015 03:37:27 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1440733047.06.0.53143129877.issue24950@psf.upfronthosting.co.za>


Felix Yan added the comment:

btw, there seems to be a relevant failure in test_pathlib as well:

test test_pathlib failed -- Traceback (most recent call last):
  File "/build/python/src/Python-3.5.0rc2/Lib/test/test_pathlib.py", line 2015, in test_expanduser
    self.assertEqual(p1.expanduser(), P(userhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')

(not sure if they are really relevant, though)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24950>
_______________________________________

From report at bugs.python.org  Fri Aug 28 08:44:06 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Aug 2015 06:44:06 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
Message-ID: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In response to my python-list request for testing tkinter/idle on linux, Petr wrote

On Fedora 21, the tests pass (Python 3.4.1 and latest dev version).

On Fedora 23, I see:

$ python3 -V
Python 3.4.3 <tests pass>

$ ./python -V
Python 3.6.0a0
$ ./python -m test -ugui test_tk test_ttk_guionly test_idle
[1/3] test_tk
[2/3] test_ttk_guionly
[3/3] test_idle
test test_idle failed -- Traceback (most recent call last):
  File "/home/pviktori/dev/cpython/Lib/idlelib/idle_test/test_configdialog.py",
line 27, in test_dialog
    d=ConfigDialog(self.root, 'Test', _utest=True)
  File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line
71, in __init__
    self.LoadConfigs()
  File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line
1078, in LoadConfigs
    self.LoadFontCfg()
  File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line
980, in LoadFontCfg
    self.SetFontSample()
  File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line
858, in SetFontSample
    self.labelFontSample.config(font=newFont)
  File "/home/pviktori/dev/cpython/Lib/tkinter/__init__.py", line
1330, in configure
    return self._configure('configure', cnf, kw)
  File "/home/pviktori/dev/cpython/Lib/tkinter/__init__.py", line
1321, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: expected integer but got ""

2 tests OK.
1 test failed:
    test_idle

Tk version: 8.6.4
---------------------------------------

----------
messages: 249275
nosy: encukou, markroseman, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle test_configdialog fails on Fedora 23, 3.6
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24951>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:30:58 2015
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 28 Aug 2015 09:30:58 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1440754258.27.0.0122225089736.issue11320@psf.upfronthosting.co.za>


Palm Kevin added the comment:

The problem seems still not resolved in Python 3.2.6 :-(
The reason has been found by Debao (msg144244). Isn't there anybody motivated to fix this bug?

----------
title: Can't call Py_SetPath() on pointer returned by Py_GetPath() -> Usage of API method Py_SetPath causes errors in Py_Initialize() (Posix ony))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Fri Aug 28 15:19:55 2015
From: report at bugs.python.org (James Salter)
Date: Fri, 28 Aug 2015 13:19:55 +0000
Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5
 with DLL loading
In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za>
Message-ID: <1440767995.07.0.645555261926.issue24748@psf.upfronthosting.co.za>


James Salter added the comment:

This also affects py2exe, which dynamically generates stub .pyc loaders inside a ZIP which then load .pyd modules outside the ZIP with the same name.

Windows 8, x64, visual studio 2015 enterprise.

It is simple enough to work around by doing a del sys.modules[modname] prior to the load_dynamic call, but obviously this goes against the documented behaviour.

----------
nosy: +James Salter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24748>
_______________________________________

From report at bugs.python.org  Fri Aug 28 15:52:03 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 28 Aug 2015 13:52:03 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>
Message-ID: <1440769923.98.0.276310767193.issue24951@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

I'd be happy to do any further testing (modulo a vacation until this Tuesday), but unfortunately I don't have time to dive into tkinter myself and look for the cause.
IDLE starts normally on this box.

Also note: Fedora 23 is currently in alpha (though Python should be stable in it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24951>
_______________________________________

From report at bugs.python.org  Fri Aug 28 16:06:13 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Fri, 28 Aug 2015 14:06:13 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1440770773.0.0.667552960385.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

A new patch with capitalization of first words of sentences + splitting lines which are too long (more PEP8 friendly).

----------
Added file: http://bugs.python.org/file40280/multibind4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Fri Aug 28 16:59:08 2015
From: report at bugs.python.org (mattip)
Date: Fri, 28 Aug 2015 14:59:08 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
Message-ID: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>


New submission from mattip:

when using thread.stack_size or threading.stack_size, if no argument is provided the stack size is reset to default. Trivial patch for 3.5 provided

----------
assignee: docs at python
components: Documentation
files: stack_size.patch
keywords: patch
messages: 249280
nosy: docs at python, mattip
priority: normal
severity: normal
status: open
title: stack_size([size]) is actually stack_size(size=0)
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40281/stack_size.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Fri Aug 28 17:16:03 2015
From: report at bugs.python.org (mattip)
Date: Fri, 28 Aug 2015 15:16:03 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440774963.2.0.451278167668.issue24952@psf.upfronthosting.co.za>


mattip added the comment:

Add a patch for 2.7

----------
versions: +Python 2.7 -Python 3.5
Added file: http://bugs.python.org/file40282/stack_size2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Fri Aug 28 17:41:38 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 15:41:38 +0000
Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime
 object
In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>
Message-ID: <1440776498.89.0.240672965983.issue22241@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40283/issue22241.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22241>
_______________________________________

From report at bugs.python.org  Fri Aug 28 18:07:51 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 16:07:51 +0000
Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime
 object
In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>
Message-ID: <1440778071.9.0.120763769567.issue22241@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


Added file: http://bugs.python.org/file40284/issue22241.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22241>
_______________________________________

From report at bugs.python.org  Fri Aug 28 18:08:01 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 16:08:01 +0000
Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime
 object
In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za>
Message-ID: <1440778081.32.0.775719081495.issue22241@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


Removed file: http://bugs.python.org/file40283/issue22241.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22241>
_______________________________________

From report at bugs.python.org  Fri Aug 28 19:08:48 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 17:08:48 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440781728.64.0.127358107925.issue23517@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
title: datetime.utcfromtimestamp parses timestamps incorrectly -> datetime.utcfromtimestamp rounds results incorrectly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Fri Aug 28 19:17:30 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 17:17:30 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440782250.49.0.0257936395098.issue23517@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I wish we could use the same algorithm in datetime.utcfromtimestamp as we use in float to string conversion.  This may allow the following chain of conversions to round trip in most cases:

float literal -> float -> datetime -> seconds.microseconds string

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Fri Aug 28 19:33:21 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 17:33:21 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1440783201.7.0.20792243712.issue13466@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Since Russia has fixed this bug legislatively last year, can we close the issue now?

http://www.theguardian.com/world/2014/jul/01/russia-state-duma-daylight-saving-time-summer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Fri Aug 28 19:48:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 17:48:41 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>
Message-ID: <1440784121.48.0.202168201849.issue24951@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please add

    print(_flatten((self._w, cmd)) + self._options(cnf))

just before the call in line 858 in Lib/tkinter/__init__.py and tell the output Petr. Could you please show your .idlerc/config-main.cfg file?

I suppose self.fontSize.get() returns an empty string for unknown reasons. Interesting, how IDLE configuration file affects tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24951>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:00:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 18:00:37 +0000
Subject: [issue24946] Tkinter tests that fail on linux in tiling window manager
In-Reply-To: <1440693856.91.0.458235687359.issue24946@psf.upfronthosting.co.za>
Message-ID: <1440784837.08.0.312470883879.issue24946@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I already added a workaround to pass these tests on my netbook (new windows are opened maximized on it). May be there is a way to make a window floating in tiled window manager in Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24946>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:35:06 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Aug 2015 18:35:06 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440786906.76.0.872112360655.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I did another round of review. I noticed that the configure part of the patch is missing and that .hgignore and .gitignore should get updated to ignore the profile files. Otherwise the only other comment was making an echoed comment a bit clearer.

And in case anyone else is on OS X Yosemite and gets an error about llvm-profdata missing, make sure that /Library/Developer/CommandLineTools/usr/bin is on your $PATH.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:46:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 18:46:55 +0000
Subject: [issue23839] Clear caches after every test
In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za>
Message-ID: <1440787615.3.0.452414226711.issue23839@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/9963/steps/test/logs/stdio

Passed 395 tests of 398 and failed on test_decimal:

...
[396/398] test_decimal
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1276, in runtest_inner
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_decimal.py", line 5598, in test_main
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support/__init__.py", line 1809, in run_unittest
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support/__init__.py", line 1775, in _run_suite
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/runner.py", line 176, in run
    test(result)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 645, in __call__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 605, in run
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 538, in _feedErrorsToResult
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/runner.py", line 69, in addError
    self.stream.writeln("ERROR")
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/runner.py", line 25, in writeln
    self.write(arg)
MemoryError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1279, in runtest_inner
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1232, in __exit__
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1172, in get_sysconfig__CONFIG_VARS
MemoryError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 532, in main
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 963, in runtest
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1300, in runtest_inner
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/traceback.py", line 163, in format_exc
    return "".join(format_exception(*sys.exc_info(), limit=limit, chain=chain))
MemoryError
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1560, in main_in_temp_cwd
    main()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_decimal:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23839>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:50:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 18:50:16 +0000
Subject: [issue23839] Clear caches after every test
In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za>
Message-ID: <1440787816.84.0.290629449378.issue23839@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be related: http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/10375/steps/test/logs/stdio

======================================================================
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5160, in testCount
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5063, in recv_data
MemoryError

======================================================================
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 266, in _tearDown
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 278, in clientRun
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5153, in _testCount
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/socket.py", line 282, in _sendfile_use_sendfile
    raise _socket.timeout('timed out')
socket.timeout: timed out

======================================================================
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5230, in testWithTimeout
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5063, in recv_data
MemoryError

======================================================================
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 266, in _tearDown
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 278, in clientRun
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5225, in _testWithTimeout
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/socket.py", line 282, in _sendfile_use_sendfile
    raise _socket.timeout('timed out')
socket.timeout: timed out

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23839>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:00:39 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Aug 2015 19:00:39 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1440788439.93.0.690635334057.issue24934@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Changeset 2f3b3c6c1190 adds the version range check to django_v2 to block it past 3.5.

I didn't add the django_v3 quite yet because I didn't realize that Django 1.8 won't work without being manually patched by us (I thought that issue was limited to our Django 1.5 copy). I did check and the issue is fixed in Django 1.9 which is due before the end of the year: https://code.djangoproject.com/wiki/Version1.9Roadmap .

Since this is for Python 3.6 which is in no way close to coming out I say we simply wait until Django 1.9.0 is released and then introduce django_v3 without having to keep our own patched version of Django around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:01:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Aug 2015 19:01:57 +0000
Subject: [issue24305] The new import system makes it inconvenient to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440788517.46.0.862030879286.issue24305@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: larry -> brett.cannon
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:03:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 19:03:15 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1440788595.24.0.742302370492.issue24881@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:20:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Aug 2015 19:20:53 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <20150828192050.27295.75144@psf.io>


Roundup Robot added the comment:

New changeset 687da8760a58 by Serhiy Storchaka in branch '3.5':
Issue #24881: Fixed setting binary mode in Python implementation of FileIO
https://hg.python.org/cpython/rev/687da8760a58

New changeset 2dd9294f679d by Serhiy Storchaka in branch 'default':
Issue #24881: Fixed setting binary mode in Python implementation of FileIO
https://hg.python.org/cpython/rev/2dd9294f679d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:22:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 19:22:18 +0000
Subject: [issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
In-Reply-To: <1439820667.47.0.427491446105.issue24881@psf.upfronthosting.co.za>
Message-ID: <1440789738.93.0.278869409962.issue24881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch. Thank you for your report Cosimo. Thank you for your patch Akira.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24881>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:24:44 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 28 Aug 2015 19:24:44 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>
Message-ID: <1440789884.97.0.208276952848.issue24951@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Config files affecting tests (and tests affecting config files!) is an issue. Would like to see config files written into a different directory when running tests. Any concerns with doing that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24951>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:30:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Aug 2015 19:30:38 +0000
Subject: [issue17945] tkinter: change API of non-functioning peer_create,
 does not instantiate Text
In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>
Message-ID: <1440790238.51.0.890544542142.issue17945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it would be better to add a way to create the Text object (or may be any widget object) for existing Tk widget. Similar problem exists for cloned menus (issue734176).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17945>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:30:40 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 28 Aug 2015 19:30:40 +0000
Subject: [issue24829] Use interactive input even if stdout is redirected
In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za>
Message-ID: <1440790240.46.0.470104643633.issue24829@psf.upfronthosting.co.za>


eryksun added the comment:

> If you dropped the isatty() check for stdout in Linux, you may 
> end up with the output of Readline in the file (assuming
> Readline is okay with this). The file would include all the
> cursor positioning codes, backspaces, etc, that Readline
> generates. But I haven?t actually tried this.

Yes, that's what happens. 

It seems to me the isatty check could be moved to call_readline in Modules/readline.c. This way PyOS_ReadlineFunctionPointer decides whether to call PyOS_StdioReadline. (See issue 512981 for the patch that introduced the isatty check.)

A related issue in Windows is that when stdout isn't a console, the text encoding defaults to the locale's ANSI encoding (e.g. cp1252). UTF-8 can be forced by setting the environment variable PYTHONIOENCODING=utf-8.

Also of concern is the pyreadline module. Its [Console class] assumes that the process standard handles are console handles. This is generally valid given the isatty check. OTOH, when I removed this check and redirected stdout to a file, pyreadline crashed in an endless loop. 

pyreadline's hook could punt to PyOS_StdioReadline if stdin and stdout don't both refer to the console. The problem there is calling the CRT's _fileno (POSIX) function in Python. Maybe the os module could wrap fileno in Modules/posixmodule.c. In addition to accepting a FILE pointer, os.fileno could accept an enum of C_STDIN, C_STDOUT, and C_STDERR.

[1]: https://github.com/pyreadline/pyreadline/blob/0be3f019ecfdaf740555dc91a1156ddd5dd195f2/pyreadline/console/console.py#L176

----------
nosy: +eryksun
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24829>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:07:37 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 28 Aug 2015 20:07:37 +0000
Subject: [issue17945] tkinter: change API of non-functioning peer_create,
 does not instantiate Text
In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>
Message-ID: <1440792457.3.0.295555404286.issue17945@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I'm not against generality, though don't think there are many places this actually comes up (the cloned menus shouldn't be affecting more than a couple people these days, and aren't the result of an explicit API call). 

For this particular call (peer_create) I just think the caller should be passing in the parent window as in other Tkinter widget creation commands, rather than the full widget path. On the exact implementation of the call I'm open to whatever works!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17945>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:41:13 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 20:41:13 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1440794473.51.0.0383365744892.issue22798@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

C mktime itself should not change timezone globals, but it may indirectly if it calls tzset() and TZ changed between calls.

I don't understand what this issue is about.  Unlike C mktime, time.mktime is not documented to call time.tzset().  If you want to change  time.tzname - you need to call time.tzset() after changing TZ.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:51:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 28 Aug 2015 20:51:53 +0000
Subject: [issue24953] ICC and version should be in COMPILER string when built
 with ICC on Windows
Message-ID: <1440795113.81.0.941398168358.issue24953@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch makes the compiler portion of the sys.version string look something like "[ICC v.1500 32-bit (Intel) with MSC v.1500 CRT]" when Python is built with ICC.  This format keeps distutils happy without having to change its parsing of the version string to decide which compiler to use for extensions, while making it possible to tell which compiler was used to build Python.

----------
assignee: zach.ware
components: Build, Windows
files: icc_version_in_sys.version.diff
keywords: patch
messages: 249297
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: ICC and version should be in COMPILER string when built with ICC on Windows
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40285/icc_version_in_sys.version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24953>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:05:57 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 21:05:57 +0000
Subject: [issue7739] time.strftime may hung while trying to open
 /etc/localtime but does not release GIL
In-Reply-To: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>
Message-ID: <1440795957.59.0.486693468398.issue7739@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:16:51 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Aug 2015 21:16:51 +0000
Subject: [issue24953] ICC and version should be in COMPILER string when built
 with ICC on Windows
In-Reply-To: <1440795113.81.0.941398168358.issue24953@psf.upfronthosting.co.za>
Message-ID: <1440796611.92.0.690471742417.issue24953@psf.upfronthosting.co.za>


Steve Dower added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24953>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:25:03 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 21:25:03 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1440797103.46.0.653161533945.issue18629@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18629>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:36:37 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 21:36:37 +0000
Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as
 such
In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za>
Message-ID: <1440797797.23.0.392622558724.issue23332@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

The premise of this issue is factually incorrect:

> ISO 8601, which states that, if no timezone is specified,
> the string is supposed to be interpreted as UTC implicitly.

The opposite is true: "If no UTC relation information is given with a time representation, the time is assumed to be in local time." <https://en.wikipedia.org/wiki/ISO_8601>

To get timezone specification included in isoformat() output - use aware datetime objects:

>>> from datetime import *
>>> datetime.now(timezone.utc).isoformat()
'2015-01-27T18:27:33.216857+00:00'

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23332>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:02:47 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Aug 2015 22:02:47 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440799367.82.0.530507114927.issue23517@psf.upfronthosting.co.za>


Tim Peters added the comment:

> I wish we could use the same algorithm in
> datetime.utcfromtimestamp as we use in float
> to string conversion.  This may allow the
> following chain of conversions to round trip in most cases:
>
> float literal -> float -> datetime -> seconds.microseconds string

I don't follow.  float->string produces the shortest string that reproduces the float exactly.  Any flavor of changing a timestamp to a microsecond-precision datetime is essentially converting a float * 1e6 to an integer - there doesn't seem to be a coherent concept of "shortest integer" that could apply.  We have to fill every bit a datetime has.

A variant of the code I posted could be "good enough":  take the result we get now (truncate float*1e6).  Also add 1 ulp to the float and do that again.  If the results are the same, we're done.  If the results are different, and the difference is 1, take the second result.  Else keep the first result.  What this "means" is that we're rounding up if and only if the original is so close to the boundary that the tiniest possible amount of floating-point noise is all that's keeping it from giving a different result - but also that the float "has enough bits" to represent a 1-microsecond difference (which is true of current times, but in a couple centuries will become false).

But that's all nuts compared to just rounding float*1e6 to the nearest int, period.  There's nothing wrong with doing that.  Truncating is propagating the tiniest possible binary fp representation error all the way into the microseconds.  It would be defensible _if_ we were using base-10 floats (in which "representation error" doesn't occur for values expressed _in_ base 10).  But we're not.  Truncating a base-2 float _as if_ it were a base-10 float is certain to cause problems.  Like the one this report is about ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:19:07 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 22:19:07 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440800347.68.0.171068977028.issue23517@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I probably misremembered a different issue.  See msg194311.

>>> timedelta(seconds=0.6112295) == timedelta(seconds=1)*0.6112295
False

I thought the problem there was that the same float was converted to one decimal by str() and to a different decimal by timedelta.  But now it looks like it was something else.

Does your algorithm guarantee that any float that is displayed with 6 decimal places or less will convert to a datetime or timedelta with microseconds matching the fractional part?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:21:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Aug 2015 22:21:13 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440800473.89.0.881280986225.issue24952@psf.upfronthosting.co.za>


Martin Panter added the comment:

In my mind this notation implies the folowing should work:

>>> threading.stack_size(size=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: stack_size() takes no keyword arguments

Perhaps you really just want make it more explicit that the special value 0 is used by default if the argument omitted? See also Issue 8706 about supporting named keyword parameters, and Issue 13386 and Issue 23738 about other possible notations to document the default value.

----------
nosy: +martin.panter
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:28:48 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Aug 2015 22:28:48 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440800928.46.0.564709796348.issue23517@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

OK, I looked at the wrong place.  Here is the correct example:

>>> x = float.fromhex('0x1.38f312b1b36bdp-1')
>>> x
0.6112295
>>> round(x, 6)
0.611229
>>> timedelta(0, x).microseconds
611230

but I no longer remember whether we concluded that timedelta got it wrong or round or both or neither. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:31:59 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Aug 2015 22:31:59 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440801119.01.0.529032315902.issue23517@psf.upfronthosting.co.za>


Tim Peters added the comment:

> Does your algorithm guarantee that any float that
> is displayed with 6 decimal places or less will
> convert to a datetime or timedelta with microseconds
> matching the fractional part?

No algorithm can, for datetimes far enough in the future (C doubles just plain run out of enough bits).

Apart from negative timestamps (which I didn't consider - they just blow up on my platform :-) ), the intent is to do the best that _can_ be done.

But _proving_ things in this area isn't simple, and there's no need for it:  check in a change to round the thing, and be done with it.  If Victor wants to rework rounding again, that's fine, but only under a _requirement_ that this particular bug remain fixed.  His change created the problem, and it's still languishing half a year after being reported - there's little sense in continuing to wait for him to do something about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:34:41 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Aug 2015 22:34:41 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
Message-ID: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The datetime isoformat() function for an aware datetime appends the timezone in the form +HH:MM or -HH:MM. But the %z format produces (strftime) or parses (strptime) either +HHMM or -HHMM. I looked it up on Wikipedia, and the ISO 8601 standard indeed uses the colon. It would be nice if there was a new format character that could produce or parse the colon...

----------
messages: 249305
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: No way to generate or parse timezone as produced by datetime.isoformat()
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Sat Aug 29 01:10:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Aug 2015 23:10:44 +0000
Subject: [issue24305] The new import system makes it inconvenient to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440803444.95.0.295426019614.issue24305@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file40286/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sat Aug 29 02:20:53 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 29 Aug 2015 00:20:53 +0000
Subject: [issue24305] The new import system makes it inconvenient to correctly
 issue a deprecation warning for a module
In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za>
Message-ID: <1440807653.83.0.320196177864.issue24305@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I figured  out what was causing the threading/subprocess problems (something in frame->f_code->co-filename was NULL), so the attached patch covers Python, C, and adds a test (as well as cleaning up the test_warnings file structure since it was old-school spread out in Lib/test).

I don't think Larry wants this going into 3.5 based on his previous comments (period, not just 3.5.0). Is that true, Larry? If so, would you accept a 3.5.0 patch to fix the warnings in formatter and imp to a more accurate stacklevel?

----------
assignee: brett.cannon -> larry
priority: critical -> release blocker
stage: patch review -> commit review
Added file: http://bugs.python.org/file40287/issue24305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

From report at bugs.python.org  Sat Aug 29 02:35:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Aug 2015 00:35:02 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440808502.45.0.760158004602.issue23517@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, I'm trying to write the rationale of the changes that I wrote in pytime.h in Python 3.3-3.5. The rounding of microseconds or nanoseconds is tricky. The code changed a lot and we used and we are still using various rounding methods depending on the case...

Alexander Belopolsky wrote:
> I believe the correct mode is "ROUND_HALF_EVEN".  This is the mode used by the builtin round() function: (...)

Right, round(float) and round(decimal.Decimal) uses the ROUND_HALF_EVEN rounding method.

On Python < 3.3, datetime.datetime.fromtimestamp(float) doesn't use exactly ROUND_HALF_EVEN, but it looks more to "round half away from zero" (the decimal module doesn't seem to support this exact rounding method).

The difference between ROUND_HALF_EVEN and "round half away from zero" is subtle. The two rounding methods only return a different result on the following case:

   divmod(t + us * 1e-6, 1.0)[1] * 1e6 == 0.5

where t and us are integers (t is a number of seconds created by mktime() and us is a number of microseconds in [0; 999999]).

I don't think that the case can occur. I failed to find such case for various values of t between 0 and 2**40, and us=0 or us=1. 1e-6 (10^-6 = 0.000001) cannot be represented exactly in base 2 (IEEE 754).

--

To move forward, we should agree on which rounding method datetime.datetime.fromtimestamp() should use, implement it in pytime.c (add a constant in pytime.h, implement it in pytime.c, and then write unit tests in test_time.py), and then use it in datetime.datetime.fromtimestamp().

IMHO we should only modify the rounding method used by datetime.datetime.fromtimestamp() and datetime.datetime.utcfromtimestamp(), other functions use the "right" rounding method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 03:40:11 2015
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Aug 2015 01:40:11 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440812411.05.0.533427732189.issue23517@psf.upfronthosting.co.za>


Tim Peters added the comment:

> >>> x = float.fromhex('0x1.38f312b1b36bdp-1')
> >>> x
> 0.6112295
> >>> round(x, 6)
> 0.611229
> >>> timedelta(0, x).microseconds
> 611230
>
> but I no longer remember whether we concluded that
> timedelta got it wrong or round or both or neither. :-)

Here you go:

>>> import decimal
>>> decimal.Decimal(x)
Decimal('0.61122949999999998116351207499974407255649566650390625')

That's the exact value you're actually using.  What's "correct" depends on what's intended.

round(x, 6) actually rounds to

>>> decimal.Decimal(round(x, 6))
0.6112290000000000222968310481519438326358795166015625

and that's fine.  timedelta's result does not match what using infinite precision would deliver, but I couldn't care much less ;-)

The real lesson to take from all this, when you design your own killer language, is that using a binary floating point type for timestamps comes with many costs and surprises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 04:08:18 2015
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Aug 2015 02:08:18 +0000
Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1440814098.73.0.541492246132.issue23517@psf.upfronthosting.co.za>


Tim Peters added the comment:

> IMHO we should only modify the rounding method used by
> datetime.datetime.fromtimestamp() and
> datetime.datetime.utcfromtimestamp(), other functions
> use the "right" rounding method.

Fine by me.  How about today? ;-)

The regression reported here must get repaired.  nearest/even is generally favored when there's a choice.

I personally _prefer_ add-a-half-and-chop in time contexts that need rounding, because it's more uniform.  That is, picturing a context that rounds to 1 digit for clarity, using a decimal system, with a uniformly spaced sequence of inputs on the first line, then a line with add-a-half-and-chop results, and then a line with nearest/even results:

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 input
0.0 1.0 1.0 2.0 2.0 3.0 3.0 4.0 add-a-half-and-chop
0.0 0.0 1.0 2.0 2.0 2.0 3.0 4.0 nearest/even

>From the last (nearest/even) line, you'd never guess that the inputs were uniformly spaced; in the second line, you would.  nearest/even's "in a tie, sometimes go up, sometimes go down" is, IMO, unnatural in this context.

But it doesn't make a lick of real difference to timestamp functions.  We're not working in decimal, and people aren't going to be staring at hex patterns in output.  So I'd pick whichever is easier to implement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________

From report at bugs.python.org  Sat Aug 29 04:25:05 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Aug 2015 02:25:05 +0000
Subject: [issue2786] Names in function call exception should have class names, 
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1440815105.46.0.0324800667014.issue2786@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think a) is worth doing regardless - in many cases, third party libraries will be dealing with function, generator or coroutine objects, rather than with code objects directly, so they'll benefit even if the updated API remains private to the interpreter.

So let's narrow the scope of this particular issue to just that, and defer the idea of a new public API for the time being.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Sat Aug 29 05:49:58 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Aug 2015 03:49:58 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1440820198.43.0.663323596983.issue11320@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Unfortunately, the answer to the question "Isn't there anybody motivated to fix this bug?" is "No, not really". As far as I am aware, all of the currently active core developers are primarily interested in the use of the default runtime interpreter as is, rather than embedding it in larger applications (which is the main case where PySys_SetPath is needed).

I'm *personally* interested in that area (hence my intermittent updates to PEP 432), but it's purely on my own time rather than being particularly work related.

That said, Steve Dower did do some significant work to provide an embedding friendly variant of the Windows builds for 3.5, so I've added him to the nosy list here in case he might be able to take a look.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Sat Aug 29 05:57:30 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Aug 2015 03:57:30 +0000
Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5
 with DLL loading
In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za>
Message-ID: <1440820650.25.0.201892322271.issue24748@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Given that both pywin32 *and* py2exe have hit this, even if it can't be resolved for 3.5.0, it would be highly desirable to address it for 3.5.1.

It's certainly intended that load_module() keep working as it has previously, rather than forcing people to switch to exec_module() in order to support extensions modules properly on Windows. Aside from general backwards compatibility expectations, there are still some things that load_module() can do that the new PEP 451/489 mechanisms can't handle yet.

----------
nosy: +larry
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24748>
_______________________________________

From report at bugs.python.org  Sat Aug 29 07:08:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Aug 2015 05:08:02 +0000
Subject: [issue24914] Python: Not just OO style but this is not mentioned on
 python.org or in FAQ
In-Reply-To: <1440225910.92.0.539487452884.issue24914@psf.upfronthosting.co.za>
Message-ID: <1440824882.8.0.0400366835555.issue24914@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24914>
_______________________________________

From report at bugs.python.org  Sat Aug 29 07:10:37 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Aug 2015 05:10:37 +0000
Subject: [issue24921] Operator precedence table in 5.15 should be highest to
 lowest precedence
In-Reply-To: <1440421712.73.0.607673856693.issue24921@psf.upfronthosting.co.za>
Message-ID: <1440825037.94.0.117704655983.issue24921@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24921>
_______________________________________

From report at bugs.python.org  Sat Aug 29 07:13:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Aug 2015 05:13:58 +0000
Subject: [issue24953] ICC and version should be in COMPILER string when built
 with ICC on Windows
In-Reply-To: <1440795113.81.0.941398168358.issue24953@psf.upfronthosting.co.za>
Message-ID: <20150829051356.3651.3713@psf.io>


Roundup Robot added the comment:

New changeset 3639520c3fe9 by Zachary Ware in branch '2.7':
Issue #24953: Include ICC version in sys.version string when bulit with ICC on Windows
https://hg.python.org/cpython/rev/3639520c3fe9

New changeset ca88db01bb51 by Zachary Ware in branch '3.5':
Issue #24953: Include ICC version in sys.version string when bulit with ICC on Windows
https://hg.python.org/cpython/rev/ca88db01bb51

New changeset 1633fe209375 by Zachary Ware in branch 'default':
Closes #24953: Merge with 3.5
https://hg.python.org/cpython/rev/1633fe209375

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24953>
_______________________________________

From report at bugs.python.org  Sat Aug 29 07:18:26 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Aug 2015 05:18:26 +0000
Subject: [issue24953] ICC and version should be in COMPILER string when built
 with ICC on Windows
In-Reply-To: <1440795113.81.0.941398168358.issue24953@psf.upfronthosting.co.za>
Message-ID: <1440825506.42.0.173421825911.issue24953@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the review, Steve!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24953>
_______________________________________

From report at bugs.python.org  Sat Aug 29 10:44:18 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 29 Aug 2015 08:44:18 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440837858.05.0.410942596889.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've updated the patches after review and implemented the checkup for llvm-profdata for both Linux and OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 29 10:44:34 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 29 Aug 2015 08:44:34 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440837874.44.0.787736724665.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40288/python2.7-pgo-v06.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 29 10:44:44 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 29 Aug 2015 08:44:44 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440837884.42.0.773405952979.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40289/python3.6-pgo-v06.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 29 12:01:40 2015
From: report at bugs.python.org (Simon Conseil)
Date: Sat, 29 Aug 2015 10:01:40 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
Message-ID: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>


New submission from Simon Conseil:

Hi,

There is an issue in the webbrowser module for Mac OS when the BROWSER environment variable is set:

Python 2.7.10 (default, Jul 14 2015, 19:46:27)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Jedi is not installed, falling back to readline
Python shell history: /Users/simon/.pythonhistory
>>> import webbrowser
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/webbrowser.py", line 669, in <module>
    cmd = _synthesize(cmdline, -1)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/webbrowser.py", line 94, in _synthesize
    if controller and name.lower() == controller.basename:
AttributeError: 'MacOSXOSAScript' object has no attribute 'basename'

If I unset BROWSER then it works fine. The issue is that the MacOSXOSAScript class overrides BaseBrowser's init without redifining the basename attribute. So a simple fix is to remove the __init__ from MacOSXOSAScript (and I guess the same applies to the MacOSX class). The same issue applies to python 3.4

----------
components: Library (Lib), Macintosh
files: webbrowser.patch
keywords: patch
messages: 249316
nosy: ned.deily, ronaldoussoren, sconseil
priority: normal
severity: normal
status: open
title: webbrowser broken on Mac OS X when using the BROWSER variable
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file40290/webbrowser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Sat Aug 29 12:17:33 2015
From: report at bugs.python.org (Simon Conseil)
Date: Sat, 29 Aug 2015 10:17:33 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1440843453.5.0.292637677203.issue24955@psf.upfronthosting.co.za>


Simon Conseil added the comment:

New version of the patch to rename the _name attribute to name as in other BaseBrowser subclasses.

----------
Added file: http://bugs.python.org/file40291/webbrowser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Sat Aug 29 12:17:52 2015
From: report at bugs.python.org (Simon Conseil)
Date: Sat, 29 Aug 2015 10:17:52 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1440843472.09.0.0908169615946.issue24955@psf.upfronthosting.co.za>


Changes by Simon Conseil <contact at saimon.org>:


Removed file: http://bugs.python.org/file40290/webbrowser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Sat Aug 29 12:19:14 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 29 Aug 2015 10:19:14 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1440843554.88.0.88860127792.issue9625@psf.upfronthosting.co.za>


Changes by Sworddragon <sworddragon2 at aol.com>:


----------
nosy: +Sworddragon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Sat Aug 29 12:26:34 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 29 Aug 2015 10:26:34 +0000
Subject: [issue24956] Default value for an argument that is not in the choices
 list gets accepted
Message-ID: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za>


New submission from Sworddragon:

Normally if a value to an argument is passed that is not in the choices list an error like "test.py: error: argument --test: invalid choice: 'c' (choose from 'a', 'b')" is shown. But if the default is set to an invalid choice no error is shown.

----------
components: Library (Lib)
messages: 249318
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Default value for an argument that is not in the choices list gets accepted
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24956>
_______________________________________

From report at bugs.python.org  Sat Aug 29 17:44:54 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 15:44:54 +0000
Subject: [issue24957] python3 -mpdb gets stuck in an unexitable infinite
 prompt loop when running some Python 2 code with syntax errors
Message-ID: <1440863094.43.0.957124241662.issue24957@psf.upfronthosting.co.za>


New submission from Shlomi Fish:

I tried Ctrl+C, Ctrl+D, "quit" and "exit", and "q" - nothing exits from the infinite prompt loop.

shlomif at telaviv1:~/Docs/homepage/homepage/trunk$ cd /home/shlomif/progs/riddles/project-euler/hg/project-euler/234
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ ls
brute-force.pl   euler-234-description.txt   euler-234-v1.py
brute-force.pl~  euler-234-description.txt~  euler-234-v1.py~
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ python3 euler-234-v1.py 
  File "euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ python3 -mpdb euler-234-v1.py 1000
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) 
(Pdb) exit
Post mortem debugger finished. The euler-234-v1.py will be restarted
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21                                                                
    print "Found[] = ", n                                                       
                     ^                                                          
SyntaxError: Missing parentheses in call to 'print'                             
Uncaught exception. Entering post mortem debugging                              
Running 'cont' or 'step' will restart the program                               
> <string>(1)<module>()                                                         
(Pdb) quit                                                                      
Post mortem debugger finished. The euler-234-v1.py will be restarted            
Traceback (most recent call last):                                              
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main                        
    pdb._runscript(mainpyfile)                                                  
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript                  
    self.run(statement)                                                         
  File "/usr/lib64/python3.4/bdb.py", line 431, in run                          
    exec(cmd, globals, locals)                                                  
  File "<string>", line 1, in <module>                                          
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) 
Post mortem debugger finished. The euler-234-v1.py will be restarted
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) --KeyboardInterrupt--
(Pdb) --KeyboardInterrupt--
(Pdb) exit
Post mortem debugger finished. The euler-234-v1.py will be restarted
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) quit
Post mortem debugger finished. The euler-234-v1.py will be restarted
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/shlomif/progs/riddles/project-euler/hg/project-euler/234/euler-234-v1.py", line 21
    print "Found[] = ", n
                     ^
SyntaxError: Missing parentheses in call to 'print'
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) 
[1]+  Stopped                 python3 -mpdb euler-234-v1.py 1000
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ kill %1

[1]+  Stopped                 python3 -mpdb euler-234-v1.py 1000
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ 
[1]+  Terminated              python3 -mpdb euler-234-v1.py 1000
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ 
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ 
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$ jobs
shlomif at telaviv1:~/progs/riddles/project-euler/hg/project-euler/234$

----------
components: Library (Lib)
files: euler-234-v1.py
messages: 249319
nosy: shlomif
priority: normal
severity: normal
status: open
title: python3 -mpdb gets stuck in an unexitable infinite prompt loop when running some Python 2 code with syntax errors
versions: Python 3.4
Added file: http://bugs.python.org/file40292/euler-234-v1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24957>
_______________________________________

From report at bugs.python.org  Sat Aug 29 17:45:47 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 15:45:47 +0000
Subject: [issue24957] python3 -mpdb gets stuck in an unexitable infinite
 prompt loop when running some Python 2 code with syntax errors
In-Reply-To: <1440863094.43.0.957124241662.issue24957@psf.upfronthosting.co.za>
Message-ID: <1440863147.68.0.398017964912.issue24957@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

I should note that I am using python3-3.4.3-6.mga6 on Mageia Linux x86-64 6/Cauldron.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24957>
_______________________________________

From report at bugs.python.org  Sat Aug 29 17:51:06 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Aug 2015 15:51:06 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1440863466.53.0.801761205009.issue11320@psf.upfronthosting.co.za>


Steve Dower added the comment:

Seems like a fairly obvious bug. From https://docs.python.org/3/c-api/init.html#c.Py_SetPath

> This also causes ... sys.prefix and sys.exec_prefix to be empty.
> It is up to the caller to modify these if required after calling
> Py_Initialize().

Apparently you can't set `sys.[exec_]prefix` before calling Py_Initialize, and you can't call Py_Initialize without setting `sys.[exec_]prefix` (much like #20891, where you can't initialize threads without holding the GIL, and you can't acquire the GIL without having initialized threads.)

I don't know how to go about resolving this though (my changes were limited to getpathp.c - and I really need to go add the same changes to the non-Windows getpath.c too...). The best way seems to be forcing Nick to finish PEP 432, but unfortunately I have no leverage over him :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Sat Aug 29 18:01:34 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 16:01:34 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
Message-ID: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>


New submission from Shlomi Fish:

After I run python3 (to run the REPL) and type "r" and then PgUp twice, I get a segfault. I'm on Mageia Linux x86-64 6 , but recall a similar problem happening before:

shlomif at telaviv1:~$ python3
Python 3.4.3 (default, Aug 13 2015, 21:40:54) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> rSegmentation fault
shlomif at telaviv1:~$ python3^C

I'm attaching the /etc/inputrc.

----------
components: Interpreter Core
files: inputrc
messages: 249322
nosy: shlomif
priority: normal
severity: normal
status: open
title: Segfault in REPL after pressing "r" and PgUp twice (on Mageia Linux x86-64 6)
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file40293/inputrc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 18:15:14 2015
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 29 Aug 2015 16:15:14 +0000
Subject: [issue24959] unittest swallows part of stack trace using "raise from"
 with AssertionError
Message-ID: <1440864914.24.0.799928607113.issue24959@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

unittest swallows some lines of the stack trace when raising an AssertionError using the "raise from" syntax inside a TestCase.  This marks it harder to pinpoint the source of test failures.  It is also confusing to see a stack trace like this because the error doesn't originate where the stack trace says it originates.

To reproduce:

    import unittest

    def foo():
        raise Exception("foo")

    class Test(unittest.TestCase):

        def test_not_okay(self):
            try:
                foo()
            except Exception as exc:
                raise AssertionError("bar") from exc

        def test_okay1(self):
            try:
                foo()
            except Exception as exc:
                raise ValueError("bar") from exc

        def test_okay2(self):
            try:
                foo()
            except Exception as exc:
                raise Exception("bar") from exc

The result (observe how the display for "test_not_okay" differs from the other two):

    ======================================================================
    ERROR: test_okay1 (error.Test)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 17, in test_okay1
        foo()
      File "/Users/chris/dev/error.py", line 5, in foo
        raise Exception("foo")
    Exception: foo

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 19, in test_okay1
        raise ValueError("bar") from exc
    ValueError: bar

    ======================================================================
    ERROR: test_okay2 (error.Test)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 23, in test_okay2
        foo()
      File "/Users/chris/dev/error.py", line 5, in foo
        raise Exception("foo")
    Exception: foo

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 25, in test_okay2
        raise Exception("bar") from exc
    Exception: bar

    ======================================================================
    FAIL: test_not_okay (error.Test)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 11, in test_not_okay
        foo()
    Exception: foo

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "/Users/chris/dev/error.py", line 13, in test_not_okay
        raise AssertionError("bar") from exc
    AssertionError: bar

    ----------------------------------------------------------------------
    Ran 3 tests in 0.001s

    FAILED (failures=1, errors=2)

----------
components: Library (Lib)
messages: 249323
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: unittest swallows part of stack trace using "raise from" with AssertionError
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24959>
_______________________________________

From report at bugs.python.org  Sat Aug 29 18:26:13 2015
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 29 Aug 2015 16:26:13 +0000
Subject: [issue24959] unittest swallows part of stack trace when raising
 AssertionError in a TestCase
In-Reply-To: <1440864914.24.0.799928607113.issue24959@psf.upfronthosting.co.za>
Message-ID: <1440865573.76.0.529667983641.issue24959@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I guess this isn't limited just to the "raise from" syntax.  It also occurs if "from exc" is removed from the example above.

----------
title: unittest swallows part of stack trace using "raise from" with AssertionError -> unittest swallows part of stack trace when raising AssertionError in a TestCase

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24959>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:05:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Aug 2015 17:05:38 +0000
Subject: [issue24956] Default value for an argument that is not in the choices
 list gets accepted
In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za>
Message-ID: <1440867938.95.0.341752995248.issue24956@psf.upfronthosting.co.za>


R. David Murray added the comment:

That might be intentional, and in any case fixing it would be backward incompatible.  I think we should just live with it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24956>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:09:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Aug 2015 17:09:49 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440868189.86.0.229563106206.issue24958@psf.upfronthosting.co.za>


R. David Murray added the comment:

What makes you think this is a bug in Python?  Can you reduce the inputrc to the minimum that reproduces the problem?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:13:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Aug 2015 17:13:39 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440868419.61.0.139027475604.issue24958@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, should have been clearer "a bug in python as opposed to one in Mageia's readline".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:20:36 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 17:20:36 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440868836.14.0.0783667412878.issue24958@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

I'm attaching here the reduced, minimal, inputrc. I think it's a bug in Python because it doesn't happen with any other program that uses readline (bash, perl -d, etc.) that I checked. I'll check with a vanilla readline compiled from source from the GNU site , though.

----------
Added file: http://bugs.python.org/file40294/_inputrc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:36:22 2015
From: report at bugs.python.org (Oleg N)
Date: Sat, 29 Aug 2015 17:36:22 +0000
Subject: [issue24960] Can't use pip or easy_install with embeddable zip file.
Message-ID: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za>


New submission from Oleg N:

Error: [Errno 2] No such file or directory: '...\\python35.zip\\lib2to3\\Grammar.txt'. Python35.zip from this archive: https://www.python.org/ftp/python/3.5.0/python-3.5.0rc2-embed-amd64.zip. Path is correct.

----------
components: Library (Lib)
messages: 249329
nosy: Oleg N
priority: normal
severity: normal
status: open
title: Can't use pip or easy_install with embeddable zip file.
type: resource usage
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24960>
_______________________________________

From report at bugs.python.org  Sat Aug 29 19:48:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Aug 2015 17:48:07 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440870487.65.0.181199276513.issue24958@psf.upfronthosting.co.za>


R. David Murray added the comment:

I can't reproduce it on my Gentoo box using 3.4 tip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 20:44:05 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 29 Aug 2015 18:44:05 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440873845.11.0.125964721246.issue24958@psf.upfronthosting.co.za>


eryksun added the comment:

Maybe the problem is using escape characters (0x1b) instead of \e. Try using the following:

"\e[5~": history-search-backward

FWIW, your inputrc doesn't crash my system (64-bit Linux, readline 6.3 and Python 3.4).

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 21:26:11 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 19:26:11 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440876371.16.0.784933582991.issue24958@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

Hi all!

Thanks for the investigation.

I have now built readline-6.3 from source using:

./configure --prefix="$HOME/apps/readline-TO_DEL" --with-curses=yes --enable-multibyte

and installed it. Then I built python 3.4.3 from source against it by setting LIBRARY_PATH/CPATH/etc. and by this patch to setup.py:

        if True: # if cross_compiling:
            self.add_gcc_paths()

After I built it and ran it, it still segfaults after I type "r" and press PgUp twice. I've attached the strace output (compressed with xz).

----------
Added file: http://bugs.python.org/file40295/py3.strace.xz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:21:43 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 29 Aug 2015 20:21:43 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440879703.45.0.682803049675.issue24915@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

The latest patch worked fine for me (Mac OS X Yosemite). I've only tried with 2.7 so far. The only thing that was a bit mystifying were the errors during the initial profile run. There is so much that floats by in the terminal window that I completely missed the warnings about errors during the test run not being anything to worry about. I only noticed the messages when I took a look at the patch more closely.

Perhaps it would be worthwhile to add a short bit about the profile-opt target and its requirements to the README file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:24:52 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 29 Aug 2015 20:24:52 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440879892.76.0.74557503087.issue24958@psf.upfronthosting.co.za>


eryksun added the comment:

A gdb backtrace may be of more help than strace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:36:49 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 20:36:49 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440880609.95.0.653114849315.issue24958@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

gdb by full attached.

----------
Added file: http://bugs.python.org/file40296/py3.gdb-bt.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:45:01 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 29 Aug 2015 20:45:01 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440881101.95.0.182605461685.issue24915@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

Not knowing a darn thing about this, I went ahead and made a provisional change to the README file.

----------
Added file: http://bugs.python.org/file40297/README.pgo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:59:20 2015
From: report at bugs.python.org (Dave Hein)
Date: Sat, 29 Aug 2015 20:59:20 +0000
Subject: [issue24961] shell stdout broken after exiting interactive python
 prompt
Message-ID: <1440881960.56.0.727538503995.issue24961@psf.upfronthosting.co.za>


New submission from Dave Hein:

With 3.4.3 from an OS X terminal prompt, if I just enter the interactive Python REPL environment (by just entering the command "python" from the command line) and then exit (via "exit()" or Ctrl-D), then stdout appears to be broken ... I see no stdout output on the terminal from that point forward. I do see stderr output.

If I just run a python script, without the "-i" flag, then stdout is not damaged and the subsequent terminal interaction is normal.

I did not see this with 3.4.2 or any other version of Python.

I'm running OS X 10.9.5, have installed Python 3.4.3 with MacPorts, and use virtualenv.

----------
components: IO
messages: 249337
nosy: datihein
priority: normal
severity: normal
status: open
title: shell stdout broken after exiting interactive python prompt
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24961>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:28:28 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Aug 2015 21:28:28 +0000
Subject: [issue24961] shell stdout broken after exiting interactive python
 prompt
In-Reply-To: <1440881960.56.0.727538503995.issue24961@psf.upfronthosting.co.za>
Message-ID: <1440883708.48.0.216258253155.issue24961@psf.upfronthosting.co.za>


Ned Deily added the comment:

There have been other problems reported with MacPorts Python 3.4 using their default most recent version of the BSD libedit package.  As far as I know, those problems have not yet been resolved but I can't get to the MacPorts issue tracker at the moment to check.  The workaround has been to install the optional py34-readline port which modifies the MacPorts python3.4 to use GNU readline rather than libedit.  In any case, you can follow up on the MacPorts tracker (https://trac.macports.org) as this is not a problem seen with a vanilla Python 3.4.x on OS X using the Apple-supplied system version of libedit.

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24961>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:40:45 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 29 Aug 2015 21:40:45 +0000
Subject: [issue24941] Add classproperty as builtin class
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440884445.57.0.490707675635.issue24941@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've posted a counter-proposal on python-ideas:

https://mail.python.org/pipermail/python-ideas/2015-August/035614.html

Basically: instead of "classproperty", add a more lenient alternative to classmethod which allows composition.  I called it "classresolved".

class classresolved:
    def __init__(self, wrapped):
        self.wrapped = wrapped
    def __get__(self, obj, cls):
        try:
            getter = self.wrapped.__get__
        except AttributeError:
            return self.wrapped
        return getter(cls, type(cls))

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:43:05 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 29 Aug 2015 21:43:05 +0000
Subject: [issue24941] Add classproperty as builtin class
In-Reply-To: <1440572823.94.0.53142388883.issue24941@psf.upfronthosting.co.za>
Message-ID: <1440884585.49.0.0735038397558.issue24941@psf.upfronthosting.co.za>


Eric Snow added the comment:

I also posted a broader proposal:

https://mail.python.org/pipermail/python-ideas/2015-August/035615.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24941>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:44:14 2015
From: report at bugs.python.org (Dave Hein)
Date: Sat, 29 Aug 2015 21:44:14 +0000
Subject: [issue24961] shell stdout broken after exiting interactive python
 prompt
In-Reply-To: <1440881960.56.0.727538503995.issue24961@psf.upfronthosting.co.za>
Message-ID: <1440884654.75.0.846040847978.issue24961@psf.upfronthosting.co.za>


Dave Hein added the comment:

Thanks. I installed py34-readline and rebuilt my virtualenv; all is well now.

I put in a MacPorts ticket when their bugtracker gets back online.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24961>
_______________________________________

From report at bugs.python.org  Sun Aug 30 00:19:19 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Aug 2015 22:19:19 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1440863466.53.0.801761205009.issue11320@psf.upfronthosting.co.za>
Message-ID: <CADiSq7ePU5uCSq0qncPAhvHDbwTZ9A0e3HSo81kWzCnkui=rwg@mail.gmail.com>


Nick Coghlan added the comment:

I think the current situation is mainly an artifact of our relative dearth
of regression testing for embedded configurations, and the fact that we
have very few core developers working for companies embedding CPython in
larger applications.

I do care about that space (hence PEP 432), but operating system
integration, software distribution tools, and improved modularisation take
precedence on work time, and the science & education sectors on my personal
time.

I did recently file issue 24932 to propose investigating and adopting a C
level unit testing framework for the embedding tests, as one of the things
my preliminary work on PEP 432 highlighted is how limited our current
direct testing capabilities for the embedding API are - at this point,
we're mostly limited to testing it the way CPython uses it, which makes it
unfortunately fragile for embedders (as issues like this one show).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Sun Aug 30 00:35:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 29 Aug 2015 22:35:30 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440887730.95.0.782846037488.issue24958@psf.upfronthosting.co.za>


Martin Panter added the comment:

Well it looks like you?ve identified that PgUp triggers a history search. Perhaps it would be good to look at your /home/shlomif/.python_history file, assuming there is nothing sensitive in there. The strace output only indicates it is 411 bytes and gives the first one-and-a-half lines. My guess is there is something funny about a line beginning with ?r?, or a nearby line.

But it still sounds like a Readline bug instead of a Python bug. If you clear or remove the history file, does the bug go away? Maybe you can replace the equivalent ~/.bash_history or Perl history file to see if it triggers a crash there.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sun Aug 30 01:08:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 29 Aug 2015 23:08:32 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440889712.09.0.781166957452.issue24958@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to the GDB backtrace, _rl_kscxt is a null pointer at <https://github.com/Distrotech/readline/blob/readline-6.3/callback.c#L188>, while the _rl_dispatch_callback() function doesn?t handle null pointers. Maybe you would find the Readline people more knowledgeable about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sun Aug 30 01:51:45 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 29 Aug 2015 23:51:45 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440892305.71.0.025452215547.issue24912@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

Well, yeah, that indeed sucks.

Not sure what the best solution is. Some options:

1) "Don't do that then"

2) Explicitly add a "__class__" property to every immutable type, that unconditionally errors out on assignment.

3) Add a hack to typeobject.c checking for the important immutable types

4) Something cleverer...? A new type flag?

The immutable types are: int, float, str, tuple, bool, frozenset, complex, bytes, and... anything else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 05:18:44 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Sun, 30 Aug 2015 03:18:44 +0000
Subject: [issue24962] Unnecessary space in using/mac
Message-ID: <1440904724.88.0.774285307228.issue24962@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

https://docs.python.org/3.4/using/mac.html#configuration

A newline in the file path of the .plist file makes a space in the rendered result.
The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: using_mac.patch
keywords: patch
messages: 249346
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Unnecessary space in using/mac
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40298/using_mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24962>
_______________________________________

From report at bugs.python.org  Sun Aug 30 05:27:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Aug 2015 03:27:59 +0000
Subject: [issue24962] Unnecessary space in using/mac
In-Reply-To: <1440904724.88.0.774285307228.issue24962@psf.upfronthosting.co.za>
Message-ID: <20150830032755.117772.85676@psf.io>


Roundup Robot added the comment:

New changeset 3ef2d694e976 by Zachary Ware in branch '2.7':
Issue #24962: Remove space from filename
https://hg.python.org/cpython/rev/3ef2d694e976

New changeset 2de6fba18ff6 by Zachary Ware in branch '3.4':
Issue #24962: Remove space from filename
https://hg.python.org/cpython/rev/2de6fba18ff6

New changeset 84c3188f6e1e by Zachary Ware in branch '3.5':
Issue #24962: Merge 3.4
https://hg.python.org/cpython/rev/84c3188f6e1e

New changeset 5711ffc2292f by Zachary Ware in branch 'default':
Closes #24962: Merge with 3.5
https://hg.python.org/cpython/rev/5711ffc2292f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24962>
_______________________________________

From report at bugs.python.org  Sun Aug 30 05:28:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 30 Aug 2015 03:28:48 +0000
Subject: [issue24962] Unnecessary space in using/mac
In-Reply-To: <1440904724.88.0.774285307228.issue24962@psf.upfronthosting.co.za>
Message-ID: <1440905328.38.0.499897655051.issue24962@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report and patch!

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24962>
_______________________________________

From report at bugs.python.org  Sun Aug 30 05:41:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Aug 2015 03:41:06 +0000
Subject: [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <20150830034103.27009.6577@psf.io>


Roundup Robot added the comment:

New changeset 192c654a7c93 by Zachary Ware in branch '3.5':
Issue #24272: Remove usage of default reST role from typing docs
https://hg.python.org/cpython/rev/192c654a7c93

New changeset 10a63ded324c by Zachary Ware in branch 'default':
Issue #24272: Merge with 3.5
https://hg.python.org/cpython/rev/10a63ded324c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24272>
_______________________________________

From report at bugs.python.org  Sun Aug 30 08:01:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Aug 2015 06:01:35 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440914495.13.0.800393670808.issue24912@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Later I had got a crash.

>>> class S(str): __slots__ = ()
... 
>>> 'a'.__class__ = S
>>> 
>>> def f(a): pass
... 
Fatal Python error: non-string found in code slot

Current thread 0xb7583700 (most recent call first):
Aborted (core dumped)

The stdlib is full of implicit caches. Virtually any hashable object can be cached and shared. Why __class__ assignment is allowed at all? There are only two uses of __class__ assignment in the stdlib besides tests (in Lib/importlib/util.py and in Lib/xml/sax/saxutils.py), and in both cases it looks as optimization trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 08:03:37 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Aug 2015 06:03:37 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440914617.85.0.91812251828.issue24912@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Probably the patch on that bug should be reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 08:59:21 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sun, 30 Aug 2015 06:59:21 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440917961.24.0.626730491062.issue24958@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

Marting Panter: I'm getting the same problem with a completely empty ~/.python_history file. Moreover, I was able to reproduce a similar bug in gdb. I'll try seeing if I can create a minimal GNU readline-using program here that reproduces it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sun Aug 30 09:14:14 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sun, 30 Aug 2015 07:14:14 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440918854.79.0.747658225389.issue24958@psf.upfronthosting.co.za>


Shlomi Fish added the comment:

Martin: [sorry for misspelling your name] I was now able to reproduce the same problem using rlwrap (see http://utopia.knoware.nl/~hlub/rlwrap/ ). I'll report it to the readline problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sun Aug 30 09:55:14 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 30 Aug 2015 07:55:14 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440921314.81.0.101345933913.issue24912@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

Python goes to great lengths to make __class__ assignment work in general (I was surprised too). Historically the exception has been that instances of statically allocated C extension type objects could not have their __class__ reassigned. Semantically, this is totally arbitrary, and Guido even suggested that fixing this would be a good idea in this thread:
   https://mail.python.org/pipermail/python-dev/2014-December/137430.html
The actual rule that's causing problems here is that *immutable* objects should not allow __class__ reassignment. (And specifically, objects which are assumed to be immutable by the interpreter. Most semantically immutable types in Python are defined by users and their immutability falls under the "consenting adults" rule; it's not enforced by the interpreter. Also this is very different from "hashable" -- even immutability isn't a requirement for being hashable, e.g., all user-defined types are mutable and hashable by default!)

By accident this category of "immutable-by-interpreter-invariant" has tended to be a subset of "defined in C using the old class definition API", so fixing the one issue uncovered the other.

This goal that motivated this patch was getting __class__ assignment to work on modules, which are mutable and uncacheable and totally safe. With this patch it becomes possible to e.g. issue deprecation warnings on module attribute access, which lets us finally deprecate some horrible global constants in numpy that have been confusing users for a decade now:
   http://mail.scipy.org/pipermail/numpy-discussion/2015-July/073205.html
   https://pypi.python.org/pypi/metamodule

I'd *really* prefer not to revert this totally, given the above. (Also, if you read that python-dev message above, you'll notice that the patch also caught and fixed a different really obscure interpreter-crashing bug.)

I think the Correct solution would be to disallow __class__ assignment specifically for the classes where it violates invariants.

If this is considered to be release critical -- and I'm not entirely sure it is, given that similar tricks have long been possible and are even referenced in the official docs?
  https://www.reddit.com/r/Python/comments/2441cv/can_you_change_the_value_of_1/ch3dwxt
  https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong
-- but if it is considered to be release critical, and it's considered too short notice to accomplish a proper fix, then a simple hack would be to add something like

if (!(oldto->tp_flags & Py_TPFLAGS_HEAPTYPE) && oldto != &PyModule_Type) {
    PyErr_Format(PyExc_TypeError, ...);
    return -1;
}

to typeobject.c:object_set_class. As compared to reverting the whole patch, this would preserve the most important case, which is one that we know is safe, and we could then progressively relax the check further in the future...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 10:30:06 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 30 Aug 2015 08:30:06 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440923406.79.0.150181741791.issue24915@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

That's a good point Skip. I added another set of patches, just for the README files, explaining the entire procedure, so now anyone reading it will see that PGO is available, what are the steps involved and a brief comment about the warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 30 10:30:17 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 30 Aug 2015 08:30:17 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440923417.95.0.915448168608.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40299/README2.7-pgo-v01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 30 10:30:25 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 30 Aug 2015 08:30:25 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1440923425.25.0.46411251283.issue24915@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file40300/README3.6-pgo-v01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24915>
_______________________________________

From report at bugs.python.org  Sun Aug 30 13:20:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 30 Aug 2015 11:20:46 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440933646.11.0.640081311584.issue5319@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe 255 is a reasonable choice. Another option is some value slightly less than 126, since Posix shells have special meanings for 126, 127, and > 128 values.

My patches already document the exit status used under the Py_Exit() function: ?If :c:func:`Py_FinalizeEx` indicates an error, the exit status is set to 1 [or 255].? Do you think it should be documented somewhere else as well, perhaps for the interpreter as a whole?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Sun Aug 30 13:43:19 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 30 Aug 2015 11:43:19 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440934999.87.0.943992144165.issue24912@psf.upfronthosting.co.za>


Mark Shannon added the comment:

Please revert c0d25de5919e.
Breaking the interpreter in order to facilitate some obscure use case is unacceptable.

If you want to do fancy stuff with modules, fine. Take a look at the source of the six module 
https://bitbucket.org/gutworth/six/src/cd1e81d33eaf3d6944f859c2aa7d5d3f515013c8/six.py?at=default for some tips.

I think immutability is a fundamental property of an object. The "consenting" adults ideas is fine for accessibility. However, making previously immutable object mutable forces developers to use lots of defensive copying and causes obscure bugs (like this one).

I do not regard the immutable of numbers as an historical accident, but as vitally important for any sort of numerical reasoning.
Just take a look at a language with mutable strings to see the problems that causes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 16:15:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 Aug 2015 14:15:07 +0000
Subject: [issue24958] Segfault in REPL after pressing "r" and PgUp twice (on
 Mageia Linux x86-64 6)
In-Reply-To: <1440864094.01.0.546248794803.issue24958@psf.upfronthosting.co.za>
Message-ID: <1440944107.87.0.712510858532.issue24958@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24958>
_______________________________________

From report at bugs.python.org  Sun Aug 30 18:17:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Aug 2015 16:17:11 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <20150830161708.117756.5713@psf.io>


Roundup Robot added the comment:

New changeset fa3ac31cfa44 by Raymond Hettinger in branch '3.4':
Issue #24931:  Resolve __dict__ conflict in namedtuple subclasses.
https://hg.python.org/cpython/rev/fa3ac31cfa44

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Sun Aug 30 18:26:25 2015
From: report at bugs.python.org (zodalahtathi)
Date: Sun, 30 Aug 2015 16:26:25 +0000
Subject: [issue24963] ipaddress.IPv6Network doc typo
Message-ID: <1440951985.53.0.495808420331.issue24963@psf.upfronthosting.co.za>


New submission from zodalahtathi:

This is probably not the biggest bug ever, but in the doc for ipaddress.IPv6Network:

"An integer packed into a bytes object of length 16, bit-endian"

should be changed to:

"An integer packed into a bytes object of length 16, big-endian"

----------
assignee: docs at python
components: Documentation
messages: 249359
nosy: docs at python, zodalahtathi
priority: normal
severity: normal
status: open
title: ipaddress.IPv6Network doc typo
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24963>
_______________________________________

From report at bugs.python.org  Sun Aug 30 18:49:36 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 30 Aug 2015 16:49:36 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440953376.13.0.223900181425.issue24912@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

Wow, Mark, why so hostile? What's so wrong with my proposed less-intrusive patch that you feel the need to call for reversion while condescendingly pointing me to a non-solution? Of course I know about six. There was a whole python-dev thread about how neither its tricks nor any of the other tricks that python 3.4 allows actually do what we need.

Let me try again.

We all agree that this bug is a bug and that numbers should be immutable.

Our old rules for __class__ assignment were also buggy; it was just an accident that they were buggy in a way that happened to prevent a different bug, ie this one. The proper way to enforce the immutability of immutable builtins is to enforce the immutability of immutable builtins, not to enforce the immutability of a bunch of random types based on an implementation detail (that happens to include the immutable builtins). Reverting the patch gives us the latter, which is why I don't think it's the proper fix.

Now maybe we don't have time for a proper fix. I'm not sure why not -- AFAICT there would not be any disaster if this fix waited for 3.5.1. This is a scary looking bug, but the effect is that it takes something that used to require 3 obscure lines involving ctypes and makes it into 1 obscure line not involving ctypes. Which is bad. But we're hardly going to see an epidemic of people using this loophole to change the type of 1 and then complaining to python-dev that they changed the type of 1, any more than we saw such an epidemic when ctypes was introduced. So we have time to take a deep breath and come up with a proper fix, is all I'm saying. But of course this is Larry's call.

If it is crucial to get a fix in for 3.5.0, then the least intrusive solution is not to revert the patch wholesale, but rather to add a (hacky but safe) guard to object_set_class. The guard I suggested above is stricter than necessary for correctness, but it catches all the problems described in this bug report, and the cases where it's over-strict are all cases where 3.4 was also over-strict, so there's minimal chance of it causing any regressions.

Like I said, I'm not sure that's what we want to do. But if it is then I can throw a patch together in a few minutes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 18:50:48 2015
From: report at bugs.python.org (Eric Snow)
Date: Sun, 30 Aug 2015 16:50:48 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1440953448.91.0.037276005025.issue11320@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:41:55 2015
From: report at bugs.python.org (Thomas)
Date: Sun, 30 Aug 2015 17:41:55 +0000
Subject: [issue24964] Add tunnel CONNECT response headers to httplib /
 http.client
Message-ID: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za>


New submission from Thomas:

When using httplib / http.client to connect to an HTTPS website through a proxy (by making a tunnel with a CONNECT request), there is no way to retrieve the HTTP headers which the proxy sends back in response to that CONNECT request.

This becomes a problem when using rotating proxy providers like ProxyMesh, who send useful information in those headers (for instance, "X-ProxyMesh-IP" contains the IP address of the proxy, which is necessary to keep the same address throughout the session).

It would be nice to save those headers in a property of the HTTPConnection class (e.g. self._tunnel_response_headers), which would be set up inside the _tunnel method (as proposed in the attached patch, lines 748 and 827-831). This would allow to get the headers back and/or pass them to a higher-level library (such as requests).

----------
components: Library (Lib)
files: httplib.py
messages: 249361
nosy: Thomas
priority: normal
severity: normal
status: open
title: Add tunnel CONNECT response headers to httplib / http.client
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40301/httplib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24964>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:44:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Aug 2015 17:44:11 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1440956651.02.0.0897273160933.issue24931@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:47:03 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 30 Aug 2015 17:47:03 +0000
Subject: [issue24965] Implement PEP 498: Literal String Formatting
Message-ID: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

See PEP 498.

>>> f'New for Python {sys.version.split()[0]}'
'New for Python 3.6.0a0'

----------
assignee: eric.smith
components: Interpreter Core
files: pep-498.diff
keywords: patch
messages: 249362
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Implement PEP 498: Literal String Formatting
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40302/pep-498.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24965>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:50:33 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 30 Aug 2015 17:50:33 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440957033.96.0.343398311791.issue24912@psf.upfronthosting.co.za>


Mark Shannon added the comment:

Nathaniel, I'm hostile to this patch remaining in the code base.
I'm not hostile to you, sorry that I came across as that way.

The proper way to deal with issues like this is to revert the change and then create a new patch, otherwise it becomes impossible to revert the change if other problems emerge.

I agree that the bug in __class__ assignment should be fixed, but such a fix should be separate from adding any new features.

Also, I'm surprised that you assert that you can't do what your metamodule does, without ctypes.
Your metamodule package is almost there.

Your statement
"Depending on the relative order of the assignment to sys.modules and imports of submodules, you can end up with different pieces of code in the same program thinking that mymodule refers to one or the other of these objects."
is true.

So, just make sure that you insert the new object into sys.modules *before* doing any imports or calls to code that could import your module and it will all work fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:51:10 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 30 Aug 2015 17:51:10 +0000
Subject: [issue24965] Implement PEP 498: Literal String Formatting
In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za>
Message-ID: <1440957070.33.0.503722869447.issue24965@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

One thing I've done in this implementation is to build up a string to pass to str.format(), instead of using the original string. This new string uses positional parameters instead of named parameters.

I had originally proposed to add a string.interpolate() to do the heavy lifting here, which would have meant I could use the original string (as seen in the source code), and not build up a new string and pass it to str.format(). I still might do that, but for now, the approach using str.format() is good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24965>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:59:59 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 30 Aug 2015 17:59:59 +0000
Subject: [issue24965] Implement PEP 498: Literal String Formatting
In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za>
Message-ID: <1440957599.34.0.734988398205.issue24965@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops, I didn't really mean to include imporlib.h. Oh, well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24965>
_______________________________________

From report at bugs.python.org  Sun Aug 30 20:28:19 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 30 Aug 2015 18:28:19 +0000
Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in
 Py2.x
In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za>
Message-ID: <1440959299.02.0.547635874366.issue12885@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jason.coombs
hgrepos: +315

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12885>
_______________________________________

From report at bugs.python.org  Sun Aug 30 20:29:11 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 30 Aug 2015 18:29:11 +0000
Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in
 Py2.x
In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za>
Message-ID: <1440959351.86.0.90436058245.issue12885@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40303/faf37fc3b097.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12885>
_______________________________________

From report at bugs.python.org  Sun Aug 30 20:32:24 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 30 Aug 2015 18:32:24 +0000
Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in
 Py2.x
In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za>
Message-ID: <1440959544.42.0.820187816054.issue12885@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Eric, would you be willing to review the commits in the referenced patch repo (collapsed in the attached diff)? If you're happy with the implementation, I'll backport it to Python 2.7 and apply it to 3.4-3.6 and then update setuptools to only monkeypatch older distutils.

----------
assignee: jason.coombs -> eric.araujo
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12885>
_______________________________________

From report at bugs.python.org  Sun Aug 30 21:24:38 2015
From: report at bugs.python.org (mattip)
Date: Sun, 30 Aug 2015 19:24:38 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440962678.01.0.903975645942.issue24952@psf.upfronthosting.co.za>


mattip added the comment:

Add the default value 0 to the documentation, please review this patch and not the previous one

----------
versions:  -Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40304/stack_size.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Sun Aug 30 21:26:27 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Aug 2015 19:26:27 +0000
Subject: [issue24965] Implement PEP 498: Literal String Formatting
In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za>
Message-ID: <1440962787.32.0.69700224732.issue24965@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24965>
_______________________________________

From report at bugs.python.org  Sun Aug 30 21:30:49 2015
From: report at bugs.python.org (mattip)
Date: Sun, 30 Aug 2015 19:30:49 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440963049.4.0.878069743562.issue24952@psf.upfronthosting.co.za>


mattip added the comment:

Add default value of 0 to documentation for 2.7

----------
versions: +Python 3.5 -Python 2.7
Added file: http://bugs.python.org/file40305/stack_size2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Sun Aug 30 21:44:36 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 30 Aug 2015 19:44:36 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1440963876.25.0.453428391244.issue24912@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I will not ship 3.5.0 with this bug.

Consider for a moment Google App Engine. If GAE updated to 3.5 with this bug, users would now have the ability to inject code into other people's programs, because interned ints (and a couple other types) are shared across interpreters.

Reverting the patch gives us back the old behavior.  Dismissing the old behavior as "buggy" is unconvincing; it was acceptable enough that it shipped with many versions of Python, and its behavior is predictable and within the boundaries of the language spec.

Nathaniel, I'm willing to consider fixes for this bug, if the other devs in this thread are satisfied with the fix.  But I am *absolutely* leaning towards backing it out for 3.5.  My goal is to ship high-quality software, and that means balancing new features against regressions and new exploits.  We almost didn't find this in time before 3.5 shipped--not to spread FUD, but what other ramifications of this code are lurking in the object model, waiting to be discovered?

p.s. I would love it if someone would add a regression test that tried mutating fields on a bunch of interned objects.  Certainly such a test would be a precondition of keeping this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Sun Aug 30 22:01:27 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 30 Aug 2015 20:01:27 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440964887.45.0.722071215891.issue5319@psf.upfronthosting.co.za>


Robert Collins added the comment:

It seems to me that how, and when, Python exits the process is important to folk who will never ever touch the C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Sun Aug 30 23:43:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Aug 2015 21:43:34 +0000
Subject: [issue24963] ipaddress.IPv6Network doc typo
In-Reply-To: <1440951985.53.0.495808420331.issue24963@psf.upfronthosting.co.za>
Message-ID: <20150830214331.117770.48596@psf.io>


Roundup Robot added the comment:

New changeset a892c67fa0eb by Benjamin Peterson in branch '3.4':
fix spelling that was a bit confused (closes #24963)
https://hg.python.org/cpython/rev/a892c67fa0eb

New changeset b5434aff4e84 by Benjamin Peterson in branch '3.5':
merge 3.4 (#24963)
https://hg.python.org/cpython/rev/b5434aff4e84

New changeset 6463279d1358 by Benjamin Peterson in branch 'default':
merge 3.5 (#24963)
https://hg.python.org/cpython/rev/6463279d1358

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24963>
_______________________________________

From report at bugs.python.org  Mon Aug 31 00:59:13 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Sun, 30 Aug 2015 22:59:13 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError is stdout
 is detached, no fallback
Message-ID: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>


New submission from Roberto S?nchez:

After the stdout stream has been overwritten and detached, the method shutils.get_terminal_size throws a ValueError exception and no fallback value is returned.

Code to reproduce it:

    >>> import os, sys, codecs, shutils
    >>> sys.stdout = codecs.getwriter("utf-8")(sys.stdout.detach())
    >>> os.get_terminal_size()
    os.terminal_size(columns=160, lines=37)
    >>> shutil.get_terminal_size((200, 30))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module> 
      File "/usr/lib64/python3.4/shutil.py", line 1057, in get_terminal_size
        size = os.get_terminal_size(sys.__stdout__.fileno())
    ValueError: underlying buffer has been detached

Is this the expected behavior ? IMHO, the given fallback values should be returned.

The official doc: "If the terminal size cannot be successfully queried, either because the system doesn?t support querying, or because we are not connected to a terminal, the value given in fallback parameter is used. fallback defaults to (80, 24) which is the default size used by many terminal emulators"


BTW, the function os.get_terminal_size() returns the correct size when it's invoked without parameters, maybe It could be a good fallback if sys.__stdout__ is not available and there isn't any user fallback values.

----------
components: IO
messages: 249372
nosy: rsc1975
priority: normal
severity: normal
status: open
title: shutil.get_terminal_size() throws ValueError is stdout is detached, no fallback
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 00:59:38 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Sun, 30 Aug 2015 22:59:38 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1440975578.28.0.771366768686.issue24966@psf.upfronthosting.co.za>


Changes by Roberto S?nchez <dev at r75.es>:


----------
title: shutil.get_terminal_size() throws ValueError is stdout is detached, no fallback -> shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 01:05:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 30 Aug 2015 23:05:15 +0000
Subject: [issue24964] Add tunnel CONNECT response headers to httplib /
 http.client
In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za>
Message-ID: <1440975915.32.0.677944435771.issue24964@psf.upfronthosting.co.za>


Martin Panter added the comment:

Such a change would involve adding a new API, so should go into a new version of Python.

Thomas: a diff rather than a full copy of the changed file would be more convenient. Also, if this gets accepted, test cases and documentation would be needed.

It is also useful to get the header of an unsuccessful CONNECT response. For example, see Issue 7291, where the Proxy-Authenticate header of the proxy?s 407 response needs to be accessible. In that issue, I started working on a patch tht may also be useful here. From memory, usage would be a bit like this:

proxy_conn = HTTPConnection("proxy")
proxy_conn.request("CONNECT", "website:443")
proxy_resp = proxy_conn.getresponse()
if proxy_resp.status == PROXY_AUTHENTICATION_REQUIRED:
    # Handle proxy_resp.msg["Proxy-Authenticate"]
    ...
# Handle proxy_resp.msg["X-ProxyMesh-IP"]
...
tunnel = proxy_conn.detach()  # Returns socket and any buffered data
website_conn = HTTPSConnection("website", tunnel=tunnel)
website_conn.request("GET", "/")
...
website_conn.close()

Thomas, let me know if this would be useful for you, and I can try and dig up my patch.

----------
nosy: +martin.panter
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24964>
_______________________________________

From report at bugs.python.org  Mon Aug 31 02:03:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 00:03:38 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1440979418.54.0.619135252528.issue24966@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 24920.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 02:05:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 00:05:13 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1440979513.75.0.916362593587.issue24966@psf.upfronthosting.co.za>


R. David Murray added the comment:

In this case it might be better to leave the error.  The buffer being detached would seem to be a programming error.  What would be the use case for using get_terminal_size in a program that detaches the standard stream buffer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 03:18:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 01:18:42 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440983922.1.0.676977196561.issue24952@psf.upfronthosting.co.za>


Martin Panter added the comment:

This version looks okay. I?ll commit it when I get a chance.

BTW, there?s no point changing the version for each patch. The version field only applies to the whole bug report.

----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag
stage:  -> commit review
versions: +Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Mon Aug 31 03:47:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 01:47:24 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440985644.33.0.309331628234.issue5319@psf.upfronthosting.co.za>


Martin Panter added the comment:

So far I haven?t noticed much documentation on the exit statuses generated by Python itself (e.g. for unhandled exceptions). I did find some discussion in <https://docs.python.org/3/library/sys.html#sys.exit>, so perhaps I will add to that.

Since it implies values beyond 127 may not work on some systems, I now propose to use the arbitrary value of 120 instead of 255. (Keeping clear of 126 and 127, which have a special meaning in Posix shells.) Although, that statement about 0?127 was added in 1998 (bbe92932a005), so may not be relevant these days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Mon Aug 31 04:41:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 02:41:51 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
 error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1440988911.16.0.914986387624.issue5319@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new patch setting the exit status to 120. I also added a What?s New entry, and some more documentation under sys.exit().

Robert, I added an entry to /PC/python3.def, following the lead of your patch in Issue 2786. You mentioned modifying the return value, but in that file I don?t see any return values. Should I ignore that bit, or am I looking in the wrong place?

----------
Added file: http://bugs.python.org/file40306/Py_FinalizeEx-120.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Mon Aug 31 05:43:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Aug 2015 03:43:52 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <20150831034348.82785.48044@psf.io>


Roundup Robot added the comment:

New changeset 328383905eaf by Martin Panter <vadmium> in branch '3.4':
Issue #24952: Clarify default argument of stack_size() in threading, _thread
https://hg.python.org/cpython/rev/328383905eaf

New changeset 606082fa2804 by Martin Panter <vadmium> in branch '3.5':
Issue #24952: Merge 3.4 into 3.5
https://hg.python.org/cpython/rev/606082fa2804

New changeset 501c9ab07996 by Martin Panter <vadmium> in branch 'default':
Issue #24952: Merge 3.5 into 3.6
https://hg.python.org/cpython/rev/501c9ab07996

New changeset 79afd50396c5 by Martin Panter <vadmium> in branch '2.7':
Issue #24952: Clarify default argument of stack_size() in threading, thread
https://hg.python.org/cpython/rev/79afd50396c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Mon Aug 31 05:48:28 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 03:48:28 +0000
Subject: [issue24952] stack_size([size]) is actually stack_size(size=0)
In-Reply-To: <1440773948.16.0.0613964686365.issue24952@psf.upfronthosting.co.za>
Message-ID: <1440992908.28.0.17059889707.issue24952@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patches

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24952>
_______________________________________

From report at bugs.python.org  Mon Aug 31 06:14:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 04:14:54 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1440994494.78.0.360619948757.issue24911@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is my proposed patch

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40307/socket-context.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Mon Aug 31 06:41:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 04:41:07 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1440996067.39.0.313565285445.issue12833@psf.upfronthosting.co.za>


Martin Panter added the comment:

I wonder if this information would be better off under the input() function, rather than under the Readline module itself.

Also see Issue 17337, about control codes in the Readline prompt. Since these issues both relate to the prompt, it might be worth documenting both in the same section or paragraph.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Mon Aug 31 06:54:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 31 Aug 2015 04:54:43 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1440996883.63.0.136335126078.issue23639@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +__base__ undocumented
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 07:23:33 2015
From: report at bugs.python.org (Palm Kevin)
Date: Mon, 31 Aug 2015 05:23:33 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
 Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1440998613.66.0.0401769091983.issue11320@psf.upfronthosting.co.za>


Palm Kevin added the comment:

@ncoghlan: Not PySys_SetPath, but Py_SetPath is causing the problem (you mentionned PySys_SetPath in your message msg249311)

I discovered PySys_SetPath only last Friday.
In fact, in my case, the usage of PySys_SetPath (after Py_Initialize) instead of Py_SetPath (before Py_Initialize) is sufficient to respond to my needs!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:38:09 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Aug 2015 06:38:09 +0000
Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in
 Py2.x
In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za>
Message-ID: <1441003089.48.0.407664871249.issue12885@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Patch looks good and would fix the reported problem.  Being a backport from setuptools also gives confidence.

Does the patch change the behaviour for the handling of the MANIFEST file (not MANIFEST.in)?  My previous message mentions that the docs say that one can include symlinks in MANIFEST.

----------
assignee: eric.araujo -> jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12885>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:49:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Aug 2015 06:49:58 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1441003798.82.0.368054310699.issue23639@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I think most of these are either implementation details
> or "private" names, so there is no need to document them. 

Also, we want to be careful to not guarantee implementation details that are subject to change.  Most of these are not intended for users to base their code on.

IIRC, Guido already opined on some of these (preferring to keep most of them undocumented) in some other tracker item this year.

As one data point, I worked on the decimal module and defined the public API.  The __decimal_context__ method is not part of the public API.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:27:31 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 31 Aug 2015 07:27:31 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1441006051.46.0.596758175228.issue24934@psf.upfronthosting.co.za>


Florin Papa added the comment:

The Django 1.8 archive that I attached is not patched, it is downloaded from the django github page without modifications. I have tested and Django 1.8 works with the latest Python version pulled from hg.python.org/cpython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:35:08 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Mon, 31 Aug 2015 07:35:08 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1441006508.24.0.513281506925.issue24966@psf.upfronthosting.co.za>


Roberto S?nchez added the comment:

In my case, I modify the stdout but the error was thrown by a third party (click lib), I need to overwrite the stdout because the program has a CLI and the locale env in the terminal seems to be wrong:
 codecs.lookup(locale.getpreferredencoding()).name == 'ascii'
 sys.getdefaultencoding() == 'utf-8'

For these cases I try to fix it forcing the the IO encoding to the value given by sys.getdefaultencoding(), otherwise the script in a CLI won't work properly. 

I can apply a monkey-patch on the third party method that return "os.get_terminal_size()" if a ValueError exception is thrown, actually, The script is working now with the monkey-patch, but I thought that a bit of more "magic" in get_terminal_size would help to deal with the encoding issues in python3 CLI programs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 10:06:19 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 31 Aug 2015 08:06:19 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1441008379.7.0.732417057901.issue24912@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I agree with Mark. This feature opens up a security hole large enough to drive a train through.

Looking at the python-dev thread, the only motivation appears to be making module look more like classes. I'd suggest to propose a PEP for making changes to module objects rather than creating a backdoor which let's you implement those changes at the expense of putting the whole interpreter at risk.

IMO, .__class__ of static types should not be mutable. I can understand why heap types need this feature (to e.g. be able to copy objects without invoking any .__init__() methods of unknown objects as is needed for unpickle style operations), but for static types the set of supported objects is limited and the consequences of calling their constructor is known.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 10:17:24 2015
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=)
Date: Mon, 31 Aug 2015 08:17:24 +0000
Subject: [issue24967] add errors='ignore' to print kwargs
Message-ID: <1441009044.09.0.443464909136.issue24967@psf.upfronthosting.co.za>


New submission from Luk?? N?mec:

Please add errors='...' to print's kwargs and pass it to codecs that are called from print. Sometimes you have undecodable/unencodable characters that you want to remove from the printed text.

Now you need to call 'mytext'.encode('enc', errors='replace').decode('enc') to achieve the same result. This would be just a shortcut.

Thank you :)

----------
messages: 249389
nosy: Luk??.N?mec
priority: normal
severity: normal
status: open
title: add errors='ignore' to print kwargs
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24967>
_______________________________________

From report at bugs.python.org  Mon Aug 31 10:42:12 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Mon, 31 Aug 2015 08:42:12 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
Message-ID: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>


New submission from Roberto S?nchez:

System: Python 3.4.2 on Linux Fedora 22

This issues is strongly related with: http://bugs.python.org/issue19846 But It isn't exactly the same case.

When I connect from my Mac OSX (using Terminal.app) to a Linux host with Fedora through ssh, the terminal session is forced to the OSX locale (default behavior in Terminal.app):

    [rob at fedora22 ~]$ locale
    locale: Cannot set LC_CTYPE to default locale: No such file or directory
    locale: Cannot set LC_MESSAGES to default locale: No such file or directory
    locale: Cannot set LC_ALL to default locale: No such file or directory
    LANG=es_ES.UTF-8
    LC_CTYPE="es_ES.UTF-8"
    LC_NUMERIC="es_ES.UTF-8"
    LC_TIME="es_ES.UTF-8"
    LC_COLLATE="es_ES.UTF-8"
    LC_MONETARY="es_ES.UTF-8"
    LC_MESSAGES="es_ES.UTF-8"
    LC_PAPER="es_ES.UTF-8"
    LC_NAME="es_ES.UTF-8"
    LC_ADDRESS="es_ES.UTF-8"
    LC_TELEPHONE="es_ES.UTF-8"
    LC_MEASUREMENT="es_ES.UTF-8"
    LC_IDENTIFICATION="es_ES.UTF-8"
    LC_ALL=

However the installed locales in Fedora are:

    [rob at fedora22 ~]$ localectl list-locales
    en_US
    en_US.iso88591
    en_US.iso885915
    en_US.utf8       <-- This is the default one

And if a launch python3 I get:

    [rob at fedora22 ~]$ python3
    Python 3.4.2 (default, Jul  9 2015, 17:24:30) 
    [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os, codecs, sys, locale
    >>> locale.getpreferredencoding()
    'ANSI_X3.4-1968'
    >>> codecs.lookup(locale.getpreferredencoding()).name
    'ascii'
    >>> locale.getdefaultlocale()
    ('es_ES', 'UTF-8')
    >>> sys.stdout.encoding
    'ANSI_X3.4-1968'
    >>> sys.getfilesystemencoding()
    'ascii'
    >>> print('Espa?a')
      File "<stdin>", line 0
        
        ^
    SyntaxError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)


So, If I'm understanding correctly, If the current locale is not supported by the system then python fallback to ascii.

I can understand this behavior when the supported locales and the current one has different encoding, but if both of them are 'utf-8' It sounds reasonable that locale.getpreferredencoding() is set to 'utf-8'.

This case is causing that programs with CLI (Command Line Interface) fails, if you are using a third party like click lib, a RuntimeException is thrown by the own lib, I learned it by the hard way, the python3 CLI programs need a valid encoding to deal with stdin/stdout, and in this case all systems seems correctly configured about the encoding, I mean, this is a real case, there is no manual locale config modification, IMHO the current behavior seems a bit strict.

----------
components: Unicode
messages: 249390
nosy: ezio.melotti, haypo, rsc1975
priority: normal
severity: normal
status: open
title: Python 3 raises Unicode errors with the xxx.UTF-8 locale
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 10:44:05 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Mon, 31 Aug 2015 08:44:05 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1441010645.72.0.602087699599.issue24966@psf.upfronthosting.co.za>


Roberto S?nchez added the comment:

I've added a new issue: http://bugs.python.org/issue24968 that is related with this one, because is the root cause to modify the stdin/stdout streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 10:44:36 2015
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 31 Aug 2015 08:44:36 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1441010676.66.0.282525048229.issue24912@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

I need to get to bed so I'll finish up tomorrow, but FYI I have a working patch -- I just want to add some __bases__ assignment test cases to make Larry happy. (Apparently there are no test cases for __bases__ assignment at all currently... :-(.)

Before anyone panics about security issues, do keep in mind that the patch you're talking about reverting fixed a buffer overflow which I strongly suspect could be used to accomplish arbitrary code execution. This is not a big deal, because all it does it let you turn the ability to execute arbitrary Python code into the ability to execute arbitrary machine code. If this were the JVM then this would be a big deal, but for CPython it isn't -- there are many "vulnerabilities" like this that are included in CPython by default as features, because CPython does not even attempt to provide a secure sandbox. The bug described in the current issue is bad, but security-wise AFAIK it's less bad than arbitrary code execution: it lets you mess with code in other subinterpreters (which is already possible through other means), and it lets you trigger assert checks that abort the interpreter, but AFAICT it doesn't violate memory safety or allow arbitrary code execution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:01:07 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 31 Aug 2015 09:01:07 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1441010676.66.0.282525048229.issue24912@psf.upfronthosting.co.za>
Message-ID: <55E417C5.6010708@egenix.com>


Marc-Andre Lemburg added the comment:

On 31.08.2015 10:44, Nathaniel Smith wrote:
> Before anyone panics about security issues, do keep in mind that the patch you're talking about
reverting fixed a buffer overflow which I strongly suspect could be used to accomplish arbitrary
code execution.
> ... it lets you trigger assert checks that abort the interpreter, but AFAICT it doesn't violate memory safety or allow arbitrary code execution.

I'm sure a buffer overflow can be fixed in other ways than allowing
42 to print out the Zen of Python when asked for a repr() ;-)

And if Serhiy can sneak in an os.system('rm -rf /') into a harmless
operation such as 42 + 2, I do believe we can call this arbitrary
code execution, even more so, since the patch only applies to a single
integer object which happens to be a singleton in CPython.

The point is: Python code will generally assume that it can trust
builtin types. It doesn't expect 42 + 2 to clear out the root dir,
just because some package installed from PyPI happens to feel in the
mood for Easter eggs :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:02:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 31 Aug 2015 09:02:46 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>
Message-ID: <1441011766.94.0.257515724101.issue24968@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +lemburg, loewis, ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:10:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 31 Aug 2015 09:10:05 +0000
Subject: [issue24967] add errors='ignore' to print kwargs
In-Reply-To: <1441009044.09.0.443464909136.issue24967@psf.upfronthosting.co.za>
Message-ID: <1441012205.41.0.879504849204.issue24967@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

print() doesn't encode characters. It just writes string representation of arguments to output text file (sys.stdout by default). It is the output file is responsible for encoding (or is not, if it saves or passes further a text directly, as StringIO).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24967>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:35:02 2015
From: report at bugs.python.org (Akira Li)
Date: Mon, 31 Aug 2015 09:35:02 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1441013702.34.0.0289762169578.issue22798@psf.upfronthosting.co.za>


Akira Li added the comment:

> C mktime itself should not change timezone globals, but it may indirectly if it calls tzset() and TZ changed between calls.

You should have run the attached test_mktime_changes_tzname.c which demonstrates that (at least on some systems) C mktime *does* change tzname global even if TZ envvar is constant in the test.

Nowhere in my bug report I had mentioned different TZ values. I did mentioned *past* *future* dates -- the same timezone may have different utc offset, timezone abbreviations at different times. These timezone globals can change even if TZ is constant.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:39:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 31 Aug 2015 09:39:28 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1441013968.87.0.788307325526.issue24912@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with Nathaniel, that this bug is not so critical to be release blocker. While it definitely should be fixed, it may wait for 3.5.1. Bug reproducing is not data driven, it needs executing special Python code, and when arbitrary Python code execution is available, there are a lot of other way to crash or compromise the interpreter. But I'm not sure that allowing __class__ assignment for larger domain of types is desirable. If we will desire that it is not, any enhancements to __class__ assignment should be withdrawn. May be __class__ assignment should be discouraged, deprecated and then disabled for all classes (in 3.6+), and other ways should be proposed to solve problems that are solved with __class__ assignment.

Nathaniel, can you provide a patch, that keeps the fix of a buffer overflow, but withdraws the ability to assign __class__ in cases that were disabled before?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:55:27 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Aug 2015 09:55:27 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za>
Message-ID: <1441014927.79.0.70008002345.issue24912@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

__class__ assignment can definitely be useful for monkey-patching, or other, purposes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 11:59:59 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 31 Aug 2015 09:59:59 +0000
Subject: [issue24912] The type of cached objects is mutable
In-Reply-To: <1441014927.79.0.70008002345.issue24912@psf.upfronthosting.co.za>
Message-ID: <55E42592.7050607@egenix.com>


Marc-Andre Lemburg added the comment:

On 31.08.2015 11:55, Antoine Pitrou wrote:
> 
> __class__ assignment can definitely be useful for monkey-patching, or other, purposes.

The feature certainly has its place for user defined types (see the
unpickle example), but I don't think we should allow this for
static types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________

From report at bugs.python.org  Mon Aug 31 13:38:43 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Aug 2015 11:38:43 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>
Message-ID: <1441021123.43.0.908545311776.issue24968@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's not a bug on Python, but a bug on your system.

> New submission from Roberto S?nchez:
> ? ? [rob at fedora22 ~]$ locale
> ? ? locale: Cannot set LC_CTYPE to default locale: No such file or directory

This message means that the chosen locale doesn't exist.

> ? ? LANG=es_ES.UTF-8
...
> ? ? [rob at fedora22 ~]$ localectl list-locales
> ....
> ? ? en_US.utf8? ? ? ?<-- This is the default one

LANG must be en_US.utf8.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 15:02:23 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 31 Aug 2015 13:02:23 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>
Message-ID: <1441026143.45.0.377647062906.issue24968@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

CPython inherits this behaviour from glibc's locale handling, so it's potentially worth raising the question further upstream. If anyone wanted to pursue that, looking at http://www.gnu.org/software/libc/development.html suggests to me that the appropriate starting point would be to email libc-help at sourceware.org and ask for advice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 15:03:13 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Mon, 31 Aug 2015 13:03:13 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>
Message-ID: <1441026193.44.0.467774506626.issue24968@psf.upfronthosting.co.za>


Roberto S?nchez added the comment:

OK, I already knew that "It is not a bug", but the scenario seems quite common, connection to a Linux host from a Mac with Terminal.app and different locales (default behavior), so a bit of "magic" when the locale's encoding part is correct would help to deal with some Unicode issues in python3 scripts.

I just say that It would be a desirable enhancement, but I have no idea how to complex can be to change the current behavior, maybe It isn't worth the effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 16:07:01 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Aug 2015 14:07:01 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1441030021.14.0.0779421103511.issue22798@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> You should have run the attached test_mktime_changes_tzname.c ...

I did run it and tried several times to understand what it does.  It did not help.

If you claim that calling mktime() changes the value of the global tzname variable, you should be able to demonstrate it in five lines of code:

extern char **tzname;
tzset();
printf("%s %s\n", tzname[0], tzname[1]);
mktime(&tt);
printf("%s %s\n", tzname[0], tzname[1]);

(plus a few lines to initialize tt)


If the code above prints two different lines - file a bug report with your C library vendor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Mon Aug 31 16:22:09 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Aug 2015 14:22:09 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1441030929.26.0.359520999466.issue22798@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Mon Aug 31 17:09:55 2015
From: report at bugs.python.org (Eric Snow)
Date: Mon, 31 Aug 2015 15:09:55 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1441033795.36.0.2510160832.issue24931@psf.upfronthosting.co.za>


Eric Snow added the comment:

Doesn't the fix mean that `vars(MyNamedtuple)` will no longer work?  While I personally don't mind (though I prefer that spelling) and appreciate the benefit of simpler code, isn't there a backward-compatibility issue here?

I do concede that fixing this bug without a compatibility break is complicated and probably not worth it.  However I want to make sure that the point is at least discussed briefly.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Mon Aug 31 17:28:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 15:28:38 +0000
Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale
In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za>
Message-ID: <1441034918.56.0.0305164437142.issue24968@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe there is at least one open issue about Python adopting utf8 as the default instead of ASCII, and in any case, several conversations about how to deal with all this better.  This is just one example of a class of issues caused by the ASCII/C posix default locale, in different contexts.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24968>
_______________________________________

From report at bugs.python.org  Mon Aug 31 17:40:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 15:40:53 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1441035653.07.0.738810557337.issue24966@psf.upfronthosting.co.za>


R. David Murray added the comment:

So, the problem is needing to compensate for a broken (according to posix) locale setup.  I don't think quieting get_terminal_size is necessarily the answer here.  See issue 19846 for more than you want to know about the ASCII locale issue.

See also issue 15216, which is probably a solution to your problem, but is an open issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 17:47:20 2015
From: report at bugs.python.org (Marek Otahal)
Date: Mon, 31 Aug 2015 15:47:20 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
Message-ID: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>


New submission from Marek Otahal:

I'd like to use @lru_cache in a library. The problem is I can't know the optimal values for 'maxsize', I need to set them at runtime. 

I came with 2 possibilities: 
1/ set cache's size from a hardcoded argument of the decorated method: 
@lru_cache
def foo_long(self, arg1, ..., **kwds):
  pass

# use
foo_long('hi', cacheSize = 1000)

This approach allows the users to customize cache size for their problem. 

2/ from function's **kwds retrieve a name (string) of an instance member of the class which will hold the cache's size value. This is not as clean as 1/, but offers greated functionality for the use in a library sw: we can compute desired cache size from internal values of the unstance, and the use of cache can be totally transparent to the end user: 
@lru_cache
def foo_long(self, arg1, .. , **kwds)
#use
foo_long('hi', cacheSizeRef='_cacheSize')

What do you think about the proposal? 
best regards, Mark

----------
messages: 249406
nosy: Marek Otahal
priority: normal
severity: normal
status: open
title: functools.lru_cache: a way to set decorator arguments at runtime
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 17:54:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 15:54:08 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>
Message-ID: <1441036448.13.0.738859823164.issue24969@psf.upfronthosting.co.za>


R. David Murray added the comment:

How is (1) different from:

  @lru_cache(maxsize=1000)
   def foo_long(self, arg1...)

As for computing it at runtime: if you need to compute it, you can compute it and *then* define the decorator wrapped function.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:00:01 2015
From: report at bugs.python.org (Marek Otahal)
Date: Mon, 31 Aug 2015 16:00:01 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>
Message-ID: <1441036801.66.0.209941969548.issue24969@psf.upfronthosting.co.za>


Marek Otahal added the comment:

Hope this example is not too confusing, it's a patch to my code and lru_cache (backport for python 2.7 from ActiveState)

It implements both approaches as highlighted above, and in the test both of them are used (that does not make much sense, normally one would use either of them only)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:09:12 2015
From: report at bugs.python.org (Marek Otahal)
Date: Mon, 31 Aug 2015 16:09:12 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>
Message-ID: <1441037352.3.0.484542034263.issue24969@psf.upfronthosting.co.za>


Marek Otahal added the comment:

Hi David, 

> How is (1) different from:
  @lru_cache(maxsize=1000)
   def foo_long(self, arg1...)

As I mentioned, for use in a library that is called by end-users. They can call functions and modify params, but do not edit the code. It's up to me (lib devs) to prepare the cache decorator. Ie.:
class MyLib():
  @lru_cache
  def foo_long(self, arg1, **kwds):
    pass
#user
import MyLib 
i = MyLib()
i.foo_long(1337)

> As for computing it at runtime: if you need to compute it, you can compute it and *then* define the decorator wrapped function.

ditto as above, at runtime no new decorator definitions should be needed for a library. 
+ a speed penalty, I'd have to wrap a wrapper in 1 or 2 more nested functions, which incures a speed penalty, and we're focusing at cache here. I esp. mention this as I've noticed the ongoing effort to use a C implementation of lru_cache here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:15:19 2015
From: report at bugs.python.org (Marek Otahal)
Date: Mon, 31 Aug 2015 16:15:19 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>
Message-ID: <1441037719.89.0.844228169817.issue24969@psf.upfronthosting.co.za>


Marek Otahal added the comment:

EDIT: 
> i.foo_long(1337)

ofc, this should be: 
i.foo_long('hi', cacheSize=1337)

or for (2): 

class MyLib():
  def __init__(arg1, arg2):
    self._cacheSize = someComputation(arg1, arg2) # returns a number
  @lru_cache
  def foo_long(self, arg1, **kwds):
    pass
#user
import MyLib 
i = MyLib(100, 21)
# not to make it so simple: 
i.changeInternalStateSomehow() # updates arg1, arg2, and also _cacheSize
i.foo_long(1337, cacheSizeName='_cacheSize') # ref to self._cacheSize

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:27:07 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=)
Date: Mon, 31 Aug 2015 16:27:07 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1441038427.5.0.311534804639.issue24966@psf.upfronthosting.co.za>


Roberto S?nchez added the comment:

Thank you for the references, changing the encoding of an open stream sounds interesting, but It's targeted for v. 3.6 so It seems a bit far away.

Anyway, as I said I fixed on my side with monkey-patching on the third-party lib, the broken locale is just the context, just to explain how I got this issue, I opened this because I honestly though that could be better to return the fallback value that raise an exception, but you know better the "big picture" so, if It's better as is, It's ok for me.

BTW, I don't find the opened issue to use utf8 as default instead ascii (except for Windows)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:47:54 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2015 16:47:54 +0000
Subject: [issue24934] django_v2 benchmark not working in Python 3.6
In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za>
Message-ID: <1441039674.45.0.834849380628.issue24934@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Hmm, strange. I downloaded Django 1.8.latest myself and placed it and I still got the getargspec() failure using the default branch. I'll try again and verify that it wasn't something odd on my end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24934>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:47:59 2015
From: report at bugs.python.org (Akira Li)
Date: Mon, 31 Aug 2015 16:47:59 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1441039679.61.0.146704205121.issue22798@psf.upfronthosting.co.za>


Akira Li added the comment:

The C code produces correct values according to the tz database.

If TZ=Europe/Moscow then
tzname={"MSK", "MSD"} at 2010-07-01 and
tzname={"MSK", "MSK"} at 2015-07-01. Notice the difference!

The code calls C mktime() with corresponding time tuples
and checks that *tzname* is equal to the expected values. That's all.

If C code is incomprehensible; here's its Python analog:

  >>> import os
  >>> os.environ['TZ'] = 'Europe/Moscow'
  >>> import time
  >>> time.tzset()
  >>> time.mktime((2010,7,1,0,0,0,-1,-1,-1))
  1277928000.0
  >>> time.tzname #XXX expected ('MSK', 'MSD')
  ('MSK', 'MSK')
  >>> time.mktime((2015,7,1,0,0,0,-1,-1,-1))
  1435698000.0
  >>> time.tzname
  ('MSK', 'MSK')


C tzname changes on my machine after the corresponding C mktime() calls 
but Python time.tzname does not change after the time.mktime() calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:50:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2015 16:50:38 +0000
Subject: [issue24967] add errors='ignore' to print kwargs
In-Reply-To: <1441009044.09.0.443464909136.issue24967@psf.upfronthosting.co.za>
Message-ID: <1441039838.24.0.436258487803.issue24967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I agree with Serhiy that this isn't print's job to worry about. It's better to be explicit than implicit and trying to cram worrying about decoding errors conflates what print does.

I'm closing as "rejected". Thanks for the suggestion, though, Luk??.

----------
nosy: +brett.cannon
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24967>
_______________________________________

From report at bugs.python.org  Mon Aug 31 19:00:05 2015
From: report at bugs.python.org (Antony Lee)
Date: Mon, 31 Aug 2015 17:00:05 +0000
Subject: [issue24970] Make distutils.Command an ABC
Message-ID: <1441040405.44.0.251292116419.issue24970@psf.upfronthosting.co.za>


New submission from Antony Lee:

Currently, distutils.Command is a "hand-written" ABC; i.e. direct instantiaion or calling the "abstract" methods initialize_options, run and finalize_options raises a RuntimeError saying that the method (not named in the error message, which is thus a little bit cryptic) must be overriden.

In particular, this makes it impossible to use super() when overriding these methods (while Command.{initialize_options,run,finalize_options} have empty implementations, using super() is a fairly normal approach when inheriting, and needed in the case of multiple inheritance).

Switching to an ABC-based design would solve this issue.

----------
components: Distutils
messages: 249415
nosy: Antony.Lee, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Make distutils.Command an ABC
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24970>
_______________________________________

From report at bugs.python.org  Mon Aug 31 19:19:23 2015
From: report at bugs.python.org (Francis Greaves)
Date: Mon, 31 Aug 2015 17:19:23 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
Message-ID: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>


New submission from Francis Greaves:

I am running an up to date Gentoo Linux x86_64. using Python 2.7
I have an environment variable defined, so from the command line 'echo $XRIT_DECOMPRESS_PATH' gives '/usr/local/bin/xRITDecompress'
however, in a Python script, 'cmd = os.environ.get('XRIT_DECOMPRESS_PATH')' gives 'None' as the output.
Why is that?

----------
components: Interpreter Core
messages: 249416
nosy: themetman
priority: normal
severity: normal
status: open
title: os.environ.get() does not return the Environment Value in Linux
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 19:33:51 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Aug 2015 17:33:51 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1441042431.9.0.414215736957.issue22798@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> C tzname changes on my machine after the corresponding C mktime() calls 

Did you run the code that I posted?  If not - please do and report the results.

(I think there is a valid issue behind all this, but you are not helping to reveal it.  I suspect we can do better by just relying on system tzset() and not have the try June and January work-around.  That's why I added Antoine to the "nosy" as the developer who last touched this code.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:28:04 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 31 Aug 2015 18:28:04 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441045684.67.0.587735087538.issue24971@psf.upfronthosting.co.za>


eryksun added the comment:

Did you mark the variable for export in your shell? For example:

    $ v=1
    $ python -c 'import os;print os.environ.get("v")'
    None

    $ export v
    $ python -c 'import os;print os.environ.get("v")'
    1

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:41:14 2015
From: report at bugs.python.org (Francis Greaves)
Date: Mon, 31 Aug 2015 18:41:14 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441046474.83.0.725133306829.issue24971@psf.upfronthosting.co.za>


Francis Greaves added the comment:

I have the environment variable in my .bashrc file.
Interestingly if I do 'os.environ.get("PATH")' it returns the correct value for $PATH. This is also defined in my .bashrc file, so it should be exported.
I have exported it manually from the command line, but it makes no difference.
The command is in a .py file run as 'python myscript.py' as follows
import os
cmd=os.environ.get("PATH")

this makes cmd as 'None'
??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:51:51 2015
From: report at bugs.python.org (Francis Greaves)
Date: Mon, 31 Aug 2015 18:51:51 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441047111.86.0.447442578547.issue24971@psf.upfronthosting.co.za>


Francis Greaves added the comment:

Sorry my error
I should have said
cmd = os.environ.get('XRIT_DECOMPRESS_PATH')' gives 'None' as the output

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:53:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 18:53:33 +0000
Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at
 runtime
In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za>
Message-ID: <1441047213.21.0.638653503474.issue24969@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is no patch/example attached. 

It seems like what you really want is an API on lru_cache for updating the cache size.

What I'm saying is that the cache size can be passed in on the MyLib call, and the decorator/function constructed as part of MyLib's initialization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24969>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:54:21 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 31 Aug 2015 18:54:21 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
Message-ID: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>


New submission from Mark Roseman:

This is a followup to #14146

I don't think this is actually a Tk bug. The text widget supports an "inactiveselectbackground" option which controls the background color of the selection when the window is not active. On Win32, this is defined as empty (i.e. no highlighting).

This option is new in Tk 8.5. I don't believe that Tk 8.4 displayed the selection differently for active and inactive windows, hence why the problem never showed up until 8.5. 

It seems that if running 8.5, setting this widget option to the desired color would then remove the need for the _highlight_workaround() in EditorWindow.py.  

Can someone else besides me try this out please?

----------
components: IDLE
messages: 249422
nosy: Rich.Rauenzahn, Todd.Rovito, dzabel, loewis, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: revisit text highlighting for inactive windows on win32
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24972>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:59:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 18:59:44 +0000
Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout
 is detached, no fallback
In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za>
Message-ID: <1441047584.57.0.881644213401.issue24966@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, I think I was thinking of issue 19846, which was fixed by using surrogateescape on the standard streams instead of "guessing" utf-8.

I'm not utterly opposed to turning the ValueError into a default return value, but as you can see, the fact that the ValueError was returned pointed toward the deeper problem (needing to have a way to change the encoding of an already-existing TextIO stream).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24966>
_______________________________________

From report at bugs.python.org  Mon Aug 31 21:05:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 19:05:21 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441047921.89.0.751820906713.issue24971@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it works fine for us (I'm on Gentoo as well).  os.environ is a pretty thin wrapper around the os functions, so I'm not sure what to suggest as far as debugging why it isn't working for you.

Did you try exactly eryksun's example yourself?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 22:18:36 2015
From: report at bugs.python.org (Francis Greaves)
Date: Mon, 31 Aug 2015 20:18:36 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441052316.09.0.519697318281.issue24971@psf.upfronthosting.co.za>


Francis Greaves added the comment:

erykson's example works perfectly.
I have a script as follows

#!/bin/python
#
import os
cmd = os.environ.get('XRIT_DECOMPRESS_PATH')
print cmd

resulting in 'None'

and if I substitute this line
cmd = os.environ.get('PATH')

resulting in '/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4:/usr/include/KDE'

however from the bash prompt
$ echo $XRIT_DECOMPRESS_PATH
results in '/usr/local/bin/xRITDecompress' so the environment variable  is there and available in bash, but not in Python.
I find this very strange

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 22:21:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2015 20:21:53 +0000
Subject: [issue24971] os.environ.get() does not return the Environment Value
 in Linux
In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za>
Message-ID: <1441052513.47.0.031023438877.issue24971@psf.upfronthosting.co.za>


R. David Murray added the comment:

That means you just haven't exported it properly.  There is nothing wrong with Python here, as demonstrated by the fact that you were able to run eryksun's example (which is equivalent to your script).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24971>
_______________________________________

From report at bugs.python.org  Mon Aug 31 22:34:51 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 31 Aug 2015 20:34:51 +0000
Subject: [issue24973] CFLAGS for Visual Studio
Message-ID: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za>


New submission from Chris Hogan:

This Visual Studio project change appends to the compiler flags any values in the CFLAGS environment variable.

----------
components: Build, Windows
files: addcflags3_5.patch
keywords: patch
messages: 249427
nosy: christopher.hogan, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CFLAGS for Visual Studio
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file40308/addcflags3_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 22:53:23 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 31 Aug 2015 20:53:23 +0000
Subject: [issue24973] CFLAGS for Visual Studio
In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za>
Message-ID: <1441054403.54.0.666788120815.issue24973@psf.upfronthosting.co.za>


Changes by Chris Hogan <christopher.hogan at Intel.com>:


Added file: http://bugs.python.org/file40309/addcflags2_7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:37:02 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 31 Aug 2015 21:37:02 +0000
Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile without
 /fp:strict
Message-ID: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za>


New submission from Zachary Ware:

When building on Windows 8.1 with ICC 15.0 (backed by VS 2015 Community), the _decimal module fails to compile:

ClCompile:
  mpdecimal.c
..\Modules\_decimal\libmpdec\mpdecimal.c(46): error : fenv_access cannot be enabled except in precise, source, double, and extended modes [P:\ath\to\cpython\PCbuild\_decimal.vcxproj]
        #pragma fenv_access(on)
                               ^

Unfortunately, I can't reproduce this on two other machines both running Windows Server 2012 R2, with otherwise nearly identical configurations to mine.

Since I can't reproduce it elsewhere (including on the ICC Windows buildbot) and have a relatively easy workaround (passing '/fp:strict' makes the problem go away), setting priority to 'low' until somebody else can reproduce it.

----------
components: Build, Windows
messages: 249428
nosy: facundobatista, mark.dickinson, paul.moore, r.david.murray, rhettinger, skrah, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
stage: test needed
status: open
title: ICC on Windows 8.1: _decimal fails to compile without /fp:strict
type: compile error
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24974>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:44:58 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 31 Aug 2015 21:44:58 +0000
Subject: [issue24973] CFLAGS for Visual Studio
In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za>
Message-ID: <1441057498.18.0.998489427564.issue24973@psf.upfronthosting.co.za>


Steve Dower added the comment:

The patch should just set it once in pyproject.props, not in each project.

Why is this necessary? Is there an option we should be exposing in some other way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:46:43 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 31 Aug 2015 21:46:43 +0000
Subject: [issue24973] CFLAGS for Visual Studio
In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za>
Message-ID: <1441057603.57.0.668395334329.issue24973@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The real driver for this is having a nice easy way to pass '/fp:strict' to icl.exe (ICC's cl.exe).  There may be other things that would be nice to be able to pass easily for customization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:47:01 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 31 Aug 2015 21:47:01 +0000
Subject: [issue24973] CFLAGS for Visual Studio
In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za>
Message-ID: <1441057621.78.0.194111975756.issue24973@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:56:32 2015
From: report at bugs.python.org (Bob Hossley)
Date: Mon, 31 Aug 2015 21:56:32 +0000
Subject: [issue24949] Identifier lookup in a multi-level package is flakey
In-Reply-To: <1440716362.21.0.0587084904786.issue24949@psf.upfronthosting.co.za>
Message-ID: <1441058192.72.0.32482704223.issue24949@psf.upfronthosting.co.za>


Bob Hossley added the comment:

msg<249269>

Thank you David Murray.

I should have asked myself, what is reasonable behavior?  In the case of email.mime.nonmultipart an explicit import is clearly needed.

I was misled by my experience with the os library.  As a "package" it is very different from the email library.  Importing os also makes available all of what appear at the script syntax level to be all its "sub-packages."

2015-08-28 09:57:26 /home/bob06
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.path.split)
<function split at 0x7fac18704320>

In the future I will try to remember that the effects of importing a "package" depend on how the "package" is packaged.

So far as I'm concerned this issue is closed.

I doubt that symptom "flakey Python behavior" is serious enough to interest Canonical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24949>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:58:20 2015
From: report at bugs.python.org (Bob Hossley)
Date: Mon, 31 Aug 2015 21:58:20 +0000
Subject: [issue24949] Identifier lookup in a multi-level package is flakey
In-Reply-To: <1440716362.21.0.0587084904786.issue24949@psf.upfronthosting.co.za>
Message-ID: <1441058300.22.0.7644461112.issue24949@psf.upfronthosting.co.za>


Bob Hossley added the comment:

msg249272

Thank you Martin Panter for the documentation URL's.  The import machinery is so complicated that I have given up trying to understand what is "correct" behavior.    Depending on the code in the relevant __init__.py and/or explicitly referenced Python modules each Python library can have vastly different import behavior.  I believe the simplest way to figure out what an import does and hence, what import statements I need is to run a Python interpreter in a terminal, execute an import statement, and then use the dir() function several times to see what the import statement did.

The import documentation is only slightly useful due to its great length and complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24949>
_______________________________________