From report at bugs.python.org  Tue Sep  1 03:13:16 2015
From: report at bugs.python.org (David Beazley)
Date: Tue, 01 Sep 2015 01:13:16 +0000
Subject: [New-bugs-announce] [issue24975] Python 3.5 can't compile AST
	involving PEP 448 unpacking
Message-ID: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za>


New submission from David Beazley:

The compile() function is not able to compile an AST created from code that uses some of the new unpacking generalizations in PEP 448.  Example:

code = '''                                                                     
a = { 'x':1, 'y':2 }
b = { **a, 'z': 3 }
'''

# Works
ccode = compile(code, '', 'exec')

# Crashes
import ast
tree = ast.parse(code)
ccode = compile(tree, '', 'exec')

# ----------------------------------

Error Traceback:

Traceback (most recent call last):
  File "bug.py", line 11, in <module>
    ccode = compile(tree, '', 'exec')
ValueError: None disallowed in expression list

Note:  This bug makes it impossible to try generalized unpacking examples interactively in IPython.

----------
components: Library (Lib)
messages: 249442
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Python 3.5 can't compile AST involving PEP 448 unpacking
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  1 08:49:42 2015
From: report at bugs.python.org (Andrew)
Date: Tue, 01 Sep 2015 06:49:42 +0000
Subject: [New-bugs-announce] [issue24976] Arithmetic/precision bug when
 using floating-point numbers
Message-ID: <1441090182.8.0.683864424738.issue24976@psf.upfronthosting.co.za>


New submission from Andrew:

I just recently discovered this bug, but when adding or subtracting a number and a precision error occurs when using at least 1 floating-point number in the operation. For example, 1 - 0.98 should output 0.02, but instead outputs 0..020000000000000018 (at least on my machine).

Included is a simple script showing what happens, just when incrementing or decrementing by 0.01 from 0 to 1.

I am running Python 3.4.3 on a 64-bit Arch Linux machine.

----------
components: Interpreter Core
files: weirdpythonbug.py
messages: 249458
nosy: videogames4all
priority: normal
severity: normal
status: open
title: Arithmetic/precision bug when using floating-point numbers
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40313/weirdpythonbug.py

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

From report at bugs.python.org  Tue Sep  1 13:26:57 2015
From: report at bugs.python.org (Jake Howard)
Date: Tue, 01 Sep 2015 11:26:57 +0000
Subject: [New-bugs-announce] [issue24977] shutil copy to non-existant
	directory
Message-ID: <1441106817.15.0.872685605647.issue24977@psf.upfronthosting.co.za>


New submission from Jake Howard:

If you try and copy a file using shutil.copy to a directory that doesnt exist, it tries to copy the file to the location of the directory, and errors as shutil can't open a directory for 'WB' access, throwing an error, that doesnt reflect the problem.

----------
messages: 249474
nosy: TheOrangeOne
priority: normal
severity: normal
status: open
title: shutil copy to non-existant directory
type: behavior

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

From report at bugs.python.org  Tue Sep  1 14:04:07 2015
From: report at bugs.python.org (Eugene)
Date: Tue, 01 Sep 2015 12:04:07 +0000
Subject: [New-bugs-announce] [issue24978] Contributing to Python 2x and 3x
 Documentation. Translation to Russian.
Message-ID: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za>


New submission from Eugene:

I am very much begging pardon if this is not the place to ask for, but..

I would like to make a thorough translation of the official Library Reference and the beginners guide to Python 2.x 3.x in Russian language.

I am aware this type of translation will be placed at
https://wiki.python.org/moin/RussianLanguage
as current https://docs.python.org/2/ does not allow changing language.

I am pretty much aware the translation should not sound any differently from the original in terms of its style, form and overall attitude. And I would also like to know, if possible, can this link be promoted somewhere at python.org. I am not in the slightest have the intentions of promoting in anywhere but in the place where most russian programmers could most definitely find it - at the oficial Python website.

Kind regards, Evgeniy.

----------
assignee: docs at python
components: Documentation
messages: 249478
nosy: docs at python, overr1de
priority: normal
severity: normal
status: open
title: Contributing to Python 2x and 3x Documentation. Translation to Russian.
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  1 16:31:14 2015
From: report at bugs.python.org (TJ)
Date: Tue, 01 Sep 2015 14:31:14 +0000
Subject: [New-bugs-announce] [issue24979] Allow timezone offsets greater
	than 24 hours
Message-ID: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za>


New submission from TJ:

The datetime module only supports timezone offsets within 24 hours of UTC:

https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

This seems like an arbitrary restriction, and prevents the library from being used in arbitrary timezone translations. For various reasons, one might need to start a new day (perhaps to implement some business logic) during the regular day. Depending on when/where this is, the effective offset can easily be greater than 24 hours.

>>> import datetime
>>> import pytz

>>> dt = pytz.utc.localize(datetime.datetime.utcnow())
>>> dt
datetime.datetime(2015, 8, 31, 23, 30, 55, 590037, tzinfo=<UTC>)

>>> tz = pytz.timezone('Pacific/Auckland_Custom')
>>> dt.astimezone(tz)
datetime.datetime(2015, 9, 2, 4, 30, 55, 590037, tzinfo=<DstTzInfo 'Pacific/Auckland_Custom' NZST+1 day, 5:00:00 STD>)

>>> dt_local = datetime.datetime.now()
>>> tz.localize(dt_local)
.../python2.7/site-packages/pytz/tzinfo.py in localize(self, dt, is_dst)
    314 loc_dt = tzinfo.normalize(dt.replace(tzinfo=tzinfo))
    315 if loc_dt.replace(tzinfo=None) == dt:
--> 316 possible_loc_dt.add(loc_dt)
    317
    318 if len(possible_loc_dt) == 1:

ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439


Note that although only offsets within 24 hours are supported, it seems to be possible to use astimezone() with arbitrary offsets. So perhaps we gain consistency in removing the restriction altogether?

This would not be unprecedented. RFC 2822 allows any offset
representable as HHMM: "the zone MUST be within the range -9959
through +9959" Section 3.3 of http://tools.ietf.org/html/rfc2822.html

----------
components: Library (Lib)
messages: 249482
nosy: tjhnson
priority: normal
severity: normal
status: open
title: Allow timezone offsets greater than 24 hours
type: enhancement

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

From report at bugs.python.org  Tue Sep  1 21:13:12 2015
From: report at bugs.python.org (Joshua Harlow)
Date: Tue, 01 Sep 2015 19:13:12 +0000
Subject: [New-bugs-announce] [issue24980] Allow for providing
 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'
Message-ID: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za>


New submission from Joshua Harlow:

In situations where thread-local variables need to be setup it is quite useful to be able to hook into the thread creation process, so that as each new thread is spun up by the ThreadPoolExecutor that the threads created initially call into a provided callback (the callback can then setup thread local state as needed).

----------
messages: 249501
nosy: harlowja
priority: normal
severity: normal
status: open
title: Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

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

From report at bugs.python.org  Tue Sep  1 22:49:15 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Sep 2015 20:49:15 +0000
Subject: [New-bugs-announce] [issue24981] Add a test which uses the ast
 module to compile the stdlib
Message-ID: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Issue #24975 shows that we can easily end up with holes in support from the ast module. We should probably make sure we have a test that goes through the entire stdlib, Does an ast.parse(), and then passes the result to compile() to verify no exceptions are raised. We should either avoid the test/ directory or blacklist specific files which will fail because they are designed to be syntactically incorrect. The test can also be behind a -u flag if it turns out to be an expensive test.

----------
components: Tests
messages: 249516
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add a test which uses the ast module to compile the stdlib
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  2 02:56:17 2015
From: report at bugs.python.org (Eugene Kolo)
Date: Wed, 02 Sep 2015 00:56:17 +0000
Subject: [New-bugs-announce] [issue24982] shutil.make_archive doesn't
	archive empty directories
Message-ID: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za>


New submission from Eugene Kolo:

Zip file is sometimes known to only contain files and the paths to them, but it can also have have empty folders, they are zero length files with a flag set.

make_archive just ignores empty directories, I propose that there should either be a flag, or it should include empty directories by default.

----------
components: Library (Lib)
messages: 249522
nosy: eugenek
priority: normal
severity: normal
status: open
title: shutil.make_archive doesn't archive empty directories
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  2 12:14:48 2015
From: report at bugs.python.org (David Unric)
Date: Wed, 02 Sep 2015 10:14:48 +0000
Subject: [New-bugs-announce] [issue24983] Wrong AttributeError propagation
Message-ID: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za>


New submission from David Unric:

Hello,

it seems python interpreter improperly handles AttributeError exception raised in __getattr__ method, after called by unresolved attribute inside a property.

Bellow is a simple Python2 example of a class which defines __getattr__ method and a property, where is non-existing attribute accessed:

from __future__ import print_function

class MyClass(object):
    def __getattr__(self, name):
        print('__getattr__ <<', name)
        raise AttributeError(name)
        return 'need know the question'

    @property
    def myproperty(self):
        print(self.missing_attribute)
        return 42

my_inst = MyClass()
print(my_inst.myproperty)

# produces following output
__getattr__ << missing_attribute
__getattr__ << myproperty
Traceback (most recent call last):
  File "a.py", line 84, in <module>
    main()
  File "a.py", line 74, in main
    print('==', my_inst.myproperty)
  File "a.py", line 36, in __getattr__
    raise AttributeError(name)
AttributeError: myproperty


By the documentation https://docs.python.org/2/reference/datamodel.html#object.__getattr__ , if class defines __getattr__ method, it gets called at AttributeError exception and should return a computed value for name, or raise (new) AttributeError exception.

The misbehavior is in 2nd call of __getattr__, with 'myproperty' as an argument.

- self.myproperty does exist, no reason to call __getattr__ for it
- AttributeError exception raised in __getattr__ should be propagated to the outer stack, no recurrence in the same

----------
components: Interpreter Core
messages: 249533
nosy: dunric
priority: normal
severity: normal
status: open
title: Wrong AttributeError propagation
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Sep  2 18:06:50 2015
From: report at bugs.python.org (Tim Tisdall)
Date: Wed, 02 Sep 2015 16:06:50 +0000
Subject: [New-bugs-announce] [issue24984] document AF_BLUETOOTH socket
	address formats
Message-ID: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za>


New submission from Tim Tisdall:

Currently https://docs.python.org/3.6/library/socket.html#socket-families only says "Certain other address families (AF_BLUETOOTH, AF_PACKET, AF_CAN) support specific representations." and there's a comment in the docs saying "document them!"...  So, I'm documenting the AF_BLUETOOTH.

I'm not sure about which versions this should be added to except for 3.6 so I'm listing the pertinent issues when changes were made: 

issue929192 seems to be where the current address format was added for L2CAP, RFCOMM, and SCO

issue1432399 seems to be where HCI was added

issue5510 seems to be where the alternate address format for HCI was added for NetBSD and DragonFlyBSD

It seems SCO used to accept a regular string but at 23ab586c427a it was changed to use a `bytes`...  I'm not sure the issue behind that.


This is my first contribution to CPython so I figured a patch to the docs would be easiest.  Please let me know if I'm doing anything wrong!

----------
assignee: docs at python
components: Documentation
files: bluetooth_socket_docs.patch
keywords: patch
messages: 249554
nosy: Tim.Tisdall, docs at python
priority: normal
severity: normal
status: open
title: document AF_BLUETOOTH socket address formats
Added file: http://bugs.python.org/file40320/bluetooth_socket_docs.patch

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

From report at bugs.python.org  Wed Sep  2 21:58:15 2015
From: report at bugs.python.org (John Nagle)
Date: Wed, 02 Sep 2015 19:58:15 +0000
Subject: [New-bugs-announce] [issue24985] Python install test fails -
	OpenSSL - "dh key too small"
Message-ID: <1441223895.76.0.826003370838.issue24985@psf.upfronthosting.co.za>


New submission from John Nagle:

Installing Python 3.4.3 on a new CentOS Linux release 7.1.1503 server.
Started with source tarball, did usual ./configure; make; make test
SSL test fails with "dh key too small".  See below.

OpenSSL has recently been modified to reject short keys, due to a security vulnerability. See
  http://www.ubuntu.com/usn/usn-2639-1/
and see here for an analysis of the issue on a Python install:
  http://www.alexrhino.net/jekyll/update/2015/07/14/dh-params-test-fail.html

Apparently the "dh512.pem" file in the test suite is now obsolete, because the minimum length dh key is now 768.

The question is, does this break anything else?  Google for "dh key too small" and various other projects report problems. 


======================================================================
ERROR: test_dh_params (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/test/test_ssl.       py", line 2728, in test_dh_params
    chatty=True, connectionchatty=True)
  File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/test/test_ssl.       py", line 1866, in server_params_test
    s.connect((HOST, server.port))
  File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line        846, in connect
    self._real_connect(addr, False)
  File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line        837, in _real_connect
    self.do_handshake()
  File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line        810, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSL_NEGATIVE_LENGTH] dh key too small (_ssl.c:600)

----------------------------------------------------------------------
Ran 99 tests in 12.012s

FAILED (errors=1, skipped=4)
test test_ssl failed
make: *** [test] Error 1

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

----------
components: Installation
messages: 249566
nosy: nagle
priority: normal
severity: normal
status: open
title: Python install test fails - OpenSSL - "dh key too small"
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  2 22:30:29 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Sep 2015 20:30:29 +0000
Subject: [New-bugs-announce] [issue24986] It should be possible to build
 successfully without external libraries
Message-ID: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za>


New submission from Zachary Ware:

We do have the option of leaving out all extension modules ("/p:IncludeExtensions=false"), but it would be nice to be able to build everything that doesn't require external libs.

This also be adds an option to skip only Tkinter (analogous to "/p:IncludeSSL=false"), as that's what I actually need at the moment :).  I'm not adding options for every external project individually, as most of them are not a big deal, but OpenSSL, Tcl/Tk/Tix, and (on 2.7) bsddb take a long time to compile and might be nice to leave out when they're not needed (so I also added the ability to leave out bsddb on 2.7).

Leaving out 3.4 as its project files are not amenable to this kind of change, and 3.4's days are numbered anyway.

----------
assignee: zach.ware
components: Build, Windows
files: 2.7_external_build_handling.diff
keywords: patch
messages: 249567
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: It should be possible to build successfully without external libraries
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40322/2.7_external_build_handling.diff

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

From report at bugs.python.org  Wed Sep  2 23:57:44 2015
From: report at bugs.python.org (asduj)
Date: Wed, 02 Sep 2015 21:57:44 +0000
Subject: [New-bugs-announce] [issue24987] subprocess.Popen with shell=True
	doesn't create socket
Message-ID: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za>


New submission from asduj:

I want to run the next command

subprocess.Popen("soffice --accept='socket,host=localhost,port=8100;urp;'", shell=True)

to make soffice listen localhost:8100. It is work in python 2.7.9, but doesn't in python 3.4.3. I control it by

netstat -a | grep 8100

----------
components: Library (Lib)
messages: 249576
nosy: asduj
priority: normal
severity: normal
status: open
title: subprocess.Popen with shell=True doesn't create socket
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  3 01:10:11 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 02 Sep 2015 23:10:11 +0000
Subject: [New-bugs-announce] [issue24988] IDLE: debugger context menus not
	working on Mac
Message-ID: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Right menu button to invoke context menu (as well as alternative control-click) not set up correctly for Mac in the debugger. Patch attached.

----------
components: IDLE
files: debug-mac-context-menu.patch
keywords: patch
messages: 249582
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: debugger context menus not working on Mac
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40325/debug-mac-context-menu.patch

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

From report at bugs.python.org  Thu Sep  3 01:40:26 2015
From: report at bugs.python.org (John Leitch)
Date: Wed, 02 Sep 2015 23:40:26 +0000
Subject: [New-bugs-announce] [issue24989] scan_eol() Buffer Over-read
Message-ID: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.5 suffers from a vulnerability caused by the behavior of the scan_eol() function. When called, the function gets a line from the buffer of a BytesIO object by searching for a newline character starting at the position in the buffer.

However, if the position is set to a value that is larger than the buffer, this logic will result in a call to memchr that reads off the end of the buffer:

    /* Move to the end of the line, up to the end of the string, s. */
    start = PyBytes_AS_STRING(self->buf) + self->pos;
    maxlen = self->string_size - self->pos;
    if (len < 0 || len > maxlen)
        len = maxlen;

    if (len) {
        n = memchr(start, '\n', len);


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:

import tempfile
a = tempfile.SpooledTemporaryFile()
a.seek(0b1)
a.readlines()

Which, depending on the arrangement of memory, may produce an exception such as this:

0:000> g
(698.188): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=fff8a14c ebx=0a0a0a0a ecx=00000000 edx=05bb1000 esi=061211b0 edi=89090909
eip=61c6caf2 esp=010af8dc ebp=010af914 iopl=0         nv up ei ng nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010292
python35!memchr+0x62:
61c6caf2 8b0a            mov     ecx,dword ptr [edx]  ds:002b:05bb1000=????????
0:000> k1
ChildEBP RetAddr  
010af8e0 61b640f1 python35!memchr+0x62 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memchr.asm @ 125]


To fix this issue, it is recommended that scan_eol() be updated to check that the position is not greater than or equal to the size of the buffer. A proposed patch is attached.

----------
files: scan_eol_Buffer_Over-read.patch
keywords: patch
messages: 249584
nosy: JohnLeitch, brycedarling
priority: normal
severity: normal
status: open
title: scan_eol() Buffer Over-read
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file40326/scan_eol_Buffer_Over-read.patch

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

From report at bugs.python.org  Thu Sep  3 01:55:39 2015
From: report at bugs.python.org (Al Sweigart)
Date: Wed, 02 Sep 2015 23:55:39 +0000
Subject: [New-bugs-announce] [issue24990] Foreign language support in turtle
	module
Message-ID: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za>


New submission from Al Sweigart:

I'd like to propose adding foreign language names for the names in the turtle module. This would effectively take this code:

    import turtle
    t = turtle.Pen()
    t.pencolor('green')
    t.forward(100)

...and have this code in French be completely equivalent:

    import turtle
    t = turtle.Plume()
    t.couleurplume('vert')
    t.avant(100)

(Pardon my google-translate French.)

This would be built into the turtle module (the "turtle" name itself would be unchanged). They would be available no matter what the OS's localization settings were set to.

This, of course, is terrible way for a software module to implement internationalization, which usually does not apply to the source code names itself. But I'd like to explain why the turtle module is different.

The turtle module is not used for professional software development, but instead as a teaching tool for children. While professional developers are expected to obtain proficiency with English, the same does not apply to school kids who are just taking a small computer programming unit. Having the turtle module available in their native language would remove a large barrier and let them focus on the core programming concepts that turtle provides.

The popular Scratch tool has a similar internationalized setup and also has LOGO-style commands, so the translation work is already done.

Technically, it would be possible to mix multiple natural languages in the same program. This would be a bad practice, but I also don't see it as a common one.

The color strings (e.g. 'green') are tk-dependent, but this can be worked around in the turtle module without requiring changes to tk.

----------
components: Library (Lib)
messages: 249586
nosy: Al.Sweigart
priority: normal
severity: normal
status: open
title: Foreign language support in turtle module
type: enhancement
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/issue24990>
_______________________________________

From report at bugs.python.org  Thu Sep  3 08:08:03 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 03 Sep 2015 06:08:03 +0000
Subject: [New-bugs-announce] [issue24991] Define instance mutability
	explicitly on type objects
Message-ID: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue #24912 showed that the interpreter has historically assumed that all instances of non-heap types are immutable when it comes to preventing __class__ reassignment, and changing this assumption caused problems with genuinely immutable types that use implicit instance caching (like string interning and the small integrer cache).

More generally, whether or not type instances are mutable or not has been defined somewhat informally - decimal.Decimal instances, for example, are nominally immutable, but this immutability is only by convention, rather than enforced by the interpreter.

It may be desirable to be able to explicitly declare instances of a type as mutable or immutable (both from Python and from C), rather than having that property be inferred from other characteristics in a situational way.

----------
messages: 249605
nosy: ncoghlan, njs
priority: normal
severity: normal
status: open
title: Define instance mutability explicitly on type objects
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  3 11:53:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Sep 2015 09:53:53 +0000
Subject: [New-bugs-announce] [issue24992] collections.OrderedDict
 constructor (odict_new) doesn't handle PyDict_New() failure
Message-ID: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za>


New submission from STINNER Victor:

If PyDict_New() fails (ex: memory allocation failure), odict_new() returns a new OrderedDict with an exception set. It's a bug. Attached patch fixes it.

odict_new() constructor also returns NULL without destroying the newly created object if _odict_initialize() fails. My patch also fixes this.

My patch inlines _odict_initialize() into odict_new() and avoids useless initialization to 0.

----------
files: odict.patch
keywords: patch
messages: 249625
nosy: eric.snow, haypo
priority: normal
severity: normal
status: open
title: collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure
versions: Python 3.6
Added file: http://bugs.python.org/file40334/odict.patch

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

From report at bugs.python.org  Thu Sep  3 12:49:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Sep 2015 10:49:48 +0000
Subject: [New-bugs-announce] [issue24993] The C function
 PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure
Message-ID: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The namereplace error handler introduced in Python 3.5 doesn't handle correctly PyCapsule_Import() failure. If the function raises an exception, the PyCodec_NameReplaceErrors() function must return NULL.

I see that the code correctly handle the case where PyCodec_NameReplaceErrors() failed, but it doesn't clear the exception.

Attached patch changes PyCodec_NameReplaceErrors() to return immediatly NULL if PyCodec_NameReplaceErrors() failed.

Or should we log the exception (PyErr_WriteUnraisable) and then clear it? PyErr_WriteUnraisable is usually used in corner case when it's impossible to report bugs to the function caller.

----------
files: namereplace_errors.patch
keywords: patch
messages: 249628
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40336/namereplace_errors.patch

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

From report at bugs.python.org  Thu Sep  3 17:11:16 2015
From: report at bugs.python.org (Cameron Walker)
Date: Thu, 03 Sep 2015 15:11:16 +0000
Subject: [New-bugs-announce] [issue24994] Python 3.4.2 64-bit Installer
 error (Please insert the disk:)
Message-ID: <1441293076.64.0.808974817159.issue24994@psf.upfronthosting.co.za>


New submission from Cameron Walker:

I had attempted to uninstall python 3.4.2 from the start menu in Windows 7, but it was still visible in my Programs and features. I tried to uninstall it from there but it said it was missing some files. So I re-downloaded the installer, but when it tried to install, the following error came up.

Please insert the disk:
with an Ok and Cancel prompt.
When I click on Ok it causes the same error to reappear, but clicking cancel causes it to abort.

Please help.

----------
components: Windows
messages: 249654
nosy: Cameron Walker, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.4.2 64-bit Installer error (Please insert the disk:)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  3 23:13:47 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 03 Sep 2015 21:13:47 +0000
Subject: [New-bugs-announce] [issue24995] better exception message when an
 unsupported object is passed to `async for` (pep 492)
Message-ID: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Should we raise something like "'int' object is not an asynchronous iterable", instead of "'async for' requires an object with __aiter__ method, got int"?


>>> foo().send(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
TypeError: 'async for' requires an object with __aiter__ method, got int


>>> for i in 1: pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

----------
assignee: yselivanov
components: Interpreter Core
messages: 249689
nosy: gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: better exception message when an unsupported object is passed to `async for` (pep 492)
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep  3 23:29:13 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 03 Sep 2015 21:29:13 +0000
Subject: [New-bugs-announce] [issue24996] IDLE: debugger local/global vars
	should not be editable
Message-ID: <1441315753.96.0.0493251705052.issue24996@psf.upfronthosting.co.za>


New submission from Mark Roseman:

In the debugger, the values for the variables shown in the locals/globals panes are editable (i.e. using Entry widget) but I don't see any mechanism to have those changes affect anything. If I'm not missing something, why Entry and not Label?

----------
messages: 249690
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: debugger local/global vars should not be editable
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/issue24996>
_______________________________________

From report at bugs.python.org  Fri Sep  4 07:08:39 2015
From: report at bugs.python.org (A Kaptur)
Date: Fri, 04 Sep 2015 05:08:39 +0000
Subject: [New-bugs-announce] [issue24997] mock.call_args compares as equal
	and not equal
Message-ID: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za>


New submission from A Kaptur:

mock.call_args can be both equal to and not equal to another object:

>>> m = Mock()
>>> m(1,2)
<Mock name='mock()' id='4483976016'>
>>> m.call_args
call(1, 2)
>>> m.call_args == call(1,2)
True
>>> m.call_args != call(1,2)
True

This appears to be a recent regression - it repros on trunk, but not on 3.3 or 2.7 with mock 1.3.0.

----------
components: Library (Lib)
messages: 249715
nosy: akaptur
priority: normal
severity: normal
stage: needs patch
status: open
title: mock.call_args compares as equal and not equal
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  4 07:11:54 2015
From: report at bugs.python.org (Paul Clarke)
Date: Fri, 04 Sep 2015 05:11:54 +0000
Subject: [New-bugs-announce] [issue24998] docs: subprocess.Popen example has
 extra/invalid parameter
Message-ID: <1441343514.48.0.676306018011.issue24998@psf.upfronthosting.co.za>


New submission from Paul Clarke:

in "subprocess" module documentation has a section for "replacing older functions with subprocess", specifically 17.1.4.5 "replacing os.popen", which includes the example on "return code handling", specifically this line:
--
process = Popen("cmd", 'w', shell=True, stdin=PIPE)
--

That 'w' shouldn't be there.

----------
assignee: docs at python
components: Documentation
messages: 249716
nosy: Paul Clarke, docs at python
priority: normal
severity: normal
status: open
title: docs: subprocess.Popen example has extra/invalid parameter
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  4 12:23:10 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Sep 2015 10:23:10 +0000
Subject: [New-bugs-announce] [issue24999] Segfault in
 test_re.test_sre_character_class_literals() when Python is compiled by ICC
Message-ID: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The crash occurred on the buildbot "x86-64 Windows Server 2012R2 ICC 3.x".

Do you we officially support the ICC compiler?

--

There are still some curious compiler warnings:

Objects\longobject.c(4498): warning #63: shift count is too large
=> "#if LONG_MAX >> 2*PyLong_SHIFT"
Objects\longobject.c(4519): warning #63: shift count is too large
=> "#if LONG_MAX >> 2*PyLong_SHIFT"

I don't understand the test: do we test if the result is zero?

On Windows, a long is only 32-bits. I guess that PyLong_SHIFT is 30 (so 2*PyLong_SHIFT=60).

Maybe we should put "#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT" before?

--

The crash itself:


http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/83/steps/test/logs/stdio

[ 14/398] test_re
Fatal Python error: Segmentation fault

Current thread 0x00000578 (most recent call first):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\re.py", line 163 in match
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_re.py", line 976 in test_sre_character_class_literals
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 600 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 648 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\runner.py", line 176 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1775 in _run_suite
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1809 in run_unittest
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1280 in test_runner
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1281 in runtest_inner
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 968 in runtest
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 763 in main
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1565 in main_in_temp_cwd
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1590 in <module>

----------
components: Build, Windows
messages: 249749
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  4 14:25:41 2015
From: report at bugs.python.org (Alex Etling)
Date: Fri, 04 Sep 2015 12:25:41 +0000
Subject: [New-bugs-announce] [issue25000] _mock_call does not properly grab
	args and kwargs
Message-ID: <1441369541.43.0.73938065209.issue25000@psf.upfronthosting.co.za>


New submission from Alex Etling:

Consider the following lines of code:

def test_mock(val):
    fake_mock = Mock()
    a = {}  
    fake_mock.func(a)
    a['val'] = 5
    fake_mock.func.assert_has_calls([call({})])
What i would expect would be for this statement to pass. What I actually see is the following:

Traceback (most recent call last):
File "/gc/gclib/python/tests/kafka_production/encoding_test.py", line 121, in test_mock
fake_mock.func.assert_has_calls([call({})])
File "/usr/local/lib/python2.7/dist-packages/mock.py", line 863, in assert_has_calls
'Actual: %r' % (calls, self.mock_calls)
AssertionError: Calls not found.
Expected: [call({})]
Actual: [call({'val': 5})]
Mock thinks that I have passed in {'val': 5}, when I in fact did pass in {}. The errors seems to be the way args and kwargs are being grabbed in _mock_call function

----------
components: Macintosh
messages: 249757
nosy: ned.deily, paetling, ronaldoussoren
priority: normal
severity: normal
status: open
title: _mock_call does not properly grab args and kwargs
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/issue25000>
_______________________________________

From report at bugs.python.org  Fri Sep  4 22:46:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Sep 2015 20:46:57 +0000
Subject: [New-bugs-announce] [issue25001] Make --nowindows argument to
 regrtest propagate when running with -j
Message-ID: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Not sure how feasible this is, but when running tests under Windows it's very nice to run with --nowindows on, else you get barraged with a ton of debugging warnings. The problem is that if you use -j the use of --nowindows gets turned off. It would be nice if using --nowindows worked with -j to speed up test execution on Windows while also being less noisy.

----------
components: Tests, Windows
messages: 249828
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Make --nowindows argument to regrtest propagate when running with -j
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  4 22:48:03 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Sep 2015 20:48:03 +0000
Subject: [New-bugs-announce] [issue25002] Deprecate asyncore/asynchat
Message-ID: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Now that we've got asyncio in two releases (3.4 and 3.5) we should start deprecating asyncore and asynchat. There isn't much use of these in the stdlib (smtpd.py uses them, and a bunch of tests) and we should probably rewrite those to use asyncio. Maybe smtpd.py can be deprecated itself.

----------
messages: 249829
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Deprecate asyncore/asynchat
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  4 23:44:28 2015
From: report at bugs.python.org (John Beck)
Date: Fri, 04 Sep 2015 21:44:28 +0000
Subject: [New-bugs-announce] [issue25003] os.urandom() should call
	getrandom(2) not getentropy(2)
Message-ID: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>


New submission from John Beck:

A recent Solaris build upgrade resulted in a massive slowdown of a package operation (our package client is written in Python).  Some DTrace revealed this was because os.urandom() calls had slowed down by a factor of over 300.  This turned out to be caused by an upgrade of Python from 2.7.9 to 2.7.10 which included:

- Issue #22585: On OpenBSD 5.6 and newer, os.urandom() now calls getentropy(),
  instead of reading /dev/urandom, to get pseudo-random bytes.

By adding ac_cv_func_getentropy=no to our configure options, we were able to get back the performance we had lost.  But our security experts warned:

---

OpenBSD only has getentropy(2) and we are compatible with that.
Linux has both getentropy(2) and getrandom(2)
Solaris has getentropy(2) and getrandom(2).

The bug is in Python it should not use getentropy(2) for the implementation of os.urandom() unless it builds its own DRBG (Deterministic Random Bit Generator) around that - which will mean it is "caching" and thus only calling getentropy() for seeding very infrequently.

You can not substitute getentropy() for getrandom(), if you need randomness then entropy does not suffice.

They are using getentropy(2) correctly in the implementation of _PyRandom_Init().

I would personally recommend that the upstream adds os.getentropy() changes
os.urandom() to use getrandom(buf, sz, GRND_NONBLOCK) and os.random() to use
getrandom(buf, sz, GRND_RANDOM).

As it is the upstream implementation is arguably a security vulnerability since you can not use entropy where you need randomness.
---

where by "upstream" he meant "python.org".  So I am filing this bug to request those changes.  I can probably prototype this in the reasonable near future, but I wanted to get the bug filed sooner rather than later.

----------
components: Interpreter Core
messages: 249837
nosy: jbeck
priority: normal
severity: normal
status: open
title: os.urandom() should call getrandom(2) not getentropy(2)
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep  5 00:06:21 2015
From: report at bugs.python.org (John Beck)
Date: Fri, 04 Sep 2015 22:06:21 +0000
Subject: [New-bugs-announce] [issue25004] test_mmap should catch f.close()
 failure in LargeMmapTests._make_test_file()
Message-ID: <1441404381.95.0.01039017408.issue25004@psf.upfronthosting.co.za>


New submission from John Beck:

When running test_mmap on a partition with < 4GB free, it back-traced:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_mmap.py", line 728, in _make_test_file
    f.flush()
OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_mmap.py", line 735, in test_large_offset
    with self._make_test_file(0x14FFFFFFF, b" ") as f:
  File "/usr/lib/python3.4/test/test_mmap.py", line 730, in _make_test_file
    f.close()
OSError: [Errno 28] No space left on device

but by wrapping the f.close() inside another try/except block, its failure was caught and the test was able to complete, resulting in a skip for this sub-test and an OK for the overall test.

----------
components: Tests
files: 26-test_mmap.patch
keywords: patch
messages: 249840
nosy: jbeck
priority: normal
severity: normal
status: open
title: test_mmap should catch f.close() failure in LargeMmapTests._make_test_file()
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40361/26-test_mmap.patch

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

From report at bugs.python.org  Sat Sep  5 01:09:09 2015
From: report at bugs.python.org (Brian Hou)
Date: Fri, 04 Sep 2015 23:09:09 +0000
Subject: [New-bugs-announce] [issue25005] webbrowser breaks on query strings
 with multiple fields on Windows
Message-ID: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za>


New submission from Brian Hou:

With Python 3.5.0rc2 (tested with both Git BASH and Cmder on Windows 8):

$ python3
>>> import webbrowser
>>> webbrowser.open_new('http://example.com/?a=1&b=2')
'b' is not recognized as an internal or external command,
operable program or batch file.
True

The opened page is http://example.com/?a=1 rather than http://example.com/?a=1&b=2.

Trying to open a URL with only one field works as expected.

----------
components: Library (Lib), Windows
messages: 249858
nosy: Brian Hou, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: webbrowser breaks on query strings with multiple fields on Windows
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep  5 01:34:54 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Fri, 04 Sep 2015 23:34:54 +0000
Subject: [New-bugs-announce] [issue25006] List pybind11 binding generator
Message-ID: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>


New submission from Wenzel Jakob:

Hi,

over the last few months, I've been developing a library ("pybind11") for creating Python bindings of C++ code. It is similar in spirit to Boost.Python but uses a very different minimalist approach.

It would be fantastic to get this library listed here: https://docs.python.org/3/faq/extending.html

The purpose of this ticket is that somebody with permissions might add it to this page.

pybind11 is here: https://github.com/wjakob/pybind11

Please let me know if you need any additional information.

Thank you,
Wenzel

----------
assignee: docs at python
components: Documentation
messages: 249865
nosy: docs at python, wenzel
priority: normal
severity: normal
status: open
title: List pybind11 binding generator
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/issue25006>
_______________________________________

From report at bugs.python.org  Sat Sep  5 12:42:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Sep 2015 10:42:33 +0000
Subject: [New-bugs-announce] [issue25007] Add support of copy protocol to
 zlib compressors and decompressors
Message-ID: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

zlib compressor and decompressor objects can be copied with the copy() method, but not with copy.copy(). It is easy to add support of copy protocol to them (just add __copy__() as an alias to copy()).

----------
components: Library (Lib)
messages: 249902
nosy: nadeem.vawda, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Add support of copy protocol to zlib compressors and decompressors
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep  5 19:08:13 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Sep 2015 17:08:13 +0000
Subject: [New-bugs-announce] [issue25008] Deprecate smtpd
Message-ID: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As mentioned in passing in issue #25002, perhaps smtpd should be deprecated or at least be updated to use asyncio.

----------
components: Library (Lib)
messages: 249911
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate smtpd
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep  5 19:12:53 2015
From: report at bugs.python.org (Alex Willmer)
Date: Sat, 05 Sep 2015 17:12:53 +0000
Subject: [New-bugs-announce] [issue25009] queue.Queue() does not validate
	the maxsize argument
Message-ID: <1441473173.56.0.310584962633.issue25009@psf.upfronthosting.co.za>


New submission from Alex Willmer:

The maxsize argument when initializing a Queue is expected to be an int (technically anything that can be compared to an int). However the class takes any value. In Python 3 this throws "TypeError: unorderable types" once e.g. .put() is called.

On the basis that errors should not pass silent, should maxsize be checked for compatibility at initialization time? e.g.

Desired:

>>> import queue
>>> q = queue.Queue(range(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/queue.py", line nnn, in __init__()
    ...
TypeError: 'range' object cannot be interpreted as an integer


Actual:

Python 3.5.0rc2 (default, Aug 25 2015, 20:29:07) 
[GCC 5.2.1 20150825] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import queue
>>> q = queue.Queue(range(10)) # Silently accepts an invalid maxsize
>>> q.put('foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/queue.py", line 127, in put
    if self.maxsize > 0:
TypeError: unorderable types: range() > int()

----------
components: Library (Lib)
messages: 249914
nosy: Alex.Willmer
priority: normal
severity: normal
status: open
title: queue.Queue() does not validate the maxsize argument
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  5 19:36:46 2015
From: report at bugs.python.org (Shaun Walbridge)
Date: Sat, 05 Sep 2015 17:36:46 +0000
Subject: [New-bugs-announce] [issue25010] minor typo in PCBuild readme.txt
Message-ID: <1441474606.12.0.269999159131.issue25010@psf.upfronthosting.co.za>


New submission from Shaun Walbridge:

A minor documentation fix. Currently, the top-level PCBuild readme.txt mentions in the final section 'Your Own Extension DLLs' that the example project is located in ../PC/example/, but the example location is ../PC/example_nt/.

----------
assignee: docs at python
components: Documentation
files: pyd-typo.diff
keywords: patch
messages: 249915
nosy: docs at python, scw
priority: normal
severity: normal
status: open
title: minor typo in PCBuild readme.txt
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file40374/pyd-typo.diff

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

From report at bugs.python.org  Sat Sep  5 23:29:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Sep 2015 21:29:27 +0000
Subject: [New-bugs-announce] [issue25011] Smarter rl complete: hide private
	and special names
Message-ID: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When press tabulation just after the dot, the output is too long. It contains all attributes, most of them are dunder names.

>>> int.
int.__abs__(            int.__doc__             int.__int__(            int.__pos__(            int.__round__(          int.__truediv__(
int.__add__(            int.__eq__(             int.__invert__(         int.__pow__(            int.__rpow__(           int.__trunc__(
int.__and__(            int.__flags__           int.__itemsize__        int.__prepare__(        int.__rrshift__(        int.__weakrefoffset__
int.__base__(           int.__float__(          int.__le__(             int.__qualname__        int.__rshift__(         int.__xor__(
int.__bases__           int.__floor__(          int.__lshift__(         int.__radd__(           int.__rsub__(           int.bit_length(
int.__basicsize__       int.__floordiv__(       int.__lt__(             int.__rand__(           int.__rtruediv__(       int.conjugate(
int.__bool__(           int.__format__(         int.__mod__(            int.__rdivmod__(        int.__rxor__(           int.denominator
int.__call__(           int.__ge__(             int.__module__          int.__reduce__(         int.__setattr__(        int.from_bytes(
int.__ceil__(           int.__getattribute__(   int.__mro__             int.__reduce_ex__(      int.__sizeof__(         int.imag
int.__class__(          int.__getnewargs__(     int.__mul__(            int.__repr__(           int.__str__(            int.mro(
int.__delattr__(        int.__gt__(             int.__name__            int.__rfloordiv__(      int.__sub__(            int.numerator
int.__dict__            int.__hash__(           int.__ne__(             int.__rlshift__(        int.__subclasscheck__(  int.real
int.__dictoffset__      int.__index__(          int.__neg__(            int.__rmod__(           int.__subclasses__(     int.to_bytes(
int.__dir__(            int.__init__(           int.__new__(            int.__rmul__(           int.__subclasshook__(   
int.__divmod__(         int.__instancecheck__(  int.__or__(             int.__ror__(            int.__text_signature__  

Proposed patch hides underscored names and show dunder names only if a prefix starts with '__', and private members only if a prefix starts with '_'.

>>> int.
int.bit_length(  int.conjugate(   int.denominator  int.from_bytes(  int.imag         int.mro(         int.numerator    int.real         int.to_bytes(
>>> int.__
int.__abs__(            int.__divmod__(         int.__init__(           int.__neg__(            int.__rlshift__(        int.__sub__(
int.__add__(            int.__doc__             int.__instancecheck__(  int.__new__(            int.__rmod__(           int.__subclasscheck__(
int.__and__(            int.__eq__(             int.__int__(            int.__or__(             int.__rmul__(           int.__subclasses__(
int.__base__(           int.__flags__           int.__invert__(         int.__pos__(            int.__ror__(            int.__subclasshook__(
int.__bases__           int.__float__(          int.__itemsize__        int.__pow__(            int.__round__(          int.__text_signature__
int.__basicsize__       int.__floor__(          int.__le__(             int.__prepare__(        int.__rpow__(           int.__truediv__(
int.__bool__(           int.__floordiv__(       int.__lshift__(         int.__qualname__        int.__rrshift__(        int.__trunc__(
int.__call__(           int.__format__(         int.__lt__(             int.__radd__(           int.__rshift__(         int.__weakrefoffset__
int.__ceil__(           int.__ge__(             int.__mod__(            int.__rand__(           int.__rsub__(           int.__xor__(
int.__class__(          int.__getattribute__(   int.__module__          int.__rdivmod__(        int.__rtruediv__(       
int.__delattr__(        int.__getnewargs__(     int.__mro__             int.__reduce__(         int.__rxor__(           
int.__dict__            int.__gt__(             int.__mul__(            int.__reduce_ex__(      int.__setattr__(        
int.__dictoffset__      int.__hash__(           int.__name__            int.__repr__(           int.__sizeof__(         
int.__dir__(            int.__index__(          int.__ne__(             int.__rfloordiv__(      int.__str__(            

(The completion of int._ returns nothing because int has no private members).

----------
components: Library (Lib)
files: rlcomplete_filter_private.patch
keywords: patch
messages: 249928
nosy: pitrou, serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: Smarter rl complete: hide private and special names
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40377/rlcomplete_filter_private.patch

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

From report at bugs.python.org  Sun Sep  6 00:05:48 2015
From: report at bugs.python.org (David Barnett)
Date: Sat, 05 Sep 2015 22:05:48 +0000
Subject: [New-bugs-announce] [issue25012] pathlib should allow converting to
 absolute paths without resolving symlinks
Message-ID: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za>


New submission from David Barnett:

There doesn't seem to be any helper in pathlib to expand a relative path to an absolute path *without* resolving symlinks.

For example, if I want to convert
  pathlib.Path('some/path')
to
  pathlib.Path('/full/path/to/some/path')
where some/path is a symlink, my best option seems to be
  pathlib.Path(os.path.abspath(str(pathlib.Path('some/path'))))

----------
components: Library (Lib)
messages: 249936
nosy: mu_mind
priority: normal
severity: normal
status: open
title: pathlib should allow converting to absolute paths without resolving symlinks
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep  6 12:36:43 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 06 Sep 2015 10:36:43 +0000
Subject: [New-bugs-announce] [issue25013] run_pdb() in test_pdb.py always
	returns stderr as None
Message-ID: <1441535803.94.0.131993266269.issue25013@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The attached patch fixes this.

----------
components: Library (Lib)
files: run_pdb.patch
keywords: patch
messages: 249989
nosy: terry.reedy, xdegaye
priority: normal
severity: normal
status: open
title: run_pdb() in test_pdb.py always returns stderr as None
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file40379/run_pdb.patch

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

From report at bugs.python.org  Sun Sep  6 14:32:15 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Sep 2015 12:32:15 +0000
Subject: [New-bugs-announce] [issue25014] Add contextlib.itercm()
Message-ID: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Add an itercm() function that receives an iterable that supports the context manager protocol (e.g. files) and calls enter/exit without having to use the with statement explicitly.

The implementation is pretty straightforward (unless I'm missing something):

def itercm(cm):
    with cm:
        yield from cm

Example usages:

def cat(fnames):
    lines = chain.from_iterable(itercm(open(f)) for f in fnames)
    for line in lines:
        print(line, end='')

This will close the files as soon as the last line is read.

The __exit__ won't be called until the generator is exhausted, so the user should make sure that it is (if he wants __exit__ to be closed).  __exit__ is still called in case of exception.

Attached a clearer example of how it works.

Do you think this would be a good addition to contextlib (or perhaps itertools)?


P.S. I'm also contemplating the idea of having e.g. it = itercm(fname, func=open) to call func lazily once the first next(it) happens, but I haven't thought in detail about the implications of this.  I also haven't considered how this interacts with coroutines.

----------
components: Library (Lib)
files: itercm-example.txt
messages: 249991
nosy: ezio.melotti, ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add contextlib.itercm()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40380/itercm-example.txt

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

From report at bugs.python.org  Sun Sep  6 21:16:05 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Sep 2015 19:16:05 +0000
Subject: [New-bugs-announce] [issue25015] Idle: scroll Text faster with
	mouse wheel
Message-ID: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://stackoverflow.com/questions/32414942/python-scroll-speed
At least on Win7, tk.Texts scroll, by default, at an anemic 2-3 lines per wheel click, ignoring the system wheel setting. What happens on other systems?  I consider this a probable tk bug, at least on Widows, but we can override the default (on Windows) with

def mousescroll(event):
   <scroll n lines>
   return 'break'
text.bind('<MouseWheel>', mousescroll)

turtledemo.__main__ has wheel code (for font resizing) for Windows, Linux, and Mac. Unless we can access system settings, we might add a config option.

----------
messages: 250013
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: scroll Text faster with mouse wheel
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep  7 08:27:26 2015
From: report at bugs.python.org (Chase Albert)
Date: Mon, 07 Sep 2015 06:27:26 +0000
Subject: [New-bugs-announce] [issue25016] defaultdict's pop gives a KeyError
Message-ID: <1441607246.41.0.522388405407.issue25016@psf.upfronthosting.co.za>


New submission from Chase Albert:

`defaultdict(list).pop(1)` raises a KeyError, this is not what I expected (I expected an empty list).

----------
components: Library (Lib)
messages: 250080
nosy: rob.anyone
priority: normal
severity: normal
status: open
title: defaultdict's pop gives a KeyError
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Sep  7 11:01:37 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Mon, 07 Sep 2015 09:01:37 +0000
Subject: [New-bugs-announce] [issue25017] htmllib deprecated: Which library
 to use? Missing sane default in docs
Message-ID: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

At the top of the htmllib module:


> Deprecated since version 2.6: The htmllib module has been removed in
> Python 3.


Source: https://docs.python.org/2/library/htmllib.html#module-htmllib


Newcomers need more advice: Which library should be used?

I know there are many html parsing libraries.

But there should be a sane default for newcomers.

Is there already an agreement of a sane default html parsing library?

----------
assignee: docs at python
components: Documentation
messages: 250088
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: htmllib deprecated: Which library to use? Missing sane default in docs

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

From report at bugs.python.org  Mon Sep  7 11:05:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2015 09:05:42 +0000
Subject: [New-bugs-announce] [issue25018] test_shutil.test_make_archive()
	fails on Windows
Message-ID: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like test_shutil fails since the changeset 4383ff47ffface248c8eabedf0f4c3bdab11f535:
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/315/

======================================================================
FAIL: test_make_tarball (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "B:\buildarea\3.x.ware-win81-release\build\lib\test\test_shutil.py", line 987, in test_make_tarball
    self.assertTrue(os.path.isfile(tarball))
AssertionError: False is not true

----------
components: Tests
messages: 250089
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_shutil.test_make_archive() fails on Windows
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep  7 17:56:02 2015
From: report at bugs.python.org (John Leitch)
Date: Mon, 07 Sep 2015 15:56:02 +0000
Subject: [New-bugs-announce] [issue25019] xmlparse_setattro() Type Confusion
Message-ID: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.4 and 3.5 suffer from a vulnerability caused by the behavior of the xmlparse_setattro() function. When called, the function uses the provided name argument in several conditional statements which assume that the name argument is a string.

However, if a name argument is provided that is not a string, this logic will make several calls to PyUnicode_CompareWithASCIIString that expect a string, yet receive some other type of object, leading to a type confusion vulnerability:

static int
xmlparse_setattro(xmlparseobject *self, PyObject *name, PyObject *v)
{
    /* Set attribute 'name' to value 'v'. v==NULL means delete */
    if (v == NULL) {
        PyErr_SetString(PyExc_RuntimeError, "Cannot delete attribute");
        return -1;
    }
    assert(PyUnicode_Check(name));
    if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) {
    [...]
}
	

In some applications, it may be possible to exploit this behavior to achieve arbitrary code execution. The type confusion can be observed by running the following script:

from xml.parsers.expat import *
p = ParserCreate()
p.__setattr__(range(0xF), 0)

Which, depending on the arrangement of memory, may produce an exception such as this:

0:000> g
(d84.ce0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0086f904 ebx=0086f8fc ecx=0050005c edx=00b60138 esi=0050005e edi=00b60138
eip=61e9a967 esp=0086f8c8 ebp=0086f8e0 iopl=0         nv up ei ng nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010287
python35!find_maxchar_surrogates+0x37:
61e9a967 0fb701          movzx   eax,word ptr [ecx]       ds:002b:0050005c=????
0:000> k3
ChildEBP RetAddr  
0086f8e0 61e9aa35 python35!find_maxchar_surrogates+0x37 [c:\build\cpython\objects\unicodeobject.c @ 1417]
0086f908 61eabcf3 python35!_PyUnicode_Ready+0x35 [c:\build\cpython\objects\unicodeobject.c @ 1466]
0086f918 61c547c3 python35!PyUnicode_CompareWithASCIIString+0x13 
[c:\build\cpython\objects\unicodeobject.c @ 10784]


To fix this issue, it is recommended that xmlparse_setattro() be updated to validate that the name argument is a string and return out of the function early if it is not. A proposed patch is attached.

Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com)

----------
components: XML
files: xmlparse_setattro_Type_Confusion.py
messages: 250116
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: xmlparse_setattro() Type Confusion
type: security
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40394/xmlparse_setattro_Type_Confusion.py

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

From report at bugs.python.org  Tue Sep  8 02:42:13 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 08 Sep 2015 00:42:13 +0000
Subject: [New-bugs-announce] [issue25020] IDLE - centralize ui policies and
	small utilities
Message-ID: <1441672933.59.0.053445062367.issue25020@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Certain policy decisions should be in one place in the code (DRY). 

These could be based on preferences or environment (should we be using ttk?), which operating system we're using (what hand cursor looks best?) or even the version of the operating system we're running (do we need to include a sizegrip?), etc.

Similarly, there are some small utilities that should be available in many places (e.g. what events to bind to for context menu clicks, setting a dialog to modal appearance) that don't necessarily fit elsewhere.

I've attached ui.py which will be a starting place for these sorts of things.

----------
components: IDLE
files: ui.py
messages: 250143
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - centralize ui policies and small utilities
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40398/ui.py

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

From report at bugs.python.org  Tue Sep  8 05:55:02 2015
From: report at bugs.python.org (John Leitch)
Date: Tue, 08 Sep 2015 03:55:02 +0000
Subject: [New-bugs-announce] [issue25021] product_setstate() Out-of-bounds
	Read
Message-ID: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.3, 3.4, and 3.5 suffer from a vulnerability caused by the behavior of the product_setstate() function. When called, the function loops over the state tuple provided and clamps each given index to a value within a range from 0 up to the max number of pools. Then, it loops over the pools and gets an item from the pool using the previously clamped index value.

However, for the upper bound, the clamping logic is using the number of pools and not the size of the individual pool, which can result in a call to PyTuple_GET_ITEM that uses an index outside of the bounds of the pool:

    for (i=0; i<n; i++)
    {
        PyObject* indexObject = PyTuple_GET_ITEM(state, i);
        Py_ssize_t index = PyLong_AsSsize_t(indexObject);
        if (index < 0 && PyErr_Occurred())
            return NULL; /* not an integer */
        /* clamp the index */
        if (index < 0)
            index = 0;
        else if (index > n-1)
            index = n-1;
        lz->indices[i] = index;
    }

    result = PyTuple_New(n);
    if (!result)
        return NULL;
    for (i=0; i<n; i++) {
        PyObject *pool = PyTuple_GET_ITEM(lz->pools, i);
        PyObject *element = PyTuple_GET_ITEM(pool, lz->indices[i]);
        Py_INCREF(element);
        PyTuple_SET_ITEM(result, i, element);
    }

The invalid result of the PyTyple_GET_ITEM() expression is then passed to Py_INCREF(), which performs a write operation that corrupts memory.

In some applications, it may be possible to exploit this behavior to corrupt sensitive information, crash, or achieve code execution. The out-of-bounds write can be observed by running the following script:

import itertools

p = itertools.product((0,),(0,))
p.__setstate__((0, 1))

Which, depending on the arrangement of memory, may produce an exception such as this:

0:000> g
(ea4.11a4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0000c962 ebx=059e8f80 ecx=00000000 edx=00000000 esi=004af564 edi=05392f78
eip=613211eb esp=004af4d0 ebp=004af4f8 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
python35_d!product_setstate+0x13b:
613211eb 8b5108          mov     edx,dword ptr [ecx+8] ds:002b:00000008=????????
0:000> k1
ChildEBP RetAddr  
004af4f8 61553a22 python35_d!product_setstate+0x13b [c:\source\python-3.5.0b3\modules\itertoolsmodule.c @ 2266]

In some cases, EIP corruption may occur:

0:000> r
eax=00000000 ebx=03e0f790 ecx=6d2ad658 edx=00000002 esi=03e0f790 edi=6d0dbb20
eip=00000000 esp=004cf6a0 ebp=004cf6ac iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
00000000 ??              ???
0:000> k4
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
004cf69c 6d08a390 0x0
004cf6ac 6d02b688 python35!PyIter_Next+0x10
004cf6c0 6d0dbb6e python35!chain_next+0x58
004cf6d0 6d0a021d python35!wrap_next+0x4e

To fix this issue, it is recommended that product_setstate() be updated to clamp indices within a range from 0 up to the size of the pool in the body of the result tuple building loop. A proposed patch is attached.

Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com)

----------
files: product_setstate_Type_Confusion.patch
keywords: patch
messages: 250152
nosy: JohnLeitch, brycedarling, rhettinger
priority: normal
severity: normal
status: open
title: product_setstate() Out-of-bounds Read
type: security
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40400/product_setstate_Type_Confusion.patch

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

From report at bugs.python.org  Tue Sep  8 06:42:30 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Sep 2015 04:42:30 +0000
Subject: [New-bugs-announce] [issue25022] Remove PC/example_nt/
Message-ID: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The instructions and examples in PC/example_nt/ are hopelessly outdated (the readme says "It has been tested with VC++ 7.1 on Python 2.4" on default!).  Is there any reason to keep and update the example, or can we just drop it?

----------
assignee: docs at python
components: Documentation, Windows
messages: 250156
nosy: docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Remove PC/example_nt/
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep  8 07:32:07 2015
From: report at bugs.python.org (grizlupo)
Date: Tue, 08 Sep 2015 05:32:07 +0000
Subject: [New-bugs-announce] [issue25023] time.strftime('%a'),
 ValueError: embedded null byte, in ko locale
Message-ID: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za>


New submission from grizlupo:

>>> locale.setlocale(locale.LC_ALL, 'en')
'en'
>>> time.strftime('%a')
'Tue'
>>> locale.setlocale(locale.LC_ALL, 'ko')
'ko'
>>> time.strftime('%a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null byte
>>>

----------
components: Unicode
messages: 250157
nosy: ezio.melotti, haypo, sy LEE
priority: normal
severity: normal
status: open
title: time.strftime('%a'), ValueError: embedded null byte, in ko locale
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  8 07:36:20 2015
From: report at bugs.python.org (Antony Lee)
Date: Tue, 08 Sep 2015 05:36:20 +0000
Subject: [New-bugs-announce] [issue25024] Allow passing "delete=False" to
	TemporaryDirectory
Message-ID: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za>


New submission from Antony Lee:

I would like to suggest allowing passing "delete=False" to the TemporaryDirectory constructor, with the effect that the directory is not deleted when the TemporaryDirectory context manager exits, or when the TemporaryDirectory object is deleted.

I realize that this would effectively duplicate the functionality of mkdtemp, but this is similar to the redundancy between NamedTemporaryFile(delete=False) and mkstemp, and would make it easier to switch between the two behaviors (which is useful e.g. when debugging, where you may need to look at the temporary files "post-mortem").

----------
components: Library (Lib)
messages: 250158
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Allow passing "delete=False" to TemporaryDirectory
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  8 07:38:22 2015
From: report at bugs.python.org (koobs)
Date: Tue, 08 Sep 2015 05:38:22 +0000
Subject: [New-bugs-announce] [issue25025] Missing 3.5.0 RC3 tarballs (FTP)
Message-ID: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za>


New submission from koobs:

3.5.0 rc3 tarballs appear to be missing on:

https://www.python.org/ftp/python/3.5.0/

----------
messages: 250159
nosy: koobs
priority: normal
severity: normal
status: open
title: Missing 3.5.0 RC3 tarballs (FTP)
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  8 08:35:17 2015
From: report at bugs.python.org (koobs)
Date: Tue, 08 Sep 2015 06:35:17 +0000
Subject: [New-bugs-announce] [issue25026] (FreeBSD/OSX) Fix fcntl module to
 accept 'unsigned long' type commands for ioctl(2).
Message-ID: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za>


New submission from koobs:

In my current attempt to create a FreeBSD port for python35, I've come across a patch rejection for the fcntlmodule.c for a local port patch we've been carrying since Python 2.6:

https://svnweb.freebsd.org/ports/head/lang/python27/files/patch-Modules__fcntlmodule.c?revision=391238&view=markup

The original commit log for this change is:

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

  Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).
  
  Although POSIX says the type is 'int', all BSD variants (including Mac OS X)
  have been using 'unsigned long' type for very long time and its use predates
  the standard long enough.  For certain commands (e.g., TIOCSWINSZ, FIONBIO),
  the Python value may get sign-extended on 64-bit platforms (by implicit type
  promotion) and it causes annoying warnings from kernel such as this:
  
  WARNING pid 24509 (python2.6): ioctl sign-extension ioctl ffffffff8004667e

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

I'm not sure how this should be fixed upstream, nor clear on how to re-patch it given recent changes to  fcntlmodule.c

----------
components: Interpreter Core
keywords: easy
messages: 250163
nosy: koobs
priority: normal
severity: normal
status: open
title: (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Sep  8 10:05:36 2015
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 08 Sep 2015 08:05:36 +0000
Subject: [New-bugs-announce] [issue25027] Python 3.5.0rc3 on Windows can not
 load more than 127 C extension modules
Message-ID: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za>


New submission from Christoph Gohlke:

This issue was first mentioned at <http://bugs.python.org/issue24872#msg249591>.

The attached script (test_dll_load_failed.py) builds up to 256 C extension modules and imports them. On Python 3.4.3 the script passes while on Python 3.5.0rc3 the script fails with:

```
Traceback (most recent call last):
File "test_dll_load_failed.py", line 42, in <module>
import_module(name)
File "X:\Python35\lib\importlib\__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 986, in _gcd_import
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 666, in _load_unlocked
File "<frozen importlib._bootstrap>", line 577, in module_from_spec
File "<frozen importlib._bootstrap_external>", line 903, in create_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed.
```

Tested on Windows 7 and 10, 64 bit, with Python 3.5.0rc3, 32 and 64 bit.

Due to this issue the "scientific stack" is practically unusable. For example, Pandas unit tests error or abort. In a Jupyter notebook, the following simple imports fail (using current builds from <http://www.lfd.uci.edu/~gohlke/pythonlibs/>):

```
In [1]:

import matplotlib.pyplot
import pandas
import statsmodels.api
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-69fcce4de550> in <module>()
      1 import matplotlib.pyplot
      2 import pandas
----> 3 import statsmodels.api

<snip>

X:\Python35\lib\site-packages\scipy\signal\__init__.py in <module>()
    276 # The spline module (a C extension) provides:
    277 #     cspline2d, qspline2d, sepfir2d, symiirord1, symiirord2
--> 278 from .spline import *
    279 
    280 from .bsplines import *

ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed.
```

The cause of this issue is that as of Python 3.5.0rc1 C extension modules are linked statically to the multi-threaded runtime library (/MT) instead of the multi-threaded DLL runtime library (/MD). A process can not load more than 127 statically-linked CRT DLLs using LoadLibrary due to a limit of fiber-local storage (FLS) as mentioned in the following links:

<http://stackoverflow.com/questions/1437422>
<https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3546c3c4-1b36-4552-85c5-1b3ba860ee84>

To put the 127 limit in perspective: the pywin32 package contains 51 C extension modules, pygame 36, scipy 65, and scikit-image 41. 

In addition to C extension modules, the 127 limit also applies to statically-linked CRT DLLs that are dynamically loaded via Ctypes or LoadLibrary.

----------
components: Extension Modules, Windows
messages: 250169
nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  8 11:46:02 2015
From: report at bugs.python.org (=?utf-8?q?Yves_M=C3=BCller?=)
Date: Tue, 08 Sep 2015 09:46:02 +0000
Subject: [New-bugs-announce] [issue25028] Reading unicode json string fails
	depending on LANG env
Message-ID: <1441705562.15.0.558425697033.issue25028@psf.upfronthosting.co.za>


New submission from Yves M?ller:

I am trying to read json containing a UTF-8 string from a file. It works when running it from a shell with LANG=en_GB.utf8 set, but fails from the empty environment.

> python3 --version
Python 3.4.0
> cat test.json 
{ "test": "?ml?ute" }
> env -u LANG python3 -c 'import json; json.load(open("test.json"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.4/json/__init__.py", line 265, in load
    return loads(fp.read(),
  File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)
> > env LANG=en_GB.UTF-8 python3 -c 'import json; print(json.load(open("test.json")))'
{'test': '?ml?ute'}

----------
components: Unicode
messages: 250175
nosy: ezio.melotti, haypo, yves
priority: normal
severity: normal
status: open
title: Reading unicode json string fails depending on LANG env
versions: Python 3.4

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

From report at bugs.python.org  Tue Sep  8 12:30:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Sep 2015 10:30:13 +0000
Subject: [New-bugs-announce] [issue25029] MemoryError in test_strptime
Message-ID: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

All builds on edelsohn-fedora-ppc64 are red starting from build 55 for 3.x and build 41 for 3.5. 3.4 is green.
http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/55/
http://buildbot.python.org/all/builders/PPC64%20Fedora%203.5/builds/41/

======================================================================
ERROR: test_TimeRE_recreation (test.test_strptime.CacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/test/test_strptime.py", line 565, in test_TimeRE_recreation
    _strptime._strptime_time('10', '%d')
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 494, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 312, in _strptime
    _TimeRE_cache = TimeRE()
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 190, in __init__
    self.locale_time = LocaleTime()
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 75, in __init__
    self.__calc_am_pm()
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 114, in __calc_am_pm
    am_pm.append(time.strftime("%p", time_tuple).lower())
MemoryError

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

----------
components: Extension Modules
messages: 250177
nosy: David.Edelsohn, larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: MemoryError in test_strptime
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep  8 15:44:41 2015
From: report at bugs.python.org (shiyao.ma)
Date: Tue, 08 Sep 2015 13:44:41 +0000
Subject: [New-bugs-announce] [issue25030] io.[Text]IOBase.seek doesn't take
	keyword parameter
Message-ID: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za>


New submission from shiyao.ma:

The doc is here: https://docs.python.org/3.5/library/io.html#io.IOBase.seek
and here: https://docs.python.org/3.5/library/io.html#io.TextIOBase.seek

It is said the parameter list is in the form of:
seek(offset, whence=SEEK_SET)

But actually only:
seek(offset) or seek(offset, whence) is allowed.

Passing seek(offset, whence=SEEK_FOOBAR) will throw an error.

The patch fixes the function signature as seek(offset[, whence])

----------
assignee: docs at python
components: Documentation
files: seek.patch
keywords: patch
messages: 250200
nosy: berker.peksag, docs at python, ezio.melotti, introom
priority: normal
severity: normal
status: open
title: io.[Text]IOBase.seek doesn't take keyword parameter
versions: Python 3.5
Added file: http://bugs.python.org/file40406/seek.patch

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

From report at bugs.python.org  Tue Sep  8 17:53:19 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 08 Sep 2015 15:53:19 +0000
Subject: [New-bugs-announce] [issue25031] IDLE - file list improvements
Message-ID: <1441727599.54.0.0383020553407.issue25031@psf.upfronthosting.co.za>


New submission from Mark Roseman:

This is a placeholder for what will be a series of patches to the FileList to generalize and enhance it.

This is part of generalizing pieces of IDLE to be more flexible, including things like editors not necessarily being in toplevel windows, dialogs not being modal, etc.

The goal is to turn the FileList into an application "hub" that knows about the various pieces of the application, and can be used for communication between them. Some aspects of this will include:

1. Ensuring other modules don't use internal implementation (e.g. dict/inversedict) so can change it later.

2. Merging PyShellFileList into here (will keep things simpler).

3. Having FileList launch/keep track of certain dialogs (e.g. config) or other non-editor components.

4. Eventually take on some other responsibilities from editors, part of a general component/container refactoring.

----------
components: IDLE
messages: 250229
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - file list improvements
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep  8 19:22:33 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 08 Sep 2015 17:22:33 +0000
Subject: [New-bugs-announce] [issue25032] IDLE - same menubar across
	application
Message-ID: <1441732953.33.0.194435848116.issue25032@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Right now the menubar is slightly different for the shell (has Debug) and the editor windows (has Format and Run). I'd like to suggest the same menubar be used for all windows.

Rationale:

1. Easier to use, especially for systems that share a single menubar visually across the top of screen.

2. Later on we'll likely have situations where shell and one or more editors are part of the same toplevel window.


Implementation Notes:

1. Tk lets you reuse the same menubar across multiple toplevel windows (it actually creates a 'clone' every time it gets attached to the window).

2. This will simplify code e.g. for managing help and windows menus, which now have to do the same thing for multiple menubars.

3. Using tabbed windows, while it's possible to swap the menubar on the fly as you swap windows, it's not necessarily desirable to do so.

4. I've mocked up a system for menu validation/dispatch that will simplify how menu commands are handled now depending on what window is in front, and makes it easier to ensure the right things are enabled/disabled based on context.

----------
components: IDLE
messages: 250242
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - same menubar across application
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep  8 19:31:57 2015
From: report at bugs.python.org (Ron Barak)
Date: Tue, 08 Sep 2015 17:31:57 +0000
Subject: [New-bugs-announce] [issue25033] Python 2.7.10 make - fails on some
 Standard Library Modules
Message-ID: <1441733517.89.0.892919144959.issue25033@psf.upfronthosting.co.za>


New submission from Ron Barak:

UnixWare7 only supports Python 1.6

I added Python 2.7.10 from sources.

Python works, but its make did not finish cleanly: several Standard Library modules failed to build (see attached: it has to be a screenshot since VirtualBox does not support cut-and-paste on UnixWare).

Can you suggest what should be done so that `multiprocessing`, `ssl`, and `select` will compile/build successfully?

----------
components: Build
files: Python_make_failure.PNG
messages: 250244
nosy: ronbarak
priority: normal
severity: normal
status: open
title: Python 2.7.10 make - fails on some Standard Library Modules
versions: Python 2.7
Added file: http://bugs.python.org/file40411/Python_make_failure.PNG

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

From report at bugs.python.org  Tue Sep  8 21:23:13 2015
From: report at bugs.python.org (Anthon van der Neut)
Date: Tue, 08 Sep 2015 19:23:13 +0000
Subject: [New-bugs-announce] [issue25034] string.Formatter accepts empty
 fields but displays wrong when nested
Message-ID: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za>


New submission from Anthon van der Neut:

Since 3.4.1, string.Formatter() accepts empty keys {}. If these are nested they give different results from explicitly numbered, where the same arguments applied  "".format() give the expected results:

    from string import Formatter

    f = Formatter()

    fmt0 = "X {:<{}} {} X"
    fmt1 = "X {0:<{1}} {2} X"

    for fmt in [fmt0, fmt1]:
        x = f.format(fmt, 'ab', 5, 1)
        y = fmt.format(   'ab', 5, 1)
        print(x)
        print(y)
gives:

    X ab    5 X
    X ab    1 X
    X ab    1 X
    X ab    1 X
of which the first line is incorrect.

----------
components: Library (Lib)
messages: 250253
nosy: anthon
priority: normal
severity: normal
status: open
title: string.Formatter accepts empty fields but displays wrong when nested
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep  9 01:01:55 2015
From: report at bugs.python.org (Sworddragon)
Date: Tue, 08 Sep 2015 23:01:55 +0000
Subject: [New-bugs-announce] [issue25035] Getter/setter for argparse keys
Message-ID: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za>


New submission from Sworddragon:

On making a look at the argparse documentation to figure out if I can get the value of the choices key of a specific argument after argument parsing or if I have to implement it myself I noticed that there is a getter/setter for the default key (ArgumentParser.get_default and ArgumentParser.set_defaults) but not for the other keys. Maybe this could also be implemented for the other keys, probably as a generic function that takes as an extra argument the requested key.

----------
components: Library (Lib)
messages: 250263
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Getter/setter for argparse keys
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  9 01:03:19 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 08 Sep 2015 23:03:19 +0000
Subject: [New-bugs-announce] [issue25036] IDLE - infrastructure changes so
 editors don't assume they're in a toplevel
Message-ID: <1441753399.73.0.466397630291.issue25036@psf.upfronthosting.co.za>


New submission from Mark Roseman:

A necessary prerequisite of tabbed windows, editor and shell in same window etc. as per #24826, is that editors stop thinking they are in their own toplevel window.

The attached component.patch is unfortunately long, but this was necessary due to the highly inter-related nature of the changes. It results in no functionality changes to IDLE at this point, just a reorganization.

In summary, WindowList.ListedToplevel was abstracted into a more general Container, which will later be expanded to do more than just a simple toplevel (though that is all it is now). EditorWindow (and friends) no longer call window operations like wm_title themselves, but go through a Container API.

At the same time, a new Component base class was created, which EditorWindow and several others now inherit from. Components get inserted into Containers of course, and the base class ensures certain things the Container needs are present. (The Component also can respond to callbacks from other Components sent via the file list; this approach is used in the patch in #25031 for configuration changes).

Finally, what remained of WindowList (effectively a simplified WindowList class, but not ListedTopLevel) was folded into FileList.

In terms of understanding and/or reviewing this patch, I'd recommend the following:
  1. start with container.py
  2. then component.py
  3. then a simple example of how it's applied, ClassBrowser.py
  4. a slightly more verbose, but equally simple example, Debugger.py
  5. FileList.py (mostly comes from WindowList, but note how used by container.py
  6. then EditorWindow.py

----------
components: IDLE
files: component.patch
keywords: patch
messages: 250264
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - infrastructure changes so editors don't assume they're in a toplevel
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40413/component.patch

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

From report at bugs.python.org  Wed Sep  9 05:43:10 2015
From: report at bugs.python.org (Alan)
Date: Wed, 09 Sep 2015 03:43:10 +0000
Subject: [New-bugs-announce] [issue25037] ValueError: invalid literal for
 int() with base 16: b'[\r\n'
Message-ID: <1441770190.19.0.487767055641.issue25037@psf.upfronthosting.co.za>


New submission from Alan:

I've written a piece of code to POST request to a web service. 

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

import json
import urllib
from urllib import request
from urllib import parse

def Payload(start_date, end_date, pnode_list):
    payload = {"startDate": start_date, 
               "endDate": end_date,
               "pnodelist": pnode_list}
    return json.dumps(payload)

def DownloadData(url, payload, header):
    data = []
    request = urllib.request.Request(url, payload, header)
    try:
        response = urllib.request.urlopen(request)
    except urllib.error.URLError as e:
        print("URLError occured.")
    except urllib.error.HTTPError as e:
        print("HTTPError occured.")
    else:
        #response.chunked = False  #if this line is commented, ValueError                    will be thrown...
        data = json.loads(response.read().decode("utf-8"))
    return data

def main():
    url = "https://dataminer.pjm.com/dataminer/rest/public/api/markets/dayahead/lmp/daily"
    payload = Payload("2015-07-01", "2015-07-01", [135389795])
    header = {"Content-Type": "application/json"}
    data = DownloadData(url, payload.encode("utf-8"), header)
    print(data)

if __name__ == "__main__":
    main()

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

However, "ValueError:invalid literal for int() with base 16: b'[\r\n'" is thrown when the HTTPResponse.read() is invoked:

Traceback (most recent call last):
  File "C:\Python34\lib\http\client.py", line 587, in _readall_chunked
    chunk_left = self._read_next_chunk_size()
  File "C:\Python34\lib\http\client.py", line 559, in _read_next_chunk_si
    return int(line, 16)
ValueError: invalid literal for int() with base 16: b'[\r\n'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "textpjm.py", line 34, in <module>
    main()
  File "textpjm.py", line 30, in main
    data = DownloadData(url, payload.encode("utf-8"), header)
  File "textpjm.py", line 23, in DownloadData
    data = json.loads(response.read().decode("utf-8"))
  File "C:\Python34\lib\http\client.py", line 506, in read
    return self._readall_chunked()
  File "C:\Python34\lib\http\client.py", line 591, in _readall_chunked
    raise IncompleteRead(b''.join(value))
http.client.IncompleteRead: IncompleteRead(0 bytes read)


I've found a solution to avoid this exception: before HTTPResponse.read() is called, I have to set HTTPResponse.chunked to be False!

I wonder if there's something wrong in HTTPResponse.

----------
components: Library (Lib)
files: testpjm.py
messages: 250275
nosy: alan
priority: normal
severity: normal
status: open
title: ValueError: invalid literal for int() with base 16: b'[\r\n'
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file40416/testpjm.py

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

From report at bugs.python.org  Wed Sep  9 08:56:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Sep 2015 06:56:50 +0000
Subject: [New-bugs-announce] [issue25038]
 test_os.TestSendfile.test_keywords() introduced a regression
Message-ID: <1441781810.94.0.0104425602054.issue25038@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The change e42e2bd47168 introduced a regression, test_os started to fail on FreeBSD. What is the rationale of the change? For example, test_os pass in the previous build on the same buildbot.

I don't know if it makes sense to pass None to headers and/or trailers.

Please revert the change or fix the test. ((But we must continue to test headers=None and trailers=None, even if these parameters now raise a TypeError).

======================================================================
ERROR: test_keywords (test.test_os.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_os.py", line 2334, in test_keywords
    headers=None, trailers=None, flags=0)
TypeError: sendfile() headers must be a sequence or None

----------
messages: 250292
nosy: haypo, martin.panter
priority: normal
severity: normal
status: open
title: test_os.TestSendfile.test_keywords() introduced a regression
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep  9 11:08:30 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 09 Sep 2015 09:08:30 +0000
Subject: [New-bugs-announce] [issue25039] Docs: Link to Stackless Python in
 Design and History FAQ section is broken
Message-ID: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za>


New submission from Camilla Montonen:

The link to Stackless Python here https://docs.python.org/2/faq/design.html#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation
is broken. 
I get an "Internal Server Error" when trying to access it.

----------
assignee: docs at python
components: Documentation
messages: 250297
nosy: Winterflower, docs at python
priority: normal
severity: normal
status: open
title: Docs: Link to Stackless Python in Design and History FAQ section is broken
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  9 14:54:11 2015
From: report at bugs.python.org (Gautier Portet)
Date: Wed, 09 Sep 2015 12:54:11 +0000
Subject: [New-bugs-announce] [issue25040] xml.sax.make_parser makes bad use
 of parser_list argument default value
Message-ID: <1441803251.56.0.483557486647.issue25040@psf.upfronthosting.co.za>


New submission from Gautier Portet:

When using xml.sax.make_parser(), there is a potential problem with
the parser_list default value. 
If another module used a default value, like the problematic parser from PyXML, your module will also use it as default parser.

You should change this:
   def make_parser(parser_list = []):

by this :
   def make_parser(parser_list = None):

And change the following code accordingly.

BTW, I fixed by problem by simply using xml.sax.make_parser([])

----------
components: XML
messages: 250303
nosy: Gautier Portet
priority: normal
severity: normal
status: open
title: xml.sax.make_parser makes bad use of parser_list argument default value
type: behavior

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

From report at bugs.python.org  Wed Sep  9 15:07:57 2015
From: report at bugs.python.org (Tim Tisdall)
Date: Wed, 09 Sep 2015 13:07:57 +0000
Subject: [New-bugs-announce] [issue25041] document AF_PACKET socket address
	format
Message-ID: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>


New submission from Tim Tisdall:

As mentioned in #24984, I'm making another issue to document the address format for AF_PACKET.  In this case there's already documentation in Modules/socketmodule.c that says:

- an AF_PACKET socket address is a tuple containing a string
  specifying the ethernet interface and an integer specifying
  the Ethernet protocol number to be received. For example:
  ("eth0",0x1234).  Optional 3rd,4th,5th elements in the tuple
  specify packet-type and ha-type/addr.

But nothing has been added to Doc/library/socket.rst .

The documentation needs to be confirmed with the code.  (It probably should be altered somewhat to state how you "specify packet-type and ha-type/addr"...  and maybe what a "ha-type/addr" is...  A quick Google search found this very useful reference: https://books.google.ca/books?id=Chr1NDlUcI8C&pg=PA472&ots=OCEwyjdXJo&sig=PuNG72WIvv4-A924f9MvzPtgQDc&hl=en&sa=X&ved=0CE8Q6AEwCGoVChMI6IiTyoDqxwIVCTs-Ch3bCAXy#v=onepage&q&f=false )

----------
assignee: docs at python
components: Documentation
messages: 250306
nosy: Tim.Tisdall, docs at python
priority: normal
severity: normal
status: open
title: document AF_PACKET socket address format
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep  9 15:48:15 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 09 Sep 2015 13:48:15 +0000
Subject: [New-bugs-announce] [issue25042] Create an "embedding SDK"
	distribution?
Message-ID: <1441806495.82.0.106064192938.issue25042@psf.upfronthosting.co.za>


New submission from Paul Moore:

At the moment, building an application that embeds Python requires the user to have a full install of Python on the build machine, to get access to the include and library files.

Now that we provide an embeddable build of Python on Windows, would it be worth also having an "embedding SDK" which consisted of a zipfile distribution of the include and lib files?

This may be pointless, as it's not that hard to install Python onto a development system, and even if it is, you'd just need to grab the "include" and "libs" directories from an existing installation, so creating your own SDK is pretty trivial. It's also extra work in the release process to provide the extra distribution file. So I'm OK if this is viewed as not worth it.

The main advantage of having such an "SDK" would be strengthening the message that embedding is a well-supported scenario.

----------
assignee: steve.dower
components: Windows
messages: 250310
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
status: open
title: Create an "embedding SDK" distribution?
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep  9 17:00:39 2015
From: report at bugs.python.org (Tim Tisdall)
Date: Wed, 09 Sep 2015 15:00:39 +0000
Subject: [New-bugs-announce] [issue25043] document socket constants for
	Bluetooth
Message-ID: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za>


New submission from Tim Tisdall:

further to #24984, I noticed there are constants that aren't mentioned in the docs.  Also BDADDR_ALL is missing (which is defined in Bluez's bluetooth.h) so I added it.

Now, I'm not totally clear on supplying multi-version patches...  I know 3.5 is in "freeze" so I'm guessing adding the BDADDR_ALL constant is a no-no.  I guess I checkout out the different version branches, make the changes, and then create a patch labelled for which version it's for?  (I see the patch has the hash for which commit it's to be applied to, but not which branch)

The repo is down right now, so I'll include a patch once I can update my local copy...  :(

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 250314
nosy: Tim.Tisdall, docs at python
priority: normal
severity: normal
status: open
title: document socket constants for Bluetooth
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep  9 17:27:22 2015
From: report at bugs.python.org (Tim Tisdall)
Date: Wed, 09 Sep 2015 15:27:22 +0000
Subject: [New-bugs-announce] [issue25044] bring BTPROTO_SCO inline with
	other Bluetooth protocols
Message-ID: <1441812442.49.0.0898907161184.issue25044@psf.upfronthosting.co.za>


New submission from Tim Tisdall:

All of the BTPROTO_ protocols accept tuples with Bluetooth addresses as regular strings.  SCO accepts a byte-string which represents a Bluetooth address.  The change was made at 23ab586c427a 

With the current implementation we get this error:

>>> import socket
>>> x = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_SEQPACKET, socket.BTPROTO_SCO)
>>> x.bind(socket.BDADDR_ANY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: getsockaddrarg: wrong format

This is because socket.BDADDR_ANY is a string while the bind() is expecting a binary string.  So the workaround would be to call x.bind(socket.BDADDR_ANY.encode()) .

Is it acceptable to change it to accept a regular string to match the other address methods and constants?  This would be essentially a breaking change, however on something that wasn't really documented prior to #24984 .

I'll submit a patch when the repo is back up...

----------
messages: 250316
nosy: Tim.Tisdall
priority: normal
severity: normal
status: open
title: bring BTPROTO_SCO inline with other Bluetooth protocols
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep  9 17:39:19 2015
From: report at bugs.python.org (Philippe Lambotte)
Date: Wed, 09 Sep 2015 15:39:19 +0000
Subject: [New-bugs-announce] [issue25045] smtplib throws exception
	TypeError: readline()
Message-ID: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za>


New submission from Philippe Lambotte:

smtplib  smtpserver.ehlo() will throw exception.
The error message : 
Traceback (most recent call last):
  File "snippet.email.sendmail.py", line 34, in <module>
    smtpserver.ehlo()
  File "/usr/lib/python3.2/smtplib.py", line 421, in ehlo
    (code, msg) = self.getreply()
  File "/usr/lib/python3.2/smtplib.py", line 367, in getreply
    line = self.file.readline(_MAXLINE + 1)
TypeError: readline() takes exactly 1 positional argument (2 given)

smtplib works with python 2.7, but not  with 3.2

If I remove the passed parameter, it works in 3.2 :
     line = self.file.readline()

----------
components: email
messages: 250317
nosy: barry, phlambotte, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib throws exception TypeError: readline()
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Sep  9 18:05:08 2015
From: report at bugs.python.org (Julio)
Date: Wed, 09 Sep 2015 16:05:08 +0000
Subject: [New-bugs-announce] [issue25046] ImportError: No module named
	Multiprocessing
Message-ID: <1441814708.41.0.657407363164.issue25046@psf.upfronthosting.co.za>


New submission from Julio:

Hi!,

I have a problem to import a multiprocessing module. I am using Python 2.7 and Windows 8. The program (.py) is executed since MS-DOS console.

If I run the program the output is "ImportError: No module named multiprocessing".

If I execute "import multiprocessing" on Python Command Line I don't have problems, but It isn't useful for my program, because I need to import since my own file .py

What do you recommend me?. I need to get benefit from the process-based parallelism and to use several processors. 

Thank you so much!

----------
components: Library (Lib)
messages: 250318
nosy: jlmora
priority: normal
severity: normal
status: open
title: ImportError: No module named Multiprocessing
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  9 21:43:38 2015
From: report at bugs.python.org (Simeon Warner)
Date: Wed, 09 Sep 2015 19:43:38 +0000
Subject: [New-bugs-announce] [issue25047] xml.etree.ElementTree encoding
 declaration should be capital ('UTF-8') rather than lowercase ('utf-8')
Message-ID: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za>


New submission from Simeon Warner:

Seems that in python3 the XML encoding declaration from xml.etree.ElementTree has changed from 2.x in that it is now lowercased, e.g. 'utf-8'. While the XML spec [1] says that decoders _SHOULD_ understand this, the encoding string _SHOULD_ be 'UTF-8'. It seems that keeping to the standard in the vein of being strictly conformant in encoding, lax in decoding will give maximum compatibility.

It also seems like an unhelpful change for 2.x to 3.x migration though that is perhaps a minor issue (but how I noticed it).

Can show with:

>cat a.py
from xml.etree.ElementTree import ElementTree, Element
import os, sys
print(sys.version_info)
if sys.version_info > (3, 0):
    fp = os.fdopen(sys.stdout.fileno(), 'wb')
else:
    fp = sys.stdout
root = Element('hello',{'beer':'good'})
ElementTree(root).write(fp, encoding='UTF-8', xml_declaration=True)
fp.write(b"\n")

>python a.py
sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0)
<?xml version='1.0' encoding='UTF-8'?>
<hello beer="good" />

>python3 a.py
sys.version_info(major=3, minor=4, micro=2, releaselevel='final', serial=0)
<?xml version='1.0' encoding='utf-8'?>
<hello beer="good" />

Cheers,
Simeon

[1] <http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EncName> "In an encoding declaration, the values "UTF-8", "UTF-16", ... should be used for the various encodings and transformations of Unicode" and then later "XML processors should match character encoding names in a case-insensitive way".

----------
components: XML
messages: 250328
nosy: zimeon
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8')
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  9 23:35:00 2015
From: report at bugs.python.org (Marc Bouvier)
Date: Wed, 09 Sep 2015 21:35:00 +0000
Subject: [New-bugs-announce] [issue25048] %e Directive Missing in Datetime
	Documentation
Message-ID: <1441834500.22.0.00847516918827.issue25048@psf.upfronthosting.co.za>


New submission from Marc Bouvier:

The %e directive is missing in the Datetime documentation. I have tried this directive in 2.6.6, 2.7.2, and 2.7.10 using datetime.datetime.strftime(datetime.datetime.now(), '%A, %B %e, %Y') and it works in all cases.

The below documentation line is pulled from, http://linux.die.net/man/3/strftime. The behavior is the same.

%e

Like %d, the day of the month as a decimal number, but a leading zero is replaced by a space. (SU)

----------
assignee: docs at python
components: Documentation
messages: 250335
nosy: docs at python, marcrbouvier
priority: normal
severity: normal
status: open
title: %e Directive Missing in Datetime Documentation
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/issue25048>
_______________________________________

From report at bugs.python.org  Thu Sep 10 10:10:44 2015
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Thu, 10 Sep 2015 08:10:44 +0000
Subject: [New-bugs-announce] [issue25049] Strange behavior under doctest:
 staticmethods have different __globals__
Message-ID: <1441872644.04.0.758819356949.issue25049@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

I found a pretty obscure bug/documentation issue.
It only happens if you use global variables in static methods under doctest.
The thing is that this code fails under doctest, while anyone would expect it to work at first sight:

class foo:
    @staticmethod
    def bar():
        """
        >>> GLOBAL = 5; foo.bar()
        5
        """
        print(GLOBAL)

The cause of the problem is that the static method has a __globals__ that for reasons beyond my understanding is not equal to the globals when run under doctest.
This might be a doctest bug, or there might be a reason for it that I don't get: than it must be documented, before it stupifies others.
The behaviour is the same under python 2 and 3.
The attached file shows all (written for Python 3, but can be trivially adapted for python 2), including the workaround.

----------
components: Library (Lib)
files: t.py
messages: 250355
nosy: jneb
priority: normal
severity: normal
status: open
title: Strange behavior under doctest: staticmethods have different __globals__
type: enhancement
Added file: http://bugs.python.org/file40422/t.py

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

From report at bugs.python.org  Thu Sep 10 10:23:03 2015
From: report at bugs.python.org (Adam Groszer)
Date: Thu, 10 Sep 2015 08:23:03 +0000
Subject: [New-bugs-announce] [issue25050] windows installer does not allow
 32 and 64 installs side by side
Message-ID: <1441873383.62.0.21526123437.issue25050@psf.upfronthosting.co.za>


New submission from Adam Groszer:

Installed with python-3.4.3.msi first, then wanted a 64bit side-by-side )of course in an other folder)

Wanted to install python-3.4.3.amd64.msi, the first thing this one did is removed the 32bit install :-(

----------
components: Installation, Windows
messages: 250356
nosy: Adam.Groszer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: windows installer does not allow 32 and 64 installs side by side
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 10 11:57:02 2015
From: report at bugs.python.org (Piotr)
Date: Thu, 10 Sep 2015 09:57:02 +0000
Subject: [New-bugs-announce] [issue25051] 'compile' refuses BOM.
Message-ID: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za>


New submission from Piotr:

Similar to Issue 679880

>>> compile(open("bom3.py").read(), "bom3.py", 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "bom3.py", line 1
    ???# coding: utf-8
      ^
SyntaxError: invalid character in identifier

----------
components: Unicode
files: bom3.py
messages: 250357
nosy: Karulis, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: 'compile' refuses BOM.
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file40423/bom3.py

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

From report at bugs.python.org  Thu Sep 10 12:11:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Sep 2015 10:11:53 +0000
Subject: [New-bugs-announce] [issue25052] Test
Message-ID: <1441879913.16.0.652873375905.issue25052@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Just for testing if I can create a *new* issue.

----------
messages: 250360
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test

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

From report at bugs.python.org  Thu Sep 10 13:33:42 2015
From: report at bugs.python.org (Stanislaw Izaak Pitucha)
Date: Thu, 10 Sep 2015 11:33:42 +0000
Subject: [New-bugs-announce] [issue25053] Possible race condition in Pool
Message-ID: <1441884822.26.0.222476862534.issue25053@psf.upfronthosting.co.za>


New submission from Stanislaw Izaak Pitucha:

This is something that happened once and I cannot reproduce anymore. In an IPython session I've done the following (see session below), which resulted in pool.map raising its internal exceptions in cases where it shouldn't. Then it worked again. (see in/out 29)

Running exactly the same lines again did not result in the same behaviour. I tried multiple times in the same session as well as new sessions. Looks like a weird race / corruption.

I'm on Ubuntu's '3.4.3 (default, Mar 26 2015, 22:03:40) \n[GCC 4.9.2]'. Running with 2 virtualised cores (vmware). 64-bit system.

In [21]: import multiprocessing
In [22]: p=multiprocessing.Pool()
... (unrelated, checked p.map? and other helps)
In [26]: class A(object):
    def a(self, i):
        print("boo", i, multiprocessing.current_process())
   ....: 
In [27]: obj = A()
In [28]: p.map(obj.a, [1,2,3,4])
Process ForkPoolWorker-1:
Process ForkPoolWorker-2:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.4/multiprocessing/queues.py", line 357, in get
    return ForkingPickler.loads(res)
AttributeError: Can't get attribute 'A' on <module '__main__'>
  File "/usr/lib/python3.4/multiprocessing/queues.py", line 357, in get
    return ForkingPickler.loads(res)
AttributeError: Can't get attribute 'A' on <module '__main__'>
boo 3 <ForkProcess(ForkPoolWorker-3, started daemon)>
boo 4 <ForkProcess(ForkPoolWorker-3, started daemon)>

^CProcess ForkPoolWorker-4:
Process ForkPoolWorker-3:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap
    self.run()
  File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.4/multiprocessing/queues.py", line 354, in get
    with self._rlock:
  File "/usr/lib/python3.4/multiprocessing/queues.py", line 355, in get
    res = self._reader.recv_bytes()
  File "/usr/lib/python3.4/multiprocessing/synchronize.py", line 96, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
  File "/usr/lib/python3.4/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/lib/python3.4/multiprocessing/connection.py", line 416, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib/python3.4/multiprocessing/connection.py", line 383, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
<ipython-input-28-3be6fbcc359b> in <module>()
----> 1 p.map(obj.a, [1,2,3,4])

/usr/lib/python3.4/multiprocessing/pool.py in map(self, func, iterable, chunksize)
    258         in a list that is returned.
    259         '''
--> 260         return self._map_async(func, iterable, mapstar, chunksize).get()
    261 
    262     def starmap(self, func, iterable, chunksize=None):

/usr/lib/python3.4/multiprocessing/pool.py in get(self, timeout)
    591 
    592     def get(self, timeout=None):
--> 593         self.wait(timeout)
    594         if not self.ready():
    595             raise TimeoutError

/usr/lib/python3.4/multiprocessing/pool.py in wait(self, timeout)
    588 
    589     def wait(self, timeout=None):
--> 590         self._event.wait(timeout)
    591 
    592     def get(self, timeout=None):

/usr/lib/python3.4/threading.py in wait(self, timeout)
    551             signaled = self._flag
    552             if not signaled:
--> 553                 signaled = self._cond.wait(timeout)
    554             return signaled
    555         finally:

/usr/lib/python3.4/threading.py in wait(self, timeout)
    288         try:    # restore state no matter what (e.g., KeyboardInterrupt)
    289             if timeout is None:
--> 290                 waiter.acquire()
    291                 gotit = True
    292             else:

KeyboardInterrupt: 

In [29]: p.map(obj.a, [1,2,3,4])
boo 1 <ForkProcess(ForkPoolWorker-5, started daemon)>
boo 2 <ForkProcess(ForkPoolWorker-6, started daemon)>
boo 3 <ForkProcess(ForkPoolWorker-5, started daemon)>
boo 4 <ForkProcess(ForkPoolWorker-6, started daemon)>
Out[29]: [None, None, None, None]

----------
components: Library (Lib)
messages: 250362
nosy: Stanislaw Izaak Pitucha
priority: normal
severity: normal
status: open
title: Possible race condition in Pool
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 10 14:19:56 2015
From: report at bugs.python.org (Alcolo Alcolo)
Date: Thu, 10 Sep 2015 12:19:56 +0000
Subject: [New-bugs-announce] [issue25054] Capturing start of line '^'
Message-ID: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za>


New submission from Alcolo Alcolo:

Why
re.findall('^|a', 'a') != ['', 'a'] ?

We have:
re.findall('^|a', ' a') == ['', 'a']
and
re.findall('$|a', ' a') == ['a', '']

Capturing '^' take the 1st character. It's look like a bug ...

----------
components: Regular Expressions
messages: 250364
nosy: Alcolo Alcolo, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Capturing start of line '^'
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 10 15:48:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Sep 2015 13:48:34 +0000
Subject: [New-bugs-announce] [issue25055] Test
Message-ID: <1441892914.52.0.893228162112.issue25055@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Just test if the tracker works for me now.

----------
messages: 250375
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test

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

From report at bugs.python.org  Thu Sep 10 15:51:56 2015
From: report at bugs.python.org (Tim Tisdall)
Date: Thu, 10 Sep 2015 13:51:56 +0000
Subject: [New-bugs-announce] [issue25056] no support for Bluetooth LE in
	socket
Message-ID: <1441893116.99.0.907046270099.issue25056@psf.upfronthosting.co.za>


New submission from Tim Tisdall:

When Bluetooth LE support was added to Bluez they expanded sockaddr_l2 (the struct for making L2CAP connections) to include a l2_bdaddr_type.  Since the existing code initializes the struct with 0's the type is set to regular Bluetooth (BDADDR_BREDR).  An additional optional argument is needed to allow it to also be set to BDADDR_LE_PUBLIC or BDADDR_LE_RANDOM which indicate it's a LE connection to be made.

----------
components: Library (Lib)
messages: 250376
nosy: Tim.Tisdall
priority: normal
severity: normal
status: open
title: no support for Bluetooth LE in socket
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 10 16:31:56 2015
From: report at bugs.python.org (shiyao.ma)
Date: Thu, 10 Sep 2015 14:31:56 +0000
Subject: [New-bugs-announce] [issue25057] Make parameter of io.base to be
	positional and keyword
Message-ID: <1441895516.87.0.702583727095.issue25057@psf.upfronthosting.co.za>


New submission from shiyao.ma:

The parameters for io.[Text]IOBase.seek are currently positional only, as discussed in http://bugs.python.org/issue25030.

We make the parameters to be both positional and keyword based.

----------
files: patch.diff
keywords: patch
messages: 250382
nosy: berker.peksag, ezio.melotti, introom
priority: normal
severity: normal
status: open
title: Make parameter of io.base to be positional and keyword
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40427/patch.diff

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

From report at bugs.python.org  Thu Sep 10 18:30:03 2015
From: report at bugs.python.org (Juan Jimenez-Anca)
Date: Thu, 10 Sep 2015 16:30:03 +0000
Subject: [New-bugs-announce] [issue25058] Right square bracket argparse
	metavar
Message-ID: <1441902603.18.0.552996969637.issue25058@psf.upfronthosting.co.za>


New submission from Juan Jimenez-Anca:

When trying to assign the metavar in add_argument() method of argparse module I'm unable to include characters after a right square bracket.

Trying to set something like this:

metavar="[host:database:collection:]field"

would raise an AssertionError, which includes:

File "/usr/lib64/python3.4/argparse.py", line 329, in _format_usage
    assert ' '.join(opt_parts) == opt_usage

However, the following is accepted:

metavar="[host:database:collection:]field"

----------
components: Library (Lib)
messages: 250388
nosy: cortopy
priority: normal
severity: normal
status: open
title: Right square bracket argparse metavar
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 10 18:45:21 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 10 Sep 2015 16:45:21 +0000
Subject: [New-bugs-announce] [issue25059] Mistake in input-output tutorial
 regarding print() seperator
Message-ID: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Feel free to make changes to the patch if you want to improve the sentence structure.

----------
assignee: docs at python
components: Documentation
messages: 250390
nosy: docs at python, sahutd
priority: normal
severity: normal
status: open
title: Mistake in input-output tutorial regarding print() seperator
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 10 19:01:36 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Sep 2015 17:01:36 +0000
Subject: [New-bugs-announce] [issue25060] BUILD_MAP stack effect suboptimal
Message-ID: <1441904496.93.0.249532808894.issue25060@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

In PyCompile_OpcodeStackEffect() compile.c:

        case BUILD_MAP:
            return 1;

But starting from 3.5, BUILD_MAP pops 2*oparg objects from the stack.

----------
components: Interpreter Core
messages: 250391
nosy: benjamin.peterson, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: BUILD_MAP stack effect suboptimal
type: resource usage
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 10 20:04:05 2015
From: report at bugs.python.org (desbma)
Date: Thu, 10 Sep 2015 18:04:05 +0000
Subject: [New-bugs-announce] [issue25061] Add native enum support for
	argparse
Message-ID: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za>


New submission from desbma:

I often find myself using the following pattern with argparse:

import argparse
import enum

CustomEnumType = enum.Enum("CustomEnumType",
                           ("VAL1", "VAL2", "VAL3", ...))

arg_parser = argparse.ArgumentParser(...)
...
arg_parser.add_argument("-p",
                        "--param",
                        type="string",
                        action="store",
                        choices=tuple(t.name.lower() for t in CustomEnumType),
                        default=CustomEnumType.VAL1.name.lower(),
                        dest="param"
                        ...)
args = arg_parser.parse_args()
args.param = CustomEnumType[args.param.upper()]

I think it would be a great addition to be able to pass the enum type to the add_argument 'type' parameter directly, and have it validate the input and store the resulting enum.

----------
messages: 250399
nosy: desbma
priority: normal
severity: normal
status: open
title: Add native enum support for argparse
type: enhancement

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

From report at bugs.python.org  Thu Sep 10 20:33:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Sep 2015 18:33:32 +0000
Subject: [New-bugs-announce] [issue25062] Doc linter error: [2]
 library/typing.rst:358: default role used
Message-ID: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The Docs buildbot is red since the changeset 7fc4306d537b5feedb7f9dac54d96ed378c093a7.

http://buildbot.python.org/all/builders/Docs%203.x/builds/52

----------
assignee: docs at python
components: Documentation
messages: 250400
nosy: docs at python, gvanrossum, haypo
priority: normal
severity: normal
status: open
title: Doc linter error:  [2] library/typing.rst:358: default role used
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 10 20:38:50 2015
From: report at bugs.python.org (desbma)
Date: Thu, 10 Sep 2015 18:38:50 +0000
Subject: [New-bugs-announce] [issue25063] shutil.copyfileobj should
 internally use os.sendfile when possible
Message-ID: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za>


New submission from desbma:

Sorry if it has already been discussed, or if this is a stupid idea.

By looking at the signature, my thought was that the only use of shutil.copyfileobj was to wrap the use of sendfile, and use a fallback if it is not available on the system or not usable with "fake" Python files (not having a file descriptor, eg. like gzip.GzipFile).

By looking at the implementation, I was surprised that it does not try to call os.sendfile.

----------
components: Library (Lib)
messages: 250401
nosy: desbma
priority: normal
severity: normal
status: open
title: shutil.copyfileobj should internally use os.sendfile when possible

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

From report at bugs.python.org  Fri Sep 11 05:46:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 11 Sep 2015 03:46:56 +0000
Subject: [New-bugs-announce] [issue25064] Adjust tempfile documentation for
	bytes filename support
Message-ID: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is a followup to Issue 24230, which added support for bytes filenames to ?tempfile? module. Currently I think the documentation is misleading, for example it suggests the default values are prefix="tmp" and suffix="", when they are actually None to avoid forcing a text filename. I suggest this patch to fix the problem.

The patch also merges the paragraphs that describe ?suffix? and ?prefix?, and points out that mktemp() does not support these changes.

----------
assignee: docs at python
components: Documentation
files: tempfile-sig.patch
keywords: patch
messages: 250440
nosy: docs at python, gregory.p.smith, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Adjust tempfile documentation for bytes filename support
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40431/tempfile-sig.patch

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

From report at bugs.python.org  Fri Sep 11 06:21:31 2015
From: report at bugs.python.org (=?utf-8?b?TWFydMOtbiBHYWl0w6Fu?=)
Date: Fri, 11 Sep 2015 04:21:31 +0000
Subject: [New-bugs-announce] [issue25065] https://docs.python.org/library
 should redirect to Python 3 doc
Message-ID: <1441945291.84.0.526704676456.issue25065@psf.upfronthosting.co.za>


New submission from Mart?n Gait?n:

The canonical link for documentation https://docs.python.org/ redirect to the index page of the stable Python 3's documentation 

However, https://docs.python.org/library still redirects to the Python 2 standard lib's docs. 

To be consequent https://docs.python.org/library should redirect to https://docs.python.org/3/library/

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 250442
nosy: Mart?n Gait?n, docs at python
priority: normal
severity: normal
status: open
title: https://docs.python.org/library should redirect to Python 3 doc
type: enhancement

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

From report at bugs.python.org  Fri Sep 11 06:25:12 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 11 Sep 2015 04:25:12 +0000
Subject: [New-bugs-announce] [issue25066] Better repr for
	multiprocessing.synchronize objects
Message-ID: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za>


New submission from Davin Potts:

Inspired by issue24391 and the changes proposed to the threading module's reprs for Event, Semaphore, BoundedSemaphore, and Barrier, the corresponding objects in the multiprocessing module should have their reprs updated accordingly.

----------
assignee: davin
components: Library (Lib)
messages: 250443
nosy: davin, jnoller, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: Better repr for multiprocessing.synchronize objects
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 11 06:54:57 2015
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 11 Sep 2015 04:54:57 +0000
Subject: [New-bugs-announce] [issue25067] Hello
Message-ID: <1441947297.37.0.741766147946.issue25067@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
files: attachment.zip
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: Hello
Added file: http://bugs.python.org/file40433/attachment.zip

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

From report at bugs.python.org  Fri Sep 11 10:46:13 2015
From: report at bugs.python.org (Chuang Cao)
Date: Fri, 11 Sep 2015 08:46:13 +0000
Subject: [New-bugs-announce] [issue25068] The proxy key's string should
	ignore case.
Message-ID: <1441961173.2.0.654001525277.issue25068@psf.upfronthosting.co.za>


New submission from Chuang Cao:

When use a urllib2.ProxyHandler to set a proxy, if the proxies's key is an upper string, like "HTTP", "HTTPS". The proxy url can't be used, because they can't find the <type>_open function.

Two way can sovle the issue.
1. Specify it in document to let users to use a lower string like "http".

2. Add a patch in urllib2.py:

diff -up ./urllib2.py.orig ./urllib2.py
--- ./urllib2.py.orig	2015-09-11 15:06:55.686927934 +0800
+++ ./urllib2.py	2015-09-11 16:56:48.306138898 +0800
@@ -102,6 +102,7 @@ import sys
 import time
 import urlparse
 import bisect
+import string
 
 try:
     from cStringIO import StringIO
@@ -713,6 +714,7 @@ class ProxyHandler(BaseHandler):
         assert hasattr(proxies, 'has_key'), "proxies must be a mapping"
         self.proxies = proxies
         for type, url in proxies.items():
+            type = string.lower(type)
             setattr(self, '%s_open' % type,
                     lambda r, proxy=url, type=type, meth=self.proxy_open: \
                     meth(r, proxy, type))


I think the second way is a good way.

----------
components: Library (Lib)
messages: 250454
nosy: Chuang Cao
priority: normal
severity: normal
status: open
title: The proxy key's string should ignore case.
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 11 12:00:54 2015
From: report at bugs.python.org (guilimo)
Date: Fri, 11 Sep 2015 10:00:54 +0000
Subject: [New-bugs-announce] [issue25069] Clean issue when generator not
 exhausted (garbage collector related?)
Message-ID: <1441965654.18.0.0798037188462.issue25069@psf.upfronthosting.co.za>


New submission from guilimo:

Hello!


I experienced a strange behavior when using a generator, with some code encapsulated in a try/finally clause or a context manager.

If the generator is not exhausted when we leave the script (because normal end of script, uncatched exception, etc...), I expect an internal mechanism to execute properly the finally clause (or __exit__ if context manager).
However, in some specific cases, it seems that this mechanism does not work as expected.


Example
=======

Consider the following code:

import time

def create_generator():
    try:
        yield
    finally:
        time.sleep(2)

ct = create_generator()
ct.next()


If you try to execute it, you will get a:
"Exception AttributeError: "'NoneType' object has no attribute 'sleep'" in <generator object create_generator at 0x7f04ad62c0f0> ignored"



Description
===========

My understanding is the following (but I may be wrong):
At the end of the script, the garbage collector automatically calls the close() method of the generator. As a result, GeneratorExit is raised from the "yield", the finally clause is executed, but for some reason, time does not exist anymore (already collected by the GC?).
If you try just a print "xxx" instead of the time.sleep, it seems that there is not any problem.


Important note:
===============

An other very strange thing:
It seems that if I use an other name than "ct" for the generator, the same exact code runs flawlessly...

You can find attached 3 examples (with try/finally, with a context manager, and with an other name for the generator).

I also found this ticket where some discussion may be related to my situation, even if not describing exactly my current problem:
https://bugs.python.org/issue25014

----------
components: Interpreter Core
files: examples.zip
messages: 250460
nosy: guilimo
priority: normal
severity: normal
status: open
title: Clean issue when generator not exhausted (garbage collector related?)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40436/examples.zip

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

From report at bugs.python.org  Fri Sep 11 15:03:44 2015
From: report at bugs.python.org (Antti Haapala)
Date: Fri, 11 Sep 2015 13:03:44 +0000
Subject: [New-bugs-announce] [issue25070] Python 2.6 - Python 3.4 allows
 unparenthesized generator with *args, **kw, forbidden in 3.5
Message-ID: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za>


New submission from Antti Haapala:

User DeTeReR asked a question (http://stackoverflow.com/questions/32521140/generator-as-function-argument) on Stack Overflow about a special case of code that seemed to work in Python 3.4:

    f(1 for x in [1], *[2])

and

    f(*[2], 1 for x in [1])

I found out that when Python 2.6 introduced the "keyword arguments after *args", the checks in ast.c did not follow:

    for (i = 0; i < NCH(n); i++) {
        node *ch = CHILD(n, i);
        if (TYPE(ch) == argument) {
            if (NCH(ch) == 1)
                nargs++;
            else if (TYPE(CHILD(ch, 1)) == gen_for)
                ngens++;
            else
                nkeywords++;
        }
    }
    if (ngens > 1 || (ngens && (nargs || nkeywords))) {
        ast_error(n, "Generator expression must be parenthesized "
                  "if not sole argument");
        return NULL;
    }

the *args, **kwargs were not considered to be of type "argument" by the Grammar, and thus the error was not generated in this case.

Further down, the error "non-keyword arg after keyword arg" was not triggered in the case of sole unparenthesized generator expression.

Now, the parsing changes in 3.5 have disallowed all of these constructs:

    f(1 for i in [42], **kw)
    f(1 for i in [42], *args)
    f(*args, 1 for i in [42])

which were (erroneously) allowed in previous versions.

I believe at least 3.5 release notes should mention this change.

----------
components: Interpreter Core
messages: 250468
nosy: ztane
priority: normal
severity: normal
status: open
title: Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5
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/issue25070>
_______________________________________

From report at bugs.python.org  Fri Sep 11 18:10:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Sep 2015 16:10:01 +0000
Subject: [New-bugs-announce] [issue25071] Windows installer requires
 TargetDir parameter when installing quietly
Message-ID: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za>


New submission from Steve Dower:

If you run the installer without UI and without specifying an installation path, it will not install. For example:

C:\> python-3.5.0rc4-amd64-webinstall.exe /passive

The workaround is to specify TargetPath:

C:\> python-3.5.0rc4-amd64-webinstall.exe /passive TargetPath="C:\Python35_x64"

However, this workaround should not be necessary. We should use the default path based on the InstallAllUsers setting (false by default).

----------
assignee: steve.dower
components: Installation, Windows
messages: 250476
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows installer requires TargetDir parameter when installing quietly
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 11 19:57:28 2015
From: report at bugs.python.org (Vincent Caloone)
Date: Fri, 11 Sep 2015 17:57:28 +0000
Subject: [New-bugs-announce] [issue25072] CGI large POST data string
	truncated
Message-ID: <1441994248.84.0.261500887085.issue25072@psf.upfronthosting.co.za>


New submission from Vincent Caloone:

For "large" POST request (> 25 ko), cgi.FieldStorage() doesn't contains all field in the html form. When we trace the root of the issue, it is located in file server.py : 

if self.command.lower() == "post" and nbytes > 0:
    data = self.rfile.read(nbytes)

the size of 'rfile' is less than the number of byte we attemp to read 'nbyte' with is corresponding to the Content-Length of the POST request header.

Issue seems to be linked with buffering since changing rbufsize from 0 to -1 : 

    # Make rfile unbuffered -- we need to read one line and then pass
    # the rest to a subprocess, so we can't use buffered input.
    #rbufsize = 0
    rbufsize = -1 

stop the issue. Any idea of the real root of this issue ?

Many thanks.

----------
messages: 250479
nosy: Vincent Caloone
priority: normal
severity: normal
status: open
title: CGI large POST data string truncated
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 11 20:09:38 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 11 Sep 2015 18:09:38 +0000
Subject: [New-bugs-announce] [issue25073] Document asyncio.test_utils
Message-ID: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za>


New submission from Zachary Ware:

asyncio.test_utils is not documented.  I'm unsure as to whether that's because it's meant to be private, or if it just hasn't been done yet.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 250482
nosy: docs at python, gvanrossum, haypo, yselivanov, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Document asyncio.test_utils
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 11 21:16:05 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 11 Sep 2015 19:16:05 +0000
Subject: [New-bugs-announce] [issue25074] Bind logger and waninigs modules
 for asyncio __del__ methods
Message-ID: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

See https://github.com/KeepSafe/aiohttp/issues/497 for the reason.

Desctructors and descendant code (`loop.call_exception_handler()`) can be called on interpreter shutdown stage, which leads to printouts like 'None object has no attribute "errror"'.

----------
assignee: asvetlov
components: asyncio
files: asyncio_bind_modules.patch
keywords: patch
messages: 250490
nosy: asvetlov, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Bind logger and waninigs modules for asyncio __del__ methods
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40442/asyncio_bind_modules.patch

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

From report at bugs.python.org  Sat Sep 12 01:37:46 2015
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Fri, 11 Sep 2015 23:37:46 +0000
Subject: [New-bugs-announce] [issue25075] issue from python in encode base64
	with Json Model
Message-ID: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za>


New submission from Ramin Farajpour Cami:

Hi,

issue from python in encode base64 with Json Model in twice encode with base64 output python different  with JAVA and C# , if programmer using rest-service in server side and other programmer using UI(Python Django) in client site , this encode different for encode and decode with match json encode model,


real example :

1- go to https://www.base64encode.org/ 
2- using {"userName":"admin","password":"admin"} (default UTF-8)
3-first encode oupput : "eyJ1c2VyTmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJhZG1pbiJ9"
4-again second encode "eyJ1c2VyTmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJhZG1pbiJ9" output :
"ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQ=="

now second output python json model : 

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

C:\Users\Matthew F4rr3ll>python
Python 2.7.7 (default, Jun  1 2014, 14:21:57) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> s1='{"userName":"admin","password":"admin"}'
>>> s2 = s1.encode("base64")
>>> e = s2.encode("base64")
>>> print e
ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQo=

>>>
>>>
>>>

now check this output : 
ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQo=
ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQ==

you see in two encode different in end line in ("o=" != "==")


also i know resolve this but you should fix in end line encode match with other language


Thanks,
Ramin

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 250502
nosy: Ramin Farajpour Cami
priority: normal
severity: normal
status: open
title: issue from python in encode base64 with Json Model
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep 12 06:41:06 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Sat, 12 Sep 2015 04:41:06 +0000
Subject: [New-bugs-announce] [issue25076] Wrong parameter name in distutils
	documentation
Message-ID: <1442032866.5.0.225181106977.issue25076@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

In Doc/distutils/apiref.rst, the palameter name of CCompiler.library_option is *lib*, but written *dir* in the documentation.

This also applies to the docstring of CCompiler.library_option().

The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: library_option.patch
keywords: patch
messages: 250512
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Wrong parameter name in distutils documentation
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40444/library_option.patch

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

From report at bugs.python.org  Sat Sep 12 09:23:30 2015
From: report at bugs.python.org (Marius Gedminas)
Date: Sat, 12 Sep 2015 07:23:30 +0000
Subject: [New-bugs-announce] [issue25077] Compiler warnings: initialization
 from incompatible pointer type
Message-ID: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

I'm seeing these compiler warnings while trying to build Python 3.5 on Ubuntu 15.04:

In file included from Python/ceval.c:300:0:
Python/ceval_gil.h: In function ?drop_gil?:
Python/ceval_gil.h:181:144: warning: initialization from incompatible pointer type
         _Py_atomic_store_relaxed(&gil_last_holder, tstate);
                                                                                                                                                ^

In file included from Python/ceval.c:300:0:
Python/ceval_gil.h: In function ?take_gil?:
Python/ceval_gil.h:243:144: warning: initialization from incompatible pointer type
         _Py_atomic_store_relaxed(&gil_last_holder, tstate);
                                                                                                                                                ^

Python/pystate.c: In function ?PyThreadState_Swap?:
Python/pystate.c:509:147: warning: initialization from incompatible pointer type
     _Py_atomic_store_relaxed(&_PyThreadState_Current, newts);
                                                                                                                                                ^

/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?classify_argument?:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:224:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 0; i < words; i++)
                ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:245:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
      for (i = 0; i < num; i++)
                    ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:264:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
      for (i = 1; i < words; i++)
                    ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:270:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 0; i < words; i++)
                ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?examine_argument?:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:323:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   for (i = 0; i < n; ++i)
                 ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?ffi_call?:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:484:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (j = 0; j < n; j++, a += 8, size -= 8)
                  ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?ffi_closure_unix64_inner?:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:659:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (j = 0; j < n; j++, a += 8)
                  ^

I saw bug #1616 and thought you might want to know about these.

----------
components: Build
messages: 250513
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Compiler warnings: initialization from incompatible pointer type
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 12 11:46:44 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 12 Sep 2015 09:46:44 +0000
Subject: [New-bugs-announce] [issue25078] Document InstallAllUsers installer
	parameter default 0
Message-ID: <1442051204.9.0.216289255081.issue25078@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

In testing the 3.5.0rc4 default installer, I found that the default for InstallAllUsers appears to be 0, whereas it's currently documented as 1.

----------
assignee: docs at python
components: Documentation
files: installallusers-default.patch
keywords: patch
messages: 250515
nosy: docs at python, steve.dower, takluyver
priority: normal
severity: normal
status: open
title: Document InstallAllUsers installer parameter default 0
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40445/installallusers-default.patch

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

From report at bugs.python.org  Sat Sep 12 11:49:19 2015
From: report at bugs.python.org (Optimal BPM)
Date: Sat, 12 Sep 2015 09:49:19 +0000
Subject: [New-bugs-announce] [issue25079] Tokenize generates NL instead of
	NEWLINE for comments
Message-ID: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za>


New submission from Optimal BPM:

Quoting the documentation:

tokenize.NL
Token value used to indicate a non-terminating newline. The NEWLINE token indicates the end of a logical line of Python code; NL tokens are generated when a logical line of code is continued over multiple physical lines.

This doesn't seem to be entirely true.
At the end of comments, an .NL, not .NEWLINE is generated:
TokenInfo(type=55 (NL), string='\n', start=(5, 22), end=(5, 23), line='# Some docs for the IF\n')

As a comment cannot extend over several lines, if would appear that a NEWLINE would be appropriate?

----------
components: Interpreter Core
messages: 250516
nosy: Optimal BPM
priority: normal
severity: normal
status: open
title: Tokenize generates NL instead of NEWLINE for comments
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 12 14:08:35 2015
From: report at bugs.python.org (Kostis ankostis)
Date: Sat, 12 Sep 2015 12:08:35 +0000
Subject: [New-bugs-announce] [issue25080] The example-code for making
 XLM-RPC requests through proxy, fail!
Message-ID: <1442059715.67.0.31958758043.issue25080@psf.upfronthosting.co.za>


New submission from Kostis ankostis:

The example code provided at the bottom of the reference-page: 
  https://docs.python.org/2/library/xmlrpclib.html#example-of-client-usage
for making XML-RPC requests through a proxy by defining a custom transport fails (at least) in python-3.4!

Obviously it has been kept intact from `xmlrpclib` python-2 but `xmlrpc.client` API has changed and consequently the code fails.
Here is a IPython session demonstratin the problem:

    >>> import xmlrpc.client, http.client
    >>>
    >>> class ProxiedTransport(xmlrpc.client.Transport):
    ...     def set_proxy(self, proxy):
    ...         self.proxy = proxy
    ...     def make_connection(self, host):
    ...         self.realhost = host
    ...         h = http.client.HTTP(self.proxy)
    ...         return h
    ...     def send_request(self, connection, handler, request_body):
    ...         connection.putrequest("POST", 'http://%s%s' % (self.realhost, handler))
    ...     def send_host(self, connection, host):
    ...         connection.putheader('Host', self.realhost)
    ...
    >>> p = ProxiedTransport()
    >>> p.set_proxy('proxy-server:8080')
    >>> server = xmlrpc.client.Server('http://time.xmlrpc.com/RPC2', transport=p)
    >>> print(server.currentTime.getCurrentTime())
    Traceback (most recent call last):
      File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\site-packages\IPython\core\interactiveshell.py", line 3035, in run_code
        exec(code_obj, self.user_global_ns, self.user_ns)
      File "<ipython-input-43-7f4e26b6cd8f>", line 1, in <module>
        print(server.currentTime.getCurrentTime())
      File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1098, in __call__
        return self.__send(self.__name, args)
      File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1437, in __request
        verbose=self.__verbose
      File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1140, in request
        return self.single_request(host, handler, request_body, verbose)
      File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1152, in single_request
        http_conn = self.send_request(host, handler, request_body, verbose)
    TypeError: send_request() takes 4 positional arguments but 5 were given

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 250518
nosy: Kostis ankostis, docs at python
priority: normal
severity: normal
status: open
title: The example-code for making XLM-RPC requests through proxy, fail!
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 13 05:07:16 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 13 Sep 2015 03:07:16 +0000
Subject: [New-bugs-announce] [issue25081] Windows installer
 Upgrade->Customize->Back goes to Install page
Message-ID: <1442113636.61.0.345920202816.issue25081@psf.upfronthosting.co.za>


New submission from Steve Dower:

If you already have Python 3.5.0b4 or later installed and you go to install a later version, it starts with an "Upgrade" page.

If you hit customize from the page, then Back, you end up at the original Install page. You should be at the Customize page.

----------
components: Windows
messages: 250547
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
status: open
title: Windows installer Upgrade->Customize->Back goes to Install page
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 13 08:42:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Sep 2015 06:42:29 +0000
Subject: [New-bugs-announce] [issue25082] Editing What's New In Python 3.5
Message-ID: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Added this issue as a place for discussion and release blocker for 3.5.

----------
assignee: yselivanov
components: Documentation
messages: 250549
nosy: larry, serhiy.storchaka, yselivanov
priority: release blocker
severity: normal
status: open
title: Editing What's New In Python 3.5
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 13 13:26:12 2015
From: report at bugs.python.org (tzickel)
Date: Sun, 13 Sep 2015 11:26:12 +0000
Subject: [New-bugs-announce] [issue25083] Python can sometimes create
	incorrect .pyc files
Message-ID: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>


New submission from tzickel:

I had a non-reproducible issue occur a few times in which python 2.7.9 would produce .pyc files with empty code objects on a network drive under windows. The .pyc might have been created due to intermittent network errors that are hard to reproduce reliably. The .pyc files would override the previous correct .pyc files that existed in the same place.

The incorrect .pyc is a valid file, but instead of having the code object of the original .py file compiled, it would have the code object of an empty .py file. Python would then go on to use the incorrect .pyc file until it is manually deleted.

This peculiar .pyc files got me thinking about how cpython can produce such an incorrect .pyc file instead of failing.

The main issue here is that getc function, returns EOF both on EOF and on file error. It seems as if the tokenizer starts reading the file stream, and gets an EOF directly, it would not check if it resulted from actually reading an empty file or because of an file error, and happily return an empty AST which would be then compiled to a bad empty code .pyc instead of aborting the process because of an file error.

----------
messages: 250556
nosy: tzickel
priority: normal
severity: normal
status: open
title: Python can sometimes create incorrect .pyc files
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 13 15:40:42 2015
From: report at bugs.python.org (Flavio Grossi)
Date: Sun, 13 Sep 2015 13:40:42 +0000
Subject: [New-bugs-announce] [issue25084] remove semi-busy loop in py2.7
 threading.Condition.wait(timeout=x)
Message-ID: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za>


New submission from Flavio Grossi:

threading.Condition.wait(timeout=x) is implemented in python 2  as a semi-busy loop which causes cpu wakeups and unexpected cpu use.

I think this is somewhat problematic since it causes problems in all modules which use that method, such as Queue.get() when used with a timeout.

This issue has been reported and "fixed" in red hat based distributions in a way which i find problematic, as detailed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1230802

The attached patch backports the following change from py3 to fix the problem:
https://hg.python.org/cpython/rev/01d1fd775d16/

----------
components: Library (Lib)
files: timedlock.patch
keywords: patch
messages: 250562
nosy: flavio, pitrou
priority: normal
severity: normal
status: open
title: remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file40450/timedlock.patch

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

From report at bugs.python.org  Sun Sep 13 15:45:45 2015
From: report at bugs.python.org (Wolfgang Langner)
Date: Sun, 13 Sep 2015 13:45:45 +0000
Subject: [New-bugs-announce] [issue25085] Windows x86-64 embeddable zip file
 contains test directorys
Message-ID: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za>


New submission from Wolfgang Langner:

The Windows x86-64 embeddable zip file (and possible the one for 32bit)
includes some unnecessary test folders in python35.zip with test scripts.

python35.zip\distutils\tests\
python35.zip\unittest\test\
python35.zip\lib2to3\tests\
python35.zip\ctypes\test\
python35.zip\sqlite3\test\

Python Version 3.5 rc4

This is only a minor issue, because it affects only size not functionality.

----------
components: Installation, Windows
messages: 250563
nosy: paul.moore, steve.dower, tds333, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows x86-64 embeddable zip file contains test directorys
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 13 15:51:08 2015
From: report at bugs.python.org (Wolfgang Langner)
Date: Sun, 13 Sep 2015 13:51:08 +0000
Subject: [New-bugs-announce] [issue25086] Windows x86-64 embeddable zip file,
 lot of big EXE files in distuils
Message-ID: <1442152268.71.0.790140517875.issue25086@psf.upfronthosting.co.za>


New submission from Wolfgang Langner:

In the Windows x86-64 embeddable zip file in
python35.zip\distutils\command\
are a lot of big EXE files. Possible during build for different
VC compilers.

I don't know the exact structure but thing there should only be EXE's
for the actual used compiler to build Python.

But there are:

wininst-10.0-amd64.exe
wininst-10.0.exe
wininst-14.0-amd64.exe
wininst-14.0.exe
wininst-6.0.exe
wininst-7.1.exe
wininst-8.0.exe
wininst-9.0-amd64.exe
wininst-9.0.exe

These files are really big, and some or all? possible not needed for
and embeddable zip distributed Python.

----------
components: Distutils, Installation, Windows
messages: 250564
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tds333, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows x86-64 embeddable zip file, lot of big EXE files in distuils
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 13 15:52:18 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 13 Sep 2015 13:52:18 +0000
Subject: [New-bugs-announce] [issue25087] Type variable substitution in type
	instances
Message-ID: <1442152338.46.0.937548163334.issue25087@psf.upfronthosting.co.za>


New submission from Stefan Krah:

If a type scheme is instantiated, should the type variables in the
class body be substituted?  This is an example (typed by hand on
a locked down Windows machine, may contain errors):


alpha = TypeVar('alpha')
beta = TypeVar('beta')

class ABTuple(Generic[alpha, beta]):
    def __init__(self, a : alpha, b : beta):
        self.value = (a, b)

get_type_hints(ABTuple.__init__)
 ==> {'b': ~beta, 'a': ~alpha}


IntIntTuple = ABTuple[int, int]

IntIntTuple
 ==> __main__.ABTuple[int, int]

get_type_hints(IntIntTuple.__init__)
{'b': ~beta, 'a': ~alpha}
      ^^^^^^      ^^^^^^


Since the type has been specialized, these should ideally be 'int'.

----------
components: Interpreter Core
messages: 250565
nosy: gvanrossum, skrah
priority: normal
severity: normal
status: open
title: Type variable substitution in type instances
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 13 17:48:22 2015
From: report at bugs.python.org (Naveen Togar)
Date: Sun, 13 Sep 2015 15:48:22 +0000
Subject: [New-bugs-announce] [issue25088] scipy (0.16.0) install fails on 3.5
Message-ID: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za>


New submission from Naveen Togar:

SciPy install using pip fails with the following error:

Running from scipy source directory.
    /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/numpy/distutils/system_info.py:594: UserWarning: Specified path /usr/local/include/python3.5m is invalid.
      warnings.warn('Specified path %s is invalid.' % d)
    /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/numpy/distutils/system_info.py:594: UserWarning: Specified path /usr/include/python3.5m is invalid.
      warnings.warn('Specified path %s is invalid.' % d)
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    "object of type 'type' has no len()" in evaluating 'len(list)' (available names: [])
    error: library dfftpack has Fortran sources but no Fortran compiler found

    ----------------------------------------
Command "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-build-kb3aqu9u/scipy/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-dljex650-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-build-kb3aqu9u/scipy

I didn't have any issues on Python 3.4.  I am on OS X Yosemite.

----------
components: Installation
messages: 250573
nosy: ntogar
priority: normal
severity: normal
status: open
title: scipy (0.16.0) install fails on 3.5
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 00:44:57 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 13 Sep 2015 22:44:57 +0000
Subject: [New-bugs-announce] [issue25089] Can't run Python Launcher on
	Windows
Message-ID: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

I first asked a few days ago, see this thread http://www.gossamer-threads.com/lists/python/python/1216917.  You can work around it by running "repair" but it takes an age to run for what, to me anyway, is a minor irritant.

----------
components: Windows
messages: 250588
nosy: BreamoreBoy, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't run Python Launcher on Windows
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 01:44:39 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 13 Sep 2015 23:44:39 +0000
Subject: [New-bugs-announce] [issue25090] IDLE: alternative to class browser
	/ code context
Message-ID: <1442187879.71.0.781728346587.issue25090@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Proposal for an alternative or perhaps replacement of both the code context extension, as well as the class browser (rooted at a particular file, not the path browser).

I'll direct your attention to the attached browser.png. On the right is IDLE's class browser window of ClassBrowser.py. On the left, I've got the same file loaded into TextMate. 

In the TextMate status bar, it shows you where you're currently located (here, in the __init__ function). When you click on that part of the status bar, it brings up a scrollable menu showing the structure of the file. I think it's easier to read than IDLE's, despite having more information (description of the parameters), thanks to reduction in 'chart junk'.

Downside of this approach is that you can't have a window along the side so you can navigate the code while seeing the class display. Though that might best be achieved if IDLE added a sidebar, rather than a true separate window.

----------
components: IDLE
files: browser.png
messages: 250589
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: alternative to class browser / code context
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40452/browser.png

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

From report at bugs.python.org  Mon Sep 14 03:37:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 01:37:45 +0000
Subject: [New-bugs-announce] [issue25091] Please revert the Windows
	Installer to micro type.
Message-ID: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The 3.4.3 installer used normal size type (10 point, I believe) in the dialog boxes.  I can more or less read this with by non 20/20 eyes.  The new 3.5.0 installer uses a smaller type (8? 7? point), which for even more people will mean using a magnifier. Please revert this anti-accessibility change.  Instead, increase to 12 point if possible.

I noticed that the Python logo picture is also shrunken by about 20%.  I checked side-by-side with the 3.4.3 box, so all system settings were the same for both.

----------
components: Installation, Windows
messages: 250593
nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Please revert the Windows Installer to micro type.
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 04:54:18 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 02:54:18 +0000
Subject: [New-bugs-announce] [issue25092] Regression: test_datetime fails on
 3.5, Win 7, works on 3.4
Message-ID: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

PS C:\Users\Terry> py -3 -m test test_datetime
[1/1] test_datetime
test test_datetime failed -- Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\test\datetimetester.py", line 1154, in test_strftime
    self.assertEqual(t.strftime(""), "") # SF bug #761337
ValueError: Invalid format string

Same result 3 times.

----------
components: Library (Lib)
messages: 250600
nosy: belopolsky, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
type: behavior

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

From report at bugs.python.org  Mon Sep 14 05:17:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 03:17:19 +0000
Subject: [New-bugs-announce] [issue25093] New 3.5.0 failure in test_tcl on
	win7
Message-ID: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

[324/397/3] test_tcl
'\\TEJAREX\C$\Programs\Python' is not recognized as an internal or external command,
operable program or batch file.
test test_tcl failed -- Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\test\test_tcl.py", line 247, in testLoadWithUNC
    self.assertIn('tkinter', f.read())
AssertionError: 'tkinter' not found in ''

I am pretty sure test ran fine in .0rc about a month ago, as it does in 3.4.3.

----------
components: Tkinter, Windows
messages: 250602
nosy: paul.moore, serhiy.storchaka, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: New 3.5.0 failure in test_tcl on win7
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 05:42:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 03:42:58 +0000
Subject: [New-bugs-announce] [issue25094] Test_tools not working on Windows.
Message-ID: <1442202178.75.0.918340459191.issue25094@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When run at part of test suite on 3.5.0 (win7)
[341/397/4] test_tools
Usage: 2to3 [options] file|dir ...

regrtest.py: error: no such option: --slaveargs
test test_tools failed -- Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1386, in parse_args
    stop = self._process_args(largs, rargs, values)
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1426, in _process_args
    self._process_long_opt(rargs, values)
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1479, in _process_long_opt
    opt = self._match_long_opt(opt)
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1464, in _match_long_opt
    return _match_abbrev(opt, self._long_opt)
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1669, in _match_abbrev
    raise BadOptionError(s)
optparse.BadOptionError: no such option: --slaveargs

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\test\test_tools\test_sundry.py", line 36, in test_sundry
    import_tool(name)
  File "C:\Programs\Python 3.5\lib\test\test_tools\__init__.py", line 22, in import_tool
    return importlib.import_module(toolname)
  File "C:\Programs\Python 3.5\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 662, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "C:\Programs\Python 3.5\Tools\scripts\2to3.py", line 5, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "C:\Programs\Python 3.5\lib\lib2to3\main.py", line 179, in main
    options, args = parser.parse_args(args)
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1388, in parse_args
    self.error(str(err))
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1568, in error
    self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
  File "C:\Programs\Python 3.5\lib\optparse.py", line 1558, in exit
    sys.exit(status)
SystemExit: 2

run by itselt (-m test test_tools)
PS C:\Users\Terry> py -3 -m test  test_tools
[1/1] test_tools
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Can't open test_tools: [Errno 2] No such file or directory: 'test_tools'
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't open test_tools: [Errno 2] No such file or directory: 'test_tools'
Warning -- logging._handlerList was modified by test_tools
test test_tools failed -- Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\test\test_tools\test_sundry.py", line 36, in test_sundry
    import_tool(name)
  File "C:\Programs\Python 3.5\lib\test\test_tools\__init__.py", line 22, in import_tool
    return importlib.import_module(toolname)
  File "C:\Programs\Python 3.5\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 662, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "C:\Programs\Python 3.5\Tools\scripts\2to3.py", line 5, in <module>
    sys.exit(main("lib2to3.fixes"))
SystemExit: 1

With 3.4.3, shorter message about multiple errors

----------
messages: 250603
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Test_tools not working on Windows.
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep 14 05:56:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 03:56:33 +0000
Subject: [New-bugs-announce] [issue25095] test_httpservers hangs on 3.5.0,
	win 7
Message-ID: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

test_httpservers ok on 3.4.3, hangs indefinitely (over an hour) on 3.5.0, win 7.

----------
components: Library (Lib), Tests, Windows
messages: 250606
nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_httpservers hangs on 3.5.0, win 7
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 06:06:25 2015
From: report at bugs.python.org (Felix Yan)
Date: Mon, 14 Sep 2015 04:06:25 +0000
Subject: [New-bugs-announce] [issue25096] test_gdb failed to read version
	for gdb >= 7.10
Message-ID: <1442203585.89.0.599357729495.issue25096@psf.upfronthosting.co.za>


New submission from Felix Yan:

The regex in test_gdb reads only one digit of gdb's minor version, which would fail for gdb >= 7.10, and skip the test as 7.1 < 7.4.

Original commit: https://hg.python.org/cpython/rev/b71cda2f48c6#l1.9

Patch attached.

----------
components: Tests
files: test_gdb-version-fix.patch
keywords: patch
messages: 250608
nosy: felixonmars
priority: normal
severity: normal
status: open
title: test_gdb failed to read version for gdb >= 7.10
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40453/test_gdb-version-fix.patch

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

From report at bugs.python.org  Mon Sep 14 06:21:07 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 04:21:07 +0000
Subject: [New-bugs-announce] [issue25097] test_logging may fail with 'Access
 is denied' when pywin32 is installed
Message-ID: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>


New submission from Zachary Ware:

With an installed Python with pywin32 installed, running the test as a non-privileged user:

======================================================================
ERROR: test_basic (test.test_logging.NTEventLogHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python34\lib\test\test_logging.py", line 4108, in test_basic
    h = logging.handlers.NTEventLogHandler('test_logging')
  File "C:\Python34\lib\logging\handlers.py", line 1011, in __init__
    self._welu.AddSourceToRegistry(appname, dllname, logtype)
  File "C:\Python34\lib\site-packages\win32\lib\win32evtlogutil.py", line 35, in AddSourceToRegistry
    "SYSTEM\\CurrentControlSet\\Services\\EventLog\\%s\\%s" % (eventLogType, appName))
pywintypes.error: (5, 'RegCreateKey', 'Access is denied.')


The test should skip in the case of 'Access is denied'.

Assumed to affect 2.7 and up, but haven't checked anything but 3.4.

----------
components: Library (Lib), Windows
keywords: easy
messages: 250610
nosy: paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging may fail with 'Access is denied' when pywin32 is installed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 14 06:23:55 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 04:23:55 +0000
Subject: [New-bugs-announce] [issue25098] test_uuid fails with pywin32
	installed
Message-ID: <1442204635.01.0.244240422269.issue25098@psf.upfronthosting.co.za>


New submission from Zachary Ware:

With installed Python with pywin32 installed:

======================================================================
ERROR: test_netbios_getnode (test.test_uuid.TestInternals)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python34\lib\test\test_uuid.py", line 479, in test_netbios_getnode
    node = uuid._netbios_getnode()
  File "C:\Python34\lib\uuid.py", line 432, in _netbios_getnode
    adapters._pack()
  File "C:\Python34\lib\site-packages\win32\lib\netbios.py", line 219, in _pack
    self._buffer_[:] = struct.pack(*(self._format,) + tuple(vals))
struct.error: argument for 's' must be a bytes object

Assumed to affect all 3.x versions, but only confirmed on 3.4.

----------
components: Library (Lib), Windows
messages: 250612
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_uuid fails with pywin32 installed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 14 06:32:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 04:32:53 +0000
Subject: [New-bugs-announce] [issue25099] test_compileall fails when run by
 unprivileged user on installed Python
Message-ID: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>


New submission from Zachary Ware:

======================================================================
FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\test\test_compileall.py", line 229, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "C:\Program Files\Python 3.5\lib\test\test_compileall.py", line 179, in assertRunOK
    *self._get_run_args(args), **env_vars)
  File "C:\Program Files\Python 3.5\lib\test\support\script_helper.py", line 135, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "C:\Program Files\Python 3.5\lib\test\support\script_helper.py", line 121, in _assert_python
    err))
AssertionError: Process return code is 1
command line: ['C:\\Program Files\\Python 3.5\\python.exe', '-X', 'faulthandler', '-S', '-m', 'compileall', '-f']

stdout:
---
(... truncated stdout ...)rror: [Errno 13] Permission denied: 'C:\\Program Files\\Python 3.5\\lib\\__pycache__\\sre_compile.cpython-35.pyc.978608563184'
Compiling 'C:\\Program Files\\Python 3.5\\lib\\sre_constants.py'...

<output continues with many more lines like the above two>

No such problem on installed 3.4.3.

----------
components: Tests, Windows
messages: 250614
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_compileall fails when run by unprivileged user on installed Python
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 06:42:47 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2015 04:42:47 +0000
Subject: [New-bugs-announce] [issue25100] Test_distutils fails instead of
	skipping if no VS2015
Message-ID: <1442205767.42.0.746068733086.issue25100@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Moved here from #12420 as a new and separate issue after diagnosis by  Mark Lawrence and Zack Ware. The following failures on new 3.5.0 all end with the same message about vcvarsall.bat (slightly different from 3.4 failures).

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_optional_extension (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_compiler_options (distutils.tests.test_msvccompiler.msvccompilerTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_vcruntime_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase)
----------------------------------------------------------------------

======================================================================
ERROR: test_vcruntime_skip_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase)
----------------------------------------------------------------------

======================================================================
FAIL: test_customize_compiler_before_get_config_vars (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\distutils\tests\test_sysconfig.py", line 197, in test_customize_compiler_before_get_c
onfig_vars
    self.assertEqual(0, p.returncode, "Subprocess failed: " + outs)
AssertionError: 0 != 1 : Subprocess failed: Traceback (most recent call last):
  File "@test_5504_tmp", line 5, in <module>
    rc = config.try_compile('int x;')
  File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 227, in try_compile
    self._compile(body, headers, include_dirs, lang)
  File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 133, in _compile
    self.compiler.compile([src], include_dirs=include_dirs)
  File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 315, in compile
    self.initialize()
  File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 208, in initialize
    vc_env = _get_vc_env(plat_spec)
  File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 83, in _get_vc_env
    raise DistutilsPlatformError("Unable to find vcvarsall.bat")
distutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat


----------------------------------------------------------------------
Ran 234 tests in 1.108s

FAILED (failures=1, errors=7, skipped=28)
Warning -- threading._dangling was modified by test_distutils
Warning -- files was modified by test_distutils

----------
components: Distutils, Tests, Windows
messages: 250620
nosy: dstufft, eric.araujo, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Test_distutils fails instead of skipping if no VS2015
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 06:54:05 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 04:54:05 +0000
Subject: [New-bugs-announce] [issue25101] test_zipfile failure when run by
 unprivileged user with installed Python
Message-ID: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za>


New submission from Zachary Ware:

======================================================================
ERROR: test_write_with_optimization (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\test\test_zipfile.py", line 771, in test_write_with_optimization
    zipfp.writepy(packagedir)
  File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1756, in writepy
    fname, arcname = self._get_codename(initname[0:-3], basename)
  File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1882, in _get_codename
    if not _compile(file_py, optimize=self._optimize):
  File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1819, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "C:\Program Files\Python 3.5\lib\py_compile.py", line 143, in compile
    importlib._bootstrap_external._write_atomic(cfile, bytecode, mode)
  File "<frozen importlib._bootstrap_external>", line 106, in _write_atomic
PermissionError: [Errno 13] Permission denied: 'C:\\Program Files\\Python 3.5\\lib\\email\\__pycache__\\__init__.cpython-35.opt-1.pyc.755404532528'

----------
components: Tests, Windows
messages: 250624
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_zipfile failure when run by unprivileged user with installed Python
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 07:01:16 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 05:01:16 +0000
Subject: [New-bugs-announce] [issue25102] Windows installer: 'precompile
 standard library' option should pre-compile with -O and -OO
Message-ID: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Since the default all-users install location is now Program Files and thus not world-writable and with the advent of optimization-tagged .pyc files, the 'precompile' option in the installer should also precompile with -O and -OO.

----------
assignee: steve.dower
components: Installation, Windows
messages: 250625
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer: 'precompile standard library' option should pre-compile with -O and -OO
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 07:33:44 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Sep 2015 05:33:44 +0000
Subject: [New-bugs-announce] [issue25103] 3.5.0 installed standard library
 on Windows has LF line endings
Message-ID: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za>


New submission from Zachary Ware:

It would be nice to install the standard library (and test suite) with CRLF line endings, to allow for reading/editing with Notepad.  Horrible though it is, it's at least always available :)

Steve, this may just be an issue of how your repository is checked out; I assume if your working directory has LF line endings, that will propagate to the installer/installed files?  The hg 'eol' extension takes care of making everything CRLF on Windows, but only if it's enabled before the working directory is created (you can force an EOL update by doing `hg up null && hg up 3.5` with 'eol' enabled).

----------
assignee: steve.dower
components: Installation, Windows
messages: 250629
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.5.0 installed standard library on Windows has LF line endings
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 07:33:52 2015
From: report at bugs.python.org (m)
Date: Mon, 14 Sep 2015 05:33:52 +0000
Subject: [New-bugs-announce] [issue25104] Wrong documentation for "chr(i)"
	function.
Message-ID: <1442208832.43.0.566078957807.issue25104@psf.upfronthosting.co.za>


New submission from m:

The documentation of the "chr(i)" function is not correct, it states that The valid range for the argument is from 0 through 1,114,111 (0x10FFFF in base 16).

Correction: The valid range for the argument is from 0 through 255 (0xFF in base 16).

----------
assignee: docs at python
components: Documentation
messages: 250630
nosy: docs at python, m
priority: normal
severity: normal
status: open
title: Wrong documentation for "chr(i)" function.
type: compile error

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

From report at bugs.python.org  Mon Sep 14 08:54:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2015 06:54:48 +0000
Subject: [New-bugs-announce] [issue25105] Docs 3.x buildbot:
Message-ID: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the changeset 34f941df3476 introduced a bug:

http://buildbot.python.org/all/builders/Docs%203.x/builds/86/steps/suspicious/logs/stdio

writing output... [ 99%] whatsnew/3.5

WARNING: [whatsnew/3.5:924] ":root" found in "'WARNING:root:warning\n'"
WARNING: [whatsnew/3.5:924] ":warning" found in "'WARNING:root:warning\n'"
WARNING: [whatsnew/3.5:1244] "::" found in ">>> addr6 = ipaddress.IPv6Address('::1')"

----------
assignee: docs at python
components: Documentation
messages: 250637
nosy: docs at python, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Docs 3.x buildbot:
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 09:29:28 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 14 Sep 2015 07:29:28 +0000
Subject: [New-bugs-announce] [issue25106] Hash computation speedup for
 {buffer, string, unicode}object
Message-ID: <1442215768.28.0.950322315319.issue25106@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 patch that improves the performance of the hash computation code on stringobject, bufferobject and unicodeobject. As can be seen from the attached sample performance results from the Grand Unified Python Benchmark, speedups up to 40% were observed. Furthermore, we see a 5-7% performance on OpenStack/Swift, where most of the code is in Python 2.7.

Attached is the patch that modifies Object/stringobject.c, Object/bufferobject.c and Object/unicodeobject.c files. We built and tested this patch for Python 2.7 on our Linux machines (CentOS 7/Ubuntu Server 14.04, Intel Xeon Haswell/Broadwell with 18/8 cores).

Steps to apply the patch:
1.  hg clone https://hg.python.org/cpython cpython 
2.  cd cpython 
3.  hg update 2.7
4.  Copy hash8.patch to the current directory 
5.  hg import --no-commit hash8.patch
6.  ./configure 
7.  make



In the following, please find our sample performance results measured on a XEON Haswell machine.  

Hardware (HW):      Intel XEON (Haswell) 18 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.0GHz by
                        echo 2000000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
                        echo 2000000 > /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

        Benchmarks          Speedup(%)
        unpack_sequence     40.32733766
        chaos               24.84002537
        chameleon           23.01392651
        silent_logging      22.27202911
        django              20.83842317
        etree_process       20.46968294
        nqueens             20.34234985
        pathlib             19.63445919
        pidigits            19.34722148
        etree_generate      19.25836634
        pybench             19.06895825
        django_v2           18.06073108
        etree_iterparse     17.3797149
        fannkuch            17.08120879
        pickle_list         16.60363602
        raytrace            16.0316265
        slowpickle          15.86611184
        pickle_dict         15.30447114
        call_simple         14.42909032
        richards            14.2949594
        simple_logging      13.6522626
        etree_parse         13.38113097
        json_dump_v2        12.26588885
        float               11.88164311
        mako                11.20606516
        spectral_norm       11.04356684
        hg_startup          10.57686164
        mako_v2             10.37912648
        slowunpickle        10.24030714
        go                  10.03567319
        meteor_contest      9.956231435
        normal_startup      9.607401586
        formatted_logging   9.601244811
        html5lib            9.082603748
        2to3                8.741557816
        html5lib_warmup     8.268150981
        nbody               7.507012306
        regex_compile       7.153922724
        bzr_startup         7.140244739
        telco               6.869411927
        slowspitfire        5.746323922
        tornado_http        5.24360121
        rietveld            3.865704876
        regex_v8            3.777622219
        hexiom2             3.586305282
        json_dump           3.477551682
        spambayes           3.183991854
        fastunpickle        2.971645347
        fastpickle          0.673086656
        regex_effbot        0.127946837
        json_load           0.023727176

Thank you,
Alecsandru

----------
components: Interpreter Core
files: hash8-v01.patch
keywords: patch
messages: 250639
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: Hash computation speedup for {buffer,string,unicode}object
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file40456/hash8-v01.patch

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

From report at bugs.python.org  Mon Sep 14 10:20:27 2015
From: report at bugs.python.org (Sergei)
Date: Mon, 14 Sep 2015 08:20:27 +0000
Subject: [New-bugs-announce] [issue25107] Windows 32-bit: exe-files doesn't
	run
Message-ID: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za>


New submission from Sergei:

Can't run IDLE or python command line on Windows XP 32-bit after installation.

----------
components: IDLE, Interpreter Core
files: Clipboard02.jpg
messages: 250641
nosy: Sergio
priority: normal
severity: normal
status: open
title: Windows 32-bit: exe-files doesn't run
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40457/Clipboard02.jpg

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

From report at bugs.python.org  Mon Sep 14 12:13:43 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Sep 2015 10:13:43 +0000
Subject: [New-bugs-announce] [issue25108] traceback.extract_stack()
	compatibility break in 3.5
Message-ID: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This can be considered a regression, although perhaps it may not be desirable to fix it in a later release.

In 3.4:

>>> def f(): return traceback.extract_stack()
... 
>>> print([x[0:3] for x in f()])
[('<stdin>', 1, '<module>'), ('<stdin>', 1, 'f')]

In 3.5:

>>> print([x[0:3] for x in f()])
[('<stdin>', 1, '<module>'), ('<stdin>', 1, 'f'), ('/home/antoine/35/lib/python3.5/traceback.py', 201, 'extract_stack')]

Note how the traceback module suddenly appears in the extracted stack. This breaks any application which uses a fixed offset into the returned stack to look up for information.

----------
components: Library (Lib)
messages: 250649
nosy: larry, ncoghlan, pitrou, rbcollins
priority: normal
severity: normal
status: open
title: traceback.extract_stack() compatibility break in 3.5
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 13:26:51 2015
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 14 Sep 2015 11:26:51 +0000
Subject: [New-bugs-announce] [issue25109] test_code_module tests fail when
 run from the installed location
Message-ID: <1442230011.36.0.482937736349.issue25109@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen when running the tests in the installed location:

the test expects:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError

but it gets:

Traceback (most recent call last):
  File "/usr/lib/python3.5/code.py", line 91, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
ValueError

same for the other failing test case.

Re-running test 'test_code_module' in verbose mode
test_banner (test.test_code_module.TestInteractiveConsole) ... ok
test_cause_tb (test.test_code_module.TestInteractiveConsole) ... FAIL
test_console_stderr (test.test_code_module.TestInteractiveConsole) ... ok
test_context_tb (test.test_code_module.TestInteractiveConsole) ... FAIL
test_ps1 (test.test_code_module.TestInteractiveConsole) ... ok
test_ps2 (test.test_code_module.TestInteractiveConsole) ... ok
test_syntax_error (test.test_code_module.TestInteractiveConsole) ... ok
test_sysexcepthook (test.test_code_module.TestInteractiveConsole) ... ok

======================================================================
FAIL: test_cause_tb (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.5/test/test_code_module.py", line 96, in test_cause_tb
    self.assertIn(expected, output)
AssertionError: '\nAttributeError\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n  File "<console>", line 1, in <module>\nValueError\n' not found in 'Python <MagicMock name=\'sys.version\' id=\'139948544843304\'> on <MagicMock name=\'sys.platform\' id=\'139948544946784\'>\nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\nAttributeError\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n  File "/usr/lib/python3.5/code.py", line 91, in runcode\n    exec(code, self.locals)\n  File "<console>", line 1, in <module>\nValueError\n\n'

======================================================================
FAIL: test_context_tb (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.5/test/test_code_module.py", line 114, in test_context_tb
    self.assertIn(expected, output)
AssertionError: '\nTraceback (most recent call last):\n  File "<console>", line 1, in <module>\nNameError: name \'ham\' is not defined\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n  File "<console>", line 2, in <module>\nNameError: name \'eggs\' is not defined\n' not found in 'Python <MagicMock name=\'sys.version\' id=\'139948132216360\'> on <MagicMock name=\'sys.platform\' id=\'139948132186544\'>\nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\nTraceback (most recent call last):\n  File "<console>", line 1, in <module>\nNameError: name \'ham\' is not defined\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n  File "/usr/lib/python3.5/code.py", line 91, in runcode\n    exec(code, self.locals)\n  File "<console>", line 2, in <module>\nNameError: name \'eggs\' is not defined\n\n'

----------
components: Tests
messages: 250655
nosy: doko
priority: normal
severity: normal
status: open
title: test_code_module tests fail when run from the installed location
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 14 16:12:47 2015
From: report at bugs.python.org (Florian Apolloner)
Date: Mon, 14 Sep 2015 14:12:47 +0000
Subject: [New-bugs-announce] [issue25110] Documentation sometimes still
	links to py3.4
Message-ID: <1442239967.4.0.711853703781.issue25110@psf.upfronthosting.co.za>


New submission from Florian Apolloner:

Compare those two URLs:
https://docs.python.org/3/whatsnew/
https://docs.python.org/3/

The first one shows version 3.4, whereas the later shows version 3.5.

----------
messages: 250667
nosy: Florian.Apolloner
priority: normal
severity: normal
status: open
title: Documentation sometimes still links to py3.4

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

From report at bugs.python.org  Mon Sep 14 19:48:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Sep 2015 17:48:43 +0000
Subject: [New-bugs-announce] [issue25111] Broken compatibility in
	FrameSummary equality
Message-ID: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since 3.5 traceback.extract_tb() and traceback.extract_stack() return a list (actually list's subclass StackSummary) of FrameSummary objects instead of a list of tuples. FrameSummary is not fully compatible with tuple. One important incompatibility is in the comparing.

>>> import traceback
>>> traceback.extract_stack()[0] == ('<stdin>', 1, '<module>', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython-3.5/Lib/traceback.py", line 254, in __eq__
    return (self.filename == other.filename and
AttributeError: 'tuple' object has no attribute 'filename'

In general __eq__ shouldn't raise an exception. Issue25108 is needed to be fixed first for tests.

Here is a patch that restores compatibility.

An alternative solution would be to make FrameSummary a subclass of tuple (namedtuple).

----------
components: Library (Lib)
messages: 250693
nosy: rbcollins, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Broken compatibility in FrameSummary equality
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 14 20:02:05 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Mon, 14 Sep 2015 18:02:05 +0000
Subject: [New-bugs-announce] [issue25112] Windows installer assigns
 non-existent icons to Python file types
Message-ID: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za>


New submission from Thijs van Dien:

Whenever the Python launcher is selected, the installer sets the icon for common Python file extensions, i.e. .py, .pyc, .pyo, .pyw, .pyz and .pyzw. Formerly (under Python 3.4) the icons were located in DLLs in the Python installation directory. The new installer assigns either py.exe,1 or py.exe,2 as the icon. Because py.exe contains just a single icon, the only valid icon index is 0. As a result of the invalid icon, all Python files show up with either blank or generic icons. Probably those icons have not been included as they should have.

Tested on Windows 7 SP1, both X86 and AMD64, both fresh a fresh install and one with quite a bit of history. It occurs with all appropriate Python 3.5 installers (pick any of X86/AMD64 and web/non-web). Make sure the Python launcher is selected; the default settings will do.

----------
components: Installation, Windows
files: Screen Shot 2015-09-14 at 20.00.50.png
messages: 250696
nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer assigns non-existent icons to Python file types
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40464/Screen Shot 2015-09-14 at 20.00.50.png

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

From report at bugs.python.org  Mon Sep 14 21:32:14 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 14 Sep 2015 19:32:14 +0000
Subject: [New-bugs-announce] [issue25113] documentation version switcher is
	broken
Message-ID: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The dropdown that allowed to switch the Python version for docs disappeared with py3.5 release.

----------
messages: 250700
nosy: eric.araujo, ezio.melotti, georg.brandl, larry, yselivanov
priority: high
severity: normal
status: open
title: documentation version switcher is broken
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 00:00:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2015 22:00:47 +0000
Subject: [New-bugs-announce] [issue25114] asynico: add ssl_object extra info
Message-ID: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds the "ssl_object" extra information to SSL sockets. For the legacy SSL implementation, it's a ssl.SSLSocket instance. For the new SSL implementation, it's a ssl.SSLObject instance.

ssl.SSLObject and ssl.SSLSocket have a similar but different API. Both classes provide important methods like getpeercert().

This issue fixes a regressions of Python 3.5 compared to Python 3.4 in asyncio SSL sockets: it's no more possible to get the peer certificate as a binary object (only as text). See the issue #22768.

My patch adds also unit tests on SSL extra info. We only had poor unit tests on these info.

----------
components: asyncio
files: ssl_object.patch
keywords: patch
messages: 250705
nosy: gvanrossum, haypo, mathieui, yselivanov
priority: normal
severity: normal
status: open
title: asynico: add ssl_object extra info
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40468/ssl_object.patch

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

From report at bugs.python.org  Tue Sep 15 03:31:16 2015
From: report at bugs.python.org (Grant Bremer)
Date: Tue, 15 Sep 2015 01:31:16 +0000
Subject: [New-bugs-announce] [issue25115] SSL_set_verify_depth not exposed
	by the ssl module
Message-ID: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za>


New submission from Grant Bremer:

The SSL_set_verify_depth OpenSSL method is not currently exposed by the ssl module. The context object would seem to be the proper place for it as an instance method.

----------
components: Library (Lib)
messages: 250718
nosy: Grant Bremer
priority: normal
severity: normal
status: open
title: SSL_set_verify_depth not exposed by the ssl module
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Tue Sep 15 05:53:43 2015
From: report at bugs.python.org (Kevin Zhang)
Date: Tue, 15 Sep 2015 03:53:43 +0000
Subject: [New-bugs-announce] [issue25116] It failed to install Py3.5 on
	win2008R2
Message-ID: <1442289223.22.0.363627873073.issue25116@psf.upfronthosting.co.za>


New submission from Kevin Zhang:

OS: Windows Server 2008 R2 Enterprise
I'm remote desktop to the server and try to install Python3.5 released version.
Remote desktop user/privilege: administrator
There is no window about installation pop up after I double clicked python-3.5.0.exe.

I could provide more info as you need.

----------
components: Installation
messages: 250719
nosy: Kevin Zhang
priority: normal
severity: normal
status: open
title: It failed to install Py3.5 on win2008R2
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 07:26:59 2015
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 15 Sep 2015 05:26:59 +0000
Subject: [New-bugs-announce] [issue25117] Windows installer: precompiling
 stdlib fails with missing DLL errors
Message-ID: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

I installed Python 3.5 on a Windows Server 2012 VM, twice (once the 32-bit, and once the 64-bit version).  When it started throwing error dialogs at me, I started taking screenshots: http://imgur.com/a/zwfz4.

What happened:
- I selected advanced installation
- checked "install for all users"
- changed the install path to c:\python35 (and c:\python35-64)
- when the installer reached "Precompiling standard library" I got the error: "Python has stopped working".
- clicking "check online for a solution" produces this explanation: "api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer".
- dismissing the error dialog leads the installer to say the installation is finished (presumably successfully); Python seems to work.

(The last dialog about VCRUNTIME140.dll is unrelated -- it's what happens if I try to use Python 3.7 to run virtualenv to create a Python 3.5 virtualenv.  I'll file a separate bug, once I figure out if it's a Python or a virtualenv bug.)

----------
components: Installation
messages: 250722
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Windows installer: precompiling stdlib fails with missing DLL errors
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 07:52:11 2015
From: report at bugs.python.org (Rocco Matano)
Date: Tue, 15 Sep 2015 05:52:11 +0000
Subject: [New-bugs-announce] [issue25118] OSError in os.waitpid
Message-ID: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za>


New submission from Rocco Matano:

On windows and python up to 3.4 using the combination of os.spawnX(os.P_NOWAIT, ...) and os.waitpid() worked as expected, but with python 3.5 this no longer works. In fact os.waitpid() now raises an OSError when the child process terminates.
Running this simple script demonstrates that:

import sys
import os
import time

print(sys.version)

file = r'c:\windows\system32\cmd.exe'
args = [file, '/C', 'ping', '1.1.1.1', '-n', '1', '>NUL']
env = os.environ

t0 = time.time()
ret = os.spawnve(os.P_NOWAIT, file, args, env)
pid, status = os.waitpid(ret, 0)
t1 = time.time()
print("process took %.1f seconds" % (t1 - t0))

I get the following outputs:

C:\Users\rmatano\test_py35>py -3.4 test_waitpid.py
3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)]
process took 3.6 seconds

C:\Users\rmatano\test_py35>py -3.5 test_waitpid.py
3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)]
Traceback (most recent call last):
  File "twp.py", line 13, in <module>
    pid, status = os.waitpid(ret, 0)
OSError: [Errno 0] Error

I guess this is a bug rather than a intended change in behavior, isn't it?

----------
components: Library (Lib)
messages: 250723
nosy: rocco.matano
priority: normal
severity: normal
status: open
title: OSError in os.waitpid
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 10:10:15 2015
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 15 Sep 2015 08:10:15 +0000
Subject: [New-bugs-announce] [issue25119] Windows installer fails to install
	VCRUNTIME140.DLL
Message-ID: <1442304615.44.0.515104060995.issue25119@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

1. Install Python 3.5 using the official Windows installer
2. Get a shell
3. python -m ensurepip (because the installer didn't install pip for me -- is that another bug?  I thought the installer was supposed to run ensurepip for me?  Is it fallout from bug 25117?)
4. python -m pip install virtualenv (gets me version 13.1.2)
5. python -m virtualenv env

I expect: a virtualenv in ./env

I get: a GUI error dialog saying "The program can't start because VCRUNTIME140.dll is missing from your computer."

----------
components: Installation
messages: 250733
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Windows installer fails to install VCRUNTIME140.DLL
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 10:13:10 2015
From: report at bugs.python.org (Djoudi Benarfa)
Date: Tue, 15 Sep 2015 08:13:10 +0000
Subject: [New-bugs-announce] [issue25120] Python want
Message-ID: <1442304790.82.0.947550272031.issue25120@psf.upfronthosting.co.za>


Changes by Djoudi Benarfa <dbenarfa at gmail.com>:


----------
components: Installation
files: py-install-xp.bmp
nosy: djoudi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python want
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40472/py-install-xp.bmp

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

From report at bugs.python.org  Tue Sep 15 10:57:34 2015
From: report at bugs.python.org (Alexander Belchenko)
Date: Tue, 15 Sep 2015 08:57:34 +0000
Subject: [New-bugs-announce] [issue25121] python logger can't wrap log file
 and blows with traceback
Message-ID: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za>


New submission from Alexander Belchenko:

We're using standard logging library for logs. On machine of my colleague there is constantly traceback like this:

[11:21:29] <altuhkov> PermissionError: [WinError 32] The process cannot access the file because it is
being used by another process: 'C:\\Users\\Andrew\\Desktop\\server\\logs\\2015-0
9-09_10-44-03\\2015-09-09_10-44-04-middleman-684.log.1'
Logged from file middleman.py, line 379
Traceback (most recent call last):
  File "c:\python33\lib\logging\handlers.py", line 73, in emit
    self.doRollover()
  File "c:\python33\lib\logging\handlers.py", line 176, in doRollover
    self.rotate(self.baseFilename, dfn)
  File "c:\python33\lib\logging\handlers.py", line 116, in rotate
    os.rename(source, dest)

middleman.py, line 379 is simple call to logger.debug:

    self.logger.debug('node %s is already processing, packet %s postponed', node_id, packet_no) 

It's strange that another log file with different basename in the same logs directory is wrapping without problems.

Anyway, my complain is about traceback. I don't think it's good behavior that my application crashes because logging library can't wrap file. The problem for me - I have no idea how to catch and ignore such problem, because it's in the logging internals.

----------
components: Library (Lib), Windows
messages: 250747
nosy: bialix, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python logger can't wrap log file and blows with traceback
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Sep 15 12:09:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Sep 2015 10:09:39 +0000
Subject: [New-bugs-announce] [issue25122] test_eintr randomly fails on
	FreeBSD
Message-ID: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I'm unable to reproduce the hang. It's probably a race condition since sometimes the test pass. It may depend on the system load, the number of CPU cores, and other factors.

I tried to use faulthandler.dump_traceback_later() in the changeset ebccac60b9e7, but it didn't print the traceback of the blocked test. So I don't know which eintr test is blocked.

In the changeset ed0e6a9c11af, I rewrote test_eintr.py to use subprocess instead of os.fork(). I was supposed to reduce the risk of race condition, but the hang still occurs.

On FreeBSD, I know that any thread can receive a signal, and most Python tests only expect that the signal is received from a specific thread. But test_eintr.py runs Lib/test/eintrdata/eintr_tester.py in a subprocess to avoid threads, and Lib/test/eintrdata/eintr_tester.py itself uses subprocess to spawn child processes, so it should also avoid threads. So I don't think that the issue is related to threads.

At least, it would help to know which test hangs.

Example:

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

[398/398] test_eintr
Timeout (1:00:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/selectors.py", line 375 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1698 in _communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1068 in communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 86 in run_python_until_end
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 96 in _assert_python
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 135 in assert_python_ok
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_eintr.py", line 17 in test_all
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1280 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1281 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 968 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 532 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1565 in main_in_temp_cwd
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1590 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1565, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_eintr: Exit code 1
*** [buildbottest] Error code 1

----------
messages: 250753
nosy: haypo
priority: normal
severity: normal
status: open
title: test_eintr randomly fails on FreeBSD
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 15 12:28:32 2015
From: report at bugs.python.org (Robin)
Date: Tue, 15 Sep 2015 10:28:32 +0000
Subject: [New-bugs-announce] [issue25123] Logging Documentation - dictConfig
 disable_existing_loggers
Message-ID: <1442312912.97.0.962237041326.issue25123@psf.upfronthosting.co.za>


New submission from Robin:

logging.config.dictConfig appears to share the same parameter as logging.config.fileConfig - disable_existing_loggers.

This parameter is documented for fileConfig but not dictConfig.

Suggest update to dictConfig documentation section.

----------
assignee: docs at python
components: Documentation
messages: 250755
nosy: coderobot, docs at python
priority: normal
severity: normal
status: open
title: Logging Documentation - dictConfig disable_existing_loggers
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 15 13:09:25 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Tue, 15 Sep 2015 11:09:25 +0000
Subject: [New-bugs-announce] [issue25124] No single .msi available for 3.5
	release
Message-ID: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

The item "A new installer for Windows has replaced the old MSI" appears on the "What's new" page as an "improvement". It is not. I disagree strongly with the decision to abandon MSI packages for Windows distribution in 3.5. This decision should be reversed immediately, if not sooner.

The .msi package format was introduced well over ten years ago. Since that day, there has been *no* excuse at all to distribute software for Windows in any other form (except "a simple ZIP will do").

The MSI file format's main advantage over ad-hoc executable installers or wrappers is in automated installation. There are several ways to deploy software in a corporate network, such as SCCM/SMS and GPO. While the former can deal with .exe packages, using MSIs is much simpler. In an MSI, the Feature table offers clear information about how to install only part of a product (ADDLOCAL=x,y,z either works as intended or fails cleanly). An .exe wrapper does not provide this information in an obvious way, instead, the user has to rely on external documentation to discover the installable features.

Python's Windows packages have been exemplary for years. This change needlessly gives up this reputation.

As far as the Universal CRT is concerned, for which there are no redist MSIs available, it should be clear that Python is not responsible for installing it, as it is a system component now. If ucrtbase.dll/KB2999226 is not present on the target system, the Python installation should simply abort and inform the user about the missing prerequisite.

(Also, as Microsoft is pushing it into the market at seemingly any cost, the market share of Windows 10 with included UCRT is likely to increase quickly, making the wrapper ever more unnecessary. Servers are, of course, another story.)

Finally, just in case there were any plans on display for the last several months: I do not usually venture into basements to check for leopards. Python's Windows packaging was perfectly fine, and there was no reason to assume that this would change, rather the opposite, in fact.

----------
components: Installation
messages: 250756
nosy: Christian.Ullrich
priority: normal
severity: normal
status: open
title: No single .msi available for 3.5 release
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 13:59:30 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Tue, 15 Sep 2015 11:59:30 +0000
Subject: [New-bugs-announce] [issue25125] "Edit with IDLE" does not work for
	shortcuts
Message-ID: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>


New submission from Thijs van Dien:

Right clicking a Python file shows "Edit with IDLE" in the context menu, then offering a next menu where one can choose which particular version of IDLE should be used. This works fine. Whenever a shortcut is created to a Python file, the same context menu is shown, but clicking for example "Edit with IDLE 3.5 (32-bit)" does not seem to do anything. This is probably related to a change in the command used to launch IDLE with the file to be edited.

Tested on a fresh install of Windows 7 SP1 X86 and AMD64, with Python 3.5.0 X86.

----------
components: IDLE, Installation, Windows
messages: 250759
nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: "Edit with IDLE" does not work for shortcuts
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 14:28:20 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Tue, 15 Sep 2015 12:28:20 +0000
Subject: [New-bugs-announce] [issue25126] Non-web installer fails without a
 connection when doing debug install
Message-ID: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za>


New submission from Thijs van Dien:

Python 3.5.0 offers a web installer. This implies that the other installer works offline. This is the case for the default component selection. When debug symbols/binaries are selected, the setup fails with error code 0x80070642 saying the user aborted the installation. This is a severe usability issue. Either everything should be included, or, if that makes the installer too big, "Install debugging symbols" should be "Download and install debugging symbols" - likewise "Install debug binaries" should be "Download and install debug binaries." When downloading fails, the failure message should mention that, rather than blaming the user for something they haven't done.

Tested under Windows 7 SP1 X86 with the X86 non-web installer of Python 3.5.0.

----------
components: Installation, Windows
messages: 250763
nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Non-web installer fails without a connection when doing debug install
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 16:47:12 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 15 Sep 2015 14:47:12 +0000
Subject: [New-bugs-announce] [issue25127] typo in
	concurrent.futures.Executor.shutdown() example
Message-ID: <1442328432.29.0.90090219234.issue25127@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

Typo in the example code in <https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.shutdown>:
in the last line, it should be "src4.txt", not "src3.txt".

----------
assignee: docs at python
components: Documentation
messages: 250774
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: typo in concurrent.futures.Executor.shutdown() example

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

From report at bugs.python.org  Tue Sep 15 17:11:40 2015
From: report at bugs.python.org (yavvsy)
Date: Tue, 15 Sep 2015 15:11:40 +0000
Subject: [New-bugs-announce] [issue25128]
 https://docs.python.org/3/download.html incorrect links to files (cannot
 download)
Message-ID: <1442329900.03.0.985918373135.issue25128@psf.upfronthosting.co.za>


New submission from yavvsy:

When clicking on a download link in:
https://docs.python.org/3/download.html
The links point to files that don't exist (older document version)

For example:
https://docs.python.org/ftp/python/doc/3.5.0/python-3.5.0-docs-pdf-letter.zip
should be instead:
https://docs.python.org/ftp/python/doc/3.5.0/python-3.5.0a3-docs-pdf-letter.zip

----------
assignee: docs at python
components: Documentation
messages: 250777
nosy: docs at python, yavvsy
priority: normal
severity: normal
status: open
title: https://docs.python.org/3/download.html incorrect links to files (cannot download)
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 15 19:28:03 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Sep 2015 17:28:03 +0000
Subject: [New-bugs-announce] [issue25129] suboptimal floating-point floor
	division
Message-ID: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> (78*6e-8) / 6e-8
78.0
>>> (78*6e-8) // 6e-8
77.0

Note this doesn't make divmod() wrong:

>>> q, r = divmod(78*6e-8, 6e-8)
>>> q, r
(77.0, 5.999999999999965e-08)
>>> r < 6e-8
True
>>> q * 6e-8 + r == 78*6e-8
True

But, still, it is somewhat of an oddity to not return the real quotient when it is an exact integer.

Note this came from a Numpy issue where Numpy actually shows better behaviour:
https://github.com/numpy/numpy/issues/6127

----------
components: Interpreter Core
messages: 250786
nosy: mark.dickinson, pitrou, tim.peters
priority: normal
severity: normal
status: open
title: suboptimal floating-point floor division
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 15 20:15:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Sep 2015 18:15:24 +0000
Subject: [New-bugs-announce] [issue25130] Make tests more PyPy compatible
Message-ID: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyPy includes modified Python 2.7 tests for testing compatibility. Some of changes skips tests for features that are not implemented in PyPy or are CPython specific, some reflects differences between error types or messages in CPython and PyPy, some are needed because PyPy doesn't use reference counting, some are workarounds for known PyPy or CPython bugs. The purpose of this issue is to port harmless non PyPy-specific changes. I'll split full patch on several parts for easier review.

The first patch in a series just adds gc.collect() or test.test_support.gc_collect() calls to force calling destructors or freeing memory.

----------
assignee: serhiy.storchaka
components: Tests
files: pypy_tests_gc_collect-2.7.patch
keywords: patch
messages: 250789
nosy: benjamin.peterson, fijall, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Make tests more PyPy compatible
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40475/pypy_tests_gc_collect-2.7.patch

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

From report at bugs.python.org  Tue Sep 15 20:28:25 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Tue, 15 Sep 2015 18:28:25 +0000
Subject: [New-bugs-announce] [issue25131] The AST for dict and set displays
 has the lineno of the first value
Message-ID: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi,

In Python 3.5, the lineno for dict and set display ASTs is the line number of the first value, not the line number of the display character, as it was until 3.5. Here's an example:


  from ast import parse
  module = parse('''{
           '1':'2',
  }
  ''')
  dict_display = module.body[0].value
  print(dict_display.lineno)

I don't seem to find anything related to this in the documentation, but I presume this is a side effect of the new parser changes. It would nice to have this fixed or at least documented.

----------
components: Library (Lib)
messages: 250790
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: The AST for dict and set displays has the lineno of the first value
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 15 20:33:18 2015
From: report at bugs.python.org (siva)
Date: Tue, 15 Sep 2015 18:33:18 +0000
Subject: [New-bugs-announce] [issue25132] unable to install
	mongo-python-driver-3.0.3 driver
Message-ID: <1442341998.85.0.950034440583.issue25132@psf.upfronthosting.co.za>


New submission from siva:

Hi There, I am using Python 2.7.10. When I am trying to install mongo-python-driver-3.0.3 driver it's showing an error. Here, I am attaching the screenshot taken from my machine.
Thanks in advance for you quick help.

[root at localhost mongo-python-driver-3.0.3]# whereis python
python: /usr/bin/python /usr/bin/python2.4 /usr/lib/python2.4 /usr/local/bin/python2.7-config /usr/local/bin/python2.7 /usr/local/bin/python /usr/local/lib/python2.7 /usr/include/python2.4 /usr/share/man/man1/python.1.gz
[root at localhost mongo-python-driver-3.0.3]# which python
/usr/local/bin/python
[root at localhost mongo-python-driver-3.0.3]# python -V
Python 2.7.10
[root at localhost mongo-python-driver-3.0.3]# pwd
/root/mongo-python-driver-3.0.3
[root at localhost mongo-python-driver-3.0.3]# ls
bson  CONTRIBUTING.rst  doc  ez_setup.py  green_framework_test.py  gridfs  LICENSE  MANIFEST.in  pymongo  README.rst  RELEASE.rst  setup.py  test  tools  tox.ini
[root at localhost mongo-python-driver-3.0.3]# python setup.py install
Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz
Traceback (most recent call last):
  File "setup.py", line 20, in <module>
    use_setuptools()
  File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 132, in use_setuptools
    return _do_download(version, download_base, to_dir, download_delay)
  File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 110, in _do_download
    to_dir, download_delay)
  File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 290, in download_setuptools
    downloader(url, saveto)
  File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 215, in download_file_wget
    _clean_check(cmd, target)
  File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 160, in _clean_check
    subprocess.check_call(cmd)
  File "/usr/local/lib/python2.7/subprocess.py", line 540, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['wget', 'https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz', '--quiet', '--output-document', '/root/mongo-python-driver-3.0.3/setuptools-1.4.2.tar.gz']' returned non-zero exit status 1

----------
components: Installation
messages: 250791
nosy: siva
priority: normal
severity: normal
status: open
title: unable to install mongo-python-driver-3.0.3 driver
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 15 20:34:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Sep 2015 18:34:44 +0000
Subject: [New-bugs-announce] [issue25133] Clarify that the constants in
	selectors are module-level
Message-ID: <1442342084.77.0.0114888594817.issue25133@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you read the docs for the selectors module it isn't obvious that the constants EVENT_WRITE and EVENT_READ are module-level and not on the various classes since they are in the Classes section of the doc. Shouldn't require any more than adding the word "module" to "the constants below".

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 250792
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Clarify that the constants in selectors are module-level
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 15 22:35:42 2015
From: report at bugs.python.org (Bar Harel)
Date: Tue, 15 Sep 2015 20:35:42 +0000
Subject: [New-bugs-announce] [issue25134] SSL asyncio
Message-ID: <1442349342.4.0.267068744355.issue25134@psf.upfronthosting.co.za>


New submission from Bar Harel:

Seems like at https://docs.python.org/3.5/library/asyncio-eventloop.html#creating-connections (Creating connections) in asyncio, it states that "On Windows with ProactorEventLoop, SSL/TLS is not supported."
But on the ProactorEventLoop it states that SSL support was added in 3.5
Please remove the "unsupported" statement in the docs of 3.5 and 3.6
p.s. Is there a way I can fix these errors myself instead of hassling other people?

----------
assignee: docs at python
components: Documentation
messages: 250803
nosy: Bar Harel, docs at python
priority: normal
severity: normal
status: open
title: SSL asyncio
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep 16 01:12:56 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Sep 2015 23:12:56 +0000
Subject: [New-bugs-announce] [issue25135] Deques to adopt the standard
 clearing procedure for mutable objects
Message-ID: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The clear method for deques is possibly reentrant.  Use the safer technique used in listobject.c, setobject.c, and dictobject.c.

----------
assignee: rhettinger
components: Extension Modules
messages: 250811
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Deques to adopt the standard clearing procedure for mutable objects
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 16 03:03:03 2015
From: report at bugs.python.org (Tim Smith)
Date: Wed, 16 Sep 2015 01:03:03 +0000
Subject: [New-bugs-announce] [issue25136] Python doesn't find Xcode 7 stub
	libraries
Message-ID: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za>


New submission from Tim Smith:

In Xcode 7, Apple is replacing many of the .dylibs in SDKROOT with textual stubs. [1] These files exist on disk with filenames like:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.tbd

They are short YAML documents that look like this: [2]

The same linker invocation that has always worked will continue to work with Xcode 7 (i.e. you still pass `-lz` to the linker), but this disrupts the checks that cpython's setup.py uses to determine if it can build extension modules. The dylibs physically exist on disk in /usr/lib, but since we've set -isysroot to the appropriate SDKROOT in CPPFLAGS, distutils searches for the dylibs in the sysroot path, and does not find them (since they have been replaced with .tbd stubs). Since distutils cannot find the libraries, setup.py declines to attempt to build any of the extension modules that depend on libraries in the OS X SDK, even though it would have succeeded if it had tried. Several Homebrew users have reported this while trialling Xcode 7 [3].

distutils should treat the .tbd files as a "real" library so that compiler.find_library_file succeeds and setup.py will proceed to attempt to build the extension modules.

The attached diff applies against the 3.5.0 release and allows extension modules to be built against Xcode 7 without installing the Command-Line Tools package.

If anyone is experiencing this issue, a workaround is to install the Xcode Command Line Tools package with `xcode-select --install` (which, among other things, installs headers to /usr/include), ensure the CLT is active with `xcode-select -s /Library/Developer/CommandLineTools`, and do not include `-isysroot` in CPPFLAGS when building python.

[1]: https://forums.developer.apple.com/thread/4572
[2]: https://gist.github.com/474233e561e28e1a8866
[3]: https://github.com/Homebrew/homebrew/issues/41085

----------
components: Build, Distutils, Macintosh
files: xcode-stubs.diff
keywords: patch
messages: 250813
nosy: dstufft, eric.araujo, ned.deily, ronaldoussoren, tdsmith
priority: normal
severity: normal
status: open
title: Python doesn't find Xcode 7 stub libraries
type: compile error
Added file: http://bugs.python.org/file40478/xcode-stubs.diff

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

From report at bugs.python.org  Wed Sep 16 03:36:32 2015
From: report at bugs.python.org (Markus Holtermann)
Date: Wed, 16 Sep 2015 01:36:32 +0000
Subject: [New-bugs-announce] [issue25137] Behavioral change / regression?
 with nested functools.partial
Message-ID: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za>


New submission from Markus Holtermann:

Since #7830 nested partials are flattened. This is a behavioral change that causes a test failure in Django because we use nested partials to resolve relationships between models: https://github.com/django/django/pull/4423#issuecomment-138996095

In my opinion this is a regression since there's no way to turn off the new behavior.

----------
components: Library (Lib)
messages: 250814
nosy: MarkusH, belopolsky
priority: normal
severity: normal
status: open
title: Behavioral change / regression? with nested functools.partial
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 16 08:52:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Sep 2015 06:52:45 +0000
Subject: [New-bugs-announce] [issue25138] test_socket: socket.EAI_NODATA
	doesn't exist on FreeBSD
Message-ID: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_socket.test_idna() uses socket.EAI_NODATA constant which doesn't exists on FreeBSD.

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

======================================================================
ERROR: test_idna (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1294, in test_idna
    socket.gethostbyname('python.org')
socket.gaierror: [Errno 8] hostname nor servname provided, or not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1296, in test_idna
    if e.errno == socket.EAI_NODATA:
AttributeError: module 'socket' has no attribute 'EAI_NODATA'

----------
components: Tests
messages: 250817
nosy: haypo
priority: normal
severity: normal
status: open
title: test_socket: socket.EAI_NODATA doesn't exist on FreeBSD
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep 16 11:26:03 2015
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lkg0KHQvNC40YDQvdC+0LI=?=)
Date: Wed, 16 Sep 2015 09:26:03 +0000
Subject: [New-bugs-announce] [issue25139] Just a little refactoring
Message-ID: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za>


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

https://github.com/python/cpython/blob/3.5/Lib/socketserver.py#L627
Must be:
try:
    self.finish_request(request, client_address)
except:
    self.handle_error(request, client_address)
finally:
    self.shutdown_request(request)

----------
components: Library (Lib)
hgrepos: 317
messages: 250833
nosy: ??????? ???????
priority: normal
severity: normal
status: open
title: Just a little refactoring
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 16 12:59:18 2015
From: report at bugs.python.org (Andrey Fedyashov)
Date: Wed, 16 Sep 2015 10:59:18 +0000
Subject: [New-bugs-announce] [issue25140] platform.platform() incorrectly
 identifies Windows 10 as 'Windows-8-6.2.9200'
Message-ID: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za>


New submission from Andrey Fedyashov:

Here's actual OS version:
OS Name:                   Microsoft Windows 10 Enterprise Insider Preview
OS Version:                10.0.10534 N/A Build 10534
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free

Here is bug repro with Python 3.4

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.platform()
'Windows-8-6.2.9200'

Here is bug repro with Python 2.7

Python 2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.platform()
'Windows-8-6.2.9200'

----------
components: Library (Lib), Windows
messages: 250837
nosy: Andrey Fedyashov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200'
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Sep 16 16:48:47 2015
From: report at bugs.python.org (Sebastian Kreft)
Date: Wed, 16 Sep 2015 14:48:47 +0000
Subject: [New-bugs-announce] [issue25142] Misleading error when initing
	ImportError
Message-ID: <1442414927.94.0.928583151354.issue25142@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

ImportError now supports the keyword arguments name and path. However, when passing invalid keyword arguments, the reported error is misleading, as shown below.

In [1]: ImportError('lib', name='lib')
Out[1]: ImportError('lib')

In [2]: ImportError('lib', name='lib', foo='foo')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-5af12651187f> in <module>()
----> 1 ImportError('lib', name='lib', foo='foo')

TypeError: ImportError does not take keyword arguments

----------
messages: 250850
nosy: Sebastian Kreft
priority: normal
severity: normal
status: open
title: Misleading error when initing ImportError
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep 16 18:18:06 2015
From: report at bugs.python.org (Paul)
Date: Wed, 16 Sep 2015 16:18:06 +0000
Subject: [New-bugs-announce] [issue25143] 3.5 install fails poorly on
	Windows XP
Message-ID: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za>


New submission from Paul:

Running the installer on an unsupported system (such as Windows XP)should fail gracefully and not just leave the user hanging.

https://mail.python.org/pipermail/python-list/2015-September/696789.html

----------
components: Installation
messages: 250852
nosy: pwatson at phs.org
priority: normal
severity: normal
status: open
title: 3.5 install fails poorly on Windows XP
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 16 19:35:32 2015
From: report at bugs.python.org (Felipe)
Date: Wed, 16 Sep 2015 17:35:32 +0000
Subject: [New-bugs-announce] [issue25144] 3.5 Win install fails with
	"TARGETDIR"
Message-ID: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za>


New submission from Felipe:

The 3.5 Windows installer fails with "The TARGETDIR variable must be provided when invoking this installer"

Here are the steps I followed:

1. Initial screen:

   - uncheck the add path and all users options
   - select "Customize installation"

2. Optional features:

   - Check all boxes except "all users"

3. Advanced options

   - Uncheck all
   - Pick a different path to install to (clean folder)


4. A message box pops up saying "The TARGETDIR variable must be provided when invoking this installer" -- I hit OK.

5. Final screen showing 0x8007063 - Fatal error during installation


I've saved the log file and can upload if helpful, but will have to remove personal info first

----------
components: Installation
messages: 250857
nosy: fov
priority: normal
severity: normal
status: open
title: 3.5 Win install fails with "TARGETDIR"
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 16 23:32:38 2015
From: report at bugs.python.org (Robert Xiao)
Date: Wed, 16 Sep 2015 21:32:38 +0000
Subject: [New-bugs-announce] [issue25145] urllib how-to should be updated to
	remove PyGoogle
Message-ID: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za>


New submission from Robert Xiao:

PyGoogle has been dead for 6-7 years at this point (probably longer), yet the newest urllib documentation (https://docs.python.org/3/howto/urllib2.html#id1) still refers to it in a footnote:

    [1] Like Google for example. The proper way to use google from a program is to use PyGoogle of course.

This should probably be amended to remove the outdated reference altogether (the footnote itself can probably just go).

While we're at it: the user agent version strings are _really_ old - MSIE 5.5 and MSIE 6.0. I know they are just illustrative, but couldn't we at least update them to something from the last decade? :P

----------
assignee: docs at python
components: Documentation
messages: 250863
nosy: docs at python, nneonneo
priority: normal
severity: normal
status: open
title: urllib how-to should be updated to remove PyGoogle
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/issue25145>
_______________________________________

From report at bugs.python.org  Wed Sep 16 23:50:21 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 16 Sep 2015 21:50:21 +0000
Subject: [New-bugs-announce] [issue25146] IDLE debugger could better
	visualize program execution
Message-ID: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za>


New submission from Mark Roseman:

(This touches a bit on things mentioned in #14111)

I'm looking through the debugger code in IDLE, and now understand that it's essentially trying to make a GUI program act like a command line program. Hence the nested call to mainloop(), when we receive a trace execution callback. This is the equivalent of saying "stop here until I input something, and then continue along" at which point the callback completes and we return to the running program.

Right now, if you run a program with the debugger on, and just hit Go, it's just like you're not running it in the debugger at all.

I've mentioned elsewhere (#15347) that I suspect the nested mainloop is behind some of the instability problems related to quitting when the debugger is active.

But if we don't assume that each time we print where we are we have to wait for input, we can do some more interesting things. Most importantly, we should be able to say "Go", and actually watch our program being executed. In other words, whenever it goes to the next statement, the debugger actually shows that statement, highlights the line in the source file, updates variables, etc. -- all without user interaction. 

Someone can sit back and watch, getting a better understanding of what their program is doing while running. You'd be able to see if a program was stuck in a loop, without necessarily going through it one statement at a time, step by step, or setting breakpoints. 

It also makes it clearer that the program is running because you see something happening... now there's not great feedback in that regard. Similarly, some of the issues with pausing/continuing or stopping the program become a bit easier to deal with.

----------
components: IDLE
messages: 250864
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE debugger could better visualize program execution
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 17 09:18:27 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 17 Sep 2015 07:18:27 +0000
Subject: [New-bugs-announce] [issue25147] Enum: remove dependency on
	OrderedDict
Message-ID: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Pulling in collections.OrderedDict has a significant startup cost (from what I've heard, and can easily believe by glancing at all the imports in collections.__init__).

By keeping a separate list for the Enum member names using Enum in the stdlib becomes more attractive.

----------
assignee: ethan.furman
messages: 250875
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: Enum: remove dependency on OrderedDict
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 17 11:12:31 2015
From: report at bugs.python.org (Barry Scott)
Date: Thu, 17 Sep 2015 09:12:31 +0000
Subject: [New-bugs-announce] [issue25148] Windows registry PythonCore key
 changed inconsistent with other releases
Message-ID: <1442481151.22.0.29783958187.issue25148@psf.upfronthosting.co.za>


New submission from Barry Scott:

I am used to looking in HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
to find out where python is installed so that my installation kit can add itself to site-packages.

I just found that the registry key used for 32 bit python 3.5 on windows changed to be '3.5-32',
which I can change my installer to cope with.

However the key for the 64bit install is ?3.5? but not '3.5-64'.

This seems like a regression to me in the interface to Python on Windows.

Is there a reason not to use the original naming?

Barry

----------
components: Installation
messages: 250877
nosy: barry.scott
priority: normal
severity: normal
status: open
title: Windows registry PythonCore key changed inconsistent with other releases
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 17 14:16:58 2015
From: report at bugs.python.org (AndreC)
Date: Thu, 17 Sep 2015 12:16:58 +0000
Subject: [New-bugs-announce] [issue25149] datetime.weekday() off by one if
 handling a date from utcfromtimestamp()
Message-ID: <1442492218.93.0.0814077677929.issue25149@psf.upfronthosting.co.za>


New submission from AndreC:

I've stumbled over an odd datetime.weekday() behaviour in Python 2.7.8 (default, Jun 18 2015, 18:54:19)  [GCC 4.9.1] on linux2) under Ubuntu. weekday() is off by 1.

Code to reproduce:

from datetime import datetime
date = datetime.utcfromtimestamp(int('1410446564'))  # datetime.datetime(2014, 9, 11, 14, 42, 44)
date.weekday()  # should be 4, not 3

I can reproduce this behaviour on our dev and production systems, and just tested it locally with python 3.4.3.

Since I'm not a smart man, I might overlook something silly...

----------
components: Library (Lib)
messages: 250881
nosy: odianus
priority: normal
severity: normal
status: open
title: datetime.weekday() off by one if handling a date from utcfromtimestamp()
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Sep 17 14:58:59 2015
From: report at bugs.python.org (Alexander Heger)
Date: Thu, 17 Sep 2015 12:58:59 +0000
Subject: [New-bugs-announce] [issue25150] yt package pip compile/install
	error
Message-ID: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za>


New submission from Alexander Heger:

trying to install the yt package, most recent version 3.2.1 on python 3.5.0 using pip

pip3 install -U yt

error output attached.  The same package installs fine with python 3.4.3, same compiler and also build from scratch, so the suspicion is that it is related to the new 3.5.0 version.  The system installed is the current Fedora 22, gcc 5.1.1-4.

----------
components: Extension Modules
files: error.txt
hgrepos: 318
messages: 250884
nosy: axh
priority: normal
severity: normal
status: open
title: yt package pip compile/install error
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file40491/error.txt

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

From report at bugs.python.org  Thu Sep 17 15:55:40 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 17 Sep 2015 13:55:40 +0000
Subject: [New-bugs-announce] [issue25151] venv does not work with debian
 releases, if you want to install pip
Message-ID: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za>


New submission from Laura Creighton:

I am reporting this here so that the next person who runs into this and looks into the bug tracker will find out what to do.

You cannot create a venv with Python3.3, 3.4, 3.5. on debian (and likely
on many debian-derived distros). 

 Instead you get Error: Command '['<directory>/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 
1

Debian knows all about this, but they don't want to make changes.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703

Instead, if you want venv to work you will need to install the debian packages python3-venv (for 3.4) and python3.5-venv for 3.5.

Can somebody close this issue now, as this is clearly a debian issue and not a Python bug.  I am just reporting it here so that somebody else who has the problem can find out what to do.

----------
components: Distutils
messages: 250887
nosy: dstufft, eric.araujo, lac
priority: normal
severity: normal
status: open
title: venv does not work with debian releases, if you want to install pip
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 17 16:13:32 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 17 Sep 2015 14:13:32 +0000
Subject: [New-bugs-announce] [issue25152] venv documentation doesn't tell
 you how to specify a particular version of python
Message-ID: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za>


New submission from Laura Creighton:

https://docs.python.org/3/library/venv.html nowhere explicitly states
how you are supposed to get a venv with a particular python version.
Users of virtualenv will be looking for a -p option.

The doc says:

"Creation of virtual environments is done by executing the pyvenv script:"

which undoubtably works if you _have_ a pyenv script, but I don't have
one.  It is nowhere stated where I should find one.

Fortunately, I can also run things as

some_python_version -m venv myvenv 

This, everybody is able to do.  (However, it may not work, see
issue 25151 --  but forget that for now.)

This is something that everybody ought to be able to do.
Thus I propose either deleting the mention of pyenv, (if it is exactly
equivalent to running python -m venv)  or expanding
the section, indicating where the script lives, and why you might
want to run it instead of python -m venv.

Then, before the line:
The command, if run with -h, will show the available options:

add the line:

The version of python used in the venv is determined at this time.
If the default version of python is not the one desired, use:

/path/to/the/python/I/want -m venv  myenv instead.

(Plus, if there is a way to do this with pyenv, then list that
part here).

----------
assignee: docs at python
components: Distutils, Documentation
messages: 250891
nosy: docs at python, dstufft, eric.araujo, lac
priority: normal
severity: normal
status: open
title: venv documentation doesn't tell you how to specify a particular version of python
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 17 17:46:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 17 Sep 2015 15:46:15 +0000
Subject: [New-bugs-announce] [issue25153] PCbuild/*.vcxproj* should use CRLF
	line endings
Message-ID: <1442504775.33.0.605516301888.issue25153@psf.upfronthosting.co.za>


New submission from Zachary Ware:

PCbuild/*.vcxproj* should be added to .hgeol to force them to CRLF.

A couple of reasons:

1) They're only used on Windows, where the default (terrible, but always available) editor doesn't understand LF

2) More importantly, the tcl, tk, and tix projects use labels in the NMakeCommandLine script, which can fail confusingly when that script has LF line endings (the error is "The system cannot find the batch label specified - build")

Thanks to Andres Guzman-ballen for bringing this to my attention again. I have also seen this on my Windows 8.1 Non-Debug buildbot, where I worked around it by turning on the hg 'eol' extension so that everything would be converted to CRLF on checkout.

----------
assignee: zach.ware
components: Build, Windows
messages: 250893
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PCbuild/*.vcxproj* should use CRLF line endings
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 17 20:35:21 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Sep 2015 18:35:21 +0000
Subject: [New-bugs-announce] [issue25154] Drop the pyvenv script
Message-ID: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I propose that the pyvenv script be deprecated in Python 3.5 and removed in Python 3.8. The reason for this proposal is because it is non-obvious what version of Python a pyvenv command is tied to (heck, it isn't necessarily obvious that it's Python 3). There would be no loss in functionality since the exact same functionality is available through `python3 -m venv`. This is a backwards-compatibility change, hence the deprecation, but changing various shell scripts and such should be trivial thanks to the -m flag. This would also help promote the use of -m, especially for any projects that rely on being tied to a specific installed interpreter.

As pointed out in issue #25152, virtualenv provides a -p flag to specify what version of Python should be used to create a virtual environment: https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command. The pyvenv script and venv package provide no such mechanism since it is included in the stdlib, which makes sense since improvements will be tied to the stdlib of the Python interpreter being used while virtualenv is a standalone project/app.

Some may argue that worrying about this is unnecessary, but we are already ending up with OSs that come with multiple versions of Python pre-installed, let alone when people install their own versions of Python on top of the system installation. For instance, OS X Yosemite comes with Python 2.6 and 2.7, and then if you install the latest version of Python independently you end up with 3 installations. If they all happened to have a pyvenv script you wouldn't easily know which Python interpreter the pyvenv command was going to use for the virtual environment.

Since the pyvenv script is just a script, the deprecation will be in the form of a message printed to sys.stderr in the Tools/scripts/pyvenv file mentioning that the deprecation and that people should switch to `python3 -m venv` instead. The long deprecation cycle is for those who have pyvenv provided by their OS and only upgrade Python every few years, and thus run the risk of missing the deprecation warning. As for the deprecation in Python 3.5.1, that's to get the warning out immediately and to minimize people missing the deprecation prior to the removal.

----------
components: Installation
messages: 250910
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Drop the pyvenv script
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 17 21:25:40 2015
From: report at bugs.python.org (Vitaly Murashev)
Date: Thu, 17 Sep 2015 19:25:40 +0000
Subject: [New-bugs-announce] [issue25155] datetime.datetime.now() raises
Message-ID: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Current time on my machine with Windows7x64 is set to year 2045 for test purposes.
Since Python3.5(amd64) I have an OverflowError when I am trying to call datetime.datetime.now()

It looks like a regress since there was no such error on Python3.4.3

Could anyone please give me a note, whether it would be reasonable for me to wait for a patch in Python3.5.x, or such behavior is common since 3.5 and should not use it in my 'strange' case at all ? 

A bit of details:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: timestamp too large to convert to C _PyTime_t
>>>

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2045, 4, 2, 2, 42, 8, 359375)
>>>

----------
components: Interpreter Core, Windows
messages: 250914
nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware
priority: normal
severity: normal
status: open
title: datetime.datetime.now() raises
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 17 22:08:05 2015
From: report at bugs.python.org (desbma)
Date: Thu, 17 Sep 2015 20:08:05 +0000
Subject: [New-bugs-announce] [issue25156] shutil.copyfile should internally
 use os.sendfile when possible
Message-ID: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>


New submission from desbma:

This is related to issue25063 (https://bugs.python.org/issue25063).

Trying to use sendfile internally in shutil.copyfileobj was considered risky because of special Python files that expose a file descriptor but wrap it to add special behavior (eg: GzipFile).

I believe such risk does not exist for shutil.copyfile, and it would be possible to use sendfile if available.

----------
components: Library (Lib)
messages: 250918
nosy: desbma
priority: normal
severity: normal
status: open
title: shutil.copyfile should internally use os.sendfile when possible
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 17 23:50:43 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 17 Sep 2015 21:50:43 +0000
Subject: [New-bugs-announce] [issue25157] Installing Python 3.5.0 32bit on
 Windows 8.1 64bit system gives Error 0x80240017
Message-ID: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>


New submission from Laura Creighton:

This in to webmaster.

The nice thing is that it came with a log file.
Maybe this will help diagnose the problem.

In the meantime, I am going to suggest to the poster to try the
remedies in http://wind8apps.com/error-0x80240017-windows/
because yesterday somebody wrote me back that the first method
mentioned there fixed his problem.


[0C40:1870][2015-09-18T00:23:09]i001: Burn v3.10.0.1823, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\Shirshendu Bhowmick\Desktop\python-3.5.0.exe
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'ActionLikeInstalling' to value 'Installing'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'ActionLikeInstallation' to value 'Setup'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'ShortVersion' to value '3.5'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'ShortVersionNoDot' to value '35'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'InstallAllUsers' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'InstallLauncherAllUsers' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'TargetDir' to value ''
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python [ShortVersion]'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'TargetPlatform' to value 'x86'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'DefaultJustForMeTargetDir' to value '[LocalAppDataFolder]Programs\Python\Python[ShortVersionNoDot]-32'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'OptionalFeaturesRegistryKey' to value 'Software\Python\PythonCore\[ShortVersion]-32\InstalledFeatures'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'TargetDirRegistryKey' to value 'Software\Python\PythonCore\[ShortVersion]-32\InstallPath'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'DefaultCustomTargetDir' to value ''
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'InstallAllUsersState' to value 'enabled'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'InstallLauncherAllUsersState' to value 'enabled'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'TargetDirState' to value 'enabled'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'CustomBrowseButtonState' to value 'enabled'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_core' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_exe' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_dev' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_lib' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_test' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_doc' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_tools' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_tcltk' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_pip' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_launcher' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_symbols' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Include_debug' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'LauncherOnly' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'AssociateFiles' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'Shortcuts' to value '1'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'PrependPath' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'CompileAll' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing numeric variable 'SimpleInstall' to value '0'
[0C40:1870][2015-09-18T00:23:09]i000: Initializing string variable 'SimpleInstallDescription' to value ''
[0C40:1870][2015-09-18T00:23:09]i009: Command Line: ''
[0C40:1870][2015-09-18T00:23:09]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309.log'
[0C40:1870][2015-09-18T00:23:09]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\Shirshendu Bhowmick\Desktop\python-3.5.0.exe'
[0C40:1870][2015-09-18T00:23:09]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\Shirshendu Bhowmick\Desktop\'
[0C40:1870][2015-09-18T00:23:09]i000: Setting string variable 'WixBundleName' to value 'Python 3.5.0 (32-bit)'
[0C40:1870][2015-09-18T00:23:09]i000: Setting string variable 'WixBundleManufacturer' to value 'Python Software Foundation'
[0C40:1870][2015-09-18T00:23:09]i000: Setting numeric variable 'CRTInstalled' to value 0
[0C40:1D68][2015-09-18T00:23:09]i000: Did not find C:\Users\Shirshendu Bhowmick\Desktop\unattend.xml
[0C40:1D68][2015-09-18T00:23:09]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[0C40:1D68][2015-09-18T00:23:09]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[0C40:1D68][2015-09-18T00:23:09]i000: Setting version variable 'WixBundleFileVersion' to value '3.5.150.0'
[0C40:1870][2015-09-18T00:23:10]i100: Detect begin, 54 packages
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.0_x86, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.0_x64, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.1_x86, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.1_x64, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.2_x86, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.2_x64, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.3_x86, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: crt_14.0_v6.3_x64, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_AllUsers_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_JustForMe_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: core_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: dev_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: dev_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: dev_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: dev_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: exe_AllUsers, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: exe_AllUsers, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_AllUsers_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: exe_JustForMe, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: exe_JustForMe, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_JustForMe_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: exe_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_AllUsers_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_JustForMe_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: lib_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_AllUsers_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_JustForMe_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: test_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: doc_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: doc_AllUsers, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: doc_AllUsers, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: doc_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: doc_JustForMe, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: doc_JustForMe, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tools_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tools_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_AllUsers, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_AllUsers, feature: AssociateFiles, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_AllUsers, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_AllUsers_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_AllUsers_pdb, feature: Symbols, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_AllUsers_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_AllUsers_d, feature: DebugBinaries, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_JustForMe, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_JustForMe, feature: AssociateFiles, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_JustForMe, feature: Shortcuts, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_JustForMe_pdb, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_JustForMe_pdb, feature: Symbols, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: tcltk_JustForMe_d, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: tcltk_JustForMe_d, feature: DebugBinaries, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: launcher_AllUsers, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: launcher_AllUsers, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: launcher_AllUsers, feature: AssociateFiles, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: launcher_JustForMe, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: launcher_JustForMe, feature: DefaultFeature, state: Absent
[0C40:1870][2015-09-18T00:23:10]i104: Detected package: launcher_JustForMe, feature: AssociateFiles, state: Absent
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: pip_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: pip_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: path_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: path_JustForMe, state: Absent, cached: Complete
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: compileall_AllUsers, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i101: Detected package: compileall_JustForMe, state: Absent, cached: None
[0C40:1870][2015-09-18T00:23:10]i000: Setting string variable 'TargetDir' to value 'C:\Users\Shirshendu Bhowmick\AppData\Local\Programs\Python\Python35-32'
[0C40:1870][2015-09-18T00:23:10]i199: Detect complete, result: 0x0
[0C40:1D68][2015-09-18T00:23:10]i052: Condition 'not WixBundleElevated and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' evaluates to true.
[0C40:1D68][2015-09-18T00:23:11]i000: Setting numeric variable 'PrependPath' to value 0
[0C40:1D68][2015-09-18T00:23:11]i000: Setting numeric variable 'InstallLauncherAllUsers' to value 1
[0C40:1D68][2015-09-18T00:23:11]i052: Condition 'not WixBundleElevated and (InstallAllUsers or (InstallLauncherAllUsers and Include_launcher))' evaluates to true.
[0C40:1D68][2015-09-18T00:23:11]i000: Setting numeric variable 'CompileAll' to value 0
[0C40:1D68][2015-09-18T00:23:11]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[0C40:1D68][2015-09-18T00:23:11]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[0C40:1870][2015-09-18T00:23:11]i200: Plan begin, 54 packages, action: Install
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.0 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.0_x86
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.0 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.0_x64
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.1 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.1_x86
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.1 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.1_x64
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.2 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.2_x86
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.2 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.2_x64
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.3 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT = v6.3 and not VersionNT64 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.3_x86
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.3 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not CRTInstalled and VersionNT64 = v6.3 and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: crt_14.0_v6.3_x64
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: core_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: core_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: core_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_core_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_001_core_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_core_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_001_core_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: dev_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: dev_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_dev_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_002_dev_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_dev_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_002_dev_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: exe_AllUsers
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: exe_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: exe_JustForMe
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_exe_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_003_exe_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_exe_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_003_exe_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: lib_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_lib_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_004_lib_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_lib_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_004_lib_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: test_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: test_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: test_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_test_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_005_test_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_test_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_005_test_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: doc_AllUsers
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: doc_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: doc_JustForMe
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_doc_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_006_doc_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_doc_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_006_doc_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: tools_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_tools_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_007_tools_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_tools_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_007_tools_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 3 msi features for package: tcltk_AllUsers
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 1 msi features for package: tcltk_AllUsers_pdb
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 1 msi features for package: tcltk_AllUsers_d
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 3 msi features for package: tcltk_JustForMe
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_tcltk_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_008_tcltk_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_tcltk_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_008_tcltk_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 1 msi features for package: tcltk_JustForMe_pdb
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 1 msi features for package: tcltk_JustForMe_d
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: launcher_AllUsers
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: launcher_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_launcher_AllUsers' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_009_launcher_AllUsers_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_launcher_AllUsers' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_009_launcher_AllUsers.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i204: Plan 2 msi features for package: launcher_JustForMe
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: pip_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleRollbackLog_pip_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_010_pip_JustForMe_rollback.log'
[0C40:1870][2015-09-18T00:23:11]i000: Setting string variable 'WixBundleLog_pip_JustForMe' to value 'C:\Users\SHIRSH~1\AppData\Local\Temp\Python 3.5.0 (32-bit)_20150918002309_010_pip_JustForMe.log'
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w322: Skipping cross-scope dependency registration on package: path_AllUsers, bundle scope: PerUser, package scope: PerMachine
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: compileall_AllUsers
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[0C40:1870][2015-09-18T00:23:11]w321: Skipping dependency registration on package with no dependency providers: compileall_JustForMe
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.0_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.0_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.1_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.1_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.2_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.2_x64, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.3_x86, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: crt_14.0_v6.3_x64, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: core_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: dev_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: dev_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: dev_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: dev_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: exe_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: lib_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: test_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: doc_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: doc_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tools_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tools_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: tcltk_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: launcher_AllUsers, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: launcher_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: pip_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: pip_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: path_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: path_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: Yes, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: compileall_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i201: Planned package: compileall_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0C40:1870][2015-09-18T00:23:11]i299: Plan complete, result: 0x0
[0C40:1870][2015-09-18T00:23:11]i300: Apply begin
[0C40:1870][2015-09-18T00:23:11]i010: Launching elevated engine process.
[0C40:1870][2015-09-18T00:23:13]i011: Launched elevated engine process.
[0C40:1870][2015-09-18T00:23:13]i012: Connected to elevated engine.
[0DE8:1E34][2015-09-18T00:23:13]i358: Pausing automatic updates.
[0DE8:1E34][2015-09-18T00:23:13]i359: Paused automatic updates.
[0DE8:1E34][2015-09-18T00:23:13]i360: Creating a system restore point.
[0DE8:1E34][2015-09-18T00:23:13]i361: Created a system restore point.
[0C40:1870][2015-09-18T00:23:13]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, options: 0x7, disable resume: No
[0C40:1870][2015-09-18T00:23:13]i000: Caching bundle from: 'C:\Users\SHIRSH~1\AppData\Local\Temp\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}\.be\python-3.5.0.exe' to: 'C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}\python-3.5.0.exe'
[0C40:1870][2015-09-18T00:23:13]i320: Registering bundle dependency provider: {1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, version: 3.5.150.0
[0C40:1870][2015-09-18T00:23:13]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, resume: Active, restart initiated: No, disable resume: No
[0DE8:0944][2015-09-18T00:23:13]i305: Verified acquired payload: crt_14.0_v6.3_x64 at path: C:\ProgramData\Package Cache\.unverified\crt_14.0_v6.3_x64, moving to: C:\ProgramData\Package Cache\FC6260C33678BB17FB8B88536C476B4015B7C5E9\Windows8.1-KB2999226-x64.msu.
[0DE8:1E34][2015-09-18T00:23:13]i301: Applying execute package: crt_14.0_v6.3_x64, action: Install, path: C:\ProgramData\Package Cache\FC6260C33678BB17FB8B88536C476B4015B7C5E9\Windows8.1-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\FC6260C33678BB17FB8B88536C476B4015B7C5E9\Windows8.1-KB2999226-x64.msu" /quiet /norestart'
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: core_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{E9E55FC3-A47F-4ACA-8691-C22469450FB1}v3.5.150.0\core.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: dev_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{D5A057BD-471E-40D6-B7E0-79E08210D8F6}v3.5.150.0\dev.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: exe_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{CE48771A-4CC2-4F35-A7B3-D136E91D04F3}v3.5.150.0\exe.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: lib_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{0740B2CD-63EC-44C7-B39E-B6EB579773E6}v3.5.150.0\lib.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: test_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{2234BC4D-E95D-40C2-818D-7845760C510F}v3.5.150.0\test.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: doc_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{169B7A58-FE29-48E8-8773-9D6390815C8C}v3.5.150.0\doc.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: tools_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{4A69B338-2C0C-4726-A261-44DBCF0DA94A}v3.5.150.0\tools.msi.
[0C40:1A0C][2015-09-18T00:23:13]i304: Verified existing payload: tcltk_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{7AB85182-2EE4-4137-A5C6-D8C03958DCBA}v3.5.150.0\tcltk.msi.
[0DE8:0944][2015-09-18T00:23:13]i304: Verified existing payload: launcher_AllUsers at path: C:\ProgramData\Package Cache\{CAA5FC80-DEF6-4DFA-9C06-23921A87F092}v3.5.150.0\launcher.msi.
[0C40:1A0C][2015-09-18T00:23:14]i304: Verified existing payload: pip_JustForMe at path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{11187860-0D92-490D-86EC-3A941C98D451}v3.5.150.0\pip.msi.
[0DE8:1E34][2015-09-18T00:23:14]e000: Error 0x80240017: Failed to execute MSU package.
[0C40:1870][2015-09-18T00:23:14]e000: Error 0x80240017: Failed to configure per-machine MSU package.
[0C40:1870][2015-09-18T00:23:14]i319: Applied execute package: crt_14.0_v6.3_x64, result: 0x80240017, restart: None
[0C40:1870][2015-09-18T00:23:14]e000: Error 0x80240017: Failed to execute MSU package.
[0DE8:1E34][2015-09-18T00:23:14]i351: Removing cached package: crt_14.0_v6.3_x64, from path: C:\ProgramData\Package Cache\FC6260C33678BB17FB8B88536C476B4015B7C5E9\
[0C40:1870][2015-09-18T00:23:14]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, resume: None, restart: None, disable resume: No
[0C40:1870][2015-09-18T00:23:14]i330: Removed bundle dependency provider: {1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}
[0C40:1870][2015-09-18T00:23:14]i352: Removing cached bundle: {1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, from path: C:\Users\Shirshendu Bhowmick\AppData\Local\Package Cache\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}\
[0C40:1870][2015-09-18T00:23:14]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1197d2bb-6cf8-488a-b994-d5bf6d7efe7b}, resume: None, restart initiated: No, disable resume: No
[0C40:1870][2015-09-18T00:23:15]i399: Apply complete, result: 0x80240017, restart: None, ba requested restart:  No

----------
components: Installation
messages: 250922
nosy: lac
priority: normal
severity: normal
status: open
title: Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 03:11:24 2015
From: report at bugs.python.org (Donal Duane)
Date: Fri, 18 Sep 2015 01:11:24 +0000
Subject: [New-bugs-announce] [issue25158] Python 3.2.2 and 3.5.0 Do not seem
 compatible with OpenSSL 1.0.2d on Solaris 10
Message-ID: <1442538684.06.0.30749904186.issue25158@psf.upfronthosting.co.za>


New submission from Donal Duane:

Hi,

I have been trying to compile both Python 3.2.2, and 3.5.0 with OpenSSL 1.0.2d.

Python 3.2.2 succeeds to compile and install, but fails to load the OpenSSL module:

>>> import ssl
ld.so.1: python3.2: fatal: relocation error: file /usr/local/ssl/lib/libssl.so.1.0.0: symbol EVP_aes_128_cbc_hmac_sha256: referenced symbol not found
Killed


Python 3.5.0 fails to make install:

ld.so.1: python: fatal: relocation error: file /usr/local/ssl/lib/libssl.so.1.0.0: symbol EVP_aes_128_cbc_hmac_sha256: referenced symbol not found
*** Error code 137
make: Fatal error: Command failed for target `install'


Has anyone seen this behavior?
Up to now, we have been successfully using Python 3.2.2 with OpenSSL 1.0.1j, but cannot use that version anymore due to a critical SSL security bug.


I would greatly appreciate any information on the above errors.

Regards,
D?nal

----------
components: Extension Modules
messages: 250928
nosy: eeiddne
priority: normal
severity: normal
status: open
title: Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0.2d on Solaris 10
type: compile error
versions: Python 3.2, Python 3.5

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

From report at bugs.python.org  Fri Sep 18 08:10:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Sep 2015 06:10:06 +0000
Subject: [New-bugs-announce] [issue25159] Import time regression
Message-ID: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are regressions in import time in 3.5 and 3.6.

$ for i in `seq 5`; do ./python -I -m timeit -n1 -r1 "import enum"; done

Python 3.4:
1 loops, best of 1: 3.45 msec per loop
1 loops, best of 1: 3.43 msec per loop
1 loops, best of 1: 3.55 msec per loop
1 loops, best of 1: 3.54 msec per loop
1 loops, best of 1: 3.42 msec per loop

Python 3.5:
1 loops, best of 1: 4.38 msec per loop
1 loops, best of 1: 4.31 msec per loop
1 loops, best of 1: 4.32 msec per loop
1 loops, best of 1: 4.32 msec per loop
1 loops, best of 1: 4.4 msec per loop

Python 3.6:
1 loops, best of 1: 20.2 msec per loop
1 loops, best of 1: 20.2 msec per loop
1 loops, best of 1: 22 msec per loop
1 loops, best of 1: 20.3 msec per loop
1 loops, best of 1: 20.4 msec per loop


$ for i in `seq 5`; do ./python -I -m timeit -n1 -r1 -s "import sys; sys.modules.clear()" -- "import enum"; done

Python 3.4:
1 loops, best of 1: 29.5 msec per loop
1 loops, best of 1: 29.3 msec per loop
1 loops, best of 1: 30 msec per loop
1 loops, best of 1: 28.9 msec per loop
1 loops, best of 1: 29.2 msec per loop

Python 3.5:
1 loops, best of 1: 43.8 msec per loop
1 loops, best of 1: 44 msec per loop
1 loops, best of 1: 43.5 msec per loop
1 loops, best of 1: 43.1 msec per loop
1 loops, best of 1: 43.8 msec per loop

Python 3.6:
1 loops, best of 1: 59.8 msec per loop
1 loops, best of 1: 59.1 msec per loop
1 loops, best of 1: 58.8 msec per loop
1 loops, best of 1: 58.6 msec per loop
1 loops, best of 1: 61.9 msec per loop


And even in importing already imported and cached module there is small regression.
$ for i in `seq 5`; do ./python -I -m timeit "import enum"; done

Python 3.4:
100000 loops, best of 3: 3.04 usec per loop
100000 loops, best of 3: 3.07 usec per loop
100000 loops, best of 3: 3.08 usec per loop
100000 loops, best of 3: 3.11 usec per loop
100000 loops, best of 3: 3.04 usec per loop

Python 3.5:
100000 loops, best of 3: 3.27 usec per loop
100000 loops, best of 3: 3.22 usec per loop
100000 loops, best of 3: 3.18 usec per loop
100000 loops, best of 3: 3.28 usec per loop
100000 loops, best of 3: 3.17 usec per loop

Python 3.6:
100000 loops, best of 3: 3.29 usec per loop
100000 loops, best of 3: 3.26 usec per loop
100000 loops, best of 3: 3.34 usec per loop
100000 loops, best of 3: 3.35 usec per loop
100000 loops, best of 3: 3.35 usec per loop

----------
messages: 250941
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Import time regression
type: performance
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 18 09:06:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Sep 2015 07:06:19 +0000
Subject: [New-bugs-announce] [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
Message-ID: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The imp module is deprecated since Python 3.4. In Python 3.4, imp uses a PendingDeprecationWarning, and Python 3.5... hum, still a PendingDeprecationWarning. It was not supposed to become a real DeprecationWarning?

Anyway, the imp module is still used in some places of the Python stdlib:

Lib/modulefinder.py:14:    import imp
Python/makeopcodetargets.py:9:import imp
Tools/i18n/pygettext.py:159:import imp
Tools/importbench/importbench.py:10:import imp

modulefinder explicitly ignore the warning :-(

with warnings.catch_warnings():
    warnings.simplefilter('ignore', PendingDeprecationWarning)
    import imp

----------
messages: 250946
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Stop using deprecated imp module; imp should now emit a real DeprecationWarning
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 18 09:21:30 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Fri, 18 Sep 2015 07:21:30 +0000
Subject: [New-bugs-announce] [issue25161] Missing periods at the end of
	sentences
Message-ID: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

The attached patch adds some periods in docs.
This applies to 3.x.

----------
assignee: docs at python
components: Documentation
files: periods.patch
keywords: patch
messages: 250951
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Missing periods at the end of sentences
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40498/periods.patch

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

From report at bugs.python.org  Fri Sep 18 10:06:21 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Fri, 18 Sep 2015 08:06:21 +0000
Subject: [New-bugs-announce] [issue25162] Windows installation does not
 appear in list of installed applications
Message-ID: <1442563581.64.0.527655601006.issue25162@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

The new Windows installer always places the uninstallation registry key into HKCU of the executing user. This is correct for a per-user installation, but when run with InstallAllUsers=1, the key should go into HKLM instead.

The "Programs and Features" list of installed applications is assembled from the HKLM and HKCU keys. In many cases, a system-wide installation will be performed by temporarily elevating the installer to a user account with administrator privileges on the local system. However, since Vista, the "Programs and Features" list is always run in the logged-on user's Explorer process, even when started by a different user (such as in an elevated command prompt). With the uninstallation key going into HKCU of some administrative account, the Python installation will not appear in this list, hence, cannot easily be removed.

Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format.

----------
components: Installation, Windows
messages: 250954
nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installation does not appear in list of installed applications
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 10:13:20 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Fri, 18 Sep 2015 08:13:20 +0000
Subject: [New-bugs-announce] [issue25163] Windows installer in AllUsers mode
 presents wrong installation path
Message-ID: <1442564000.23.0.122739262623.issue25163@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

When run with InstallAllUsers=1, the Windows installer displays (%LOCALAPPDATA%)\Programs\Python\Python35 as the installation target directory, but actually installs into the path for a system-wide installation, "%PROGRAMFILES%\Python 3.5".

Ceterum censeo: This bug could have been avoided, and would certainly have been detected in time, by using MSI as the distribution package format. Because most MSI UI will display TARGETDIR as the target directory, an accidental override (or missing override) of this path would have been obvious.

----------
components: Installation, Windows
messages: 250955
nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer in AllUsers mode presents wrong installation path
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 10:21:22 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Fri, 18 Sep 2015 08:21:22 +0000
Subject: [New-bugs-announce] [issue25164] Windows default installation path
 is inconsistent between per-user and system-wide installation
Message-ID: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

On Windows, a per-user installation uses %LOCALAPPDATA%\Programs\Python\Python35 as the default target directory. A system-wide (InstallAllUsers=1) installation, however, goes into "%PROGRAMFILES%\Python 3.5" instead. The two directory names should be consistent with each other (and with earlier versions), that is, should be "Python35" in all cases.

----------
components: Installation, Windows
messages: 250956
nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows default installation path is inconsistent between per-user and system-wide installation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 11:03:04 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Fri, 18 Sep 2015 09:03:04 +0000
Subject: [New-bugs-announce] [issue25165] Windows uninstallation should not
 remove launcher if other versions remain
Message-ID: <1442566984.06.0.904088337084.issue25165@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

Uninstalling 3.5 on Windows removes the py.exe launcher. If it was installed in the system-wide path (%SYSTEMROOT%), it may have replaced an existing copy from an earlier version. In this case, removing the launcher will break this remaining installation, requiring a repair.

Instead, the launcher should not be deleted. It uses the static CRT, hence has no DLL dependencies that would be removed by the uninstallation, and it will -- as PEP 397 demands -- select the Python version it starts based on the command line and the available installations.

Ceterum censeo: This bug could have been avoided by using MSI as the distribution package format and using the same component code for the launcher file in all supporting versions. Even if the file itself is different, the identical component code would have ensured through reference counting that it would only have been removed with the last referencing installation. Upward compatibility of older launchers could have become a problem, though.

----------
components: Installation, Windows
messages: 250957
nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows uninstallation should not remove launcher if other versions remain
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 13:18:10 2015
From: report at bugs.python.org (Christian Ullrich)
Date: Fri, 18 Sep 2015 11:18:10 +0000
Subject: [New-bugs-announce] [issue25166] Windows AllUsers installation
 places uninstaller in user profile
Message-ID: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za>


New submission from Christian Ullrich:

A system-wide installation on Windows (using InstallAllUsers=1) still places the uninstall executable into the profile (%LOCALAPPDATA%) of the installing user. If that user profile is deleted, the (system-wide) installation cannot be removed anymore.

Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format.

----------
components: Installation, Windows
messages: 250962
nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows AllUsers installation places uninstaller in user profile
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 13:47:02 2015
From: report at bugs.python.org (james)
Date: Fri, 18 Sep 2015 11:47:02 +0000
Subject: [New-bugs-announce] [issue25167] THE SCORCH TRIALS OF MAZE RUNNER
	DISFACTION LOGGIC
Message-ID: <1442576822.25.0.748464063855.issue25167@psf.upfronthosting.co.za>


New submission from james:

http://www.thebigidea.co.nz/profile/james/65456
http://www.cyclefish.com/hebucoho/
https://soundation.com/user/MazeRunnerTheScorchTrials
https://issuu.com/mazerunnerthescorchtrials
http://poputka.ua/user-profile-39591.aspx
http://www.pikore.com/mazerunnerthescorch
https://instagram.com/mazerunnerthescorch/
http://iconosquare.com/mazerunnerthescorch
https://tofo.me/mazerunnerthescorch
http://buzzsta.com/mazerunnerthescorch
https://bitbucket.org/hebucoho/

----------
components: asyncio
messages: 250965
nosy: gvanrossum, haypo, leo, yselivanov
priority: normal
severity: normal
status: open
title: THE SCORCH TRIALS OF MAZE RUNNER DISFACTION LOGGIC
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 18 15:50:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Sep 2015 13:50:49 +0000
Subject: [New-bugs-announce] [issue25168] test_datetime.test_strptime()
 random failures on "s390x SLES" buildbots
Message-ID: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the failure is random. It probably depends on the test order.

http://buildbot.python.org/all/builders/s390x%20SLES%203.4/builds/45/steps/test/logs/stdio

======================================================================
ERROR: test_strptime (test.datetimetester.TestDateTimeTZ_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime
    dt = strptime(dtstr, "%z %Z")
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime
    return _strptime._strptime_datetime(cls, date_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

======================================================================
ERROR: test_strptime (test.datetimetester.TestDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime
    dt = strptime(dtstr, "%z %Z")
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime
    return _strptime._strptime_datetime(cls, date_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

======================================================================
ERROR: test_strptime (test.datetimetester.TestSubclassDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime
    dt = strptime(dtstr, "%z %Z")
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime
    return _strptime._strptime_datetime(cls, date_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

----------
keywords: buildbot
messages: 250987
nosy: belopolsky, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_datetime.test_strptime() random failures on "s390x SLES" buildbots
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 18 16:54:36 2015
From: report at bugs.python.org (John Taylor)
Date: Fri, 18 Sep 2015 14:54:36 +0000
Subject: [New-bugs-announce] [issue25169] multiprocess documentation
Message-ID: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za>


New submission from John Taylor:

In the Windows Help File for Python 3.5:

17.2 multiprocessing
17.2.1.1 The Process class
2nd code example: "To show the individual process IDs involved, here is an expanded example"

def info(title):
    print(title)
    print('module name:', __name__)
    if hasattr(os, 'getppid'):  # only available on Unix
        print('parent process:', os.getppid())
    print('process id:', os.getpid())

os.getppid() is now available on Windows, so you can remove the if statement.

----------
assignee: docs at python
components: Documentation
messages: 251002
nosy: docs at python, jftuga
priority: normal
severity: normal
status: open
title: multiprocess documentation
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 18 20:41:34 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 Sep 2015 18:41:34 +0000
Subject: [New-bugs-announce] [issue25170] 3.5.0 documentation archives
	missing
Message-ID: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Documentation archives for final 3.5.0 release are missing in https://www.python.org/ftp/python/doc/3.5.0/

(Compare it with e.g. https://www.python.org/ftp/python/doc/3.4.0/ and https://www.python.org/ftp/python/doc/3.4.3/)

----------
assignee: larry
components: Documentation
messages: 251018
nosy: Arfrever, larry
priority: normal
severity: normal
status: open
title: 3.5.0 documentation archives missing
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 19 01:16:15 2015
From: report at bugs.python.org (Remi Pointel)
Date: Fri, 18 Sep 2015 23:16:15 +0000
Subject: [New-bugs-announce] [issue25171] does not build on OpenBSD with no
 value defined for PY_GETENTROPY
Message-ID: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za>


New submission from Remi Pointel:

Hi,

I'm trying to build Python on OpenBSD-current, but it does not build because it seems that PY_GETENTROPY does not have a value.

$ make
...
gcc -pthread -c -fno-strict-aliasing -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -O2 -pipe   -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Python/random.o Python/random.c
Python/random.c:367:20: error: #if with no expression
Python/random.c: In function '_PyOS_URandom':
Python/random.c:370: warning: implicit declaration of function 'dev_urandom_python'
Python/random.c:414:20: error: #if with no expression
Python/random.c: In function '_PyRandom_Init':
Python/random.c:417: warning: implicit declaration of function 'dev_urandom_noraise'
Python/random.c:430:20: error: #if with no expression
Python/random.c: In function '_PyRandom_Fini':
Python/random.c:433: warning: implicit declaration of function 'dev_urandom_close'
*** Error 1 in /home/remi/dev/cpython (Makefile:1534 'Python/random.o')

If I defined the PY_GETENTROPY to the value "1" line 76, it seems to works fine.

Remi.

----------
files: Python_random_c
messages: 251040
nosy: rpointel
priority: normal
severity: normal
status: open
title: does not build on OpenBSD with no value defined for PY_GETENTROPY
versions: Python 3.6
Added file: http://bugs.python.org/file40511/Python_random_c

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

From report at bugs.python.org  Sat Sep 19 02:49:31 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Sep 2015 00:49:31 +0000
Subject: [New-bugs-announce] [issue25172] Unix-only crypt should not be
	present on Windows.
Message-ID: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Except for crypt, all the modules labeled 'Unix' or 'Linux' on the module index https://docs.python.org/3/py-modindex.html are absent from /Lib on Windows.  'import xyz' fails with "ImportError: no module named 'zyz'".  (I presume the same is true on unix for Windows-only modules.) 

However, crypt is present, and 'import crypt' fails with "...'_crypt'", leading one to think that the C accelerator should be present but is not. Assuming that _crypt should (cannot) not be present, please add crypt to the list of modules omitted from the Windows installer, however this is done. And if 'unix-only' is obsolete and _crypt should be present, please fix this instead. ;-)

This is 3.x issue only, as crypt is not present in my Windows 2.7.10 /Lib.  The fact that is was somehow added to some 3.x prompted me to look and see if there is anything useful without _crypt present.  I think not.

----------
components: Library (Lib), Windows
messages: 251046
nosy: jafo, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unix-only crypt should not be present on Windows.
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 19 04:26:48 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sat, 19 Sep 2015 02:26:48 +0000
Subject: [New-bugs-announce] [issue25173] IDLE - several common dialogs
 don't have correct parent set
Message-ID: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za>


New submission from Mark Roseman:

The confirmation, file, etc. common dialogs in tkinter accept both a 'master' and a 'parent' argument. Master is not required (it will use parent if not provided). Parent is used to associate the dialog with a given window. On Mac OS X, using parent further turns this into a 'sheet' attached to that window.

Most places in IDLE we're correctly using parent, but there are several places that master is provided, but not parent, e.g. IOBinding.py. This is most noticeable doing a 'do you want to save before closing...' where now it is not attached to the window on Mac, but it should be.

Need to go through the code, every place the common dialogs are used and check if master/parent are being used correctly.

----------
components: IDLE
messages: 251048
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - several common dialogs don't have correct parent set
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 19 04:45:58 2015
From: report at bugs.python.org (Jared Bevis)
Date: Sat, 19 Sep 2015 02:45:58 +0000
Subject: [New-bugs-announce] [issue25174] Backspace Escape Character at End
	of String
Message-ID: <1442630758.17.0.869659981248.issue25174@psf.upfronthosting.co.za>


New submission from Jared Bevis:

I'm a new python learner but I noticed inconsistent behavior of the backspace character when used in strings.  I'm running 2.7.10.  Whenever the backspace character '\b' is at the very end of a string, nothing happens, but if it is in the middle of string it behaves as expected.  

For example:
print "12345" + '\b'
returns:
>>>12345

But:
print "12345" + '\b' + '6'
returns:
>>> 12346

----------
components: Regular Expressions
messages: 251049
nosy: Jared Bevis, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Backspace Escape Character at End of String
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep 19 12:01:04 2015
From: report at bugs.python.org (Rishit Bansal)
Date: Sat, 19 Sep 2015 10:01:04 +0000
Subject: [New-bugs-announce] [issue25175] Documentation-Tkinter wrong
	statement
Message-ID: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>


New submission from Rishit Bansal:

The statement required to check whether Tkinter is installed on a system is mentioned in the documentation as python -m tkinter , whereas it is supposed to be python -m Tkinter (with a big 't'). Please correct this error on the documentation here:https://docs.python.org/3/library/tkinter.html as it is very misleading to beginners.

----------
assignee: docs at python
components: Documentation
messages: 251070
nosy: Rishit Bansal, docs at python
priority: normal
severity: normal
status: open
title: Documentation-Tkinter wrong statement
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep 19 12:17:02 2015
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 19 Sep 2015 10:17:02 +0000
Subject: [New-bugs-announce] [issue25176] Link to urllib.parse.parse_qsl,
 not parse_qs, from cgi.parse_qsl doc
Message-ID: <1442657822.78.0.00192788068763.issue25176@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

The docs for cgi.parse_qsl should link to urllib.parse.parse_qsl instead of urllib.parse.parse_qs, patch attached.

----------
assignee: docs at python
components: Documentation
files: cgi.parse_qsl.doc.patch
keywords: patch
messages: 251072
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40514/cgi.parse_qsl.doc.patch

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

From report at bugs.python.org  Sat Sep 19 13:40:40 2015
From: report at bugs.python.org (David MacIver)
Date: Sat, 19 Sep 2015 11:40:40 +0000
Subject: [New-bugs-announce] [issue25177] OverflowError in statistics.mean
 when summing large floats
Message-ID: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>


New submission from David MacIver:

The following code produces an OverflowError:

import statistics
statistics.mean([8.988465674311579e+307, 8.98846567431158e+307])

The error is:

  File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line 293, in mean
    return _sum(data)/n
  File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line 184, in _sum
    return T(total)
  File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/numbers.py", line 291, in __float__
    return self.numerator / self.denominator
OverflowError: integer division result too large for a float


If this is intended behaviour then it is not documented: https://docs.python.org/3/library/statistics.html#statistics.mean only specifies that it may raise StatisticsError.

----------
components: Library (Lib)
messages: 251076
nosy: David MacIver
priority: normal
severity: normal
status: open
title: OverflowError in statistics.mean when summing large floats
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 19 20:34:41 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sat, 19 Sep 2015 18:34:41 +0000
Subject: [New-bugs-announce] [issue25178] IDLE: search regex errors should
 be in/attached to search dialog
Message-ID: <1442687681.31.0.813309084762.issue25178@psf.upfronthosting.co.za>


New submission from Mark Roseman:

Follow-on to #25173, any regex errors are displayed by SearchEngine but they should be shown by the dialog where the user is typing the error. Either as a modal tkMessageBox attached to the dialog, or as an inline error in the dialog itself.

----------
components: IDLE
messages: 251097
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: search regex errors should be in/attached to search dialog
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/issue25178>
_______________________________________

From report at bugs.python.org  Sat Sep 19 20:55:18 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Sep 2015 18:55:18 +0000
Subject: [New-bugs-announce] [issue25179] PEP 498 f-strings need to be
	documented
Message-ID: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

Issue 24965 add f-strings (see PEP 498). They need to be documented.

----------
assignee: docs at python
components: Documentation
messages: 251101
nosy: docs at python, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 498 f-strings need to be documented
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 19 21:17:23 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Sep 2015 19:17:23 +0000
Subject: [New-bugs-announce] [issue25180] Tools/parser/unparse.py needs to
	be updated for f-strings
Message-ID: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

test_unparse.py occasionally fails if it picks a module that uses f-strings.

----------
assignee: eric.smith
keywords: easy
messages: 251106
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/parser/unparse.py needs to be updated for f-strings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 19 22:21:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 20:21:35 +0000
Subject: [New-bugs-announce] [issue25181] Tests failed in nondecodable
	directory
Message-ID: <1442694095.16.0.133026836681.issue25181@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

A number of tests are failed or skipped when run in directory with a name that contains non-decodable characters. Attached output of following command:

./python -m test.regrtest -uall -v test_cgitb test_cmd_line test_gdb test_inspect test_multiprocessin_fork test_multiprocessing_forkserver test_multiprocessing_spawn test_pdb test_pydoc test_pyexpat test_sax test_site test_subprocess test_tk test_venv test_xml_etree test_xml_etree_c

test_logging just hangs.

Locale is en_US.utf8.

----------
components: Tests
files: tests.log
messages: 251113
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tests failed in nondecodable directory
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40521/tests.log

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

From report at bugs.python.org  Sat Sep 19 22:48:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 20:48:46 +0000
Subject: [New-bugs-announce] [issue25182] python -v crashes in nonencodable
	directory
Message-ID: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ pwd
/home/serhiy/py/cpy?thon-3.5
$ ./python -v
import _frozen_importlib # frozen
import _imp # builtin
import sys # builtin
import '_warnings' # <class '_frozen_importlib.BuiltinImporter'>
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'>
import '_io' # <class '_frozen_importlib.BuiltinImporter'>
import 'marshal' # <class '_frozen_importlib.BuiltinImporter'>
import 'posix' # <class '_frozen_importlib.BuiltinImporter'>
import _thread # previously loaded ('_thread')
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import _weakref # previously loaded ('_weakref')
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# installing zipimport hook
import 'zipimport' # <class '_frozen_importlib.BuiltinImporter'>
# installed zipimport hook
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
# destroy io
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
# destroy io
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
# destroy io
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
# destroy io
  File "<frozen importlib._bootstrap_external>", line 759, in get_code
# destroy io
  File "<frozen importlib._bootstrap_external>", line 368, in _verbose_message
# destroy io
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 21: surrogates not allowed
# destroy encodings
Aborted (core dumped)

----------
messages: 251115
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: python -v crashes in nonencodable directory
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 19 22:57:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 20:57:40 +0000
Subject: [New-bugs-announce] [issue25183] python -m inspect --details fails
 in nondecodable directory
Message-ID: <1442696260.6.0.26315436798.issue25183@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ pwd
/home/serhiy/py/cpy?thon-3.5
$ ./python -m inspect --details unittest
Target: unittest
Traceback (most recent call last):
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/inspect.py", line 3050, in <module>
    _main()
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/inspect.py", line 3030, in _main
    print('Origin: {}'.format(getsourcefile(module)))
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 27: surrogates not allowed

----------
components: Library (Lib)
messages: 251116
nosy: serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: python -m inspect --details fails in nondecodable directory
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 19 23:07:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 21:07:25 +0000
Subject: [New-bugs-announce] [issue25184] "python -m pydoc -w" fails in
	nondecodable directory
Message-ID: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ pwd
/home/serhiy/py/cpy?thon-3.5
$ ./python -m pydoc -w pydoc
Traceback (most recent call last):
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 2648, in <module>
    cli()
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 2611, in cli
    writedoc(arg)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 1642, in writedoc
    page = html.page(describe(object), html.document(object, name))
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 370, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 651, in docmodule
    url = urllib.parse.quote(path)
  File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/urllib/parse.py", line 706, in quote
    string = string.encode(encoding, errors)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 19: surrogates not allowed

----------
components: Library (Lib)
messages: 251117
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
status: open
title: "python -m pydoc -w" fails in nondecodable directory
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 19 23:29:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Sep 2015 21:29:19 +0000
Subject: [New-bugs-announce] [issue25185] Inconsistency between venv and site
Message-ID: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

venv writes pyvenv.cfg with utf-8 encoding, but site reads it with locale encoding.

----------
components: Library (Lib)
messages: 251119
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency between venv and site
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 20 01:02:12 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 19 Sep 2015 23:02:12 +0000
Subject: [New-bugs-announce] [issue25186] Don't duplicate _verbose_message
 in importlib._bootstrap and _bootstrap_external
Message-ID: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za>


New submission from Brett Cannon:

For some reason _verbose_message() is defined in both _bootstrap and _bootstrap_external. Probably should only have it in _bootstrap, unless Eric has a reason he duplicated the code.

----------
components: Library (Lib)
messages: 251124
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: Don't duplicate _verbose_message in importlib._bootstrap and _bootstrap_external
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 20 04:12:36 2015
From: report at bugs.python.org (David Ward)
Date: Sun, 20 Sep 2015 02:12:36 +0000
Subject: [New-bugs-announce] [issue25187] bdist_rpm fails due to wrong
 hardcoded assumption about RPM filename format
Message-ID: <1442715156.03.0.0265256317041.issue25187@psf.upfronthosting.co.za>


New submission from David Ward:

bdist_rpm wrongly assumes a hard-coded format for the filename of the non-source RPM which is generated when it calls rpmbuild, specifically:
"%{arch}/%{name}-%{version}-%{release}.%{arch}.rpm"

The format used by rpmbuild is actually specified by the RPM macro %{_rpmfilename}. With the /usr/lib/rpm/macros file that is shipped with official releases of RPM (at http://rpm.org), %{_rpmfilename} evaluates to the value above. However this value cannot be assumed: the directory "%{arch}/" is dropped under the Mock chroot environment (https://fedoraproject.org/wiki/Mock). Mock is used to build all official Fedora Project packages (by Koji) as well as unofficial packages (by Copr). These two build systems also target Extra Packages for Enterprise Linux (EPEL) in addition to Fedora releases.

As a result, bdist_rpm fails when trying to move the non-source RPM to the 'dist' folder after it is built by rpmbuild.

The attached patch causes bdist_rpm to evaluate "%{_rpmfilename}" instead of relying on the hard-coded value.

----------
components: Distutils
files: python-bdist_rpm-evaluate-_rpmfilename.patch
keywords: patch
messages: 251136
nosy: dpward, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: bdist_rpm fails due to wrong hardcoded assumption about RPM filename format
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/file40523/python-bdist_rpm-evaluate-_rpmfilename.patch

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

From report at bugs.python.org  Sun Sep 20 07:26:22 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 20 Sep 2015 05:26:22 +0000
Subject: [New-bugs-announce] [issue25188] regrtest.py improvement for
 Profile Guided Optimization builds
Message-ID: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>


New submission from Alecsandru Patrascu:

This issue adds improved support for Profile Guided Optimization builds in the regression test suite. 

Mainly, we keep the visual progress status in this process and suppress errors or any other unnecessary output that can alarm users.

----------
components: Library (Lib)
messages: 251140
nosy: alecsandru.patrascu
priority: normal
severity: normal
status: open
title: regrtest.py improvement for Profile Guided Optimization builds
type: performance
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 20 07:43:39 2015
From: report at bugs.python.org (yangyanbo)
Date: Sun, 20 Sep 2015 05:43:39 +0000
Subject: [New-bugs-announce] [issue25189] An issue about os.acess
Message-ID: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za>


New submission from yangyanbo:

On Windows 10 . The telnet function is closed on Windows10, I open it and I can use it in WIN CMD.
But when i start python shell?and import os module? I use the command
os.acess(r"C:\Windows\System32\telnet.exe",os.X_OK)  to check it is or not be executeable?And I got False.
Why I use it because winpexpect moudle use it to check.
I try this in three PCS,and i doubt it may be an issue

----------
components: Windows
messages: 251145
nosy: berlinsaint, loewis, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: An issue about os.acess
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 20 08:15:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 20 Sep 2015 06:15:12 +0000
Subject: [New-bugs-announce] [issue25190] Define StringIO seek offset as
	code point offset
Message-ID: <1442729712.98.0.451356431809.issue25190@psf.upfronthosting.co.za>


New submission from Martin Panter:

This follows from Issue 12922. When no newline translation is being done, it would be useful to define the seek() offset as the code point offset into the underlying string, allowing stuff like:

s = StringIO()
print("line", file=s)  # Some inflexible API with an unwanted newline
s.seek(-1, SEEK_CUR)  # Undo the trailing newline
s.truncate()

In general, relative seeks are not allowed for text streams, and absolute offsets have arbitrary values. But when no encoding is actually going on, these restrictions are annoying.

I guess the biggest problem is what to do when newline translation is enabled. But I think this is a rarely-used feature of StringIO. I suggest to say that offsets in that case remain arbitrary, and let the code do whatever it happens to do (probably jumping to the wrong character, chopping CRLFs in half, etc, as long as it won?t crash).

----------
components: IO
messages: 251149
nosy: martin.panter
priority: normal
severity: normal
status: open
title: Define StringIO seek offset as code point offset
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 20 10:31:18 2015
From: report at bugs.python.org (Remi Pointel)
Date: Sun, 20 Sep 2015 08:31:18 +0000
Subject: [New-bugs-announce] [issue25191] test_getsetlocale_issue1813 failed
	on OpenBSD
Message-ID: <1442737878.41.0.0154038500687.issue25191@psf.upfronthosting.co.za>


New submission from Remi Pointel:

Hi,

the test test_getsetlocale_issue1813 in ./Lib/test/test_locale.py failed on OpenBSD:

======================================================================
...........s....ss..................testing with ('tr_TR', 'ISO8859-9') E....ss
ERROR: test_getsetlocale_issue1813 (__main__.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_locale.py.orig", line 515, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "/usr/ports/pobj/Python-3.5.0/Python-3.5.0/Lib/locale.py", line 595, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------------------------------------------------------------------
Ran 38 tests in 0.040s

FAILED (errors=1, skipped=5)

The first setlocale(locale.LC_CTYPE, 'tr_TR') works fine, but loc = locale.getlocale(locale.LC_CTYPE) then locale.setlocale(locale.LC_CTYPE, loc) does not work.

Attached is a patch to skip the second part if it does not work, is it correct?

Thanks,

Remi.

----------
components: Library (Lib), Tests
files: patch-Lib_test_test_locale_py
messages: 251153
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_getsetlocale_issue1813 failed on OpenBSD
versions: Python 3.5
Added file: http://bugs.python.org/file40526/patch-Lib_test_test_locale_py

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

From report at bugs.python.org  Sun Sep 20 10:36:22 2015
From: report at bugs.python.org (Alun Champion)
Date: Sun, 20 Sep 2015 08:36:22 +0000
Subject: [New-bugs-announce] [issue25192] deque append and appendleft should
 return value if maxlen set
Message-ID: <1442738182.66.0.606955570535.issue25192@psf.upfronthosting.co.za>


New submission from Alun Champion:

Currently if you append or appendleft when len(deque) == maxlen item from the other end of the deque is discarded. These should return the discarded value to allow you to write:

    x = deque.append(y)

vs

    if len(deque) == deque.maxlen():
        x = deque.pop()
    deque.append(y)

It should return None if len(deque) < maxlen or maxlen is not set.

----------
components: Library (Lib)
messages: 251154
nosy: Alun Champion
priority: normal
severity: normal
status: open
title: deque append and appendleft should return value if maxlen set

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

From report at bugs.python.org  Sun Sep 20 10:46:40 2015
From: report at bugs.python.org (Alun Champion)
Date: Sun, 20 Sep 2015 08:46:40 +0000
Subject: [New-bugs-announce] [issue25193] itertools.accumlate should have an
 optional initializer argument
Message-ID: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za>


New submission from Alun Champion:

itertools.accumulate should have an initializer with the same semantics as functools.reduce.
These two functions are closely related, reduce only providing you the end result accumulate providing an iterator over all the intermediate results.
However, if you want all the intermediate results to this reduce:

    functools.reduce(operator.mul, range(1, 4), 10)

You currently need to do:

    itertools.accumulate(itertools.chain([10], range(1,4), operator.mul)

Adding an optional initialiser argument would avoid this.

----------
components: Library (Lib)
messages: 251155
nosy: Alun Champion
priority: normal
severity: normal
status: open
title: itertools.accumlate should have an optional initializer argument
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 20 11:17:48 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Sep 2015 09:17:48 +0000
Subject: [New-bugs-announce] [issue25194] Register of Financial Interests
	for core contributors
Message-ID: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As suggested at https://mail.python.org/pipermail/python-committers/2015-September/003556.html, this is a draft patch for a new section in the developer guide that allows core contributors to declare our major financial interest (if any) in the core development process.

In addition to adding a paragraph suggesting new core developers consider filling in the register, I also rephrased the section regarding respecting people's time to reflect the fact that we're not all volunteers these days.

Based on the discussion in the python-committers thread, I made the disclosure of commercial interests potentially impacting Python's design & development the main aim of the register, with the creation of a public list of the core developers available for contract and consulting work as a positive side benefit.

----------
assignee: ncoghlan
components: Devguide
files: register-of-interests.diff
keywords: patch
messages: 251158
nosy: ezio.melotti, ncoghlan, willingc
priority: normal
severity: normal
stage: patch review
status: open
title: Register of Financial Interests for core contributors
type: enhancement
Added file: http://bugs.python.org/file40527/register-of-interests.diff

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

From report at bugs.python.org  Sun Sep 20 12:27:20 2015
From: report at bugs.python.org (Felix Yan)
Date: Sun, 20 Sep 2015 10:27:20 +0000
Subject: [New-bugs-announce] [issue25195] mock.ANY doesn't match
	mock.MagicMock() object
Message-ID: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za>


New submission from Felix Yan:

Since Python 3.5.0 mock.MagicMock() object seems not matched by mock.ANY. This behavior looks weird and breaks tests of boto.

Minimized example:

In Python 3.4.3:
>>> from unittest import mock
>>> m = mock.MagicMock()
>>> m(mock.MagicMock())
<MagicMock name='mock()' id='139728217270704'>
>>> m.assert_called_with(mock.ANY)
>>>

In Python 3.5.0:
>>> from unittest import mock
>>> m = mock.MagicMock()
>>> m(mock.MagicMock())
<MagicMock name='mock()' id='140093484276536'>
>>> m.assert_called_with(mock.ANY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/unittest/mock.py", line 792, in assert_called_with
    raise AssertionError(_error_message()) from cause
AssertionError: Expected call: mock(<ANY>)
Actual call: mock(<MagicMock id='140093520206872'>)

----------
components: Library (Lib)
messages: 251162
nosy: felixonmars
priority: normal
severity: normal
status: open
title: mock.ANY doesn't match mock.MagicMock() object
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 20 20:48:33 2015
From: report at bugs.python.org (Abdullah Hilson)
Date: Sun, 20 Sep 2015 18:48:33 +0000
Subject: [New-bugs-announce] [issue25196] Installer>Install in user folder
 by default when you check: for all users
Message-ID: <1442774913.98.0.448713689083.issue25196@psf.upfronthosting.co.za>


New submission from Abdullah Hilson:

Hello
Just downloaded :
https://www.python.org/ftp/python/3.5.0/python-3.5.0-amd64.exe
And I launch the install, I check checkbox to install for all users
And folder for installation stay at:
C:\Users\myusername\AppData\Local\Programs\Python\Python35\
I have to change it manually

Well, I don't want it in that folder when I install globally.
Thanks

----------
components: Windows
messages: 251174
nosy: Abdullah Hilson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Installer>Install in user folder by default when you check: for all users
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 20 22:14:52 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 20 Sep 2015 20:14:52 +0000
Subject: [New-bugs-announce] [issue25197] Allow documentation switcher to
 change url to /3/ and /dev/
Message-ID: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za>


New submission from Matthias Bussonnier:

The current documentation  version switcher does not allow to get back to the `python.org/3/..`
and `python.org/dev/...` url who permanently track the stable/developement release of Python
the attached patch allows that and should permit  in the long term less link on the internet to be out of date.

----------
assignee: docs at python
components: Documentation
files: docp.patch
keywords: patch
messages: 251177
nosy: docs at python, mbussonn
priority: normal
severity: normal
status: open
title: Allow documentation switcher to change url to /3/ and /dev/
type: enhancement
Added file: http://bugs.python.org/file40529/docp.patch

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

From report at bugs.python.org  Mon Sep 21 02:07:47 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Sep 2015 00:07:47 +0000
Subject: [New-bugs-announce] [issue25198] Idle: improve idle.html help
	viewer.
Message-ID: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I just pushed the new viewer as part of #16893.  Possible improvements:

* Font size should initially reflect user's size choice.  Possibly change with control-mousewheel.  (Possible same for edit windows.)

* Make within-file links work.

* Make Find ^F work, even without menu entry.

* Possible immediate bug fixes.

----------
assignee: terry.reedy
messages: 251181
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: improve idle.html help viewer.
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 21 03:04:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Sep 2015 01:04:45 +0000
Subject: [New-bugs-announce] [issue25199] Idle: add cross-references from
	and to macosxSupport
Message-ID: <1442797485.62.0.138053002868.issue25199@psf.upfronthosting.co.za>


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


----------
assignee: terry.reedy
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: add cross-references from and to macosxSupport
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 21 03:46:04 2015
From: report at bugs.python.org (Diego Palharini)
Date: Mon, 21 Sep 2015 01:46:04 +0000
Subject: [New-bugs-announce] [issue25200] bug on re.search using the char ,
	-:
Message-ID: <1442799964.46.0.602494976102.issue25200@psf.upfronthosting.co.za>


New submission from Diego Palharini:

Using the packet re for regular expressions I found a strange behavior with the following command:


re.search("[,-:]","89")

it returns that one of those chars exists into the string "89" or whatever number you may use.

----------
components: IDLE
messages: 251187
nosy: DPalharini
priority: normal
severity: normal
status: open
title: bug on re.search using the char ,-:
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 21 06:05:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 21 Sep 2015 04:05:21 +0000
Subject: [New-bugs-announce] [issue25201] lock of multiprocessing.Value is
 not a keyword-only argument
Message-ID: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za>


New submission from Berker Peksag:

>From https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Value

    Note that lock is a keyword-only argument.

But the signature of Value (in Lib/multiprocessing/context.py)

    def Value(self, typecode_or_type, *args, lock=True):

and (in Lib/multiprocessing/sharedctypes.py)

    def Value(typecode_or_type, *args, lock=True, ctx=None):

I'd suggest to remove that part of the documentation in 3.4+. We can also make it a keyword-only argument in Python 3.6. That will make the API more similar with https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array

----------
assignee: docs at python
components: Documentation
messages: 251196
nosy: berker.peksag, davin, docs at python, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: lock of multiprocessing.Value is not a keyword-only argument
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 21 15:17:04 2015
From: report at bugs.python.org (Lauri Kajan)
Date: Mon, 21 Sep 2015 13:17:04 +0000
Subject: [New-bugs-announce] [issue25202] with-statement doesn't release
 file handle after exception
Message-ID: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za>


New submission from Lauri Kajan:

Hi all,

I found out that handle to a file opened with with-statement is not released in all cases.

I'm trying to delete a file when space on a disk is filled (0 bit left) by writing this file. I catch the IOError 28 to figure this out.
I write the file within the with-statement that is wrapped with try except. In the except block I try to delete the file but the handle to the file is not released.

In the following code fill-file can't be deleted because the file is still open.
I have described the problem also in stackoverflow [1].

# I recommend filling the disk almost full with some better tool.
import os
import errno

fill = 'J:/fill.txt'
try:
    with open(fill, 'wb') as f:
        while True:
            n = f.write(b"\0")
except IOError as e:
    if e.errno == errno.ENOSPC:
        os.remove(fill)

This gives the following traceback:

Traceback (most recent call last):
  File "nospacelef.py", line 8, in <module>
    n = f.write(b"\0")
IOError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "nospacelef.py", line 8, in <module>
    n = f.write(b"\0")
IOError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "nospacelef.py", line 11, in <module>
    os.remove(fill)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'J:/fill.txt'



[1] http://stackoverflow.com/questions/32690018/cant-delete-a-file-after-no-space-left-on-device

----------
components: IO
messages: 251225
nosy: Lauri Kajan
priority: normal
severity: normal
status: open
title: with-statement doesn't release file handle after exception
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 21 18:30:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 16:30:47 +0000
Subject: [New-bugs-announce] [issue25203] Incorrect handling MemoryError in
 readline.set_completer_delims
Message-ID: <1442853047.02.0.107801341655.issue25203@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

MemoryError raised in readline.set_completer_delims() turns the readline library to incorrect state.

$ (ulimit -v 200000; ./python;)
Python 3.6.0a0 (default:e33b4c18af59+, Sep 17 2015, 17:05:17) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_completer_delims()
' \t\n`~!@#$%^&*()-=+[{]}\\|;:\'",<>/?'
>>> readline.set_completer_delims(' '*10**8)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> readline.get_completer_delims()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 1: invalid continuation byte

Proposed patch fixes the issue.

----------
components: Extension Modules
files: readline_set_completer_delims.patch
keywords: patch
messages: 251239
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: Incorrect handling MemoryError in readline.set_completer_delims
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40535/readline_set_completer_delims.patch

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

From report at bugs.python.org  Mon Sep 21 20:22:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 18:22:00 +0000
Subject: [New-bugs-announce] [issue25204] Confusing (?) warning when run
 deprecated module as script
Message-ID: <1442859720.94.0.332591501975.issue25204@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -Wa Lib/imp.py
sys:1: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

"sys:1:" is output when the stacklevel argument is larger then the deep of the stack.

Following patch stops raising just below the surface.

$ ./python -Wa Lib/imp.py
Lib/imp.py:33: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  PendingDeprecationWarning, stacklevel=2)

However I'm not sure that the current behavior is incorrect.

----------
components: Extension Modules, Library (Lib)
files: warnings_surface.patch
keywords: patch
messages: 251247
nosy: brett.cannon, eric.snow, haypo, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Confusing (?) warning when run deprecated module as script
Added file: http://bugs.python.org/file40536/warnings_surface.patch

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

From report at bugs.python.org  Mon Sep 21 20:59:20 2015
From: report at bugs.python.org (W deW)
Date: Mon, 21 Sep 2015 18:59:20 +0000
Subject: [New-bugs-announce] [issue25205] setattr accepts invalid identifiers
Message-ID: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za>


New submission from W deW:

An identifier is defined by 

identifier ::=  (letter|"_") (letter | digit | "_")*

setattr accepts identifiers that do not meet this criterion:

<pre>
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(object): pass
...
>>> o=C()
>>> setattr(o, "$$$", True)
>>>  dir(o)
['$$$', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__in
module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__su
__', '__weakref__']
>>> o.$$$
  File "<stdin>", line 1
    o.$$$
      ^
SyntaxError: invalid syntax
>>>
</pre>

----------
components: Interpreter Core
messages: 251248
nosy: W deW
priority: normal
severity: normal
status: open
title: setattr accepts invalid identifiers
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 21 21:57:01 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Sep 2015 19:57:01 +0000
Subject: [New-bugs-announce] [issue25206] PEP 498: Minor mistakes/outdateness
Message-ID: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

"""
For example, this code:

 f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'

Might be be evaluated as:

 'abc' + format(expr1, spec1) + format(repr(expr2)) + 'def' + format(str(expr3)) + 'ghi'
"""

format(repr(expr2)) should be format(repr(expr2), spec2)



"""
>>> f'x={x'
  File "<stdin>", line 1
SyntaxError: missing '}' in format string expression
"""

Actually implemented exception message is:
SyntaxError: f-string: expecting '}'



"""
>>> f'x={!x}'
  File "<fstring>", line 1
    !x
    ^
SyntaxError: invalid syntax
"""

Actually implemented exception message is:
SyntaxError: f-string: invalid conversion character: expected 's', 'r', or 'a'

----------
assignee: eric.smith
messages: 251250
nosy: Arfrever, eric.smith
priority: normal
severity: normal
status: open
title: PEP 498: Minor mistakes/outdateness

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

From report at bugs.python.org  Mon Sep 21 22:36:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Sep 2015 20:36:38 +0000
Subject: [New-bugs-announce] [issue25207] ICC compiler warnings
Message-ID: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/109/steps/compile/logs/warnings%20%2832%29

     2>C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj(418,5): warning : Toolset Intel C++ Compiler 16.0 is not used for official builds. Your build may have errors or incompatibilities.
     2>..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Modules\_winapi.c(1083): warning #1478: function "GetVersion" (declared at line 110 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\PC\winreg.c(885): warning #810: conversion from "void *" to "DWORD={unsigned long}" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\PC\msvcrtmodule.c(544): warning #592: variable "st" is used before its value is set [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
     2>..\Python\sysmodule.c(830): warning #1478: function "GetVersionExA" (declared at line 433 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
    19>..\PC\_msi.c(1035): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
    19>..\PC\_msi.c(1036): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
    19>..\PC\_msi.c(1037): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
    19>..\PC\_msi.c(1038): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
    19>..\PC\_msi.c(1039): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
         C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj(418,5): warning : Toolset Intel C++ Compiler 16.0 is not used for official builds. Your build may have errors or incompatibilities.
         ..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Modules\_winapi.c(1083): warning #1478: function "GetVersion" (declared at line 110 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\PC\winreg.c(885): warning #810: conversion from "void *" to "DWORD={unsigned long}" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\PC\msvcrtmodule.c(544): warning #592: variable "st" is used before its value is set [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\Python\sysmodule.c(830): warning #1478: function "GetVersionExA" (declared at line 433 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj]
         ..\PC\_msi.c(1035): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
         ..\PC\_msi.c(1036): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
         ..\PC\_msi.c(1037): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
         ..\PC\_msi.c(1038): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]
         ..\PC\_msi.c(1039): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj]

----------
messages: 251253
nosy: haypo
priority: normal
severity: normal
status: open
title: ICC compiler warnings
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 21 22:59:47 2015
From: report at bugs.python.org (Benjamin Hodgson)
Date: Mon, 21 Sep 2015 20:59:47 +0000
Subject: [New-bugs-announce] [issue25208] improvements to the asyncio
	documentation
Message-ID: <1442869187.79.0.516080462087.issue25208@psf.upfronthosting.co.za>


New submission from Benjamin Hodgson:

I spotted some grammatical errors in the "Develop with asyncio" page, so I improved the wording a bit. I also added a more explicit link to BaseEventLoop.set_debug().

----------
assignee: docs at python
components: Documentation
files: asynciodocs.patch
keywords: patch
messages: 251260
nosy: Benjamin Hodgson, docs at python
priority: normal
severity: normal
status: open
title: improvements to the asyncio documentation
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40537/asynciodocs.patch

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

From report at bugs.python.org  Mon Sep 21 23:25:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Sep 2015 21:25:14 +0000
Subject: [New-bugs-announce] [issue25209] Append space after completed
	keywords
Message-ID: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Open parenthesis ('(') is appended after completed callable globals and attributes. I propose to add a space after completed keyword. In most cases a space is either required after the keyword, or recommended by PEP8. Attached patch implements this.

----------
components: Extension Modules
files: rlcompleter_keyword_space.patch
keywords: patch
messages: 251262
nosy: pitrou, r.david.murray, serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: Append space after completed keywords
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40538/rlcompleter_keyword_space.patch

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

From report at bugs.python.org  Tue Sep 22 07:48:47 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Sep 2015 05:48:47 +0000
Subject: [New-bugs-announce] [issue25210] Special-case NoneType() in
	do_richcompare()
Message-ID: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

do_richcompare() has a comment (at Objects/object.c:689) that reads:

/* XXX Special-case None so it doesn't show as NoneType() */

This refers to the following error message:

>>> 3 < None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < NoneType()

This is a common error that comes up while ordering/sorting, and NoneType() is potentially confusing, so I find the request reasonable.
If the consensus is favourable, it should be implemented, if not, the comment should be removed.

----------
components: Interpreter Core
keywords: easy
messages: 251288
nosy: ezio.melotti
priority: low
severity: normal
stage: test needed
status: open
title: Special-case NoneType() in do_richcompare()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 22 09:52:15 2015
From: report at bugs.python.org (s-wakaba)
Date: Tue, 22 Sep 2015 07:52:15 +0000
Subject: [New-bugs-announce] [issue25211] Error message formatting errors in
 int object unit-test script
Message-ID: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za>


New submission from s-wakaba:

I've found some parts there are illegal message formatting in int object unit test script "Lib/test/test_long.py" when hacking the interpreter.

because they were an easy problem, I already fixed them to promote my work.
Therefore, the patch has been attacked.

thanks

----------
components: Tests
files: test_long.py.patch
keywords: patch
messages: 251291
nosy: s-wakaba
priority: normal
severity: normal
status: open
title: Error message formatting errors in int object unit-test script
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40543/test_long.py.patch

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

From report at bugs.python.org  Tue Sep 22 14:18:16 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 22 Sep 2015 12:18:16 +0000
Subject: [New-bugs-announce] [issue25212] Remove the double spaces in the
	C-API Intro
Message-ID: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

Remove the double spaces in the C-API intro in the documentation.

----------
assignee: docs at python
components: Documentation
files: remove_double_space_capi.patch
keywords: patch
messages: 251310
nosy: docs at python, matrixise
priority: normal
severity: normal
status: open
title: Remove the double spaces in the C-API Intro
versions: Python 3.6
Added file: http://bugs.python.org/file40548/remove_double_space_capi.patch

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

From report at bugs.python.org  Tue Sep 22 15:48:40 2015
From: report at bugs.python.org (Nick Evans)
Date: Tue, 22 Sep 2015 13:48:40 +0000
Subject: [New-bugs-announce] [issue25213] Regression: Python 3.5.0
 shutil.copy2 doesn't raise PermissionError on Windows 7
Message-ID: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za>


New submission from Nick Evans:

Python 3.5.0 shutil.copy2 doesn't raise PermissionError when it does not have permission to copy a file (tested on Windows 7):

C:\Users\X\Desktop>C:\Users\X\AppData\Local\Programs\Python\Python35-32\python.exe
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("test.txt", "/")
'/test.txt'
>>> shutil.copy2("test.txt", "C:\\")
'C:\\test.txt'

NB: The file is not copied.

Python 3.4.3 does raise PermissionError:

C:\Users\X\Desktop>C:\Python34\python.exe
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("test.txt", "/")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\shutil.py", line 245, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "C:\Python34\lib\shutil.py", line 109, in copyfile
    with open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: '/test.txt'
>>> shutil.copy2("test.txt", "C:\\")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\shutil.py", line 245, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "C:\Python34\lib\shutil.py", line 109, in copyfile
    with open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: 'C:\\test.txt'

----------
components: Library (Lib)
messages: 251322
nosy: nre3976
priority: normal
severity: normal
status: open
title: Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 22 16:16:37 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 22 Sep 2015 14:16:37 +0000
Subject: [New-bugs-announce] [issue25214] asyncio ssl transport regression
Message-ID: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Before using SSL BIO (which is great itself BTW) I has a way to access peers certificate by `ssl_transp.get_extra_info('socket').getpeercert()` call.

Now socket is a regular socket without `.getpeercert()` method.
I use hack like `ssl_transp._ssl_protocol._sslpipe.ssl_object.getpeercert()` as workaround but really interesting in the proper way to do this using public API only.

I suggest adding 'ssl_object' key to `ssl_proto` for BIO-based SSL.

Thoughts?

P.S.
See aiohttp commit for workaround bugfix: https://github.com/KeepSafe/aiohttp/commit/e286d4f9fb1993de2438bdca40712cf1660faf9e

----------
components: asyncio
keywords: 3.5regression
messages: 251323
nosy: asvetlov, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio ssl transport regression
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 22 17:08:36 2015
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 22 Sep 2015 15:08:36 +0000
Subject: [New-bugs-announce] [issue25215] Simple extension to iter(): iter()
 returns empty generator
Message-ID: <1442934516.43.0.38615635977.issue25215@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

When looking for a "neat" way to create an empty generator, I saw on stackOverflow that the crowd wasn't sure what was the "least ugly" way to do it.
Proposals where:
def emptyIter(): return; yield
or
def emptyIter(): return iter([])

Then it struck me that a trivial extension to the iter() built-in would be to allow to call it without arguments, thus giving a simple to understand empty iterator, and allowing:
def emptyIter(): return iter()
(And, of course, this function would not need to exist in any reasonable program in that case.)

The implementation would be trivial, I assume.

----------
components: Library (Lib)
messages: 251324
nosy: jneb
priority: normal
severity: normal
status: open
title: Simple extension to iter(): iter() returns empty generator
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/issue25215>
_______________________________________

From report at bugs.python.org  Tue Sep 22 17:47:00 2015
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 22 Sep 2015 15:47:00 +0000
Subject: [New-bugs-announce] [issue25216] Warnings stacklevel frames to skip
Message-ID: <1442936820.56.0.704192147978.issue25216@psf.upfronthosting.co.za>


New submission from Jim Jewett:

warnings.warn(stacklevel=2) is a longstanding idiom.

It broke in 3.3 because python itself added some additional infrastructure frames in between; now stacklevel should be 8 or 10 in some releases.

issue24305 adds a workaround for 3.5, to ignore internal frames -- defined as those which contain both 'importlib' and '_bootstrap' in filename.

I would prefer to see a supported hook, so that either the caller or the program setup could list other modules or packages to ignore when counting frames.  That way, I could write

mycall(otherlib(foo))

and otherlib could ensure that the warning pointed to mycall, rather than to something internal to otherlib, even if otherlib were refactored to a different stack depth.

Ignoring just the import machinery would of course be a good default.

----------
components: Library (Lib)
messages: 251328
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: Warnings stacklevel frames to skip
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 22 20:59:11 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Sep 2015 18:59:11 +0000
Subject: [New-bugs-announce] [issue25217] Method cache can crash at shutdown
	in _PyType_Lookup
Message-ID: <1442948351.56.0.970630575285.issue25217@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

In the following gdb backtrace you'll see that if Python code is executed from the PyInterpreterState_Clear() step in Py_Finalize() (apparently when clearing the builtins), _PyType_Lookup() can be executed and crash on a NULL entry in the method cache.

Note the reason this happens is that we set a weakref callback on the global print() function, and for some reason the weakref is able to survive longer than the global print() function. We don't have the crash on previous versions of Python (< 3.5).

Here is the backtrace:

#0  0x00007fc17dba90cf in _PyType_Lookup (type=type at entry=0x291e0d8, name=name at entry='_globals') at Objects/typeobject.c:2913
#1  0x00007fc17db90346 in _PyObject_GenericGetAttrWithDict (obj=
    <Context(_globals=<UniqueDict at remote 0x7fc1751aced8>, attributes={<_TypeMetaclass(_abc_negative_cache_version=30, __module__='numba.types', _abc_registry=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c384a8>, data=set()) at remote 0x7fc175c366d8>, __doc__=None, __abstractmethods__=frozenset(), _abc_negative_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c38618>, data=set()) at remote 0x7fc175c36878>, _abc_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c38560>, data=set()) at remote 0x7fc175c367a8>) at remote 0x2809e18>: <NamedTupleAttribute(context=<...>) at remote 0x7fc1741c2948>, <_TypeMetaclass(_abc_negative_cache_version=30, _abc_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c269b0>, data=set()) at remote 0x7fc175c286d8>, key=<property at remote 0x7fc175c2a058>, __init__=<function at remote 0x7fc175c26560>, can_convert_to=<function a...(truncated), name='_globals', 
    dict=dict at entry=0x0) at Objects/object.c:1052
#2  0x00007fc17db905ef in PyObject_GenericGetAttr (obj=<optimized out>, name=<optimized out>) at Objects/object.c:1119
#3  0x00007fc17db8e3c4 in PyObject_GetAttr (
    v=v at entry=<Context(_globals=<UniqueDict at remote 0x7fc1751aced8>, attributes={<_TypeMetaclass(_abc_negative_cache_version=30, __module__='numba.types', _abc_registry=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c384a8>, data=set()) at remote 0x7fc175c366d8>, __doc__=None, __abstractmethods__=frozenset(), _abc_negative_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c38618>, data=set()) at remote 0x7fc175c36878>, _abc_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c38560>, data=set()) at remote 0x7fc175c367a8>) at remote 0x2809e18>: <NamedTupleAttribute(context=<...>) at remote 0x7fc1741c2948>, <_TypeMetaclass(_abc_negative_cache_version=30, _abc_cache=<WeakSet(_iterating=set(), _pending_removals=[], _remove=<function at remote 0x7fc175c269b0>, data=set()) at remote 0x7fc175c286d8>, key=<property at remote 0x7fc175c2a058>, __init__=<function at remote 0x7fc175c26560>, can_convert_to=<function a...(truncated), name=<optimized out>)
    at Objects/object.c:889
#4  0x00007fc17dc37e9d in PyEval_EvalFrameEx (
    f=f at entry=Frame 0x7fc17c7887f8, for file /home/antoine/numba/numba/typing/context.py, line 238, in on_disposal (wr=<weakref at remote 0x7fc1741bd2d8>), throwflag=throwflag at entry=0) at Python/ceval.c:2688
#5  0x00007fc17dc3c56c in _PyEval_EvalCodeWithName (_co=<code at remote 0x7fc1799ffe80>, globals=<optimized out>, locals=locals at entry=0x0, 
    args=args at entry=0x7fc174b5e428, argcount=1, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, 
    closure=(<cell at remote 0x7fc17421c358>,), name=0x0, qualname=0x0) at Python/ceval.c:3962
#6  0x00007fc17dc3c659 in PyEval_EvalCodeEx (_co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x7fc174b5e428, 
    argcount=<optimized out>, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=(<cell at remote 0x7fc17421c358>,))
    at Python/ceval.c:3983
#7  0x00007fc17db66f08 in function_call (func=<function at remote 0x7fc1741c4280>, arg=(<weakref at remote 0x7fc1741bd2d8>,), kw=0x0)
    at Objects/funcobject.c:632
#8  0x00007fc17db30ce1 in PyObject_Call (func=func at entry=<function at remote 0x7fc1741c4280>, arg=arg at entry=(<weakref at remote 0x7fc1741bd2d8>,), 
    kw=kw at entry=0x0) at Objects/abstract.c:2147
#9  0x00007fc17db318e8 in PyObject_CallFunctionObjArgs (callable=callable at entry=<function at remote 0x7fc1741c4280>) at Objects/abstract.c:2427
#10 0x00007fc17dc04228 in handle_callback (ref=ref at entry=0x7fc1741bd2d8, callback=callback at entry=<function at remote 0x7fc1741c4280>)
    at Objects/weakrefobject.c:868
#11 0x00007fc17dc047aa in PyObject_ClearWeakRefs (object=object at entry=<built-in method print of module object at remote 0x7fc17e1adc58>)
    at Objects/weakrefobject.c:913
#12 0x00007fc17db8b57c in meth_dealloc (m=m at entry=0x7fc17e1b2d00) at Objects/methodobject.c:155
#13 0x00007fc17db8ee49 in _Py_Dealloc (op=<built-in method print of module object at remote 0x7fc17e1adc58>) at Objects/object.c:1786
#14 0x00007fc17db79ca0 in free_keys_object (keys=keys at entry=0x221cef0) at Objects/dictobject.c:354
#15 0x00007fc17db7bb63 in dict_dealloc (mp=mp at entry=0x7fc17e1d62f8) at Objects/dictobject.c:1567
#16 0x00007fc17db8ee49 in _Py_Dealloc (
    op={'FileExistsError': <type at remote 0x7fc17dfab6c0>, 'NotImplementedError': <type at remote 0x7fc17dfaa380>, 'eval': <built-in method eval of builtin_function_or_method object at remote 0x7fc17e1649b8>, 'SystemError': <type at remote 0x7fc17dfa7e40>, 'max': <built-in method max of module object at remote 0x7fc17e1adc58>, 'repr': <built-in method repr of module object at remote 0x7fc17e1adc58>, 'sum': <built-in method sum of module object at remote 0x7fc17e1adc58>, 'ValueError': <type at remote 0x7fc17dfa90c0>, 'Ellipsis': <ellipsis at remote 0x7fc17dfbbba0>, 'next': <built-in method next of builtin_function_or_method object at remote 0x7fc17e1b2328>, 'tuple': <type at remote 0x7fc17dfbc840>, 'StopIteration': <type at remote 0x7fc17dfad080>, 'ReferenceError': <type at remote 0x7fc17dfa7c80>, 'OverflowError': <type at remote 0x7fc17dfa81c0>, 'RuntimeWarning': <type at remote 0x7fc17dfa6e80>, 'issubclass': <built-in method issubclass of builtin_function_or_method object at remote 0x7fc17e1b2b20>, 'range': <type ...(truncated)) at Objects/object.c:1786
#17 0x00007fc17dc6520a in PyInterpreterState_Clear (interp=0x21f4470) at Python/pystate.c:119
#18 0x00007fc17dc63771 in Py_Finalize () at Python/pylifecycle.c:633
#19 0x00007fc17dc640cb in Py_Exit (sts=sts at entry=0) at Python/pylifecycle.c:1454
#20 0x00007fc17dc668ed in handle_system_exit () at Python/pythonrun.c:602
#21 0x00007fc17dc67858 in PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars at entry=1) at Python/pythonrun.c:612
#22 0x00007fc17dc67cb1 in PyErr_Print () at Python/pythonrun.c:508
#23 0x00007fc17dc68eb7 in PyRun_SimpleFileExFlags (fp=fp at entry=0x22bce90, filename=<optimized out>, filename at entry=0x7fc17e152550 "numba/pycc/pycc", 
    closeit=closeit at entry=1, flags=flags at entry=0x7ffc35eb0970) at Python/pythonrun.c:401
#24 0x00007fc17dc6900c in PyRun_AnyFileExFlags (fp=fp at entry=0x22bce90, filename=0x7fc17e152550 "numba/pycc/pycc", closeit=closeit at entry=1, 
    flags=flags at entry=0x7ffc35eb0970) at Python/pythonrun.c:80
#25 0x00007fc17dc83e57 in run_file (fp=fp at entry=0x22bce90, filename=filename at entry=0x21f4300 L"numba/pycc/pycc", p_cf=p_cf at entry=0x7ffc35eb0970)
    at Modules/main.c:318
#26 0x00007fc17dc84a9b in Py_Main (argc=argc at entry=3, argv=argv at entry=0x21f3020) at Modules/main.c:769
#27 0x0000000000400bea in main (argc=3, argv=0x7ffc35eb0b88) at ./Programs/python.c:69

Some inspection of local variables at the crash point:

(gdb) p type
$1 = (PyTypeObject *) 0x291e0d8
(gdb) p type->tp_flags
$2 = 808449
(gdb) p type->tp_version_tag 
$3 = 1769
(gdb) p method_cache
$4 = {{version = 0, name = 0x0, value = 0x0} <repeats 3483 times>, {version = 1769, name = 0x0, value = 0x0}, {version = 0, name = 0x0, 
    value = 0x0} <repeats 612 times>}
(gdb) p method_cache[h]
$5 = {version = 1769, name = 0x0, value = 0x0}

----------
components: Interpreter Core
messages: 251341
nosy: pitrou
priority: normal
severity: normal
status: open
title: Method cache can crash at shutdown in _PyType_Lookup
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep 23 05:42:35 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2015 03:42:35 +0000
Subject: [New-bugs-announce] [issue25218] Automate creation of
 idlelib/help.html from Doc/.../idle.html
Message-ID: <1442979755.02.0.25591432423.issue25218@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This continues #16893, which replaced help.txt with help.html for the Idle doc display.  It also replaced the display classes with new classes in help.py.  I currently create help.html in a .bat file.  With Doc as current directory, it uses
  ..\pcbuild\python_d.exe -c "from idlelib.help import copy_strip; copy_strip()"
With a change to the help.py if __name__ block so that
  ..\pcbuild\python_d.exe -m idlelib.help copy_strip
would work.

This issue is first about revising Zack Ware's makefile patch, https://bugs.python.org/file36975/issue16893-v4.diff, which adds an 'idledoc' target.  It is attached to #16893.  It needs 'copy' replaced by 'copy, strip, and rename'. The command above requires finding a compatible python.exe, and I do not know if that is a problem.

In normal use, 'idledoc' should only be invoked for the earliest 3.x getting maintenance patches, and the result merged forward.

If this is resolved, it would be nice if the new 'idledoc' target were built as apart of the release process, and any changes checked in.  But the latter should currently still be done for all 3.x branches

----------
assignee: terry.reedy
messages: 251402
nosy: terry.reedy, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Automate creation of idlelib/help.html from Doc/.../idle.html
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/issue25218>
_______________________________________

From report at bugs.python.org  Wed Sep 23 08:34:44 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2015 06:34:44 +0000
Subject: [New-bugs-announce] [issue25219] Update doc for Idle command line
	argument.
Message-ID: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

idle.rst is either wrong or obsolete.  Some options are missing and the notes are not now correct.  I am editing so it matches code and help message in PyShell.py.

I believe there is a mismatch between code and help message with respect to interaction with configuration settings.  But I need to do some tests to be sure.

----------
messages: 251407
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update doc for Idle command line argument.
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/issue25219>
_______________________________________

From report at bugs.python.org  Wed Sep 23 12:12:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Sep 2015 10:12:34 +0000
Subject: [New-bugs-announce] [issue25220] Enhance and refactor test.regrtest
 (convert regrtest.py to a package)
Message-ID: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The Lib/test/regrtest.py file became a monster. It's very long, it uses a lot of global variables. It's hard to review and hard to maintain. I propose to:

- split single file regrtest.py into multiple files in a new Lib/test/regrtest/ package
- refactor the test runner as a class to avoid global variables
- refactor the multiprocessing test runner as a class in a separated file

Attached patch implements this idea.


The following commands still work:

   ./python -m test [options] [args]
   ./python -m test.regrtest [options] [args]

But the following command doesn't work anymore:

   ./python Lib/test/regrtest.py [options] [args]

If regrtest.py is executed directly on buildbots, these buildbots should be modified first.


The "./python -m test.regrtest" command should work on all Python versions (Python 2 and Python 3) and so should be preferred. The "./python -m test" command only works on Python 3 (thanks to the new __main__.py feature).


The change adds a new feature: it now displays name of concurrent tests running since 30 seconds or longer when the multiprocessing test runner is used (-j command line option). Example:

    ...
    [240/399] test_uu
    [241/399] test_urllib_response
    [242/399] test_struct
    [243/399] test_descrtut
    [244/399] test_threadedtempfile
    [245/399] test_tracemalloc -- running: test_concurrent_futures (30 sec)
    [246/399] test_dbm_dumb -- running: test_concurrent_futures (30 sec)
    [247/399] test_codeop -- running: test_concurrent_futures (30 sec)
    ...
    [395/399/1] test_asyncio -- running: test_multiprocessing_fork (40 sec), test_multiprocessing_spawn (44 sec)
    [396/399/1] test_faulthandler -- running: test_multiprocessing_fork (50 sec), test_multiprocessing_spawn (54 sec)
    [397/399/1] test_multiprocessing_fork (52 sec) -- running: test_multiprocessing_spawn (56 sec)
    [398/399/1] test_multiprocessing_spawn (68 sec) -- running: test_multiprocessing_forkserver (39 sec)
    [399/399/1] test_multiprocessing_forkserver (50 sec)

I want this feature to analysis why more and more buildbots fail with a timeout without saying which test was running (well, I suspect multiprocessing tests...).

Note: faulthandler can show where regrtest is blocked, but not when the multiprocessing test runner is used. And sometimes the process is killed by the buildbot, not by faulthandler :-/


Another minor new feature: on CTRL+c, it shows which tests are running when the multiprocessing test runner is used. Example:

    [ 38/399] test_dummy_thread
    [ 39/399] test_codecmaps_jp
    [ 40/399] test_future5
    ^C
    Waiting for test_scope, test_decimal, test_memoryview, test_heapq, test_unicodedata, test_trace, test_threadsignals, test_cgitb, test_runpy, test_cmd_line_script


Other changes:

* Show test timing when a test runs longer than 30 seconds

* Don't make __file__ absolute, findtestdir() calls os.path.abspath() instead. Remove these lines:

    __file__ = os.path.abspath(__file__)
    assert __file__ == os.path.abspath(sys.argv[0])

* print() is now called wih flush=True (it didn't check all calls, only the major calls), remove sys.stdout.flush() and  sys.stdout.flush()

* A lot of refactoring. Sorry, I didn't take notes for each change.


I fear that test_regrtest has a small code coverage. I only tested major options, I didn't test -R for example.


Note: I don't understand how the --single option works when regrtest is not run from the Python source code directory. A temporary directory, so the pynexttest file is removed after its creation, no? If it doesn't make sense to use --single outside Python directory, maybe an error should be raised?

----------
components: Tests
files: regrtest_package.patch
keywords: patch
messages: 251419
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Enhance and refactor test.regrtest (convert regrtest.py to a package)
versions: Python 3.6
Added file: http://bugs.python.org/file40554/regrtest_package.patch

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

From report at bugs.python.org  Wed Sep 23 19:23:52 2015
From: report at bugs.python.org (s-wakaba)
Date: Wed, 23 Sep 2015 17:23:52 +0000
Subject: [New-bugs-announce] [issue25221] PyLong_FromLong() potentially
 returns irregular object when small_ints[] isn't used
Message-ID: <1443029032.54.0.224615984306.issue25221@psf.upfronthosting.co.za>


New submission from s-wakaba:

When compiling cpython with specifying NSMALLPOSINTS and NSMALLNEGINTS macros as zero to skip making small_ints[] array, like following command, process couldn't finish.

$ ./configure CPPFLAGS='-DNSMALLPOSINTS=0 -DNSMALLNEGINTS=0'
$ make

The reason looks a problem that PyLong_FromLong(0) returns irregular int object: Py_SIZE(zero_int) must be 0, but it becomes 1.

maybe this problem never appears in actual cases, but in "longobject.c", it still looks supported to compile without small_ints[].
I don't know it should be fixed or not. but, as a result, I could compile cpython after addition of one line like attached patch.
Could you confirm this point?

Thanks.

----------
components: Interpreter Core
files: longobject.c.patch
keywords: patch
messages: 251436
nosy: s-wakaba
priority: normal
severity: normal
status: open
title: PyLong_FromLong() potentially returns irregular object when small_ints[] isn't used
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40555/longobject.c.patch

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

From report at bugs.python.org  Wed Sep 23 22:58:54 2015
From: report at bugs.python.org (Bernie Hackett)
Date: Wed, 23 Sep 2015 20:58:54 +0000
Subject: [New-bugs-announce] [issue25222] 3.5.0 regression - Fatal Python
 error: Cannot recover from stack overflow
Message-ID: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za>


New submission from Bernie Hackett:

While running PyMongo's test suite against python 3.5.0 the interpreter inconsistently aborts when we test encoding a recursive data structure like:

evil = {}
evil['evil'] = evil

The test that triggers this was added to test the use of Py_EnterRecursiveCall in PyMongo's C extensions and passes without issues on all previous CPython releases back to 2.4.x (the oldest version PyMongo supports). The interesting thing about this abort is that it only occurs when testing PyMongo *without* its C extensions. The stacktrace looks like this:

test_bad_encode (test_bson.TestBSON) ... Exception ignored in: <bound method PeriodicExecutor.close of <pymongo.periodic
_executor.PeriodicExecutor object at 0x00000000046AB0F0>>
RecursionError: maximum recursion depth exceeded while calling a Python object
Fatal Python error: Cannot recover from stack overflow.
 
Thread 0x00000b6c (most recent call first):
  File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 105 in _run
  File "C:\Python35\lib\threading.py", line 871 in run
  File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
  File "C:\Python35\lib\threading.py", line 891 in _bootstrap
 
Thread 0x00000690 (most recent call first):
  File "C:\Python35\lib\threading.py", line 297 in wait
  File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait
  File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in _run
  File "C:\Python35\lib\threading.py", line 871 in run
  File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
  File "C:\Python35\lib\threading.py", line 891 in _bootstrap
 
Thread 0x00000900 (most recent call first):
  File "C:\Python35\lib\threading.py", line 297 in wait
  File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait
  File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in _run
  File "C:\Python35\lib\threading.py", line 871 in run
  File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
  File "C:\Python35\lib\threading.py", line 891 in _bootstrap
 
Current thread 0x00000a20 (most recent call first):
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in <listcomp>
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson
  File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson

My current working theory is if RecursionError is raised during a thread switch the recursion depth is deemed too great to recover from. Maybe the GIL is no longer being held during some call to _Py_CheckRecursiveCall? This failure looks suspiciously similar to issue22971 given that, in that ticket, the failure occurs while or immediately after running test_thread.

The failure has been observed on 64 and 32bit Windows 7 VMs as well as a 64bit Amazon Linux instance. Sadly, I haven't yet been able to devise a reproduction that doesn't involve running PyMongo's test suite.

----------
components: Interpreter Core
messages: 251453
nosy: behackett
priority: normal
severity: normal
status: open
title: 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 23 23:52:16 2015
From: report at bugs.python.org (acx01bc)
Date: Wed, 23 Sep 2015 21:52:16 +0000
Subject: [New-bugs-announce] [issue25223] Statically or dynamically linked
 to the VC++runtime ? or how Python install fails o Vista despite the VC
 redist packages - api-ms-win-crt-runtime-l1-1-0.dll
Message-ID: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>


New submission from acx01bc:

I think you should build Python.exe with the option to be statically linked to the VC++-runtime. This way, the executable is a little bigger, but you ensure nobody will have troubles with some VC-runtime different Dll versions.

DETAILS : (I posted it also there http://stackoverflow.com/questions/32748932/python-3-4-3-works-on-windows-vista-but-not-3-5-0-because-of-vc-redist-package )

I am on Windows Vista 32bits. I downloaded Python 3.5.0 but I got the famous api-ms-win-crt-runtime-l1-1-0.dll problem. Then I installed many Visual C++ Redistributable Packages (I tried the 2015's one, then 2013, and 2012) but none of these packages installed any .dll of the correct name. Then, I tried to download a previous version of Python, the 3.3.2 win32 release, I got the same problem !

----> Then, I downloaded the Python 3.4.3 Win32 release, and this-one worked immediately. I suspect that version to have been statically linked with the VC-runtime. This clearly lacks of coherence, some Python releases work, while others don't. So I hope some of the Python developers will see that message and will be able to build some binaries compatible with Windows Vista and the VC-redist-packages.

Question : did anyone understand where that api-ms-win-crt-runtime-l1-1-0.dll comes from ? I suppose it is related to the VC++ compiler options used when building Python.exe (on my VS2010 I have the options code generation/runtime library/multi-threaded, static or dynamic and general/platform_toolset, V100, V110, V120 or V140) ?

----------
components: Installation
messages: 251463
nosy: acx01bc
priority: normal
severity: normal
status: open
title: Statically or dynamically linked  to the VC++runtime ? or how Python install fails o Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 23 23:56:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2015 21:56:49 +0000
Subject: [New-bugs-announce] [issue25224] Replace Idle's README.txt with
	annotated file list
Message-ID: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

idlelib currently has user information that belongs in either the Idle reference idle.rst or possibly a separate Idle howto #17583. This information should be removed and replaced with an annotated list of files in idlelib.  The latter would help people working of Idle, and even people just browsing.

----------
assignee: terry.reedy
components: IDLE
messages: 251464
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace Idle's README.txt with annotated file list
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep 24 01:11:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Sep 2015 23:11:41 +0000
Subject: [New-bugs-announce] [issue25225] Idle doc: redo Syntax Colors
	section
Message-ID: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I plan to make the following changes to the Syntax colors section:

* Change name to Text and syntax colors, as not all colors are code-syntax related.

* Make it a subsection of the previous Editing and navigation section, which is about editor and shell windows, which are what get colored. Begin by stating that both window types get colored.

* Greatly reduce excessive white space.  Put item and default color on one line, such as * Strings: green, and single space lines.

* Add missing item: color pairs

* Correct instruction on how to change defaults.

----------
assignee: terry.reedy
messages: 251468
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle doc: redo Syntax Colors section
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/issue25225>
_______________________________________

From report at bugs.python.org  Thu Sep 24 11:34:38 2015
From: report at bugs.python.org (NobilisVir)
Date: Thu, 24 Sep 2015 09:34:38 +0000
Subject: [New-bugs-announce] [issue25226] "suffix" attribute not documented
 in logging.TimedRotatingFileHandler
Message-ID: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za>


New submission from NobilisVir:

The suffix attribute that controls the timestamp portion that gets appended to the file name is not documented (but it would be very useful to be). The documentation is here - https://docs.python.org/2/library/logging.handlers.html#timedrotatingfilehandler

I learned about this attribute from an SO answer after searching for a solution to how to control the file name (this answer - http://stackoverflow.com/a/338566/1006955).

----------
assignee: docs at python
components: Documentation
messages: 251503
nosy: NobilisVir, docs at python
priority: normal
severity: normal
status: open
title: "suffix" attribute not documented in logging.TimedRotatingFileHandler
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 24 14:48:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Sep 2015 12:48:03 +0000
Subject: [New-bugs-announce] [issue25227] Optimize ASCII/latin1 encoder with
 surrogateescape error handlers
Message-ID: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch is based on faster_surrogates_hadling.patch written by Serhiy Storchaka for the issue #24870. It optimizes str.encode('ascii', 'surrogateescape') and str.encode('ascii', 'latin1').

----------
messages: 251516
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize ASCII/latin1 encoder with surrogateescape error handlers
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 24 18:57:56 2015
From: report at bugs.python.org (Tim Graham)
Date: Thu, 24 Sep 2015 16:57:56 +0000
Subject: [New-bugs-announce] [issue25228] Regression in cookie parsing with
	brackets and quotes
Message-ID: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>


New submission from Tim Graham:

Regression in https://hg.python.org/cpython/rev/9e765e65e5cb (affects 2.7 and 3.2+), similar to issue22931 where inserting an invalid cookie value can cause the rest of the cookie to be ignored. A test is attached, and here's a quick demo:

Old:
>>> from http.cookies import SimpleCookie
>>> SimpleCookie('a=b; messages=[\"\"]; c=d;')
{'a': 'b', 'c': 'd', 'messages': ''}

New:
>>> SimpleCookie('a=b; messages=[\"\"]; c=d;')
{'a': 'b'}

Reported in Django's tracker, but Django simply delegates to SimpleCookie: https://code.djangoproject.com/ticket/25458

----------
components: Library (Lib)
files: cookie-bracket-quotes-test.diff
keywords: patch
messages: 251538
nosy: Tim.Graham
priority: normal
severity: normal
status: open
title: Regression in cookie parsing with brackets and quotes
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/file40566/cookie-bracket-quotes-test.diff

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

From report at bugs.python.org  Thu Sep 24 23:32:11 2015
From: report at bugs.python.org (Calvin Walton)
Date: Thu, 24 Sep 2015 21:32:11 +0000
Subject: [New-bugs-announce] [issue25229] distutils doesn't add "-Wl,
 " prefix to "-R" on Linux if the C compiler  isn't named 'gcc'
Message-ID: <1443130331.16.0.912755488197.issue25229@psf.upfronthosting.co.za>


New submission from Calvin Walton:

On Exherbo, the main C/C++ compilers are named e.g. "x86_64-pc-linux-gnu-cc" and "x86_64-pc-linux-gnu-c++", and they are symlinks to either (usually) gcc or (rarely) clang.

Since distutils (in unixccompiler.py) is checking for the substring "gcc" or "g++" in the compiler name, this does not match our compiler - and the "-Wl," prefix is missing, resulting in link errors in some cases.

(We are particularly noticing this when doing gobject-introspection builds via cmake, where giscanner uses distutils to build the link command)

As far as I know, all major compilers on Linux require the -Wl, option to pass through linker options - clang actually interprets -R without -Wl, to mean something completely different. We are planning to locally patch distutils to have an additional condition to the gcc check, `sys.platform[:5] == "linux" or self._is_gcc(compiler):` in our distribution to work around the issue.

I'll attach patches once they're prepared, but I'd appreciate feedback about the problem.

----------
components: Distutils
messages: 251546
nosy: Calvin Walton, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils doesn't add "-Wl," prefix to "-R" on Linux if the C compiler  isn't named 'gcc'
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/issue25229>
_______________________________________

From report at bugs.python.org  Fri Sep 25 00:14:21 2015
From: report at bugs.python.org (rb)
Date: Thu, 24 Sep 2015 22:14:21 +0000
Subject: [New-bugs-announce] [issue25230] Unix datagram sockets not supported
Message-ID: <1443132861.89.0.286854164453.issue25230@psf.upfronthosting.co.za>


New submission from rb:

AF_UNIX, SOCK_DGRAM sockets are valid, but asyncio doesn't appear to support them.

I've tried combinations of create_connection, create_datagram_endpoint and create_unix_connection, creating a socket myself and passing in sock, and equivalent methods at the server end. There seem to be implicit assumptions about addresses being 2-tuples (instead of strings) and transports being hardcoded to be constructed as either stream or datagram transports. create_unix_connection makes the assumption that it will be a stream, and create_datagram_endpoint that it will be AF_INET or AF_INET6 with (host, port) addressing.

I used 3.4.3, but looking at the docs it doesn't look like this was addressed in 3.5 either.

I'd like this because message boundaries are preserved (unlike in SOCK_STREAM), which if it Just Worked would make local system IPC (eg. with JSON-RPC) extremely trivial to implement in asyncio.

----------
components: asyncio
messages: 251549
nosy: gvanrossum, haypo, rb, yselivanov
priority: normal
severity: normal
status: open
title: Unix datagram sockets not supported
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 25 13:53:57 2015
From: report at bugs.python.org (=?utf-8?q?Ond=C5=99ej_Profant?=)
Date: Fri, 25 Sep 2015 11:53:57 +0000
Subject: [New-bugs-announce] [issue25231] Argparse module and escape
 sequence (special symbols) in argument value
Message-ID: <1443182037.79.0.167999689484.issue25231@psf.upfronthosting.co.za>


New submission from Ond?ej Profant:

I am trying to put tabulator '\t' into argument value. 

Minimal working example:

<code>
#!/usr/bin/env python3

import argparse

def main():
        parser = argparse.ArgumentParser()
        parser.add_argument('-f', '--foo', default="test", help="test")
        args = parser.parse_args()

        print("Argument foo is: " + args.foo + "|")
        print("Tabulator usage: |\t|")

if __name__ == '__main__':
        main()
</code>

My attempts:
./test.py -f \t
./test.py -f '\t'
./test.py -f "\t"

But this is not functional. Is there way to put special characters into argument?
~

----------
components: Library (Lib)
messages: 251580
nosy: Ond?ej Profant
priority: normal
severity: normal
status: open
title: Argparse module and escape sequence (special symbols) in argument value
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 25 17:44:41 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 25 Sep 2015 15:44:41 +0000
Subject: [New-bugs-announce] [issue25232] CGIRequestHandler behave
 incorrectly with query component consisting mutliple ?
Message-ID: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

According to rfc3986, section 3.4:

 The query component is indicated by the first question
 mark ("?") character and terminated by a number sign ("#") character
 or by the end of the URI.

 The characters slash ("/") and question mark ("?") may represent data
 within the query component.

But for CGIRequestHandler, it uses the content after the last ? as
query component. For uri http://localhost:8000/cgi-bin/test.py?a=b?c=d,
the QUERY_STRING is c=d.

----------
files: multiple?.diff
keywords: patch
messages: 251586
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: CGIRequestHandler behave incorrectly with query component consisting mutliple ?
Added file: http://bugs.python.org/file40574/multiple?.diff

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

From report at bugs.python.org  Fri Sep 25 19:27:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Sep 2015 17:27:20 +0000
Subject: [New-bugs-announce] [issue25233] AssertionError from asyncio Queue
	get
Message-ID: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

See https://github.com/python/asyncio/issues/265 and https://github.com/python/asyncio/issues/268. This looks like an important regression and we should fix it before 3.5.1 goes out.

The symptom is "AssertionError: queue non-empty, why are getters waiting?" from Queue.get or Queue.get_nowait. The first issue discusses the cause and a possible hack to fix it.

----------
components: asyncio
keywords: 3.5regression
messages: 251590
nosy: gvanrossum, haypo, yselivanov
priority: release blocker
severity: normal
status: open
title: AssertionError from asyncio Queue get
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 25 21:41:19 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 19:41:19 +0000
Subject: [New-bugs-announce] [issue25234] test_einter.test_os_open hangs
	under Xcode 7
Message-ID: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Specifically:
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

I'm assuming this is a Mac issue since none of the buildbots are having a similar issue.

----------
components: Macintosh
messages: 251597
nosy: brett.cannon, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_einter.test_os_open hangs under Xcode 7
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 25 21:47:28 2015
From: report at bugs.python.org (Kai Groner)
Date: Fri, 25 Sep 2015 19:47:28 +0000
Subject: [New-bugs-announce] [issue25235] EmailMessage.add_attachment()
 creates parts with spurious MIME-Version header.
Message-ID: <1443210448.87.0.407287169878.issue25235@psf.upfronthosting.co.za>


New submission from Kai Groner:

Because MIMEPart.add_attachment() creates parts using type(self), EmailMessage.add_attachment() creates parts of type EmailMessage.  This results in a MIME-Version header being added to parts where it isn't needed.

https://tools.ietf.org/html/rfc2045#section-4

----------
components: email
files: test_add_attachment_does_not_add_MIME_Version_in_attachment.patch
keywords: patch
messages: 251600
nosy: barry, groner, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40576/test_add_attachment_does_not_add_MIME_Version_in_attachment.patch

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

From report at bugs.python.org  Fri Sep 25 22:10:38 2015
From: report at bugs.python.org (Brian O'Neill)
Date: Fri, 25 Sep 2015 20:10:38 +0000
Subject: [New-bugs-announce] [issue25236] str.maketrans wrong description
 for optional 3rd parameter
Message-ID: <1443211838.26.0.822902603996.issue25236@psf.upfronthosting.co.za>


New submission from Brian O'Neill:

The doc says "If there is a third argument, it must be a string, whose characters will be mapped to None in the result." The characters of the optional third argument get mapped to '', of course, not to None.

----------
assignee: docs at python
components: Documentation
messages: 251603
nosy: BrianO, docs at python
priority: normal
severity: normal
status: open
title: str.maketrans wrong description for optional 3rd parameter
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 26 05:03:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 03:03:32 +0000
Subject: [New-bugs-announce] [issue25237] Add doc for tkinter
	commondialog.Dialog and subclasses
Message-ID: <1443236612.77.0.515516122635.issue25237@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

As noted in #15346, several modules are not documented except in the code.  Having just had to do that for #25173, I would like there to be a page for commondialog.Dialog and its subclasses, messagebox.Message and colorchooser.Chooser, and the associated module functions.  I hope to submit a .rst file for review if no one else does so.  My plan is to copy from web pages produced by the pydoc server, add markup, and edit.

----------
messages: 251630
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add doc for tkinter commondialog.Dialog and subclasses
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Sep 26 13:57:42 2015
From: report at bugs.python.org (desbma)
Date: Sat, 26 Sep 2015 11:57:42 +0000
Subject: [New-bugs-announce] [issue25238] Version added of context parameter
 for xmlrpc.client.ServerProxy incorrect
Message-ID: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>


New submission from desbma:

Doc of 3.4 branch says the context parameter for xmlrpc.client.ServerProxy was added at version 3.4.3: https://docs.python.org/3.4/library/xmlrpc.client.html?highlight=xmlrpc.client#module-xmlrpc.client

Although doc of 3.5 branch says the context parameter for xmlrpc.client.ServerProxy was added at version 3.5: https://docs.python.org/3/library/xmlrpc.client.html?highlight=xmlrpc.client#module-xmlrpc.client

See issue22960 for original issue and patch.

----------
components: Library (Lib)
messages: 251644
nosy: desbma
priority: normal
severity: normal
status: open
title: Version added of context parameter for xmlrpc.client.ServerProxy incorrect
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 26 18:46:39 2015
From: report at bugs.python.org (Sean Liu)
Date: Sat, 26 Sep 2015 16:46:39 +0000
Subject: [New-bugs-announce] [issue25239] HTMLParser handle_starttag
 replaces entity references in attribute value even without semicolon
Message-ID: <1443285999.33.0.0508878437802.issue25239@psf.upfronthosting.co.za>


New submission from Sean Liu:

In the document of HTMLParser.handle_starttag, it states "All entity references from html.entities are replaced in the attribute values." However it will replace the string if it matches ampersand followed by the entity name without the semicolon.

For example <a href="go?t=buy&currency=usd">foo</a> will produce "t=buy?cy=usd" as the value of href attribute due to "curren" is the entity name for the currency sign.

----------
components: Library (Lib)
files: parserentity.py
messages: 251654
nosy: Sean Liu
priority: normal
severity: normal
status: open
title: HTMLParser handle_starttag replaces entity references in attribute value even without semicolon
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40588/parserentity.py

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

From report at bugs.python.org  Sat Sep 26 18:47:58 2015
From: report at bugs.python.org (Ceridwen)
Date: Sat, 26 Sep 2015 16:47:58 +0000
Subject: [New-bugs-announce] [issue25240] Stack overflow in reprlib causes a
	core dump
Message-ID: <1443286078.54.0.18490843262.issue25240@psf.upfronthosting.co.za>


New submission from Ceridwen:

I have a linked list implementation made of nested tuples with a custom repr:

    def __repr__(self):
        return 'LinkedList(' + ', '.join(repr(v) for v in self) + ')'

(Iterating over a LinkedList returns just its contents.)

When using Raymond Hettinger's recipe for finding the size in memory of an object, https://code.activestate.com/recipes/577504-compute-memory-footprint-of-an-object-and-its-cont/?in=user-178123 , when I set verbose=True and exceed the recursion limit with reprlib.repr, I get the following error:

Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007fa24200d700 (most recent call first):
  File "<name of LinkedList file>.py", line 327 in __repr__
  File "/usr/lib/python3.4/reprlib.py", line 135 in repr_instance
  File "/usr/lib/python3.4/reprlib.py", line 64 in repr1
  File "/usr/lib/python3.4/reprlib.py", line 54 in repr
  File "recipe.py", line 46 in sizeof
  [many instances of the above line repeated]
  ...
Aborted (core dumped)

The line in the recipe it fails when recursing on is:

            print(s, type(o), repr(o), file=stderr)

On 2.7 it fails with a RuntimeError as I'd expect.

----------
components: Library (Lib)
messages: 251655
nosy: ceridwen
priority: normal
severity: normal
status: open
title: Stack overflow in reprlib causes a core dump
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 26 19:29:11 2015
From: report at bugs.python.org (Dum Dum)
Date: Sat, 26 Sep 2015 17:29:11 +0000
Subject: [New-bugs-announce] [issue25241] ctypes: access violation reading
Message-ID: <1443288551.09.0.384343854167.issue25241@psf.upfronthosting.co.za>


New submission from Dum Dum:

On Windows 8.1 64-bit, using a fresh installation of Python 3.5.150.0 64-bit, `error_script.py` crashes, while Python 3.4.3150 and 2.7.10150 (both 64-bit) run the script properly.

Here is a traceback: https://bpaste.net/show/3ecfbf93b96e

----------
files: error_script.py
messages: 251658
nosy: Dum.Dum
priority: normal
severity: normal
status: open
title: ctypes: access violation reading
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file40589/error_script.py

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

From report at bugs.python.org  Sat Sep 26 20:57:37 2015
From: report at bugs.python.org (Open Genomes)
Date: Sat, 26 Sep 2015 18:57:37 +0000
Subject: [New-bugs-announce] [issue25242] Failed tests for Python 3.5.0 on
	shared virtual host
Message-ID: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>


New submission from Open Genomes:

Several tests for Python 3.5.0 failed. 
The install is a local one on a shared virtual server from bluehost.com
This is a local user install, with a prefix in $HOME/python directory. 
Output of uname -a:
Linux box874.bluehost.com 3.12.35.1418868052 #1 SMP Wed Dec 17 20:04:02 CST 2014 x86_64 x86_64 x86_64 GNU/Linux

It would seem that there are no permissions to spawn() a new process, and to write temporary files to /tmp

The tests should be able to work on a virtual server, or the test should check if there are permissions to fork a process and write to a system-wide temporary directory. Of course many installations use Python on virtual hosts and often the system-wide default installation on Linux systems is 2.7.0. The tests need to fail gracefully or accommodate the lack of permissions for to fork new processes and write to system-wide temporary directories.

----------
components: Tests
files: tests.out
messages: 251659
nosy: Open Genomes
priority: normal
severity: normal
status: open
title: Failed tests for Python 3.5.0 on shared virtual host
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file40590/tests.out

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

From report at bugs.python.org  Sun Sep 27 00:40:20 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 26 Sep 2015 22:40:20 +0000
Subject: [New-bugs-announce] [issue25243] decouple string-to-boolean logic
 from ConfigParser.getboolean and offer as separate function
Message-ID: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>


New submission from Joshua Bronson:

ConfigParser.getboolean[1] has logic to convert strings like '0' and 'False' to False. This logic is generally useful in other contexts and need not be coupled to ConfigParser. Would you consider accepting a patch that factored this string-to-boolean logic out of ConfigParser into a standalone function, and changed ConfigParser.getboolean internally to call that?

Thanks for your consideration.

[1] https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.getboolean

----------
messages: 251664
nosy: jab
priority: normal
severity: normal
status: open
title: decouple string-to-boolean logic from ConfigParser.getboolean and offer as separate function
type: enhancement

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

From report at bugs.python.org  Sun Sep 27 01:12:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 23:12:19 +0000
Subject: [New-bugs-announce] [issue25244] Idle: refine right-click behavior
Message-ID: <1443309139.01.0.264782757887.issue25244@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Spinoff from #24988, where I noted "The standard on Windows is to bring up a context menu on right-button-release, not on r-b-press." and asked "What about linux and mac?"

The question is relevant for 'Go to File/Line'.  Look at text where pressed or where released?

Current code in multiple places is
        if macosxSupport.isAquaTk():
            listbox.bind("<ButtonPress-2>", self.popup_event)
            listbox.bind("<Control-Button-1>", self.popup_event)
        else:
            listbox.bind("<ButtonPress-3>", self.popup_event)

Also for paste: where insert?

Thunderbird and Notepad++ move the insertion cursor on rb-press, That is the paste position even if the mouse is moved before release. Notepad does not move the insert cursor. MS Word is confusing, erasing the cursor when the menu is displayed and moving it when the menu goes away.

Additional note: Testing with my middle button, a press and release act the same as left click to move the insertion cursor to the mouse cursor. Moving my mouse while holding the middle button down moves the text pane within the text window. The insertion cursor is not moved. This is pretty much redundant with using the scroll wheel or scroll bar.

----------
assignee: terry.reedy
messages: 251669
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: refine right-click behavior
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 27 07:34:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 05:34:59 +0000
Subject: [New-bugs-announce] [issue25245] Compile warnings in _pickle.c
Message-ID: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Changeset 88d98f6c2d7d causes compile warnings in Modules/_pickle.c.

/home/serhiy/py/cpython/Modules/_pickle.c: In function ?load_counted_long?:
/home/serhiy/py/cpython/Modules/_pickle.c:4752:15: warning: ?pdata? may be used uninitialized in this function [-Wmaybe-uninitialized]
         value = _PyLong_FromByteArray((unsigned char *)pdata, (size_t)size,
               ^
/home/serhiy/py/cpython/Modules/_pickle.c: In function ?load?:
/home/serhiy/py/cpython/Modules/_pickle.c:5534:24: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     idx = Py_CHARMASK(s[0]);
                        ^
/home/serhiy/py/cpython/Modules/_pickle.c:5529:11: note: ?s? was declared here
     char *s;
           ^
/home/serhiy/py/cpython/Modules/_pickle.c:4800:7: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     x = _PyFloat_Unpack8((unsigned char *)s, 0);
       ^
/home/serhiy/py/cpython/Modules/_pickle.c:4795:11: note: ?s? was declared here
     char *s;
           ^

----------
components: Extension Modules
messages: 251683
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compile warnings in _pickle.c
type: compile error
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 27 10:43:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Sep 2015 08:43:41 +0000
Subject: [New-bugs-announce] [issue25246] Alternative algorithm for
	deque_remove()
Message-ID: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The current algorithm for remove() rotates the deque one-by-one until a match is found, pops it off the deque and does single mass rotate to undo the 1-step rotates.

An alternative approach is to use deque_index() to locate the value of interest and use deque_del_item() to remove it.  

If not value is found, the alternative is better because it never moves the data in the deque.  If the value is found, the alternative removes it using two mass rotations.  The advantage in that case is the mass rotates are faster than many 1-step rotates.  The disadvantage is that we go through the pointer chain twice (the first time visiting and comparing every element and the second time only following the chain of links).

If the deque mutates during the search, a RuntimeError is raised.  This is a behavior change, formerly it raised an IndexError.

----------
assignee: rhettinger
files: deque_better_remove.diff
keywords: patch
messages: 251691
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Alternative algorithm for deque_remove()
versions: Python 3.6
Added file: http://bugs.python.org/file40594/deque_better_remove.diff

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

From report at bugs.python.org  Sun Sep 27 16:09:15 2015
From: report at bugs.python.org (Abrantes Araujo Silva Filho)
Date: Sun, 27 Sep 2015 14:09:15 +0000
Subject: [New-bugs-announce] [issue25247] Tkinter modules built successfully
 but removed because they could not be imported
Message-ID: <1443362955.97.0.479963022327.issue25247@psf.upfronthosting.co.za>


New submission from Abrantes Araujo Silva Filho:

I'm trying to compile Python 3.5 on a CentOS 7.1, with TCL 8.6.4, but make always give me the following message:

*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-3.5/_tkinter.cpython-35m-x86_64-linux-gnu.so: undefined symbol: Tcl_GetCharLength

Following modules built successfully but were removed because they could not be imported:
_tkinter


The configure command was the following (both, Tcl and Tk are installed under /usr/local/lib/tcl8.6.4):

CXX=g++ ./configure --prefix=/usr/local/python3 --enable-shared --enable-loadable-sqlite-extensions --enable-ipv6 --with-tcltk-includes="-I/usr/local/lib/tcl8.6.4/include" --with-tcltk-libs="-L/usr/local/lib/tcl8.6.4/lib"

I could not found a solution for this issue, and I do not know if this is a bug.

----------
components: Tkinter
messages: 251703
nosy: abrantesasf
priority: normal
severity: normal
status: open
title: Tkinter modules built successfully but removed because they could not be imported
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 27 17:23:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 15:23:56 +0000
Subject: [New-bugs-announce] [issue25248] Discrepancy in unpickling integers
	with protocol 0
Message-ID: <1443367436.97.0.896349138795.issue25248@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are discrepancies between Python 2 and Python 3, Python and C implementations, INT and LONG opcodes when unpickle integer with protocol 0.

Python 2.7:

>>> import pickle, cPickle
>>> pickle.loads(b'I010\n.')
10
>>> cPickle.loads(b'I010\n.')
8
>>> pickle.loads(b'L010\n.')
8L
>>> cPickle.loads(b'L010\n.')
8L

Python 3.6:

>>> import pickle
>>> pickle.loads(b'I010\n.')
8
>>> pickle._loads(b'I010\n.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1557, in _loads
    encoding=encoding, errors=errors).load()
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1039, in load
    dispatch[key[0]](self)
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1106, in load_int
    val = int(data, 0)
ValueError: invalid literal for int() with base 0: b'010\n'
>>> pickle.loads(b'L010\n.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 0: '010\n'
>>> pickle._loads(b'L010\n.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1557, in _loads
    encoding=encoding, errors=errors).load()
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1039, in load
    dispatch[key[0]](self)
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1126, in load_long
    self.append(int(val, 0))
ValueError: invalid literal for int() with base 0: b'010'

----------
components: Extension Modules, Library (Lib)
messages: 251705
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Discrepancy in unpickling integers with protocol 0
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/issue25248>
_______________________________________

From report at bugs.python.org  Sun Sep 27 21:40:34 2015
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 27 Sep 2015 19:40:34 +0000
Subject: [New-bugs-announce] [issue25249] Unneeded and unsafe mkstemp
 replacement in test_subprocess.py
Message-ID: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>


New submission from Nir Soffer:

The module define unsafe replacement if tempfile.mkstemp is not available.

This function is available in both master and 2.7 branches.

----------
components: Tests
files: 0001-Remove-unneeded-and-unsafe-mkstemp-replacement.patch
keywords: patch
messages: 251720
nosy: nirs
priority: normal
severity: normal
status: open
title: Unneeded and unsafe mkstemp replacement in test_subprocess.py
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40599/0001-Remove-unneeded-and-unsafe-mkstemp-replacement.patch

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

From report at bugs.python.org  Sun Sep 27 22:24:54 2015
From: report at bugs.python.org (Matt Hickford)
Date: Sun, 27 Sep 2015 20:24:54 +0000
Subject: [New-bugs-announce] [issue25250] AttributeError: 'MSVCCompiler'
 object has no attribute '_MSVCCompiler__version'
Message-ID: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>


New submission from Matt Hickford:

Hi distutils. I wrote a setup.py that conditions on compiler type, following the guide at [1]. I needed to add an extra include when the compiler is an msvc version older than 9.0 (infamously missing stdint.h [2])

Anyway the code I wrote to do this was:

if self.compiler.compiler_type == "msvc" and int(self.compiler._MSVCCompiler__version) <= 9:

Which worked fine on all Python versions (tested 2.7 through 3.4) UNTIL the recent release of Python 3.5. On Python 3.5 I get the error:

AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'

Oh no. My fault I suppose for relying on a private variable. Can you suggest a more reliable way to test "compiler is msvc <= 9.0"? The test should be compatible all Python versions 2.7 through 3.5 so it can safely go in a setup.py

Can you help?

[1] http://stackoverflow.com/a/5192738/284795
[2] https://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio

----------
components: Distutils
messages: 251724
nosy: Matt.Hickford, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 28 00:17:44 2015
From: report at bugs.python.org (Matt Hickford)
Date: Sun, 27 Sep 2015 22:17:44 +0000
Subject: [New-bugs-announce] [issue25251] Unknown MS Compiler version 1900
Message-ID: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>


New submission from Matt Hickford:

Hi distutils. I previously used compiler=mingw32 with success. Today I installed Visual Studio 2015. Now compiler=mingw32 gives me an error

File "c:\python35\lib\distutils\cygwinccompiler.py", line 86, in get_msvcr
    raise ValueError("Unknown MS Compiler version %s " % msc_ver)
ValueError: Unknown MS Compiler version 1900

Any ideas? I don't understand why what msvc I have installed affects build with mingw32

----------
components: Distutils
messages: 251730
nosy: Matt.Hickford, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Unknown MS Compiler version 1900
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 28 00:34:35 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 27 Sep 2015 22:34:35 +0000
Subject: [New-bugs-announce] [issue25252] Hard-coded line ending in
 asyncio.streams.StreamReader.readline
Message-ID: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

A group of us (all added as nosy) spent part of the day working on issue 25008 (write an smtpd with asyncio).

We came across some code that contained a copy of StreamReader.readline, but it used b'\r\n' instead of b'\n' for a line ending character. In StreamReader.readline, '\n' is hard coded.

I'd like to propose that the line ending be passed in to readline, with a default of b'\n', and that multi-byte line ending sequences be explicitly supported.

Further, I'm hoping we can treat this as a bug and not a feature request, so that it can go in to 3.4 and 3.5. Adding a default parameter will be backward compatible.

----------
components: asyncio
messages: 251732
nosy: akuchling, barry, eric.smith, gvanrossum, haypo, jason.coombs, r.david.murray, yselivanov
priority: normal
severity: normal
status: open
title: Hard-coded line ending in asyncio.streams.StreamReader.readline
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 28 04:26:34 2015
From: report at bugs.python.org (Tony)
Date: Mon, 28 Sep 2015 02:26:34 +0000
Subject: [New-bugs-announce] [issue25253] AttributeError: 'Weather' object
	has no attribute 'dom'
Message-ID: <1443407194.23.0.284487454334.issue25253@psf.upfronthosting.co.za>


New submission from Tony:

The source code for ctw (CurseTheWeather) can be found here: https://github.com/tdy/ctw

Running `ctw USCA0987` or `ctw --nometric USCA0987` (happens regardless of location) results in an attribute error with Python 3.4.3. Running `ctw` by itself does print a *Welcome to "Curse the Weather" Version 0.6* message.

Traceback (most recent call last):
  File "/usr/bin/ctw", line 378, in 
    curses.wrapper(main)
  File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
    return func(stdscr, *args, **kwds)
  File "/usr/bin/ctw", line 283, in main
    update(stdscr)
  File "/usr/bin/ctw", line 250, in update
    weather = weatherfeed.Weather(location, metric)
  File "/usr/lib/python3.4/weatherfeed.py", line 40, in __init__
    self.dom = parseString(self._getData())
  File "/usr/lib/python3.4/xml/dom/minidom.py", line 1970, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib/python3.4/xml/dom/expatbuilder.py", line 925, in parseString
    return builder.parseString(string)
  File "/usr/lib/python3.4/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 64, column 26
Exception ignored in: >
Traceback (most recent call last):
  File "/usr/lib/python3.4/weatherfeed.py", line 44, in __del__
    self.dom.unlink()
AttributeError: 'Weather' object has no attribute 'dom'

I did notice the API URL in weatherfeed.py gives a Bad Request error for:

urlHandle = urllib.request.urlopen('http://xoap.weather.com/weather/local/%s?cc=1&dayf=5&prod=xoap&link=xoap&unit=%s&par=1003666583&key=4128909340a9b2fc'

I also noticed the weather.com API now redirects to wunderground.com so I registered a new API and updated the URL in weatherfeed.py only to still get the same AttributeError. 

The new API is something like http://api.wunderground.com/api/APIKEY/conditions/q/CA/San_Francisco.json

----------
components: Library (Lib), XML
messages: 251742
nosy: tc
priority: normal
severity: normal
status: open
title: AttributeError: 'Weather' object has no attribute 'dom'
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 28 05:16:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Sep 2015 03:16:01 +0000
Subject: [New-bugs-announce] [issue25254] Idle: debugger source line
	highlighting fails again
Message-ID: <1443410161.14.0.45288371975.issue25254@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Re-occurrence of #14146. On that issue, msg225380, 2014-08-15, I said "Debugger source line highlighting works fine." I am really sure it was true when I posted previously, 2013-05-29.  In 3.4.3, Feb 24 2015, it is not working.  Ditto for 2.7.10 and 3.5.0, released subsequently, and repository versions of 2.7 and 3.4,  The problem is not the fix in #14146, which I tested separately before replacing it in #24972.

----------
components: IDLE
messages: 251746
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: debugger source line highlighting fails again
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/issue25254>
_______________________________________

From report at bugs.python.org  Mon Sep 28 10:05:18 2015
From: report at bugs.python.org (phelix bitcoin)
Date: Mon, 28 Sep 2015 08:05:18 +0000
Subject: [New-bugs-announce] [issue25255] Security of CPython Builds
Message-ID: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>


New submission from phelix bitcoin:

A description of the build and release process for CPython binaries (e.g. for Windows) would be great. Maybe I am missing something? I could not find any information other than the 14 years old PEP 101 which says: "Notify the experts that they can start building binaries." 

E.g. how is it ensured there are no backdoors in the binaries?

Background: For the Namecoin project we are currently discussing the potential necessity of reproducible builds.

----------
assignee: docs at python
components: Build, Devguide, Documentation, Windows
messages: 251753
nosy: docs at python, ezio.melotti, paul.moore, phelix bitcoin, steve.dower, tim.golden, willingc, zach.ware
priority: normal
severity: normal
status: open
title: Security of CPython Builds
type: enhancement

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

From report at bugs.python.org  Mon Sep 28 15:15:00 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 13:15:00 +0000
Subject: [New-bugs-announce] [issue25256] Add sys.is_debug_build() public
 function to check if Python was compiled in debug mode
Message-ID: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds the sys.is_debug_build() public function and replaces hasattr(sys, xxx) tests to check for debug mode with sys.is_debug_build().

+.. function:: is_debug_build()
+
+   Return :const:`True` if the Python executable was compiled in debug mode,
+   return :const:`False` if it was compiled in release mode.
+
+   The debug mode is enabled with ``#define Py_DEBUG``, or with
+   ``./configure --with-pydebug``.
+
+   .. versionadded:: 3.6

I would like to add an obvious way to check if Python was compiled in debug mode, instead of having hacks/tips to check it.

For example, 3 different checks are proposed on StackOverflow and only one looks portable:

http://stackoverflow.com/questions/646518/python-how-to-detect-debug-interpreter

I don't think that we need to mark the function as an implementation detail or specific to CPython. Other implementations of Python would probably benefit from such flag. If they don't care, they can simply return False.

Alternative: Add a new sys.implementation.debug_build flag.

Note: I chose the "is_debug_build" name using the existing sysconfig.is_python_build(). There is a sys.flags.debug flag, so "is_debug()" can be confusing. I prefer to attach the "build" suffix.

----------
components: Library (Lib)
files: is_debug_build.patch
keywords: patch
messages: 251765
nosy: haypo
priority: normal
severity: normal
status: open
title: Add sys.is_debug_build() public function to check if Python was compiled in debug mode
versions: Python 3.6
Added file: http://bugs.python.org/file40610/is_debug_build.patch

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

From report at bugs.python.org  Mon Sep 28 20:19:52 2015
From: report at bugs.python.org (Bob Hossley)
Date: Mon, 28 Sep 2015 18:19:52 +0000
Subject: [New-bugs-announce] [issue25257] In subject line email library
 inserts unwanted space after a thousands comma in a number
Message-ID: <1443464392.64.0.380133301442.issue25257@psf.upfronthosting.co.za>


New submission from Bob Hossley:

In my function makeMsg(), there is:

    msg = email.mime.nonmultipart.MIMENonMultipart('text',
        'plain', charset='utf-8')
    msg['Subject'] = email.header.Header(subject, 'utf-8')

subject has no space after the thousands comma:

u'1,010 words - "The Blackmail Caucus, a.k.a. the Republican Party" By Paul Krugman'


But

msg['Subject'].__str__()

'1, 010 words - "The Blackmail Caucus,\n a.k.a. the Republican Party" By Paul Krugman'

has a space after the thousands comma and the email message later generated has a space after the thousands comma.

This is objectionable.

Note that the email library also inserts a newline after the comma that is followed by a space.  Since I see no effect of this newline on the email generated, I have no objection to the newline.

----------
components: email
messages: 251782
nosy: SegundoBob, barry, r.david.murray
priority: normal
severity: normal
status: open
title: In subject line email library inserts unwanted space after a thousands comma in a number
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 28 21:26:34 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Mon, 28 Sep 2015 19:26:34 +0000
Subject: [New-bugs-announce] [issue25258] HtmlParser doesn't handle void
	element tags correctly
Message-ID: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>


New submission from Chenyun Yang:

For void elements such as (<link>, <img>), there doesn't need to have xhtml empty end tag. HtmlParser which relies on the XHTML empty end syntax failed to handle this situation. 

from HTMLParser import HTMLParser

# create a subclass and override the handler methods
class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print "Encountered a start tag:", tag
    def handle_endtag(self, tag):
        print "Encountered an end tag :", tag
    def handle_data(self, data):
        print "Encountered some data  :", data

>>> parser.feed('<link rel="import"><img src="som">')
Encountered a start tag: link
Encountered a start tag: img
>>> parser.feed('<link rel="import"/><img src="som"/>')
Encountered a start tag: link
Encountered an end tag : link
Encountered a start tag: img
Encountered an end tag : img


Reference:
https://github.com/python/cpython/blob/bdfb14c688b873567d179881fc5bb67363a6074c/Lib/html/parser.py
http://www.w3.org/TR/html5/syntax.html#void-elements

----------
components: Library (Lib)
messages: 251792
nosy: Chenyun Yang
priority: normal
severity: normal
status: open
title: HtmlParser doesn't handle void element tags correctly
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 28 22:53:09 2015
From: report at bugs.python.org (Tim Chase)
Date: Mon, 28 Sep 2015 20:53:09 +0000
Subject: [New-bugs-announce] [issue25259] readline macros can segfault Python
Message-ID: <1443473589.61.0.823349470149.issue25259@psf.upfronthosting.co.za>


New submission from Tim Chase:

Attempting to use a readline macro (use "C-x (" to start recording, "C-x )" to stop recording, and "C-x e" to playback) with more than one newline in it will cause a segfault.  The behavior also presents in the [`rlwrap` tool](https://github.com/hanslub42/rlwrap/issues/36) but not in `bash`.  I've tested and reproduced with Python 2.[4-6] and 3.4, but I don't see any similar bug-reports that would suggest that the problem doesn't also exist in all 3.x series releases.  To reproduce, in a `readline`-enabled Python:

    $ python
    ?
    >>> import cmd
    >>> cmd.Cmd().cmdloop()  
    (Cmd) # do "C-x ( <NL> <NL> C-x ) C-x e" and it segfaults

The author of `rlwrap` is working to create a minimum working example, and I'm not sure whether this is a problem with the underlying `libreadline` or just how it's being used by `rlwrap` and Python.

----------
components: Library (Lib)
messages: 251800
nosy: gumnos
priority: normal
severity: normal
status: open
title: readline macros can segfault Python
type: crash
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/issue25259>
_______________________________________

From report at bugs.python.org  Tue Sep 29 00:20:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 22:20:02 +0000
Subject: [New-bugs-announce] [issue25260] python -m test --coverage doesn't
	work on Windows
Message-ID: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"python -m test --coverage" doesn't work on Windows because the tracer ignores the root directory of Python source code.

The code works on Linux because sys.base_prefix and sys.base_exec_prefix don't point to the Python source code, but to /usr/local.

I'm not sure why sys.base_prefix and sys.base_exec_prefix are ignored.

----------
components: Tests, Windows
messages: 251804
nosy: haypo, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python -m test --coverage doesn't work on Windows
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 29 06:05:54 2015
From: report at bugs.python.org (Sreenivasulu Saya)
Date: Tue, 29 Sep 2015 04:05:54 +0000
Subject: [New-bugs-announce] [issue25261] Incorrect Return Values for any()
 and all() Built-in Functions
Message-ID: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>


New submission from Sreenivasulu Saya:

The results displayed by the any() and all() is incorrect (differs from what is documented and what makes sense).

Here is the code:
-----------------
multiples_of_6 = (not (i % 6) for i in range(1, 10))

print("List: ", list(multiples_of_6 ), "\nAny: ", any(multiples_of_6),
        "\nAll: ", all(multiples_of_6))
---------------

The distribution in use is:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32

Here is the output on Windows7:
-------------------------------
List:  [False, False, False, False, False, True, False, False, False]
Any:  False    <<<<< This should be True
All:  True     <<<<< This should be False

----------
components: Build
messages: 251816
nosy: Sreenivasulu Saya
priority: normal
severity: normal
status: open
title: Incorrect Return Values for any() and all() Built-in Functions
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 29 08:14:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 06:14:22 +0000
Subject: [New-bugs-announce] [issue25262] Issues with BINUNICODE8 and
	BINBYTES8 opcodes in pickle
Message-ID: <1443507262.81.0.140687476176.issue25262@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are issues with BINUNICODE8 and BINBYTES8 opcodes in pickle.

1. Unpickling BINBYTES8 is not implemented in Python implementation.

2. Highest 32 bits of 64-bit size are silently ignored in C implementation on 32-bit platforms.

3. There are no tests for BINUNICODE8 and BINBYTES8.

Proposed patch fixes these issues.

----------
assignee: serhiy.storchaka
components: Extension Modules, Library (Lib), Tests
files: pickle_binbytes8.patch
keywords: patch
messages: 251823
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40615/pickle_binbytes8.patch

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

From report at bugs.python.org  Tue Sep 29 09:54:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 07:54:14 +0000
Subject: [New-bugs-announce] [issue25263] test_tkinter fails randomly on the
 buildbots "AMD64 Windows10" (3.4, 3.5, 3.x)
Message-ID: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

======================================================================
ERROR: setUpClass (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_font.py", line 17, in setUpClass
    cls.font = font.Font(root=cls.root, name=fontname, exists=True)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\font.py", line 71, in __init__
    root = tkinter._default_root
AttributeError: module 'tkinter' has no attribute '_default_root'

======================================================================
ERROR: test_use (tkinter.test.test_tkinter.test_widgets.ToplevelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 95, in test_use
    widget2 = self.create(use=wid)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 70, in create
    return tkinter.Toplevel(self.root, **kwargs)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\__init__.py", line 2181, in __init__
    BaseWidget.__init__(self, master, 'toplevel', cnf, {}, extra)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\__init__.py", line 2138, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: integer value too large to represent

----------
messages: 251827
nosy: haypo
priority: normal
severity: normal
status: open
title: test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x)
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 29 10:01:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 08:01:48 +0000
Subject: [New-bugs-announce] [issue25264] test_marshal always crashs on
 "AMD64 Windows10 2.7" buildbot
Message-ID: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_marshal crash on Windows AMD64 since the first build of the "AMD64 Windows10 2.7" buildbot:

http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/1/steps/test/logs/stdio

It crashs since this build of the "AMD64 Windows8 2.7" buildbot:

http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/368/steps/test/logs/stdio

Blamelist:

    Change #43682
    Category 	None
    Changed by 	Zachary Ware <zachary.ware at gmail.com>
    Changed at 	Thu 16 Jul 2015 05:42:04
    Branch 	2.7
    Revision 	ca78b9449e040abf313659ea00ddcb6b20a68830
    Comments

    Close #24508: Backport the 3.5 MSBuild project files.

    The old project files move to PC/VS9.0 and remain supported.

    VS2008 is still required to build 2.7; VS2010 (or later, plus Windows SDK 7.1)
    is *also* required to use the new project files.

Between builds 367 and 368, the number of warnings doubled: 404 warnings => 796 warnings.


Recent build:

http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/76/steps/test/logs/stdio

...
[ 53/401] test_marshal
program finished with exit code -1073741571

----------
components: Tests, Windows
messages: 251828
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_marshal always crashs on "AMD64 Windows10 2.7" buildbot
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 29 12:00:24 2015
From: report at bugs.python.org (Rahil Khurshid)
Date: Tue, 29 Sep 2015 10:00:24 +0000
Subject: [New-bugs-announce] [issue25265] Python install failed windows 8.1-
 Error 0x80240017: Failed to execute MSU package
Message-ID: <1443520824.73.0.137010188648.issue25265@psf.upfronthosting.co.za>


New submission from Rahil Khurshid:

Just downloaded and try to install the Python 3.5.0 .exe installer on Windows 8.1 Pro, which unexpectedly failed to install and crash on this error
Error 0x80240017: Failed to execute MSU package (according to the logs)
Then tried the older 3.4.3 .msi installer which worked for me. My guess it's about the new .exe installer.

----------
components: Installation, Windows
messages: 251838
nosy: Rahil Khurshid, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python install failed windows 8.1- Error 0x80240017: Failed to execute MSU package
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 29 13:21:01 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 29 Sep 2015 11:21:01 +0000
Subject: [New-bugs-announce] [issue25266] mako benchmark not working in
	Python 3.6
Message-ID: <1443525661.77.0.371661807917.issue25266@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 deprecates the mako benchmark for Python 3.6 and above. The mako benchmark uses inspect.getargspec(), which is deprecated and was removed in Python 3.6. Therefore, it crashes with the message "AttributeError: module 'inspect' has no attribute 'getargspec'" when using the latest version of Python on the default branch.

The patch limits the version range of the mako benchmark to Python 3.5 and below.

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy mako_deprecation.patch to the current directory
hg import --no-commit mako_deprecation.patch
 
Regards,
Florin

----------
components: Benchmarks
files: mako_deprecation.patch
keywords: patch
messages: 251844
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: mako benchmark not working in Python 3.6
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file40618/mako_deprecation.patch

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

From report at bugs.python.org  Tue Sep 29 13:30:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 11:30:34 +0000
Subject: [New-bugs-announce] [issue25267] Optimize UTF-8 encoder with error
	handlers
Message-ID: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch optimizes the UTF-8 encoder for error handlers: ignore, replace, surrogateescape, surrogatepass. It is based on the patch  faster_surrogates_hadling.patch written by Serhiy Storchaka in the issue #24870.

It also modifies unicode_encode_ucs1() to use memset() for the replace error handler. It should be faster for long sequences of unencodable characters, but it may be slower for short sequences of unencodable characters.

The patch adds new unit tests and fix unit tests to ensure that utf-8-sig codec is also well tested.

TODO: write a benchmark.

See also the issue #25227 which optimized ASCII and latin1 encoders with the surrogateescape error handlers.

----------
components: Unicode
files: utf8_encoder_errors.patch
keywords: patch
messages: 251845
nosy: ezio.melotti, haypo, naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize UTF-8 encoder with error handlers
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40619/utf8_encoder_errors.patch

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

From report at bugs.python.org  Tue Sep 29 14:45:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Sep 2015 12:45:32 +0000
Subject: [New-bugs-announce] [issue25268] Support pointing frozen modules to
 the corresponding source files, if available.
Message-ID: <1443530732.6.0.47195880813.issue25268@psf.upfronthosting.co.za>


New submission from Eric Snow:

(a generalization of issue #21335)

One way or another, we should be able to record the appropriate path in the resulting data when a module is frozen.  Keeping track of the source location is useful when debugging, especially with tracebacks.  Also see a related conversation on python-dev. [1]

If the original filename for a frozen module is preserved, several possibilities open up:

* the `get_source` method of `importlib._bootstrap.FrozenImporter` could return the original source
* the traceback module could work around the co_filename issue pointed out in #21335
* the filename could be incorporated into the value set for co_filename and __file__
* frozen modules could be optionally reloaded from source

Given that the filename would (likely) be available only through loading the module, it *might* not make sense to store it on the module's spec.  However, it might also make sense to store the filename in a way that it can be exposed during the "find" stage of import.  In that case it would arguably *belong* on the module's spec.

Note that there's a chance that the original filename for a frozen module is no longer available.  That shouldn't be much of a problem, though.


[1] https://mail.python.org/pipermail/python-dev/2014-April/134097.html

----------
components: Library (Lib)
messages: 251851
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Support pointing frozen modules to the corresponding source files, if available.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 29 14:48:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Sep 2015 12:48:03 +0000
Subject: [New-bugs-announce] [issue25269] Add method to detect if a string
	contains surrogates
Message-ID: <1443530883.35.0.305082154526.issue25269@psf.upfronthosting.co.za>


New submission from R. David Murray:

Because surrogates are in several contexts used to "smuggle" bytes through string APIs using surrogateescape, it is very useful to be able to determine if a given string contains surrogates.  The email package, for example, uses different logic to handle strings that contain smuggled bytes and strings that don't when serializing a Message object.  Currently it uses x.encode() and checks for an exception (we determined that for CPython this was the most efficient method to check).  It would be better, I think, to have a dedicated method on str for this, among other reasons so that different python implementations could optimize it appropriately.

(Note that another aspect of dealing with surrogateescaped strings is discussed in issue 18814.)

----------
components: Interpreter Core
messages: 251853
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Add method to detect if a string contains surrogates
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 29 18:05:58 2015
From: report at bugs.python.org (Paul Kehrer)
Date: Tue, 29 Sep 2015 16:05:58 +0000
Subject: [New-bugs-announce] [issue25270] codecs.escape_encode systemerror
	on empty byte string
Message-ID: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>


New submission from Paul Kehrer:

Python 3.5.0 (default, Sep 13 2015, 10:33:07) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> codecs.escape_encode(b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/bytesobject.c:3553: bad argument to internal function


I've tested this on Python 3.2 through 3.5.

----------
components: Interpreter Core
messages: 251868
nosy: reaperhulk
priority: normal
severity: normal
status: open
title: codecs.escape_encode systemerror on empty byte string
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Sep 29 18:23:20 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 29 Sep 2015 16:23:20 +0000
Subject: [New-bugs-announce] [issue25271] SystemError when doing
	codecs.escape_encode(b'')
Message-ID: <1443543800.33.0.489853899894.issue25271@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

I can reproduce this with 3.4.3 and 3.5.0:

>>> import codecs
>>> codecs.escape_encode(b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/bytesobject.c:3553: bad argument to internal function

----------
components: Interpreter Core
messages: 251869
nosy: The Compiler, doerwalter, lemburg
priority: normal
severity: normal
status: open
title: SystemError when doing codecs.escape_encode(b'')
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Sep 29 20:59:11 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2015 18:59:11 +0000
Subject: [New-bugs-announce] [issue25272] asyncio tests are getting noisy
Message-ID: <1443553151.38.0.791479091232.issue25272@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

In 3.5 and up the asyncio test are pretty chatty with warnings. E.g. a recent run gave me this in 3.5:

./python.exe -m test.test_asyncio
.........................................................................................................../Users/guido/src/cpython/Lib/asyncio/selector_events.py:574: ResourceWarning: unclosed transport <_SelectorSslTransport closing fd=27>
  warnings.warn("unclosed transport %r" % self, ResourceWarning)
Task was destroyed but it is pending!
task: <Task pending coro=<BaseSelectorEventLoop._accept_connection2() done, defined at /Users/guido/src/cpython/Lib/asyncio/selector_events.py:192> wait_for=<Future pending cb=[Task._wakeup()]>>
.........................................................................Task was destroyed but it is pending!
task: <Task pending coro=<BaseSelectorEventLoop._accept_connection2() running at /Users/guido/src/cpython/Lib/asyncio/selector_events.py:227> wait_for=<Future finished exception=RuntimeError('Event loop is closed',)>>
/Users/guido/src/cpython/Lib/asyncio/selector_events.py:574: ResourceWarning: unclosed transport <_SelectorSocketTransport closing fd=26>
  warnings.warn("unclosed transport %r" % self, ResourceWarning)
...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................returning true from eof_received() has no effect when using ssl
...returning true from eof_received() has no effect when using ssl
...................................................................................................................................................................................................................................................................ss
----------------------------------------------------------------------
Ran 939 tests in 25.032s

OK (skipped=2)

----------
components: asyncio
messages: 251875
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio tests are getting noisy
type: resource usage
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 29 21:33:40 2015
From: report at bugs.python.org (Vladislav Ignatenko)
Date: Tue, 29 Sep 2015 19:33:40 +0000
Subject: [New-bugs-announce] [issue25273] Console interpreter holds a hard
 link on last displayed object
Message-ID: <1443555220.63.0.97010949652.issue25273@psf.upfronthosting.co.za>


Changes by Vladislav Ignatenko <GPCracker at mail.ru>:


----------
components: Interpreter Core
nosy: GPCracker
priority: normal
severity: normal
status: open
title: Console interpreter holds a hard link on last displayed object
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 30 01:45:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 23:45:48 +0000
Subject: [New-bugs-announce] [issue25274] "./python -m test -R 3:3:
 test_sys": Fatal Python error: Cannot recover from stack overflow
Message-ID: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>


New submission from STINNER Victor:

haypo at selma$ ./python -m test -R 3:3: test_sys 
[1/1] test_sys
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007f1921854700 (most recent call first):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 176 in handle
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 727 in assertRaises
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 215 in test_recursionlimit_recovery
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600 in run
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1674 in run
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 1098 in test_main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 165 in runtest_inner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 129 in runtest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 60 in runtest_ns
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 271 in run_test
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 293 in run_tests_sequential
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 336 in run_tests
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 367 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 405 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 427 in main_in_temp_cwd
  File "/home/haypo/prog/python/default/Lib/test/__main__.py", line 3 in <module>
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 85 in _run_code
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 170 in _run_module_as_main
Fatal Python error: Aborted

Current thread 0x00007f1921854700 (most recent call first):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 176 in handle
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 727 in assertRaises
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 215 in test_recursionlimit_recovery
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600 in run
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1674 in run
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 1098 in test_main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 165 in runtest_inner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 129 in runtest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 60 in runtest_ns
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 271 in run_test
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 293 in run_tests_sequential
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 336 in run_tests
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 367 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 405 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 427 in main_in_temp_cwd
  File "/home/haypo/prog/python/default/Lib/test/__main__.py", line 3 in <module>
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 85 in _run_code
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 170 in _run_module_as_main
Abandon (core dumped)

----------
messages: 251897
nosy: haypo
priority: normal
severity: normal
status: open
title: "./python -m test -R 3:3: test_sys": Fatal Python error: Cannot recover from stack overflow
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 30 07:19:45 2015
From: report at bugs.python.org (Shreevatsa R)
Date: Wed, 30 Sep 2015 05:19:45 +0000
Subject: [New-bugs-announce] [issue25275] Documentation v/s behaviour
 mismatch wrt integer literals containing non-ASCII characters
Message-ID: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>


New submission from Shreevatsa R:

Summary: This is about int(u'????') == 1234.

At https://docs.python.org/2/library/functions.html and also https://docs.python.org/3/library/functions.html the documentation for 

     class int(x=0)
     class int(x, base=10)

says (respectively):

> If x is not a number or if base is given, then x must be a string or Unicode object representing an integer literal in radix base.

> If x is not a number or if base is given, then x must be a string, bytes, or bytearray instance representing an integer literal in radix base.

If you follow the definition of "integer literal" into the reference (https://docs.python.org/2/reference/lexical_analysis.html#integers and https://docs.python.org/3/reference/lexical_analysis.html#integers respectively), the definitions ultimately involve

     nonzerodigit   ::=  "1"..."9"
     octdigit       ::=  "0"..."7"
     bindigit       ::=  "0" | "1"
     digit          ::=  "0"..."9"

So it looks like whether the behaviour of int() conforms to its documentation hinges on what "representing" means. Apparently it is some definition under which u'????' represents the integer literal 1234, but it would be great to either clarify the documentation of int() or change its behaviour.

----------
assignee: docs at python
components: Documentation, Interpreter Core, Unicode
messages: 251915
nosy: docs at python, ezio.melotti, haypo, shreevatsa
priority: normal
severity: normal
status: open
title: Documentation v/s behaviour mismatch wrt integer literals containing non-ASCII characters

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

From report at bugs.python.org  Wed Sep 30 11:26:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 09:26:05 +0000
Subject: [New-bugs-announce] [issue25276] test_decimal sometimes crash on
	PPC64 AIX 3.x
Message-ID: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>


New submission from STINNER Victor:

This buildbot has low free memory. Maybe some part of _decimal doesn't handle an allocation failure?

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4173/steps/test/logs/stdio

...
[307/399/10] test_decimal
Fatal Python error: Segmentation fault

Current thread 0x00000001 (most recent call first):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 444 in eval_equation
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 321 in eval_line
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 299 in eval_file
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 5591 in <lambda>
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 600 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 648 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/runner.py", line 176 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 5598 in test_main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 113 in runtest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 292 in run_tests_sequential
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 334 in run_tests
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 365 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 407 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 429 in main_in_temp_cwd
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 85 in _run_code
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Segmentation fault (core dumped)

----------
messages: 251919
nosy: haypo
priority: normal
severity: normal
status: open
title: test_decimal sometimes crash on PPC64 AIX 3.x
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 30 11:32:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 09:32:48 +0000
Subject: [New-bugs-announce] [issue25277] test_eintr hangs on randomly on
	"AMD64 FreeBSD 9.x 3.x"
Message-ID: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Too bad, the test test_eintr hangs sometimes on "AMD64 FreeBSD 9.x 3.x".

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

[397/399] test_traceback -- running: test_eintr (254 sec), test_subprocess (62 sec)
[398/399] test_subprocess (71 sec) -- running: test_eintr (264 sec)
running: test_eintr (324 sec)
running: test_eintr (384 sec)
running: test_eintr (444 sec)
running: test_eintr (504 sec)
...

running: test_eintr (3505 sec)
running: test_eintr (3565 sec)
[399/399] test_eintr
Timeout (1:00:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/selectors.py", line 375 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1698 in _communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1068 in communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 86 in run_python_until_end
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 96 in _assert_python
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 135 in assert_python_ok
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_eintr.py", line 19 in test_all
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 159 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 113 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_slave
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 357 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 407 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 429 in main_in_temp_cwd
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 39 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 429, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 407, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 365, in main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 332, in run_tests
    run_tests_multiprocess(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 210, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_eintr: Exit code 1
*** [buildbottest] Error code 1

----------
messages: 251920
nosy: haypo
priority: normal
severity: normal
status: open
title: test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x"
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 30 15:20:44 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 13:20:44 +0000
Subject: [New-bugs-announce] [issue25278] Unexpected socket exception on
	SFTP 'STOR' command
Message-ID: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>


New submission from Blanquier:

With Filezilla Server 0.9.53, SFTP activated (force SSL on login, allow explicit FTP over TLS). From the FTP client point of view: when I use ftp_id.storbinary( 'STOR file_name'...), a socket.error exception arrive sometime. It's a socket.error exception and the errno record value is 0 (zero). The full message is b'[Errno 0] Error'. If I want to obtain the real server answer, I MUST call ftp_id.getresp().
It looks like a desynchronisation between the command and the answer.

Could you correct it please ?

Best regards.

----------
components: Library (Lib)
messages: 251933
nosy: blanquier
priority: normal
severity: normal
status: open
title: Unexpected socket exception on SFTP 'STOR' command
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 30 15:26:33 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 13:26:33 +0000
Subject: [New-bugs-announce] [issue25279] Unexpected ftplib.error_xxx
 exception on SFTP 'STOR' command
Message-ID: <1443619593.75.0.232169259081.issue25279@psf.upfronthosting.co.za>


New submission from Blanquier:

activated (force SSL on login, allow explicit FTP over TLS). From the FTP client point of view: when I use ftp_id.storbinary( 'STOR file_name'...), a ftplib.error_xxx exception arrive someting. 

On the windows server:
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Handle.exe
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Handle.exe"
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 550 can't access file.
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> TYPE I
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> 200 Type set to I
(000336)30/09/2015 08:57:59 - nemo_pyc (135.238.179.15)>  ?3DG?}
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 'Y'jQ?~.
?0??? ?3DG?~
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> ???!x?d???A?:?\ ?3DG?
...

could you fix the bug please ?
Best regards,

----------
components: Library (Lib)
messages: 251934
nosy: blanquier
priority: normal
severity: normal
status: open
title: Unexpected ftplib.error_xxx exception on SFTP 'STOR' command
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 30 15:32:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 13:32:17 +0000
Subject: [New-bugs-announce] [issue25280] Message can be formatted twice in
	importlib
Message-ID: <1443619937.76.0.139042721481.issue25280@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In importlib a verbose message can be formatted twice, the first time before passing it to _verbose_message(), and the second time in _verbose_message(), Example:

$ python -v
...
>>> open('{0}.pyc', 'wb').close()
>>> __import__('{0}')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
  File "<frozen importlib._bootstrap_external>", line 869, in get_code
  File "<frozen importlib._bootstrap_external>", line 440, in _validate_bytecode_header
  File "<frozen importlib._bootstrap_external>", line 368, in _verbose_message
IndexError: tuple index out of range

Proposed patch fixes the issue.

----------
components: Library (Lib)
files: importlib_format_verbose_message.patch
keywords: patch
messages: 251937
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Message can be formatted twice in importlib
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40626/importlib_format_verbose_message.patch

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

From report at bugs.python.org  Wed Sep 30 16:48:44 2015
From: report at bugs.python.org (Vitaly Belman)
Date: Wed, 30 Sep 2015 14:48:44 +0000
Subject: [New-bugs-announce] [issue25281] Incorrect enum behavior during
	json.dumps serialization
Message-ID: <1443624524.13.0.988046915141.issue25281@psf.upfronthosting.co.za>


New submission from Vitaly Belman:

Possibly related to: http://bugs.python.org/issue18264


The following code:

>>> import IntEnum from enum
>>> from enum import IntEnum
>>> class a(IntEnum): a=0
>>> json.loads(json.dumps({"x": a.a}))

Produces:

ValueError: No JSON object could be decoded

Which makes sense because the json dumps function produces is: {"x": a.a}

----------
messages: 251945
nosy: Vitaly Belman
priority: normal
severity: normal
status: open
title: Incorrect enum behavior during json.dumps serialization
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 30 17:47:13 2015
From: report at bugs.python.org (Sworddragon)
Date: Wed, 30 Sep 2015 15:47:13 +0000
Subject: [New-bugs-announce] [issue25282] Support for recursive patterns
Message-ID: <1443628033.35.0.583237537087.issue25282@psf.upfronthosting.co.za>


New submission from Sworddragon:

It seems Python's own regular expressions aren't able of handling nested structures so maybe this can be enhanced like it is done with PCRE's recursive patterns.

----------
components: Library (Lib)
messages: 251951
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Support for recursive patterns
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 30 18:53:39 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Sep 2015 16:53:39 +0000
Subject: [New-bugs-announce] [issue25283] Make tm_gmtoff and tm_zone
	available on all platforms
Message-ID: <1443632019.41.0.93426740001.issue25283@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

See datetime-sig thread [1] for details.

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

----------
assignee: belopolsky
messages: 251954
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Make tm_gmtoff and tm_zone available on all platforms
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 30 22:33:57 2015
From: report at bugs.python.org (Yaroslav Admin)
Date: Wed, 30 Sep 2015 20:33:57 +0000
Subject: [New-bugs-announce] [issue25284] Docs for
 BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
Message-ID: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>


New submission from Yaroslav Admin:

Parameter for BaseEventLoop.run_in_executor(executor, callback, *args) was renamed from callback to func in 3.5.0 release, but it's not reflected in the docs.

Commit with change: https://github.com/python/cpython/commit/111610562141a46f1eaac64d497d79fe13290847#diff-08afa52ab2b1511bee8527814ad44d80L468
Documentation: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.run_in_executor

----------
components: asyncio
messages: 251961
nosy: Yaroslav Admin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 30 22:36:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 20:36:02 +0000
Subject: [New-bugs-announce] [issue25285] regrtest: run tests in
	subprocesses with -j1 on buildbots
Message-ID: <1443645362.81.0.234212686686.issue25285@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, regrtest ignores the -j1 parameter. For -jN, the multiprocess mode is only enabled for N != 1. I propose to modify regrtest to run tests in subprocesses when -j1 is used. It would solve the issue #18906.

I also want to run tests in subprocesses in buildbot to better isolate tests. Running all tests in the same process, sequentially, cause various issues:

* various kinds of side effects
* memory leaks
* random failures (unreliable tests)

"make buildbot" already runs regrtest with -j1. I propose to also modify Tools/buildbot/test.bat to use run tests with -j1 by default on Windows.

I fixed regrtest to setup tests using the same code for classic mode and multiprocess mode: slaves (child processes running tests for regrtest -jN) now inherit
--memlimit/-M, --threshold/-t and --nowindows/-n options.

Only 3 remaining functions are incompatible with -jN: --coverage/-T and --findleaks/-l.

Finally, the multiprocess mode of regrtest now displays the duration of tests which took longer than 30 seconds, and every minute, it displays the tests running since longer than 30 seconds. Example with multiple workers (-j4):
---
...
[395/399/1] test_mimetypes -- running: test_lzma (111 sec), test_multiprocessing_forkserver (224 sec)
[396/399/1] test_poplib -- running: test_lzma (111 sec), test_multiprocessing_forkserver (225 sec)
[397/399/1] test_lzma (111 sec) -- running: test_multiprocessing_forkserver (225 sec)
[398/399/1] test_range -- running: test_multiprocessing_forkserver (227 sec)
running: test_multiprocessing_forkserver (287 sec)
[399/399/1] test_multiprocessing_forkserver (340 sec)
378 tests OK.
---

Note: "python -m test -j1 -j4" uses 4 workers, only the last -jN parameter is used. Some buildbots add -jN to use more workers.

----------
components: Tests
messages: 251962
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: run tests in subprocesses with -j1 on buildbots
versions: Python 3.6

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