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: [New-bugs-announce] [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 08:08:55 2015
From: report at bugs.python.org (Alex Budovski)
Date: Sat, 01 Aug 2015 06:08:55 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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: [New-bugs-announce] [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 21:17:27 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 Aug 2015 19:17:27 +0000
Subject: [New-bugs-announce] [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:19:49 2015
From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=)
Date: Sat, 01 Aug 2015 19:19:49 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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:12:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2015 21:12:47 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:25:07 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Sun, 02 Aug 2015 08:25:07 +0000
Subject: [New-bugs-announce] [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 18:32:37 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 02 Aug 2015 16:32:37 +0000
Subject: [New-bugs-announce] [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:49:29 2015
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 02 Aug 2015 16:49:29 +0000
Subject: [New-bugs-announce] [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 23:02:15 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 02 Aug 2015 21:02:15 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 11:06:58 2015
From: report at bugs.python.org (Louis Dassy)
Date: Mon, 03 Aug 2015 09:06:58 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 02:05:57 2015
From: report at bugs.python.org (Tiago Wright)
Date: Tue, 04 Aug 2015 00:05:57 +0000
Subject: [New-bugs-announce] [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 22:10:42 2015
From: report at bugs.python.org (Pastafarianist)
Date: Tue, 04 Aug 2015 20:10:42 +0000
Subject: [New-bugs-announce] [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:22:18 2015
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 04 Aug 2015 20:22:18 +0000
Subject: [New-bugs-announce] [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  Wed Aug  5 02:29:22 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Aug 2015 00:29:22 +0000
Subject: [New-bugs-announce] [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 05:42:24 2015
From: report at bugs.python.org (Ben Longbons)
Date: Wed, 05 Aug 2015 03:42:24 +0000
Subject: [New-bugs-announce] [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 10:51:02 2015
From: report at bugs.python.org (Amund Hov)
Date: Wed, 05 Aug 2015 08:51:02 +0000
Subject: [New-bugs-announce] [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 11:07:24 2015
From: report at bugs.python.org (Gregor)
Date: Wed, 05 Aug 2015 09:07:24 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 14:38:31 2015
From: report at bugs.python.org (=?utf-8?q?Mathias_Fr=C3=B6jdman?=)
Date: Wed, 05 Aug 2015 12:38:31 +0000
Subject: [New-bugs-announce] [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 15:05:17 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Aug 2015 13:05:17 +0000
Subject: [New-bugs-announce] [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 17:18:45 2015
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 05 Aug 2015 15:18:45 +0000
Subject: [New-bugs-announce] [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 18:25:34 2015
From: report at bugs.python.org (gladman)
Date: Wed, 05 Aug 2015 16:25:34 +0000
Subject: [New-bugs-announce] [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 21:05:39 2015
From: report at bugs.python.org (Al Sweigart)
Date: Wed, 05 Aug 2015 19:05:39 +0000
Subject: [New-bugs-announce] [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:44:41 2015
From: report at bugs.python.org (Peter Eastman)
Date: Wed, 05 Aug 2015 19:44:41 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 05:15:20 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:15:20 +0000
Subject: [New-bugs-announce] [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:18:43 2015
From: report at bugs.python.org (John Leitch)
Date: Thu, 06 Aug 2015 03:18:43 +0000
Subject: [New-bugs-announce] [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 06:17:40 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 06 Aug 2015 04:17:40 +0000
Subject: [New-bugs-announce] [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 07:15:40 2015
From: report at bugs.python.org (Debarshi Goswami)
Date: Thu, 06 Aug 2015 05:15:40 +0000
Subject: [New-bugs-announce] [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 09:00:11 2015
From: report at bugs.python.org (Brecht Machiels)
Date: Thu, 06 Aug 2015 07:00:11 +0000
Subject: [New-bugs-announce] [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 12:28:21 2015
From: report at bugs.python.org (Jon Ribbens)
Date: Thu, 06 Aug 2015 10:28:21 +0000
Subject: [New-bugs-announce] [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:35:58 2015
From: report at bugs.python.org (Joseph Weston)
Date: Thu, 06 Aug 2015 10:35:58 +0000
Subject: [New-bugs-announce] [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 16:08:40 2015
From: report at bugs.python.org (Will Booth)
Date: Thu, 06 Aug 2015 14:08:40 +0000
Subject: [New-bugs-announce] [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 17:19:29 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 06 Aug 2015 15:19:29 +0000
Subject: [New-bugs-announce] [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  Fri Aug  7 00:58:03 2015
From: report at bugs.python.org (zsero)
Date: Thu, 06 Aug 2015 22:58:03 +0000
Subject: [New-bugs-announce] [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 06:15:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:15:38 +0000
Subject: [New-bugs-announce] [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:19:42 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:19:42 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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:44:11 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:44:11 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:54:17 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 04:54:17 +0000
Subject: [New-bugs-announce] [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 08:11:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Aug 2015 06:11:26 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 12:18:08 2015
From: report at bugs.python.org (Tom Pohl)
Date: Fri, 07 Aug 2015 10:18:08 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 16:16:34 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 07 Aug 2015 14:16:34 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  Sat Aug  8 05:02:04 2015
From: report at bugs.python.org (umedoblock)
Date: Sat, 08 Aug 2015 03:02:04 +0000
Subject: [New-bugs-announce] [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 16:03:34 2015
From: report at bugs.python.org (Xavier Morel)
Date: Sat, 08 Aug 2015 14:03:34 +0000
Subject: [New-bugs-announce] [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: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: [New-bugs-announce] [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: [New-bugs-announce] [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:38:48 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Aug 2015 15:38:48 +0000
Subject: [New-bugs-announce] [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 18:48:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Aug 2015 16:48:15 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 12:10:56 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:10:56 +0000
Subject: [New-bugs-announce] [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:26:26 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Aug 2015 10:26:26 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 20:04:23 2015
From: report at bugs.python.org (Roddy Shuler)
Date: Mon, 10 Aug 2015 18:04:23 +0000
Subject: [New-bugs-announce] [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:43 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 10 Aug 2015 18:15:43 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:29:01 2015
From: report at bugs.python.org (Vinson Lee)
Date: Tue, 11 Aug 2015 00:29:01 +0000
Subject: [New-bugs-announce] [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 06:17:28 2015
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 11 Aug 2015 04:17:28 +0000
Subject: [New-bugs-announce] [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 09:46:43 2015
From: report at bugs.python.org (gladman)
Date: Tue, 11 Aug 2015 07:46:43 +0000
Subject: [New-bugs-announce] [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 19:06:44 2015
From: report at bugs.python.org (David Beazley)
Date: Tue, 11 Aug 2015 17:06:44 +0000
Subject: [New-bugs-announce] [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 22:38:01 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 11 Aug 2015 20:38:01 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:14:33 2015
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 12 Aug 2015 01:14:33 +0000
Subject: [New-bugs-announce] [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 09:36:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Aug 2015 07:36:05 +0000
Subject: [New-bugs-announce] [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 12:47:16 2015
From: report at bugs.python.org (flying sheep)
Date: Wed, 12 Aug 2015 10:47:16 +0000
Subject: [New-bugs-announce] [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 19:01:25 2015
From: report at bugs.python.org (Cyril Bouthors)
Date: Wed, 12 Aug 2015 17:01:25 +0000
Subject: [New-bugs-announce] [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 22:40:48 2015
From: report at bugs.python.org (Paul Murphy)
Date: Wed, 12 Aug 2015 20:40:48 +0000
Subject: [New-bugs-announce] [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  Thu Aug 13 02:20:33 2015
From: report at bugs.python.org (John Hagen)
Date: Thu, 13 Aug 2015 00:20:33 +0000
Subject: [New-bugs-announce] [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 04:10:34 2015
From: report at bugs.python.org (Alex Budovski)
Date: Thu, 13 Aug 2015 02:10:34 +0000
Subject: [New-bugs-announce] [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 08:04:14 2015
From: report at bugs.python.org (Pankaj Sharma)
Date: Thu, 13 Aug 2015 06:04:14 +0000
Subject: [New-bugs-announce] [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:56:17 2015
From: report at bugs.python.org (sih4sing5hong5)
Date: Thu, 13 Aug 2015 06:56:17 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:34:41 2015
From: report at bugs.python.org (Wilfred Hughes)
Date: Thu, 13 Aug 2015 08:34:41 +0000
Subject: [New-bugs-announce] [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 19:23:00 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 13 Aug 2015 17:23:00 +0000
Subject: [New-bugs-announce] [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 21:20:46 2015
From: report at bugs.python.org (zeero)
Date: Thu, 13 Aug 2015 19:20:46 +0000
Subject: [New-bugs-announce] [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 22:02:23 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 13 Aug 2015 20:02:23 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 09:07:42 2015
From: report at bugs.python.org (Christian Klein)
Date: Fri, 14 Aug 2015 07:07:42 +0000
Subject: [New-bugs-announce] [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 10:59:02 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 14 Aug 2015 08:59:02 +0000
Subject: [New-bugs-announce] [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:10:21 2015
From: report at bugs.python.org (Vlad Gumerov)
Date: Fri, 14 Aug 2015 09:10:21 +0000
Subject: [New-bugs-announce] [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 12:06:01 2015
From: report at bugs.python.org (Frunit)
Date: Fri, 14 Aug 2015 10:06:01 +0000
Subject: [New-bugs-announce] [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 17:26:22 2015
From: report at bugs.python.org (David Griffin)
Date: Fri, 14 Aug 2015 15:26:22 +0000
Subject: [New-bugs-announce] [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:54:20 2015
From: report at bugs.python.org (jack)
Date: Fri, 14 Aug 2015 15:54:20 +0000
Subject: [New-bugs-announce] [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 19:06:03 2015
From: report at bugs.python.org (Robert Escriva)
Date: Fri, 14 Aug 2015 17:06:03 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:46 2015
From: report at bugs.python.org (Mikhail Terekhov)
Date: Sat, 15 Aug 2015 03:13:46 +0000
Subject: [New-bugs-announce] [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 21:20:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 19:20:38 +0000
Subject: [New-bugs-announce] [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 22:01:13 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 15 Aug 2015 20:01:13 +0000
Subject: [New-bugs-announce] [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 23:23:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2015 21:23:07 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4?=
 =?utf-8?q?t_install_PIP_inside_a_new_venv_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 13:34:52 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 16 Aug 2015 11:34:52 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 06:28:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 04:28:58 +0000
Subject: [New-bugs-announce] [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 07:33:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Aug 2015 05:33:10 +0000
Subject: [New-bugs-announce] [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 09:20:06 2015
From: report at bugs.python.org (Jan Wagner)
Date: Mon, 17 Aug 2015 07:20:06 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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:59:00 2015
From: report at bugs.python.org (Matt Spitz)
Date: Mon, 17 Aug 2015 14:59:00 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 11:36:54 2015
From: report at bugs.python.org (Marian Horban)
Date: Tue, 18 Aug 2015 09:36:54 +0000
Subject: [New-bugs-announce] [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:48:30 2015
From: report at bugs.python.org (Aymeric Augustin)
Date: Tue, 18 Aug 2015 09:48:30 +0000
Subject: [New-bugs-announce] [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 13:24:52 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 18 Aug 2015 11:24:52 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 16:36:31 2015
From: report at bugs.python.org (Geoffrey Royer)
Date: Tue, 18 Aug 2015 14:36:31 +0000
Subject: [New-bugs-announce] [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 22:03:11 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Aug 2015 20:03:11 +0000
Subject: [New-bugs-announce] [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 23:14:26 2015
From: report at bugs.python.org (Brendan Barnwell)
Date: Tue, 18 Aug 2015 21:14:26 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:37:47 2015
From: report at bugs.python.org (Timothy Geiser)
Date: Tue, 18 Aug 2015 22:37:47 +0000
Subject: [New-bugs-announce] [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 03:06:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2015 01:06:14 +0000
Subject: [New-bugs-announce] [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 08:10:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Aug 2015 06:10:25 +0000
Subject: [New-bugs-announce] [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 12:01:44 2015
From: report at bugs.python.org (Laurent Coustet)
Date: Wed, 19 Aug 2015 10:01:44 +0000
Subject: [New-bugs-announce] [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:38:11 2015
From: report at bugs.python.org (Leif Arne Storset)
Date: Wed, 19 Aug 2015 12:38:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:34:48 2015
From: report at bugs.python.org (Ted Lemon)
Date: Thu, 20 Aug 2015 02:34:48 +0000
Subject: [New-bugs-announce] [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 08:03:37 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Aug 2015 06:03:37 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 12:42:09 2015
From: report at bugs.python.org (shiva prasanth)
Date: Thu, 20 Aug 2015 10:42:09 +0000
Subject: [New-bugs-announce] [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 14:43:34 2015
From: report at bugs.python.org (Felix Kaiser)
Date: Thu, 20 Aug 2015 12:43:34 +0000
Subject: [New-bugs-announce] [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 19:05:40 2015
From: report at bugs.python.org (Jake Garver)
Date: Thu, 20 Aug 2015 17:05:40 +0000
Subject: [New-bugs-announce] [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  Fri Aug 21 00:18:07 2015
From: report at bugs.python.org (John Taylor)
Date: Thu, 20 Aug 2015 22:18:07 +0000
Subject: [New-bugs-announce] [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 10:05:21 2015
From: report at bugs.python.org (Jim Minter)
Date: Fri, 21 Aug 2015 08:05:21 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:18:53 2015
From: report at bugs.python.org (Vadim Kantorov)
Date: Fri, 21 Aug 2015 10:18:53 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 18:51:55 2015
From: report at bugs.python.org (Adam Meily)
Date: Fri, 21 Aug 2015 16:51:55 +0000
Subject: [New-bugs-announce] [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 20:49:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Aug 2015 18:49:52 +0000
Subject: [New-bugs-announce] [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 22:34:06 2015
From: report at bugs.python.org (zodalahtathi)
Date: Fri, 21 Aug 2015 20:34:06 +0000
Subject: [New-bugs-announce] [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  Sat Aug 22 00:02:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Aug 2015 22:02:50 +0000
Subject: [New-bugs-announce] [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 01:09:06 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 21 Aug 2015 23:09:06 +0000
Subject: [New-bugs-announce] [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 08:45:10 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Sat, 22 Aug 2015 06:45:10 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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  Sun Aug 23 01:39:19 2015
From: report at bugs.python.org (John Leitch)
Date: Sat, 22 Aug 2015 23:39:19 +0000
Subject: [New-bugs-announce] [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 22:20:07 2015
From: report at bugs.python.org (asldkjfn)
Date: Sun, 23 Aug 2015 20:20:07 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 05:35:14 2015
From: report at bugs.python.org (Isaac Levy)
Date: Mon, 24 Aug 2015 03:35:14 +0000
Subject: [New-bugs-announce] [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 15:08:32 2015
From: report at bugs.python.org (Joseph Schachner)
Date: Mon, 24 Aug 2015 13:08:32 +0000
Subject: [New-bugs-announce] [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:15:48 2015
From: report at bugs.python.org (Cal Leeming)
Date: Mon, 24 Aug 2015 14:15:48 +0000
Subject: [New-bugs-announce] [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:55:21 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 24 Aug 2015 14:55:21 +0000
Subject: [New-bugs-announce] [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 17:25:11 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 24 Aug 2015 15:25:11 +0000
Subject: [New-bugs-announce] [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 18:20:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2015 16:20:04 +0000
Subject: [New-bugs-announce] [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:42:46 2015
From: report at bugs.python.org (Vineet Kumar Doshi)
Date: Mon, 24 Aug 2015 16:42:46 +0000
Subject: [New-bugs-announce] [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 19:05:17 2015
From: report at bugs.python.org (Jonas Obrist)
Date: Mon, 24 Aug 2015 17:05:17 +0000
Subject: [New-bugs-announce] [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 21:19:55 2015
From: report at bugs.python.org (Alexander Oblovatniy)
Date: Mon, 24 Aug 2015 19:19:55 +0000
Subject: [New-bugs-announce] [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 23:39:09 2015
From: report at bugs.python.org (Steve Yeung)
Date: Mon, 24 Aug 2015 21:39:09 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:49:48 2015
From: report at bugs.python.org (Samuel Isaacson)
Date: Mon, 24 Aug 2015 23:49:48 +0000
Subject: [New-bugs-announce] [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 07:51:28 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Aug 2015 05:51:28 +0000
Subject: [New-bugs-announce] [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 13:28:15 2015
From: report at bugs.python.org (Andrey Wagin)
Date: Tue, 25 Aug 2015 11:28:15 +0000
Subject: [New-bugs-announce] [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 15:09:39 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 25 Aug 2015 13:09:39 +0000
Subject: [New-bugs-announce] [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 17:47:24 2015
From: report at bugs.python.org (yunlian)
Date: Tue, 25 Aug 2015 15:47:24 +0000
Subject: [New-bugs-announce] [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 18:41:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Aug 2015 16:41:24 +0000
Subject: [New-bugs-announce] [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:32 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 25 Aug 2015 16:41:32 +0000
Subject: [New-bugs-announce] [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 20:49:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Aug 2015 18:49:27 +0000
Subject: [New-bugs-announce] [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 23:30:11 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 25 Aug 2015 21:30:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 09:07:03 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 26 Aug 2015 07:07:03 +0000
Subject: [New-bugs-announce] [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 22:51:43 2015
From: report at bugs.python.org (Lee Clemens)
Date: Wed, 26 Aug 2015 20:51:43 +0000
Subject: [New-bugs-announce] [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  Thu Aug 27 09:18:51 2015
From: report at bugs.python.org (Sworddragon)
Date: Thu, 27 Aug 2015 07:18:51 +0000
Subject: [New-bugs-announce] [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 11:15:35 2015
From: report at bugs.python.org (Hassan El Karouni)
Date: Thu, 27 Aug 2015 09:15:35 +0000
Subject: [New-bugs-announce] [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 15:50:54 2015
From: report at bugs.python.org (Erik Bray)
Date: Thu, 27 Aug 2015 13:50:54 +0000
Subject: [New-bugs-announce] [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 18:44:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 Aug 2015 16:44:16 +0000
Subject: [New-bugs-announce] [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 22:50:01 2015
From: report at bugs.python.org (tagatac)
Date: Thu, 27 Aug 2015 20:50:01 +0000
Subject: [New-bugs-announce] [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 23:20:29 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 27 Aug 2015 21:20:29 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 05:28:26 2015
From: report at bugs.python.org (Felix Yan)
Date: Fri, 28 Aug 2015 03:28:26 +0000
Subject: [New-bugs-announce] [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 08:44:06 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Aug 2015 06:44:06 +0000
Subject: [New-bugs-announce] [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 16:59:08 2015
From: report at bugs.python.org (mattip)
Date: Fri, 28 Aug 2015 14:59:08 +0000
Subject: [New-bugs-announce] [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 22:51:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 28 Aug 2015 20:51:53 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 12:01:40 2015
From: report at bugs.python.org (Simon Conseil)
Date: Sat, 29 Aug 2015 10:01:40 +0000
Subject: [New-bugs-announce] [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:26:34 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 29 Aug 2015 10:26:34 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 18:01:34 2015
From: report at bugs.python.org (Shlomi Fish)
Date: Sat, 29 Aug 2015 16:01:34 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 19:36:22 2015
From: report at bugs.python.org (Oleg N)
Date: Sat, 29 Aug 2015 17:36:22 +0000
Subject: [New-bugs-announce] [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 22:59:20 2015
From: report at bugs.python.org (Dave Hein)
Date: Sat, 29 Aug 2015 20:59:20 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 18:26:25 2015
From: report at bugs.python.org (zodalahtathi)
Date: Sun, 30 Aug 2015 16:26:25 +0000
Subject: [New-bugs-announce] [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 19:41:50 2015
From: report at bugs.python.org (Thomas)
Date: Sun, 30 Aug 2015 17:41:50 +0000
Subject: [New-bugs-announce] [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:47:00 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 30 Aug 2015 17:47:00 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:17:24 2015
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=)
Date: Mon, 31 Aug 2015 08:17:24 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 17:47:20 2015
From: report at bugs.python.org (Marek Otahal)
Date: Mon, 31 Aug 2015 15:47:20 +0000
Subject: [New-bugs-announce] [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 19:00:05 2015
From: report at bugs.python.org (Antony Lee)
Date: Mon, 31 Aug 2015 17:00:05 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 20:54:21 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 31 Aug 2015 18:54:21 +0000
Subject: [New-bugs-announce] [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 22:34:51 2015
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 31 Aug 2015 20:34:51 +0000
Subject: [New-bugs-announce] [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 23:37:02 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 31 Aug 2015 21:37:02 +0000
Subject: [New-bugs-announce] [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>
_______________________________________